周金根：个人敏捷的创立与详解Scrum会议
个人简介：周金根，个人成长教练，软件产品架构师，培训师，敏捷个人创立者和推广者。
以下内容为采访实录：
记者：请问你是如何接触到敏捷开发的？敏捷个人的创立是出于什么样的想法？
周金根：最早我们是采用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 回顾会议的结果
- Sprint 时间表已经安排
- Sprint 计划会议 1 的时间安排
- Sprint 计划会议 2 的时间安排
- Sprint 的第一天已确定
- Sprint 的最后一天已确定
- Scrum 每日例会的时间安排
- Sprint 评审会议的时间安排
- 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 分钟内）
- 上次会议时的任务哪些已经完成：把任务从“正在处理”状态转为“已完成”状态
- 下一次会议之前，你计划完成什么任务？ •如果任务状态为“待处理”：转为“正在处理”状态
- 如果任务不在 Sprint Backlog 上：添加这个任务
- 如果任务不能在一天内完成：把这任务细分成多个任务
- 如果任务可以在一天内完成：把任务状态设为“正在处理”
- 如果任务状态已经是“正在处理”：询问是否存在阻碍任务完成得问题
- 有什么问题阻碍了你的开发：如果有阻碍你开发进度的问题，把该障碍加入到障碍 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、团队所有成员 、产品负责人（可选）
- 附属工具：为所有参与者准备的荧光笔、贴纸、白板磁吸、白板和挂纸板
- 准备一个回顾白板，分三列。第一列和第二列是回顾过去，第三列是展望将来。
- Good：如果重做同一个sprint，哪些做法可以保持
- Could have done better：如果重做同一个sprint，哪些做法需要改变
- Improvements：有关将来如何改进的具体想法
会议进程（1－3小时）
- 介绍会议目标和议程
- 准备（setting the stage）：制定和回顾团队价值观和约定（Team values and working agreements）：(10-30分钟）
- 不管我们现在发现了什么问题，我们必须懂得并坚信每个人通过他们当时所知的，他所拥有的技能和可得到的资源，在限定的环境下，都尽其所能做出了最好的成绩
- 每个人都参与
- 坦诚交流
- 多说I，少用You
- 不深究具体业务细节内部问题
- 收集数据（Gather Data）：收集硬数据：事件（events）、度量（metrics）、完成的故事等
- 事件：对团队每个人都重要的任何事件，包含会议、决策点、里程碑、采用新技术等，例如上期回顾会议中确定的改进项是否执行了
- 度量：包含燃烧图、速度、bug数、完成故事点数、代码重构数等
- 产生见解（Generate Insights）：多问“为什么”，从收集的数据中找出优点和问题
- 向与会者解说如何使用该贴纸进行工作：使用贴纸时，注意一张贴纸只记录一件事。
- 派发贴纸，通过头脑风暴分别得出回顾白板三列的所有想法。
- 确定改进项（Decide What to Do）
- 每人三票，投票决定下一sprint着重进行哪些改进（2－5项左右）。
- 结束回顾（Close the Retrospective）
- 给会议做个总结，表明下一个回顾会议需要跟踪哪些做法
会议结果
- 回顾白板，以及下一sprint需要改进的做法，在下一个回顾中，会跟踪这些改进的执行情况把障碍增加到障碍 Backlog 中去