Scrum需要一个双刃团队

直接阅读 博客原文，你能获得更好的阅读体验、以及最新的内容

Scrum是一场创业

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

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

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

---

用双刃武装团队

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

image

而敏捷的精髓在于敏捷树的根部，是敏捷提倡的那套尊重、沟通、专注、承诺、勇气、反馈、开放，价值观不像实践那么具体看得见摸得着，但它值得团队在实践中持续不断地通过自省的方式来打造高效团队，构建统一愿景和目标。

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

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

1986年，《哈弗商业评论》上一篇题为《新产品开发新游戏》的论文对Scrum起着启发性的影响，该论文描述了世界上最优秀的公司最卓越的团队具备以下三个特质：

1. 超越寻常，即追求卓越
2. 自主性，即自组织团队
3. 多功能，即全功能团队

任何尝试敏捷的团队都值得付出努力让自己具备上述三种特质，用自省和志同双刃来武装团队无疑是一个明智的决策。

---

自省是持续改进的基本原则

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

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

---

志同是高效协作的核心保障

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

Scrum核心目标之一就是要克服团队协作的障碍，Scrum创始人借用这个橄榄球运动的专业术语，它的原本意思是：团队通力合作，在场地内传球。这个过程需要团队认真配合、信念一致和目标明确。所以一个成熟的Scrum团队，团队成员都应该保证目标一致且互相信任的。在这个基础上，成员各个身怀绝技，并且具备较强的责任感和自我管理的能力，在毫无自上而下发令的前提下，自下而上的自发协作完成工作，且积极主动承担更多的挑战。

打造一支这样的团队并非容易的事情，过程中也离不开不断地自省改进。《Scrum精髓》中描述了Scrum中优秀的开发团队的应该具备的十种特征：

1. 规模规模适中
2. 自组织
3. 跨职能的多样化和全面化
4. 团队成员稳定
5. 专注、有责任感
6. 火枪手态度：人人为我，我为人人
7. T型技能
8. 透明沟通
9. 高带宽沟通
10. 工作节奏可持续

以上十种特征分别从团队组成（1，2，3，4）、团队成员（5，6，7）、团队文化（8，9，10）三个视角提供了很好的参考，你也可以在你的团队中，经常检视团队有没有具备这些特征以及如何能够培养这些特征，并付诸行动。

---

敏捷真的很难吗？

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

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

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

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

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

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

对着你的团队不断地发问，缩短检视和调整的周期，敏捷终有一天会成为你碗中菜。

---

守术、破法、离道

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