和敏捷宣言发起人学习Snowman

by Terry

周末有幸参加EXIN由敏捷宣言发起人之一Arie van Bennekum主讲的Agile Scrum Master授权讲师课程。之前了解到一些团队在敏捷转型时使用的并不是标准的Scrum，而是Snowman这样一种方式，但具体的实践模式各有差异，很多最后都变成了“中华田园式敏捷”，实操还是比较“神秘”的。通过本次和Arie学习，对“神秘的”Snowman有了更深入的了解，也和大家分享一下。

整体来说，Snowman是在Scrum的基础上强化了研发团队外业务团队相关人的参与度，增加了“Heartbeat”这样一个流程，加强与业务视角需求的沟通和确认，从而实现在Sprint Review时能够更好地交付令相关方满意的结果。

下面从 角色变化、流程变化和实践优势 三个方面对Snowman进行介绍。

一、角色变化

相较Scrum而言，Snowman增加了3个角色：管理层、业务相关人（这两个角色也不完全算是“新增”，可以理解为对Scrum团队内部Stakeholder的细化）与BA。如图所示，Snowman包括Head（头部）和Belly（肚子）两部分。Belly是标准的Scrum团队配置，包括SM、PO和Dev Team，增加了一个BA的角色；Head包括管理层与业务相关人。管理层（如图S与V所示）在这里可能是CEO、CTO与CFO，他们对研发的整体方向与投入进行决策。然而，由于管理层管理事务繁多，不可能很深入地参与到研发过程，所以这里的BA更多是作为管理层的需求信使，确保Dev Team交付结果满足管理层的相关要求；而业务相关人（如图NFS）所示，可能是法务部门、销售部门或市场部门等的业务部门代表，负责确保Dev Team交付结果满足业务方面的相关需求，比如银行往往受到监管限制，那么在开发过程中能够有法务部门代表始终确认交付结果满足法务相关要求是非常重要的。

在有多个Scrum团队时，可能Head只有一个，对应Belly有多个。

二、流程变化

相较Scrum而言，Snowman增加了“Heartbeat”这样一个环节，下面介绍下这个环节的参与者、频次与内容。

参与者：如图所示，“Heartbeat”这条线之下的所有人为该环节的参与者，包括SM、PO、Dev Team、BA和业务相关人。

频次：一般2-4天一次，但也要视实际迭代时长而定。如图假设是一个为期2周的迭代，可以每2-3天进行一次，一个迭代内共安排4次。

内容：由SM组织，Dev Team提前演示已完成的Demo，由PO、BA和业务相关人从产品需求、管理需求和业务需求方面进行评估，提前识别未满足需求的问题，以便Dev Team更好地理解需求进行优化，减少Review时的验收问题，实现更快速的改善与更高质量的交付。

三、实践优势

Snowman的优势相对应该比较明显，个人理解主要包括2点：

第一， 沟通强化促进交付效率与效果提升。 通过引入管理需求与业务需求代表，以Heartbeat强化沟通，并践行精益尽早暴露问题解决问题的理念，而不是在Sprint Review的时候才进行Demo演示发现问题，让交付效率更高，交付成果更加尽善尽美，质量更能从多方面得到保障；

第二， 非业务部门参与强化促进敏捷理解。 敏捷转型不仅仅是研发团队的事，而是随着变革的深入，需要更多的部门参与支持。以往按照ADAPT模型的Scrum转型实践以研发团队范围为主，在Promotion和Transition阶段可能会通过成功案例的分享与传播去影响到更多业务部门，让他们了解到敏捷变革的优势并能进行协同。然而这往往发生在“事后”，或者在过程中与业务部门进行协调时，很多业务部门“被配合”做一些工作是不太乐意的，而Snowman却让业务部门更好地参与到整个Scrum的过程，需求方的角色也不会让他们“抵触”而是比较乐意的，通过需求得到关注与满足对敏捷变革产生更为积极的支持态度，形成了一个由研发部门扩展到研发之外的全面协作、更为理想的敏捷团队。Heartbeat这个词也是非常有意思，真的是让大家形成一个拥有共同“心跳”的团队，“齐心协力”为客户提供更好的产品创造价值。

以上就是对Snowman的介绍。另外补充2点内容：

第一是补充说明一下，Snowman并不是和Scrum、Kanban、XP、TDD等并列的一种敏捷开发实践，可以认为是Scrum从研发团队扩展到非研发团队参与的实践方法；

第二是前段时间我们团队内外部讨论比较热烈的一个问题，那就是“用户故事下的所有任务完成是否等于用户故事完成？”这个讨论源于请国内资深敏捷教练——蔡建斌老师协助进行Worktile于2019.11.16发布的全新研发产品评测时。蔡老师在试用我们的全新研发产品后评价道：

“作为一个深度的敏捷管理产品使用者，在快速试用了Worktile的最新研发产品后，还是被惊艳到了。第一个念头是：这么一款重磅产品，任何参与到这个产品的研发人员，都值得为自己自豪。
亮点：

  1. Agile产品的即开即用的SCRUM模式，需求的默认层级（Epic-Feature-Story），不需任何配置即可上手使用。
  2. 持续交付流水线，在如今Devops大火的时代，已经成为优秀团队的标配，Pipe简洁而易上手，瞬间提升团队格调。
  3. 质量管理是软件研发管理中最重要的一环之一，Testhhub和Trace，一个从测试角度，一个从线上日志的角度，提供了很好的数据和支持。
  4. 重要的是这四大产品的数据互通，同时又可插拔，给人感觉简洁、灵活而又强大。
  5. 大到产品方向，小到一些细节展现出的很好的用户体验，都说明了这是个匠心之作。”

然而，对于有一个功能蔡老师提出了一些建议，就是在“迭代”的“规划板”，我们产品在这里是支持用户故事下任务的拖拽与状态变更，但可能所有任务的状态都是完成，并不能代表用户故事是完成的，尤其是考虑到一些非功能性需求，现在有一些研发管理软件在看板默认设置为基于用户故事进行拖拽。

“任务完成不等于用户故事完成”，这种情况在很多Scrum团队确实很常见。个人认为问题产生的根本原因还是在于需求的生产方也就是Dev Team对需求的提出方也就是PO或Snowman中包括的管理层与业务相关人是否足够理解。当然，需求的标准总在持续变化，但如果Dev Team对其各方面需求的理解更为到位，彼此之间更有默契，那么在制定任务时考虑也会更为周全，在Review时能够交付更为满意的成果通过验收。然而想达到这一点，沟通是关键。Snowman便为更为高频、广泛和全面的沟通提供了这样一种机制。

回到产品功能上再说的话，由于每个迭代的用户故事有限并不像任务那么多，在迭代的工作项查看用户故事状态便一目了然了。另外比较赞成一种说法是：“用户故事是用来交付的，而不是用来完成的。”对于用户故事的数量与状态可以通过Burn-down Bar Chart进行更加便捷的管理。

希望对大家更好地转型敏捷优化实践提供一些参考。敏捷开发的优势早已证明，可只有真正开始实践才能受益，也放上Arie的一句话和大家分享：

“Agile will become the default, it’s to do or to die for companies. ”

如果看到蔡老师试用反馈的研发朋友对这样“强大神奇”的产品有点儿好奇想要体验一下，欢迎扫描二维码注册试用。平心而论，真的是目前最强大好用的研发产品了，能够将研发全流程数据打通、支持标准的Scrum、快速完成流水线搭建并且用户友好颜值高可以立马上手（并且真的爱不释手会上瘾！！！）的研发产品，也就只有Worktile强大的研发天团这么“能造”了~

以上内容欢迎大家留言交流讨论。