在接触敏捷的这一段时间内，也听了不少曲折离奇的故事。很少有团队在转型敏捷的时候，没有系统学习或外力支持就能做的风生水起。毕竟这里面的“水”很深。
比较巧合的是，我所供职的公司目前便在做敏捷转型。不过，我们的转型过程并不是顺风顺水的。因此，在转型过程中，我们注意到的那些“ 事儿”，你也一定关心。
领导是在充分认识到敏捷的益处之后，决定转型敏捷的。因为敏捷所提倡的“拥抱变化”更适应公司的开发过程：尽管公司是 To B 企业，但用户参与度依旧很高，这就导致产品经理在与用户代表对接的过程中，会不断地产生产品需求更改的情况。既然是这样，那么沿用瀑布开发的模式就显得有些笨重了。
困难一：全员敏捷
决定要转型敏捷之后，如何让公司全员了解敏捷呢？第一个困难出现了。
针对这一问题，公司开始引入敏捷方法论的知识，推动全员进行敏捷方法论的学习，包括制定学习计划来督促大家的学习进度：观看敏捷相关视频、阅读敏捷书籍等。在有了一定的理论知识之后，敏捷开发的推进就稍显轻松。
顾虑到除研发部门外，其他业务部门转型敏捷的优先级并不算高，公司决定先将研发部门划为试点部门，小范围试行敏捷。所以就出现了每天早上，其他部门的同事都要去看一看研发部门有没有在开站立会议的现象。尤其是将 Scrum 流程融入到日常办公中时，这给同事们带来了一种之前从未体验过的新鲜感。这种新鲜感让其他业务部门不仅有了对敏捷一探究竟的好奇心，还开始憧憬自己部门转型敏捷之后的“愉快生活”。
显然，研发部门的敏捷转型成功了，这带给了公司上下莫大的信心。紧接着，其余的业务部门也开始了敏捷转型。实施了一段时间之后，大家发现，转型敏捷是一个非常正确的决策。在大家都沉浸在“转型成功”的欢天喜地的氛围中时，领导又拧紧了眉毛。
困难二：流于形式
领导发现，虽然各方面的形式做到位了，但公司实际并没有明显的业务价值的提高，问题出在哪里？
考虑了一下，领导选择请一位敏捷教练，让他到公司实际考察，帮助捋清到底哪里产生了问题。敏捷教练的到来让公司有了意外的收获。教练在各个业务部门之间转了几天，了解了我们的现有敏捷模式，随后指出了几点问题：
- 站立会议流于形式，其他人并没有认真听主讲人的工作内容及问题；
- 看板的应用不规范，无法得到及时更新，不能传递相应价值；
- 工时估算随意，无法体现任务价值等。
除此之外，敏捷教练还纠正了很多我们在工作中的小问题。在教练的帮助下，虽然大大小小的会议依旧不少，但在不断迭代的过程中,大家都很明显地发现自己的工作计划变得更加完善详实了，其间如果出现与计划不相符的结果，也能很快地找到问题所在。
可以说，我们转型没有失败的很大原因，在于我们将小范围的试点扩大到了整个公司的范围内。除自己公司之外，我也有看到过其他转型敏捷的公司，只是在某一部门中推行敏捷，尽管小范围内的敏捷转型成功了，但它也有相应的局限性，会阻碍敏捷带来的深远影响和战略价值。
除去转型的准备工作，公司也拿出了很多的时间来巩固转型的成果：比如 开展各种敏捷培训， 定期开展工作回顾与总结等，这些无一不在丰富我们对敏捷的认知。
直到现在，我们虽还未转型成功，但也算小有心得。公司员工的愿景一致，是否借助外部力量，还是通过管理工具进行调整，这些都还是次要。最重要的是，公司是否有转型敏捷的毅力与魄力，毕竟这是一场真正的持久战。
往期文章：
{{m.name}}
原创文章，作者：kepupublish，如若转载，请注明出处：https://blog.ytso.com/97960.html