【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
欢迎转载,转载请注明:转载自敏捷个人网站