敏捷社区正在如火如荼地讨论什么情况下团队能真正地敏捷起来,又有哪些是实施敏捷的正确方法。Jason Little 撰写了博文《你干得比你认为的更出色》,分享了他的观点:面对敏捷实施的各种意见,我们该何去何从?
敏捷社区可以迅速地找出你队伍中的问题。你“Scrum 用得不对”,你在“照搬 (doing) 敏捷”,而没有“变得 (being)”敏捷,或者类似的一些废话。但你究竟有什么是做得对的呢?
他认为,敏捷不是“照搬敏捷”或者“变得敏捷”,而是意味着行动上的改变和进步。
我知道大家在进步,因为我看到了不一样的表现,这是几个月前不曾有过的。我感到大家在进步,因为大家给我讲了一年前的生活和现在的生活的种种不同,工作上的各种改进。
Jason 建议多关注做得好的地方,并引以为傲:
我不认为公司足够关注大家做得好的事情,因为各种权威总是指出大家做得不好的地方。……我现在所在的团队就为他们所取得的进步感到非常骄傲……昂首挺胸,我为你们骄傲。
Tommy Bryntse 写了一篇名为《什么是敏捷》的博客,其中他指出了团队可以号称敏捷的关键点。他阐述了他所理解的敏捷,以及什么情况下不算敏捷:
敏捷宣言是敏捷的灵魂。宣言中的十二法则充分诠释了敏捷。无须赘述……变得敏捷就是遵循宣言精神及其身后的法则。如果你没做到,不好意思:不能算敏捷!
他建议如果做不到,还是暂时不要说自己要做敏捷了,先做个列表出来,告诉自己“算不上敏捷”的原因。
请不要只因为开了日常站立会议,用白板记录故事、分派工作,就标榜自己在做敏捷开发。……要实现敏捷,你得先检查前面提到的“算不上敏捷”列表……如果榜上有名,你就不算敏捷。话虽这么说,我并不是让大家停止手中的实践。那些优秀实践可以帮助你交付更好的软件。只是如果你没有真正做到,就别说在做。
在 InfoQ 对 Jeff Sutherland 题为《敏捷团队真的敏捷吗?》的采访中,他回顾了敏捷宣言发布以来这十年的历程。他也就如何判断是不是敏捷发表了自己的观点:
……在 Sprint 结束时能够交付可运行的产品确实很有挑战,如果没有完善的敏捷团队很难做到,而正如我们所讨论的,这一点又是相当关键的基本原则,做不到就算不上敏捷。
Jeff 还举了几个实施 Scrum 的正面和反面例子:
……有数据表明,做得好的 Scrum 效率要快 10 倍。
要做好 Scrum,头一件事就是要在 Sprint 结束时交付可工作的软件。……另一件重要的事是 Sprint 所需要的 Backlog:Backlog 准备好了吗?是否清晰?是否每个待办项都大小合适?团队能够理解 Backlog 从而做出估算?是否有验收测试条件?
我和 Ken 发明并在软件开发中运用了 Scrum,我们把能想到的软件知识都用上了,但结果是,如果 Scrum 不精益,就是糟糕的 Scrum。一旦开始实施精益瘦身,就意味着要从系统中移除浪费。而 Scrum 就是致力于扫除障碍,和减少浪费一脉相承。
在名为《婴儿和洗澡水》的博文中,Jim York 探讨了如何看待五花八门的敏捷实践、工具和技术。他就如何决定选用哪些敏捷实践给了些建议:
Scrum 的一个基本前提是如果事情进展顺利,就继续做。反言之,如果什么事情进展不利,一定要及时改变。Scrum 并没有规定哪些敏捷实践在它的框架之内,而是将做这个决定的权利留给了自组织团队自由发挥。而这个“自由发挥”往往是 Scrum 实施中最难的部分。
他认为团队应该通过了解哪些实践合适他们,哪些不合适来自己发掘敏捷的真谛:
我更愿意将 Scrum 看作是一个学习加速器。每个 Sprint 都是个实验,是个学习的机会。……公司从过去他们经常使用的开发增量产品的流程中学到新的东西。学到的经验可以进一步地改进流程。
评论