如何在企业中选择合适的试点进行敏捷方法实践应用

2022-07-06 14:05:00
豹子头姐姐-明兰
原创
38

选择什么样的团队做试点团队比较合适呢?Mike Cohn提出了一个试点团队的选择框架,选择试点团队从以下几个维度考虑(如图)。




试点团队选择模型图




1.项目规模

最好选择那些独立的、规模在5-9人以内的试点团队。第一个试点不要选择大团队,比如几十人规模不适合做团队级敏捷的试点。试点的目标虽然是探索敏捷在企业里如何落地,但是全公司的人都在关注试点团队的效果。因此对于第一个试点,尽量避免选择团队之间交织依赖的项目,避开不必要的复杂性,增加试点成功的概率。需要多个团队协作的大型项目,适合在企业开展产品级敏捷的时候做试点。


如果企业里没有小规模项目,那么退而求其次,可以选择大项目中的一个小团队做试点。



2.业务利益干系人的参与

如果缺少具有业务决策权的人参与试点,那就只能在研发范围内开展敏捷,但是业务人员在价值流的最上游,没有他们的参与就无法开展真正的敏捷。如果你选择的是Scrum框架,那么具有产品决策权的人应该参与到Scrum流程中承担产品负责人的角色。


3.项目周期

很多企业的管理层期望敏捷开始试点后马上立竿见影。但是,凡是经历过组织变革的人都知道,这是几乎不可能的事情。一种新思想、新方法引入后,团队需要先学习和适应才能开始进入状态。凭我的经验看,如果看到敏捷团队一些定性的效果,至少需要一个迭代的时间才有可能看到透明化、沟通协作高效、团队士气提升的效果。如果要通过数据量化看结果,需要4-6个迭代的时间,待团队的迭代速率保持稳定后,才团队效率可能会有提升的趋势。


因此,项目的周期不能太短。有些公司的一些项目,团队人员不固定,每个迭代都是临时组队,交付完规划的特性后,人员释放,下个周期重新组建团队,这样就没有办法看到持续的效果。但是,项目的周期也不需要太长,因为那些长到1-2年的项目往往节奏缓慢,缺乏变革的紧迫感。


4.项目的重要性


!常踩的坑:


一些企业的管理层担心敏捷转型会影响项目的进度,因此喜欢选择那些内部产品,原因是内部产品的进度可松可紧,没有外部客户和市场的压力;或者倾向于选择那些不在公司的主航道上的项目,原因是如果这些项目失败或延期,对公司的核心业务没有影响。但是,在这样的项目里即使试点成功,对公司的主航道项目人员也没有说服力,因为大家会觉得这些项目不重要,他们有闲功夫来尝试,而我们没有时间。


因此,试点要选择那些在企业的业务主航道上的项目。但是,不要选择那些最关键的项目,比如对企业生死攸关的项目,或处于救火状态的项目,因为抛开敏捷转型因素不谈,一旦这些项目自身运作有了问题,大家会归咎于“都是敏捷的错”。所以,要选择那些在企业的主航道上的中等重要程度的项目。


除了上图的模型里提到的考虑因素外,还需要考虑以下因素:



5.团队最好坐在一起


尽量不要选择那些团队分布在不同的地区甚至国家的项目,除非这种分布式团队是企业的主流团队。



6.最好选择那些新产品开发的项目,而不是维护类型的项目


维护类型的项目往往不能够引入太多的变化,比如:你无法用敏捷的方式实践新的Idea从诞生到上线的整个过程。此外,一般来说,维护类型的项目遗留代码的包袱比较重,在遗留代码上尝试敏捷工程实践尤为困难


7.优先选择纯软件项目


如果企业有软件、硬件集成的项目,要先选择纯软件项目来试点,试点见效后再考虑将硬件项目试点。虽然有很多报道、案例证实敏捷完全可以应用在硬件项目中,我也做过硬件项目的敏捷辅导,但是,相对来说,软件的本质决定了软件项目更加适合敏捷,也更容易让企业看到变化。


最后,如果你找不到以上条件都满足的项目,那么要权衡利弊,结合企业自身情况选择最合适的项目。

联系我们
联系人: 柴老师
电话: +86 185 1045 6582
Email: clientservice@hardenx.cn
地址: 北京市海淀区善缘街1号立方庭1-105