当前位置：首页 > 看板管理 > 正文

敏捷团队管理︱解析Scrumban从理念到实践

2022-11-05 来源：翰德恩业务敏捷，作者王明兰

周期不能太短。有些公司的一些项目，团队人员不固定，每个迭代都是临时组队，交付完规划的特性后，人员释放，下个周期重新组建团队，这样就没有办法看到持续的效果。

但是，项目的周期也不要太长，因为那些长到1-2年的项目往往节奏缓慢，缺乏变革的紧迫感。

项目的重要性

常见误区：

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

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

选择试点还需要考虑啥？

除了Mike Conh的模型里提到的考虑因素外，还需要考虑以下因素：

团队最好坐在一起

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

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

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

纯软件项目优先

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

最后，如果你找不到以上条件都满足的项目，那么要权衡利弊，结合企业自身情况选择最合适的项目。选择了试点项目后，祝贺你，你的敏捷之旅可以扬帆起航了！

分享到:

免责声明：
　　1、IT项目管理界发布的所有资讯与文章是出于为业界传递更多信息之目的，并不意味着赞同其观点或证实其描述。其原创性以及文中陈述文字和内容未经本站证实，对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺，请浏览者仅作参考，并请自行核实相关内容。
　　2、本站部分内容转载于其他网站和媒体，版权归原作者或原发布媒体所有。如文章涉及版权等问题，请联系本站，我们将在两个工作日内进行删除或修改处理。敬请谅解！

上一篇：
Scrumban看板管理︱解析Scrumban从理念到实践
下一篇：
最后一页

延伸阅读：

more 会议活动

more 公开课

more PMO

微信扫一扫关注

敏捷团队管理︱解析Scrumban从理念到实践

延伸阅读：

会议活动

公开课

PMO

IT项目管理界官方微信

PMO大会官方微信