【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
会议准备
会议进程（4 小时）
会议结果
为Sprint计划会议2的进行准备好既定产品 Backlog
sprint计划会议2
在 Sprint 计划会议 2 中，团队将既定产品 Backlog 中的每一项细化成多个任务。每个任务完成的时间限定在一天内。
目标
确定所有任务，生成 Sprint Backlog，确认 Sprint 目标
会议准备
会议进程（4 小时）
会议结果
2、Scrum之 站立例会（以下内容摘自周金根博客）
在sprint期间，每天都会通过站立例会来进行沟通，以下我将把会议主要内容罗列一下。（以下会议内容来自于Scrum Checklists)
会议内容
目标
团队成员间工作进度的沟通和协调
会议准备
会议进程（15 分钟内）
会议结果
其他
可以指定一个主持人（或轮流）。他来召集并控制会议时间，会议中注意引导话题，在会议结束时可以做个简短的总结，说出重点就行，做好每日规划。
3、Scrum之 评审会议（以下内容摘自周金根博客）
在sprint周期最后，需要进行一次评审会议，让团队向产品负责人和利益相关者展示已完成的功能。sprint审核的大部分实践用于团队成员展示 功能、回答利益相关者对展示的疑问并记录所期望的更改。评审会议可以吸引相关利益者的关注，让其他人了解团队在做些什么，并得到重要反馈。做演示也会迫使 开发团队真正完成一些工作。
会议进程（4小时）
会议结果
其他
4、Scrum之 回顾会议（以下内容摘自周金根博客）
Scrum中Sprint计划会议是最重要的事件，第二重要的事件就是回顾会议，因为这是团队做改进的最佳时机。如果没有回顾，就会发现团队在重犯相同的错误。在sprint的评审会议后，团队需要进行一次回顾会议，以下我将把会议主要内容罗列一下。（以下会议内容来自于Scrum Checklists和scrum-and-xp)
会议内容
目标
通过总结以往的实践经验来提高团队生产力。
会议准备
会议进程（1－3小时）
会议结果
记者： 对于未来几年敏捷开发的发展，您希望看到哪些新方向?有何建议?
周金根：敏捷只是一个代名词，我希望它不仅仅只包含开发，还能能够在基于敏捷思想下，把方法框架扩充到市场、业务、营销环节等软件产品开发全生命周期。
转：http://developer.51cto.com/art/201303/387329.htm
推荐：你可能需要的在线电子书
敏捷个人sina微刊：http://kan.weibo.com/kan/3483302195814612
欢迎转载，转载请注明：转载自敏捷个人网站
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
