"潮湿的"Scrum

最新推荐文章于 2025-08-11 19:05:22 发布

姜信宝BobJiang

最新推荐文章于 2025-08-11 19:05:22 发布

阅读量1.3k

点赞数

分类专栏：精益+敏捷文章标签： scrum 极限编程软件开发创新需求

精益+敏捷专栏收录该内容

22 篇文章

订阅专栏

许多公司标榜自己在做“敏捷”。敏捷是执行软件开发的最新的框架。这个框架下有不同的方法，如Scrum，极限编程（XP），RUP等。Scrum目前是最热门的。一般来说，组织会使用一个混合的版本来适合他们的需求，也受到组织的环境限制（EEF、OPA；指的是企业环境因素，组织流程资产）(EEF/OPA, or enterprise environmental factors/organizational process assets).

因此，公司为什么要转型到敏捷呢？

我们用敏捷宣言来概括回答这个问题：

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

敏捷赋予客户更改的灵活性，因为整个流程是迭代的并且客户知道每个迭代的进展。还有，团队计划且承诺每个迭代的工作，并一起完成承诺。

对于双方这是一种双赢的场景：

客户实时得到项目、产品的更新状态，并且客户可以自由地改变需求。
团队就像军队里的阿尔法单元（5-9个人），一起在短迭代内荣做。

不争的事实：

这些都是理论。然而生活不是非黑即白：哪里都有灰色地带。

“do Agile做敏捷”比“be Agile成为敏捷”更容易一些。敏捷需要一定的纪律来得到正确的结果。

会议在时间盒内吗？
会议中你是很好的倾听者吗？
PO或者ScrumMaster就是唯一说话的人吗？
PO或ScrumMaster把工作“强加”给你吗？
在Sprint计划会议时，PO不等团队的输入就要求承诺吗？
被迫给故事ABC分配XYZ点数的估算吗？
在回顾会议你不“公开”，因为害怕所说的适得其反吗？
在sprint过程中你被迫承担新故事，而影响了你已经承诺的交付吗？
在每日站会上你从来不谈论尽管已经存在的障碍？
你希望PO或SM微管理而你只需要工作即可吗？
你相信胡萝卜加大棒的管理方法很重要吗？

这些场景只是其中很少的例子；可能的清单是无穷无尽的。这些表明你在“做敏捷”（只是为了完成而已），但你不是“成为敏捷”，因为你不知道敏捷实践和交付的真正重要性。

你可能是遵循瀑布式开发人的敏捷傀儡。这种Scrum是臭名昭著的“Water-Scrum-Fall”。（译者注：也有叫做Scrum-But）

我给这个方法起了个新名字：“潮湿的”Scrum

遵循瀑布式开发的实践Scrum就变“潮湿”了。人们根据场景和难度有选择的使用Scrum。然而这么做很难（几乎不可能）理解敏捷的精髓。

潮湿的Scrum如何工作

客户需要以下内容：

更多的人为干预
可控的工作组织在短迭代内，而不是把整个项目、产品作为一个整体进行管理。
事实更新完成的工作
改变需求的权利
高质量结果

这些都是Scrum理论上的交付物。然而，如果团队没有纪律性，也不关注使项目成功的话，就没有工作方法可以确保项目成功。

客户很着迷使用Scrum来解决上述的需求。这会对XYZ公司的高层转到Scrum产生了压力。这种压力向下传递给中层，最后是团队。团队不必认识到敏捷的价值，但他们需要成为敏捷，因为这是高层明确的要求和客户的声音。团队开始每日站会，sprint计划会议和回顾会议，而他们并不清楚最终目标或者目的。燃尽图从字面上看也烧毁了这些潮湿的Scrum团队。数字对于他们就像外星人。他们不确定PO和ScrumMaster的角色是干什么的。他们相信自己是自组织的，但还需要经理来管理他们的工作。

概括地说，他们被客户（或管理层）要求“敏捷”的；然而，他们离成为敏捷还很远。这是一种很悲伤的状态，对团队也很残酷。逐渐地，团队觉得这些会议没有用。例如，如果在sprint过程中经常承担更多的故事，那么sprint计划会议就失去了目的，也就变成是浪费时间。类似的，如果每日站会开了30分钟，很明显对于整个团队都是在浪费时间（30分钟乘以每天的团队成员数）。

长此以往，团队开始崩溃了。他们失去重心和动力，并且产品也会从创新模式掉到生存模式。

每个人都会抱怨敏捷是失败的源头。然而，如果参与项目的人不想做好，用什么方法都会失败的。