Scrum精髓双刃

Scrum是一场创业

1993年，Jeff和Ken创造了Scrum，至今已经有25年之久。如今敏捷开发也不是什么流行词儿，不少IT组织已经走在敏捷转型的路上，还有一部分组织则刚痛下决心抛弃瀑布式计划型开发模型，试图采纳敏捷开发框架（比如Scrum）。但大部分组织即便拼得遍体鳞伤，仍然无法按期交付卓越的软件，最后要么放弃，要么就医 – 引入专业敏捷咨询师，ThoughtWorks已帮助业界诸多大型组织成功地敏捷转型。

在瀑布模型的IT组织中，试点团队一旦决定采纳Scrum，就如同开启创业。对于创业，我们喜闻乐见的是：有人有想法、有抱负、有激情也有行动力去推动变革，做不一样的事情，此时，Ta或者Ta们会试图去寻找志同道合的人，寄希望于通过团队来提高成功的几率。

就好比软件永远无法甩掉 业务不确定 的天然属性，Scrum创业团队自然也脱离不了创业团队的属性，而这些属性我认为最核心两个是： 自省 和 志同 。

Scrum齐眉双刃

如果将敏捷划分成三个层次 – 道、法、术，敏捷树的根部就是对应的道，它是敏捷的根本，比如敏捷宣言以及敏捷宣言中所体现的价值观。树的枝干对应了敏捷的十二原则，树叶则是一些敏捷的框架、实践和工具。

而敏捷的精髓在于敏捷树的根部，是敏捷提倡的那套 尊重 、 沟通 、 专注 、 承诺 、 勇气 、 反馈 、 开放 ，价值观不像实践那么具体看得见摸得着，但它值得团队在实践中持续不断地通过自省的方式来打造高效团队，任何尝试敏捷的团队都可以借助 自省 和 志同 这把双刃刀来武装自己。

自省是持续改进的基本手段

在术的层面，我们不缺乏 工具 和知识框架，Scrum和XP就是很好的指导框架（《Scrum精髓》）。很多团队即便丰富的知识框架的指导下，依然效果不甚理想，总感觉心有余而力不足。仔细观察他们的日常”敏捷实践”，你会发现一起有趣的现象：规划会开成谈判会、站会开成汇报会、冲刺搞成斗牛场，回顾会开成吐槽大会。

这里面很大的原因是团队把关注点放在术的层面，而忽略了这些术背后道和法，每当遇到阻碍时，团队需要停下步伐去思考和反省，跳出术的视野，不要着急去怀疑依样画葫芦却仍然失败的实践，更多去探索在实践过程中有没有违背核心价值观。比如，站会效果差，是不是团队不够包容，职责文化重，大家没有勇气去暴露问题。再比如，大家不愿意参加回顾会，是不是团队存在隐形政治，团队成员不敢发表自己的观点，互相不信任。这些都是值得我们不断去思考和反思的，持续做出调整和改进，在团队建设上更刻不容缓。

志同是高效团队的核心保障

Jeff在他的 《敏捷革命》 中提到两个例子来突出团队的力量：

1. 耶鲁大学的乔尔•斯波尔斯基研究一位教授的最难学课程，最后发现该课程得分为A的最快的学生和最慢的学生的时间比是1/10，
2. 大量研究表明，同等质量完成一份工作，最快的团队用了1周，最慢的用了2000周。

所以Jeff 聚焦团队，而非个人

传统瀑布计划型开发模型将软件开发周期分成了几个大的阶段，每个阶段由不同的职能团队负责，各自只对自己的环节负责，缺乏全局的视野，没有统一的目标，很难培养出共同的责任感和使命感，进而很难保障团队与团队之间信任的建立，不利于高质量的软件交付。

敏捷真的很难吗？

当我还是婴儿的时候，我走路中遇到障碍物摔倒后，我不会立即爬起来就跑，而是会在摔跤地好奇的扫几眼（可能哭着看），然后才爬起来继续，而且还会时不时回头撇几眼摔跤点（不是为了记恨它）。

当我在备战高考的时候，每周一小考，每月一大考，期中期末上巨考，这些考试都是在频繁地检查我在该阶段的学习成果（暂且不讨论学习方法科学与否），每次我都会根据考试成绩，做出针对性调整，而且不断地在重复这个循环。

除了这些习以为常的事情，比如管理界著名的PDCA戴明环[1]，军事界的著名的博伊德OODA环[2]，无不在凸显很重要的两点： 检视 、 调整 ，这两天加上 透明 也正是Srume的三大支柱。

就连大部分IT组织正在进行传统的瀑布开发模型，借用极限编程的思想理念[3]：我们可以把整个软件开发周期阶段引入到每个版本中，进而引入到每个迭代中，最后引入到每个用户故事[4]中，也就被扣上了敏捷帽子。

敏捷其实一直都在，不管你是在意还是不在意。而对于Scrum方法更简单 – 无论你什么时候启动一个项目，为什么不经常检验一下自己在做的事情：

1. 团队现在前进的方向对不对？
2. 当前结果是不是大家真正希望看到的？
3. 是否有什么办法能改善目前正在做的事情？
4. 如何才能做的更快更好？
5. 未来会存在那些潜在的障碍和风险？

时刻武装这些问题，增加发问的频率，缩短检视和调整的周期，敏捷会慢慢成为你碗中菜。

守术、破法、离道

对应敏捷的 道 、 法 、 术 ， 守 、 破 、 离 是一个好的前进方式。新团队，先守住术，比如逐步在团队中引入Scrum框架中的实践，守的过程肯定会不断遇到问题，始终手持双刃，通过不断地自省，持续改进，沉淀敏捷团队文化。对守的问题游刃有余之后，尝试去破法，根据团队自身情况尝试一些不一样的实践，找到跟团队更匹配的实践。当团队都深深理解敏捷价值观了，敏捷就变成了开源框架，团队可以随心所欲的做出取舍和创新，只要不违背价值观。

注释

待续

期待与你交流，我的联系方式： 邮箱 |