说透敏捷
宋宁
IBM资深敏捷教练
立即订阅
4919 人已学习
课程目录
已完结 12 讲
开篇词 (1讲)
开篇词 | 重识敏捷,让你的研发管理少走一些弯路
免费
原理篇 (2讲)
01 | 灵魂拷问:如何利用敏捷思维更好地解决实际问题?
02 | 老生常谈:你真的知道敏捷到底是什么吗?
实战篇 (4讲)
03 | 评估诊断:成功迈出敏捷推进的第一步
04 | 团队试点(一):让你的敏捷实践“事半功倍”
05 | 团队试点(二):打造一支无往不胜的敏捷团队
06 | 规模化推广:复制粘贴试点的经验就够了吗?
策略篇 (2讲)
07 | 填坑指南:填好这4个坑,快速做对敏捷
08 | 避雷策略:如何防止你的敏捷变为“小瀑布”?
管理篇 (2讲)
09 | 内部教练:守护敏捷实践,求人不如求己
10 | 服务型领导:在敏捷中你该怎样提升自己的领导力?
结束语 (1讲)
结束语 | 用敏捷提升自己,从敏捷走向未来
说透敏捷
登录|注册

03 | 评估诊断:成功迈出敏捷推进的第一步

宋宁 2020-01-06
你好,我是宋宁。从今天这一讲起,我要给你讲一下具体怎么推进敏捷,并结合案例,通过四讲来介绍推进敏捷所涉及的评估诊断、团队敏捷试点、大规模推广这三大步骤。今天,我们先来看推进敏捷的第一步:评估诊断。
在我做咨询的过程中,一开始经常会碰到以下这些问题:
有很多人一头雾水,跑过来问我:“老师,我们现在准备开始做敏捷实践了,可是从哪里开始呢?敏捷那么多方法,我要先用哪个呢?”
还有的人说:“敏捷很好,因此我要制定标准,所有项目都要遵循这个标准。”
而有的人在敏捷面前踌躇不前:“敏捷对人的要求很高,我们现在不具备条件做敏捷,等条件成熟了再说吧。”
其实,无论是想做敏捷但不知道怎么选择敏捷方法,还是不管三七二十一直接套用成熟的敏捷实践,抑或以自己不具备条件为借口犹犹豫豫不敢做敏捷,这些问题反映的都是他们没有做前期的评估诊断,因此不了解自己的现状,不清楚自己的痛点,不知道从哪里下手去推进敏捷。
就像医生看病之前需要患者做各种相关检查,有了检查结果,医生才好对症下药;敏捷亦是如此。在我们决定推进敏捷前,第一步就要评估企业目前的整体情况是什么样的,它在文化、实践、工具等维度上,已经达到了什么程度?它有什么痛点亟待解决?只有把这个第一步做好,对自身的情况有个清晰的认识,我们才能针对自身的问题找到适合自己的敏捷方法。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《说透敏捷》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(7)

  • Aaron(健廷)
    启动敏捷前的诊断过程,就是ㄧ连串大量的个体交互过程,充分呼应了敏捷的第一条宣言
    2020-01-06
    2
  • 吴言乱语
    谈一个具体点的例子吧,因为公司的业务交付流程比较长,所以很多的业务需求是需要跨技术团队协作的,现象是我们这个团队的产品经理经常就被莫名其妙的拉进一个需求讨论群,负责跟我们对接的业务负责人会告知我们需要配合做什么样的功能。
    但我们产品经理的疑惑常常是:
    1.项目是哪个部门牵头的,牵头业务部门和技术团队是哪个
    2.各系统的对接人是谁
    3.技术对接方案如何确定
    4.项目排期如何确定
    5.测试方案和测试分工如何安排
    6.上线顺序如何确定
    在实施中,还经常遇到信息不回复和回复慢的各种问题。
    学习敏捷,针对这些问题,能想到的改善方法
    1.确定项目责任人和配合方,由责任人统一协调
    2.组织项目组,公布所有项目相关事宜,各系统负责人,分工等
    3.确立项目沟通机制,保证沟通效率
    2020-01-07
    1
  • escray
    开玩笑的讲,如果让我来牵头推进敏捷,那么首先就请专栏作者来做一次宣讲,然后再请专业的敏捷顾问来帮助实施。一方面,外来的和尚好念经,敏捷转型最好又体系之外的人来牵头,可以避免不必要的内部矛盾;另一方面,专业的敏捷教练显然更有转型经验,也更具说服力,内部也可以借此更快的培养出内部敏捷教练。

    评估诊断这个还是比较困难的,有点像是老中医的望闻问切。

    挑选代表性的项目相对容易一些,内部人士更为熟悉,挑选并不困难。但是可能存在,把最好的项目拿出来“秀”,或者把最差的项目拿出来“示威”的情况。除了按项目大小挑选,也可从人员能力、项目进展等角度来挑选。有一个疑问,就是进展程度不同的项目如何区别对待?

    访谈评估我觉的是最难的部分,因为虽然可以从几个维度来考察,但是没有办法量化,只能依赖敏捷顾问的个人经验。并且,在这一部分应该可以了解到团队成员的技术水平和个人特质,也需要在转型的过程中考虑。

    制定转型计划这一步和前面的步骤紧密相连,同样依赖敏捷教练的经验,并且在执行的过程中也可能需要手把手的指导。

    沟通并达成共识,如果有相关干系人没有办法说服怎么办?整个团队达成一致意见,这个也并不容易。如果是由上层试压,那么在执行中就会走样;如果上层不支持,那么压根没法继续。敏捷教练也不容易。在层级相对严格的单位,可能取得领导的认可,更为重要。前一段时间,好像是华为在做敏捷转型吧,似乎就有大老板喊话来着。

    我觉的一般的公司推进敏捷转型,还是需要依靠敏捷教练;即使内部员工参加了敏捷培训,其实也很难迅速扮演教练或者顾问的角色。通过评估诊断,找到痛点,然后依据计划,逐步推进,让相关干系人体验到敏捷带来的好处,这样才有可能顺利的推进。
    2020-01-10
  • Raymond吕
    敏捷前诊断由公司内部的人来做的话,如果没有高层直接授权,靠个人能力推动转变太难了,请问老师如何能让大家自发的认识到问题,对敏捷带来的转变不那么抵触?

    作者回复: 在教练技巧里有提问的技巧,可以提一些强有力的问题,这个需要有专门的训练,通过提问引发思考,意识到问题并让他们想到解决方法,在团队工作中我经常会用到。

    2020-01-09
  • 李永智
    业务人员配合敏捷项目不积极,或者由于客观原因,他们还有自己的事情,咱们有什么办法说服领导做这个?如何让业务人员感受到好处?

    作者回复: 这是个好问题,是业务敏捷的初步问题,在实操中很多公司都有这个问题。有两种解决方式,一种是激进式的,把业务人员和开发测试划归到了一个部门管理,成立了事业部,甚至是成立了公司,目标绑定,从上至下推进,业内有公司做过;还有一种是渐进式的,也是大部分公司采纳的,比较温和的改变,很多公司先把自己的研发的痛点解决了,有一些亮点,给业务看。把业务的领导前期请到参与到这里面来,给业务领导做宣讲,跟他们一起做业务规划,或者请业务领导来给研发讲解业务目标,说研发兄弟配合他们的工作,让业务领导派驻业务代表到研发团队,研发进度透明化,让他们定期可以看到产出,对研发有一些理解,可以积极的收集他们的反馈,需求前期业务与开发一起共创,产生创意等等。在现实中,业务的工作不仅是支持研发,它非常重要的工作是要完成业务目标,所以要争取把这件事情排到他们的工作列表中。这里面有很多内容,涉及的部门多,领域也比较广,也有跨部门合作的很高的艺术,业务敏捷是后面敏捷的重要趋势之一。

    2020-01-08
  • enjoylearning
    我虽然在团队中推行了敏捷scrum的一些实践,但效果往往跟我之前团队差距较大,一度怀疑人水平不行,原来是少了诊断评估这一步,明白了
    2020-01-07
  • 规划架构
    请问老师,敏捷成熟度评估有模型吗?

    作者回复: 有的,各家咨询公司的形式可能不一样,对很多公司而言,评估方法是他们的保密资产

    2020-01-07
    1
收起评论
7
返回
顶部