敏捷个人的创立与详解Scrum会议

 

【51CTO专稿】在敏捷实践中，Scrum可以说是用于运行项目的框架，它基于敏捷的原则和 价值。对于管理严格的项目团队，Scrum会议也会每天都在同一时间进行。通过每日Scrum 会议，团队成员之间可以彼此相互熟悉工作内容，充分了解项目进度，相互帮助解决问题。那么，在Scrum中的Sprint计划会议应当如何进行？记者采访 了敏捷个人创立者，周金根老师跟网友们谈谈Scrum的实施与Sprint计划会议。

 

个人简介：周金根，个人成长教练，软件产品架构师，培训师，敏捷个人创立者和推广者。

以下内容为采访实录：

记者：请问你是如何接触到敏捷开发的？敏捷个人的创立是出于什么样的想法？

周金根：最早我们是采用RUP开发的（可以看看从IT方法论来谈RUP）， 我记得在一个产品设计阶段，我们使用Rose画了很多图，但是最终开发的时候其实没有人去看；更为重要的是，产品交付之后需求变更很多。这之后，我就开始 关注软件全生命周期的方法、技术和工具，于是了解了敏捷。最早是XP，然后是Scrum。08年我去了一个新的项目组，这个组没有开发流程方法，也不知道 如何做需求，于是我在这个组实践了一些新的方法，其中包括Scrum。在Scrum的实施过程中，我发现并不像最初想象的简单。看似简单的流程和角色，真 正要发挥功效并不容易，除了技术能力之外，我还需要让自己学习更多管理方法，更需要自己深入领悟敏捷管理背后的东西。对Scrum的深入思考，我越发觉得 团队中每个人的成长是敏捷发生效果的动力，这让我对个人管理这个话题有了更加浓厚的兴趣，于是把自己在个人管理和个人成长方面的思考写下来，并在团队中学 习和实践。团队中的成员有自发打印出来给家属学习的，也有主动参与讨论的，以及后期社区对敏捷个人的认可，这都鼓励和激发我慢慢系统化的思考个人成长，并 提出了敏捷个人。 经过两年多的思考，目前敏捷个人已经是一个较为体系的个人成长框架，它可以帮助个人成长，并促进敏捷团队的形成。

记者：请问敏捷开发是否真的能解决传统开发的一些问题？如何去认识敏捷的根本？

周金根：从瀑布到敏捷，我们已经发现产品更适合用户、质量越高、上市时间也越短，敏捷顺应不断变化的时代，是否能解决传统开发已经不是一个问题。对于敏捷，我认为其根本在于学习和适应，这也是拥抱变化需要具备的两项最重要的能力。

 

 

记者：团队的敏捷实践与管理是分不开的，您是怎么看目前国内的管理？

周金根：在没有敏捷之前我们就在管理，但在敏捷盛行的时候，有些管理者就分不清敏捷和管理了。其实我不太在意某种最佳实践出自哪种敏捷方法，我认为 只要有利于当前团队的实践都是管理的一种工具，也就是说，作为管理者，我们仍需保持更大的视角，敏捷仅是管理的一种工具，我们还要学习目标设定、流程优化、团队建设、个人成长等更多管理方法。

记者：有些人认为敏捷开发并不适用于水平一般的程序员或团队，您是怎么认为的？

周金根：任何方法都不是银弹，也说明了没有一种方法是完美的。既然没有完美的方法，那自然也不必是完美的人去执行了。水平高的程序员在技术实践领域 的敏捷固然可以做得更好，但一个产品的失败大多数都不是因为你是否采用了测试驱动、结对编程等最佳实践，而是开发管理上的问题。Scrum作为一种敏捷方 法，背后具有很多管理思想，只要管理者和团队对Scrum有进一步的思考和认识，也可以很大程度上去提高技术水平一般的程序员团队。

周金根：敏捷方法在国内实施起会导致项目管理原有模式的改变，而很多公司都没有达到敏捷的目的。以致公司往往不愿意引进这样的开发模式。您怎么看待这个问题呢？

回答：从公司角度来说，你能把软件越快越好的做出来就可以了，至于采用的是敏捷还是瀑布并不重要。与其说是公司不愿意引进这种模式，不如说是软件开 发负责人不愿意或者没有能力引进新的方法。敏捷开发相对来说已经比较成熟，我认为现在不是讨论是否愿不愿意引进这种开发模式的时候，反而是思考如何引进的 问题，这不仅仅是技术实践，还有管理，甚至是个人成长方面的改变。

记者：团队的人数对于敏捷开发有何影响？如何进行拆分？

周金根：人数的规模会带来团队的复杂性，随着人数增加，管理、沟通等都会越来越困难。而保持7±2人左右的小团队，可以更利于团队的形成。在这样的 团队中，人与人之间都更为熟悉，协作起来就更容易。那这样的小团队由哪些人组成呢？这也需要根据产品的规模来定。对于一个小型产品，这个团队将由市场、需 求、开发、测试等人员组成全功能性团队；如果产品属于中大型，那有可能会形成单一功能性团队，再由多个这样的团队组成一个大的敏捷团队，由这个大的团队来 实现对客户的交付。

记者：敏捷实践过程中Scrum实施整个过程怎样规划。

周金根：实施Scrum，我们可以采用类似学习一样的过程，首先完全按照Scrum流程执行；然后再根据执行后的效果进行自我裁剪和补充；最后淡化Scrum的概念，与更大范围的软件产品周期过程融合起来。

记者：敏捷开发的方法内有很多不同的程度，而几乎每个敏捷开发团队都有scrum会议，在您们的团队中是如何进行的？

周金根：沟通在任何团队都是必不可少的，而会议是其中一种。我认为Scrum中的Sprint计划会议是最重要的事件，这确定了每次迭代的目标。回 顾会议是第二重要的事件，因为这是团队做改进的最佳时机，如果没有回顾，就会发现团队在重犯相同的错误。如何进行可以看看我之前写的几篇blog：

1、Scrum之 Sprint计划会议（以下内容摘自周金根博客）

在sprint第一天召开sprint计划会议，这个会议分为两部分，计划会议1由PO、SM和Team参加，主要是从产品 backlog中挑选出需要放到当前sprint下的既定产品backlog，然后由SM、Team参加计划会议2，把既定产品backlog的故事拆分 成任务进行估算，PO也可以一起参加这个部分来了解具体的开发细节。以下我将把会议主要内容罗列一下。

会议内容

sprint计划会议1

产品负责人和团队一起，在先前评估的成果基础上，定出 Sprint 目标和既定产品Backlog。

目标

定出 Sprint 目标和既定产品 Backlog

会议准备

• 邀请与会者：产品负责人、Scrum Master、团队所有成员
• 已按优先级排列产品 Backlog 中各项问题
• 已评估 Backlog 中的各项问题
• 把产品 Backlog 公开给会议中的每个人，保证其可被获取
• 预期团队中有哪些人已明确会缺席（如度假）
• 保证房间环境适合小组讨论
• 每个人都可以获取上次 Sprint 评审会议和 Sprint 回顾会议的结果

1. Sprint 时间表已经安排
2. Sprint 计划会议 1 的时间安排
3. Sprint 计划会议 2 的时间安排
4. Sprint 的第一天已确定
5. Sprint 的最后一天已确定
6. Scrum 每日例会的时间安排
7. Sprint 评审会议的时间安排
8. Sprint 回顾会议的时间安排

• （可选）为既定 Backlog 准备图钉板:一个至少 2x2 米的图钉板、卡片和贴纸、荧光笔
• （可选）用作计划纸牌的卡片

会议进程（4 小时）

• 把 Sprint 时间表公开给所有人
• 把 Sprint 评审会议的结果公开给所有人
• 把 Sprint 回顾会议的结果公开给所有人
• 产品负责人向团队产品阐述产品远景
• 产品负责人和团队一起确定 Sprint 目标
• 如果 Backlog 里有问题遗漏：产品负责人有权限往 Backlog 里添加问题
• 如果产品 Backlog 完全未被评估：选择 Backlog 中您认为是最小用例的问题，并指派其工作量为 2 个Story Point。以这个最小用例的工作量标准，分配 Backlog 中其他问题的 Story Point
• 如果 Backlog 中的一些问题尚未被评估：根据其他问题工作量，评估这些问题的 Story Point 量
• 如果产品 Backlog 中的各项还没能合理地按优先级排序:产品负责人对产品 Backlog 中的各项按优先级排序
• 产品负责人和小组成员相互认可这 Sprint 目标和既定产品 Backlog

会议结果

为Sprint计划会议2的进行准备好既定产品 Backlog

sprint计划会议2

在 Sprint 计划会议 2 中，团队将既定产品 Backlog 中的每一项细化成多个任务。每个任务完成的时间限定在一天内。

目标

确定所有任务，生成 Sprint Backlog，确认 Sprint 目标

会议准备

• 邀请与会者：Scrum Master、团队所有成员、产品负责人（可以有权得知所有问题）
• 任务规划时可以参考既定产品 Backlog
• （可选）为既定 Backlog 准备图钉板:一个至少 2x2 米的图钉板、卡片和贴纸、荧光笔

会议进程（4 小时）

• 团队成员从 Backlog 的各项问题中分出相应的任务
• 确保考虑到工作中所有的细节:编码、测试、代码评审、会议、学习新技术、编写文档
• 如果任务需时超过一天：尝试把该任务分割成几个小任务
• 如果团队认为 Sprint Backlog 中项过多：和产品负责人一起删减 Backlog 中的问题
• 如果团队认为 Sprint Backlog 中的项过少：和产品负责人一起从产品 Backlog 中选出最重要问题，加入Sprint Backlog 中
• 团队确认 Sprint 目标

会议结果

• Sprint 目标和 Sprint Backlog 对于公司内的所有人都是公开的
• 所有团队成员都可以获取 Sprint Backlog 中的任务

2、Scrum之 站立例会（以下内容摘自周金根博客）

在sprint期间，每天都会通过站立例会来进行沟通，以下我将把会议主要内容罗列一下。（以下会议内容来自于Scrum Checklists)

 

会议内容

目标

团队成员间工作进度的沟通和协调

会议准备

• 邀请与会者：团队所有成员、Scrum Master、产品负责人（可选）、相关人员（可选）
• 在Sprint Backlog 上的所有任务都是可以增删修改，可重排序的
• 任务的状态可设为todo、doing、done（可以再加一个test表示需要验证）

会议进程（15 分钟内）

• 上次会议时的任务哪些已经完成：把任务从“正在处理”状态转为“已完成”状态
• 下一次会议之前，你计划完成什么任务？ •如果任务状态为“待处理”：转为“正在处理”状态

1. 如果任务不在 Sprint Backlog 上：添加这个任务
2. 如果任务不能在一天内完成：把这任务细分成多个任务
3. 如果任务可以在一天内完成：把任务状态设为“正在处理”
4. 如果任务状态已经是“正在处理”：询问是否存在阻碍任务完成得问题

• 有什么问题阻碍了你的开发：如果有阻碍你开发进度的问题，把该障碍加入到障碍 Backlog 中
• 如果展开了一个问题的讨论：提醒团队的成员们注意把精力集中在回答关键问题上
• 如果相关人员想发表些言论：礼貌地提醒他，该会议只允许让小组成员讨论

会议结果

• 得到最新的障碍 Backlog
• 得到最新的 Sprint Backlog
• 最新的工作进度图

其他

可以指定一个主持人（或轮流）。他来召集并控制会议时间，会议中注意引导话题，在会议结束时可以做个简短的总结，说出重点就行，做好每日规划。

3、Scrum之 评审会议（以下内容摘自周金根博客）

在sprint周期最后，需要进行一次评审会议，让团队向产品负责人和利益相关者展示已完成的功能。sprint审核的大部分实践用于团队成员展示 功能、回答利益相关者对展示的疑问并记录所期望的更改。评审会议可以吸引相关利益者的关注，让其他人了解团队在做些什么，并得到重要反馈。做演示也会迫使 开发团队真正完成一些工作。

• 小组准备好工作站和设备等等，用以展示产品的新功能
• 团队准备sprint审核实践不应超过1小时

会议进程（4小时）

• 确保所有人员都清晰目标，如果有人对产品不知道，则花几分钟来进行描述。
• 团队按 Backlog 中的问题，逐个地介绍这次 Sprint 的结果，和演示新功能。
• 如果产品负责人想要改变功能：添加一个新问题到产品 Backlog 中
• 如果对功能有一个新的想法：添加一个新问题到产品 Backlog 中
• 如果小组报告项目遇到阻碍现在还没能解决：把该障碍加入到障碍 Backlog
• 会议结束时，ScrumMaster向产品负责人和全体利益相关者宣布下一次审核的地点和时间。

会议结果

• 对这次 Sprint 的结果和整个产品的开发状态的共识

其他

• 让演示关注业务层次，不要关注技术细节。注意力放在“我们做了什么”，而不是“我们怎么做的”
• 有的sprint可能会包含很多bug修复等功能，在评审会议中不要演示太多一大堆细碎的bug修复，除非这个很重要。

4、Scrum之 回顾会议（以下内容摘自周金根博客）

Scrum中Sprint计划会议是最重要的事件，第二重要的事件就是回顾会议，因为这是团队做改进的最佳时机。如果没有回顾，就会发现团队在重犯相同的错误。在sprint的评审会议后，团队需要进行一次回顾会议，以下我将把会议主要内容罗列一下。（以下会议内容来自于Scrum Checklists和scrum-and-xp)

会议内容

目标

通过总结以往的实践经验来提高团队生产力。

会议准备

• 邀请与会者：  Scrum Master、团队所有成员 、产品负责人（可选）
• 附属工具：为所有参与者准备的荧光笔、贴纸、白板磁吸、白板和挂纸板
• 准备一个回顾白板，分三列。第一列和第二列是回顾过去，第三列是展望将来。

1. Good：如果重做同一个sprint，哪些做法可以保持
2. Could have done better：如果重做同一个sprint，哪些做法需要改变
3. Improvements：有关将来如何改进的具体想法

 

会议进程（1－3小时）

• 介绍会议目标和议程
• 准备（setting the stage）：制定和回顾团队价值观和约定（Team values and working agreements）：(10-30分钟）

1. 不管我们现在发现了什么问题，我们必须懂得并坚信每个人通过他们当时所知的，他所拥有的技能和可得到的资源，在限定的环境下，都尽其所能做出了最好的成绩
2. 每个人都参与
3. 坦诚交流
4. 多说I，少用You
5. 不深究具体业务细节内部问题

• 收集数据（Gather Data）：收集硬数据：事件（events）、度量（metrics）、完成的故事等

1. 事件：对团队每个人都重要的任何事件，包含会议、决策点、里程碑、采用新技术等，例如上期回顾会议中确定的改进项是否执行了
2. 度量：包含燃烧图、速度、bug数、完成故事点数、代码重构数等

• 产生见解（Generate Insights）：多问“为什么”，从收集的数据中找出优点和问题

1. 向与会者解说如何使用该贴纸进行工作：使用贴纸时，注意一张贴纸只记录一件事。
2. 派发贴纸，通过头脑风暴分别得出回顾白板三列的所有想法。

• 确定改进项（Decide What to Do）

1. 每人三票，投票决定下一sprint着重进行哪些改进（2－5项左右）。

• 结束回顾（Close the Retrospective）

1. 给会议做个总结，表明下一个回顾会议需要跟踪哪些做法

会议结果

• 回顾白板，以及下一sprint需要改进的做法，在下一个回顾中，会跟踪这些改进的执行情况把障碍增加到障碍 Backlog 中去 

记者： 对于未来几年敏捷开发的发展，您希望看到哪些新方向?有何建议?

周金根：敏捷只是一个代名词，我希望它不仅仅只包含开发，还能能够在基于敏捷思想下，把方法框架扩充到市场、业务、营销环节等软件产品开发全生命周期。

转：http://developer.51cto.com/art/201303/387329.htm

 

推荐：你可能需要的在线电子书

敏捷个人sina微刊：http://kan.weibo.com/kan/3483302195814612

 欢迎转载，转载请注明：转载自敏捷个人网站