哪种敏捷实践能让“老板”最快看到团队敏捷转型的效果？

surfirst

已于 2022-05-14 21:17:09 修改

阅读量261

点赞数

分类专栏：领导力管理文章标签： scrum 敏捷开发团队开发

于 2022-05-14 19:39:18 首次发布

本文链接：https://blog.csdn.net/surfirst/article/details/124744463

版权

领导力同时被 2 个专栏收录

32 篇文章 1 订阅

订阅专栏

管理

26 篇文章 0 订阅

订阅专栏

在软件开发中，“老板”最关心的就是工作进展，而最能够代表工作进展的当然就是可以展示的工作成果了。展示工作成果多长时间一次最好呢？“老板”肯定希望周期越短越好了。敏捷团队的迭代周期一般是2周，每个迭代结束时，团队需要开“Sprint Review Meeting”，汇报成果。在这个会里，团队需要展示在这个迭代里的研发成果，所以每两周一次的“Sprint Review Meeting”肯定最能体现团队的交付能力，也是“老板”观察团队敏捷转型效果的最佳窗口。

先来看看“Sprint Review Meeting”应该邀请谁来参加？

外部客户
内部客户
部门领导
兄弟部门
敏捷团队
其他对团队研发成果感兴趣的同事

从上面的列表，我们可以看到在这个会上团队需要给“外部”团队汇报本团队的阶段性成果。展示对象既包括关系到项目成败的“内外部客户”，又关系到团队成员晋升的“领导层”。

要在短短的 2 周也就是 10 个工作日内，每次都能做出能够展示的成果，这是一件不容易完成的任务。

为什么每个迭代都要向客户展示成果？

如果是为某个项目合同开发而成立的团队，可能会有人问，既然已经跟客户签订了项目合同，直接按照合同规定在项目结束以前完成所有功能不就可以满足客户的需求了？提前给客户展示阶段性成果，客户会不会提出额外的要求，这样是不是反而会延误工期？

大家还记得敏捷宣言中的“更客户合作重于合同谈判”吗？其实如果你经常和客户互动，你就会发现在很多情况下客户的要求很简单，而团队有时候为了实现某个需求反而把问题想复杂了。另一方面，信息的传递经过的环节越多信息就越可能失真，因此直接面对客户从客户那儿直接拿到反馈可以让团队的工作始终维系在正确的方向上。
在这里插入图片描述
客户对产品的理解也需要一个过程，比起文档来可以运行的软件更能描述最后的结果。当客户看到了最终运行的结果，他们就会和实际的需求相比较，看看是不是和期望相符，如果相符，团队就可以确定工作已经完成，减少额外的浪费，如果不符，可以根据客户的反馈及时止损、调整方向。产品经理也可以根据反馈和客户及时沟通尽可能地为团队争取时间和资源，控制项目风险。

如果团队开发的是有创意的产品，团队更需要尽早把产品投入市场验证假设是否正确，实现快速地PDCA 循环。

作为研发团队的高层领导在成果展示会上通过直接观摩研发成果掌握第一手的项目进展信息。每个团队成员应该轮流主持展示会，展示研发成果，这样高层领导就有机会了解每个团队成员的能力，为晋升提供实绩资料。团队成员也通过展示会提高自己的展示能力，锻炼沟通技巧。由于要讲解产品的使用过程，团队成员也会更关心团队的研发进展和产品细节。

如何做到每个迭代都有可展示的成果？

当团队收到要每两周直接向客户、外部团队以及高层领导展示迭代成果的任务时候，他们往往觉得不太可能在仅仅两周内就能有可以展示的成果。如果这个项目是个偏后端的项目怎么办呢？团队总觉得没有准备好，总是希望完美。

这些问题正是敏捷框架要解决的问题！

团队共识

团队首先需要建立共识，这是建立敏捷框架的基础。本文对每项内容只做简单介绍，读者可以自己查阅相关资料或者订阅本频道获得更多详细介绍。

需求准入标准
这是为需求梳理会的输入和输出建立标准，决定什么样的用户故事可以进入迭代，开始研发。需求准入标准应该由团队共同制定，目标是进入迭代的用户故事都是可以在一个迭代中可以完成并且展示的。
定义完成 (Definition of Done)
做完一个用户故事的标准是什么？应该经过哪些过程？这也应该是团队根据自己的实际情况共同制定的。DoD 是所有共识中最重要的，只有达成了 DoD 团队才能确认一个用户故事已经可以被交付了。

下面是某敏捷团队制定的标准：
在这里插入图片描述
3. 团队的名字
一个有独特名字的团队会让团队成员觉得与众不同，产生归属感，增强责任心。

制定会议计划
在敏捷框架中有一系列会议，确定这些会议在每个迭代中的时间并固定下来，为团队成员的基本交流形成习惯打下基础。特别是“Sprint Review Meeting”的时间因为涉及到外部团队，一旦定下来就不要再有变化以确保和客户和外部团队保持一致。下面是某团队的会议计划。

建立敏捷框架

敏捷框架由一系列会议组成。它们保证了团队运行的基本节奏，更确保除去敏捷框架下的会议外，团队 90% 的时间都能放在研发工作上。

这里假设每个迭代为2周，每周有5个工作日，每个工作日有8小时工作时间。敏捷会议的总时间占比约为 2+1+0.5+1+10*0.5=8.5个小时。8.5 除以 80 个小时的工作时间，大约等于0.1也就是10%为会议时间，剩余的90%时间就是研发时间。

在这里插入图片描述

敏捷框架由上图所示的一系列会议组成，下面简单介绍各个会议的目的、输入和输出：

用户故事梳理 (User Story Grooming)
这个会议的目的是为了选出可以进入迭代的候选用户故事。这个会议的输入是产品经理根据优先级排好的，积压的但是还没有标记为已梳理的用户故事。是否表示为“已被梳理”，由团队制定的需求准入标准决定。团队需要在会议规定时间内尽可能的梳理用户故事，以备将来制定迭代计划时使用。该会议的输出是已梳理的用户故事。
迭代计划 (Sprint Planning)
迭代计划的输入为已被梳理的、经过产品经理根据优先级排序过的用户故事，输出为这个迭代准备完成的用户故事列表和为每个用户故事拆解的开发任务。团队需要根据自己的可用工作时间来控制在该迭代中需要完成用户故事数量，同时应该根据 MVP 原则保证在成果展示会上有可以展示的内容。
迭代成果展示 (Sprint Review)
前文已经讨论过迭代成果展示会的内容，这里就不再赘述了。
反思 (Retrospective)
那些能够认真总结的团队才能进步。反思会上团队共同总结在这个迭代中有哪些做得好的地方和需要改进的地方，并且制定行动计划。
每日站会
如果明白了 Sprint Review Meeting 的重要性，在站会上就不应该只讨论每个成员昨天做了什么，今天准备做什么？而应该围绕团队制定的迭代计划，讨论如何能集中全力优先完成优先级高的用户故事，以保证在成果展示会上有可以展示的内容。

总结

本文推荐使用 Sprint Review Meeting 作为团队敏捷转型的第一步。这样团队就可以以始为终，通过努力做到定期向客户和外部团队展示团队研发成果，获得敏捷转型的驱动力。本文也简单介绍了敏捷框架的内容，以及敏捷框架如何帮助团队实现定期成果展示的目标的过程。读者可以通过关注本号获得敏捷框架的详细介绍。