Scrum是一场创业

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

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

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


用双刃武装团队

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

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

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


注释

  1. PDCA戴明环,Plan-Do-Check-Act,由美国质量管理专家休哈特博士首先提出的,由戴明采纳、宣传,获得普及,所以又称戴明环
  2. OODA循环,Observe-Orient-Decide-Act,是美国空军上校约翰•博伊德根据人脑决策过程建立的一种空战理论
  3. 极限编程理念:如果一个实践能够创造真实价值,我们就应该努力将其做到极限
  4. 用户故事极限编程的一项实践,它是在迭代中指导开发的业务需求单元载体


期待与你交流,我的联系方式:邮箱 | 微信

Posted by Yuan Shenjian • November 27th, 2018

版权声明:自由转载•非商用•非衍生•保持署名 | Creative Commons BY-NC-ND 4.0

原文链接:https://sjyuan.cc/scrum-needs-a-team-with-two-blades/
支持原创
⤧  Previous post 深入解读敏捷宣言