许多公司标榜自己在做“敏捷”。敏捷是执行软件开发的最新的框架。这个框架下有不同的方法,如Scrum,极限编程(XP),RUP等。Scrum目前是最热门的。一般来说,组织会使用一个混合的版本来适合他们的需求,也受到组织的环境限制(EEF、OPA;指的是企业环境因素,组织流程资产)(EEF/OPA, or enterprise environmental factors/organizational process assets).
因此,公司为什么要转型到敏捷呢?
我们用敏捷宣言来概括回答这个问题:
敏捷赋予客户更改的灵活性,因为整个流程是迭代的并且客户知道每个迭代的进展。还有,团队计划且承诺每个迭代的工作,并一起完成承诺。
对于双方这是一种双赢的场景:
这些都是理论。然而生活不是非黑即白:哪里都有灰色地带。
“do Agile做敏捷”比“be Agile成为敏捷”更容易一些。敏捷需要一定的纪律来得到正确的结果。
这些场景只是其中很少的例子;可能的清单是无穷无尽的。这些表明你在“做敏捷”(只是为了完成而已),但你不是“成为敏捷”,因为你不知道敏捷实践和交付的真正重要性。
你可能是遵循瀑布式开发人的敏捷傀儡。这种Scrum是臭名昭著的“Water-Scrum-Fall”。(译者注:也有叫做Scrum-But)
我给这个方法起了个新名字:“潮湿的”Scrum
遵循瀑布式开发的实践Scrum就变“潮湿”了。人们根据场景和难度有选择的使用Scrum。然而这么做很难(几乎不可能)理解敏捷的精髓。
客户需要以下内容:
这些都是Scrum理论上的交付物。然而,如果团队没有纪律性,也不关注使项目成功的话,就没有工作方法可以确保项目成功。
客户很着迷使用Scrum来解决上述的需求。这会对XYZ公司的高层转到Scrum产生了压力。这种压力向下传递给中层,最后是团队。团队不必认识到敏捷的价值,但他们需要成为敏捷,因为这是高层明确的要求和客户的声音。团队开始每日站会,sprint计划会议和回顾会议,而他们并不清楚最终目标或者目的。燃尽图从字面上看也烧毁了这些潮湿的Scrum团队。数字对于他们就像外星人。他们不确定PO和ScrumMaster的角色是干什么的。他们相信自己是自组织的,但还需要经理来管理他们的工作。
概括地说,他们被客户(或管理层)要求“敏捷”的;然而,他们离成为敏捷还很远。这是一种很悲伤的状态,对团队也很残酷。逐渐地,团队觉得这些会议没有用。例如,如果在sprint过程中经常承担更多的故事,那么sprint计划会议就失去了目的,也就变成是浪费时间。类似的,如果每日站会开了30分钟,很明显对于整个团队都是在浪费时间(30分钟乘以每天的团队成员数)。
长此以往,团队开始崩溃了。他们失去重心和动力,并且产品也会从创新模式掉到生存模式。
每个人都会抱怨敏捷是失败的源头。然而,如果参与项目的人不想做好,用什么方法都会失败的。
竞争是激烈的,因此公司会竭尽全力挖掘新客户和保住老客户。这也包括了转型到Scrum,看板等新型工作方法。然而,如果不理解敏捷的真正价值,这会扼杀员工的创造力、创新、愿景和动力。
敏捷生来就是赋予人们权力和沟通,然而潮湿的Scrum中丢掉这些核心价值。
赶快醒醒吧!
原文链接:http://www.scrumalliance.org/community/articles/2013/december/wet-scrum