Scrum，幸福来得挺突然

    某天，正在驾校学车，突然收到Boss的短信“请将敏捷开发方法总结一下，我们全公司推广”，当时有个师弟刚开始练倒车，正被师傅揪着耳朵教训，想想自己走过来的路，偶一阵得意。
    偶现在的公司做的是金融服务，软件开发团队分为四个事业部，大约一百多号人，偶在三个季度左右的时间里担任其中一个事业部的开发团队负责人。现在回忆起最初的那段日子依然心有余悸，相信好多在软件行当里混的兄弟们都经历过某些类似场景：
创业型公司，来自产品和业务部门的需求积压着一大堆，而且一个比一个紧急；
包括QA和SCM在内也就十个人左右的团队像一台小挖掘机，一点点消耗着需求大山；
包括负责人在内的所有人都参与开发，解决关键问题紧急问题，松散的任务跟踪导致了一边是做不完的事情，一边是大量开发人员灰色时间的浪费；
生搬硬套的所谓RUP流程划分了一堆角色，定义了各个角色在流程中要做的事情，于是每个角色很“负责”地履行自己的职责，你会看到产品负责人费了好长时间整理的的需求文档被开发和QA团队不断地否决重做，开发团队发布的产品因为达不到测试标准不断被QA踢回，整个项目的周期没有办法有效控制；
业务人员急到骂娘，项目还是会卡在某个环节上，因为环节上下方对某个问题的不同看法而停滞不前；
团队士气低落，开发人员有任务就做，得空就做布朗运动，看博客，玩网页游戏；
嘈杂的开发环境，不断被业务人员和用户投诉打扰，开发人员日有效工作时间在50%左右；
做出来的产品经过开发和QA的测试都没问题了，一上线就出事，然后被业务的同事一顿臭骂，开发团队在公司里的地位越来越低，被鄙视程度越来越高；
大家偶尔也会一起坐下来讨论如何改进，却往往找不到有效的方法，最后随波逐流；
每天都在忙，下班以后脑袋里却空空如也，一无所获；
一切看起来都没有拯救的希望，你似乎要永远地跟问题生活在一起......
    嗯，我承认我有些渲染气氛，不过上面描述的情况都在我所在的部门发生了，作为负责人的我必须找到一个出路才能活下来。这个时候，我读到一本名叫《硝烟中的Scrum和XP》的小册子。
    至今我还记得读这份文档的心情，仿佛久病的人找到了可以疗救顽疾的灵药，150页的pdf文档，一天的工作时间，细细地读完，生怕漏掉一个字。如果可能，我真想当晚就召集team里的同学，把文档中提到的敏捷方法共享给大家，然后马上开始实践。
    实际开始跟team探讨和实施Scrum的时间是在接下来的两天里，把分散的team成员集中到一起，腾出一面墙做任务墙，赶着定制Backlog模板......（此处略去实施过程）
    实施Scrum是在六月初，七月份我加入到另外一个部门，原部门继续实施Scrum。前两天收到了一份来在公司QA team的项目统计报告，我待过的那个部门7-8月份完成的任务量超过了上个季度的总工作量，而且产品质量还有所提升--这是在我这个原负责人离开的情况下做到的（原来在的时候还可以帮团队分担相当一部分工作）；考虑到Scrum是从6月份开始实施的，这样算起来Scrum实施前后的团队战斗力提升了50%左右。
    于是，就有了开头我收到的Boss发来的那条短信。收到短信后，仔细考虑了一下Scrum到底如何给团队带来改变，结合实际的实践过程，整理了一份演示文稿，思虑再三，始终是原著《硝烟中的Scrum和XP》讲解的透彻，于是把自己的文档命名为导读，跟原著一起附在下面，共享给在开发困境中挣扎的xdjm们。
原著：《硝烟中的Scrum和XP》-- http://www.infoq.com/cn/minibooks/scrum-xp-from-the-trenches
我整理的导读： -- http://www.slideshare.net/ohmygodlzl/scrum-1993831
如果slideshare访问不了，请从附件下载

评论

71 楼 lookdd1 2010-07-31  

偶和LZ一样。同样是看了这本电子书就在团队中实施SCRUM。但限于技术能力，我们没有做单元测试，使用hudson做CI，同样没有自动化测试。使用cvssat+bat+apache做 CVS每日统计，使用jira做BUG管理。scrum的很多想法都是切中要害的，是完完全全为了做好项目而准备的。我们团队的大多数水平都是非常菜，他们甚至都没听说过敏捷，我也没和他们解释这就是敏捷。OK。就跟着我这么做吧！   效果很好！ 

70 楼 scott.yao 2010-07-02  

ohmygodlzl 写道

taochenpfj 写道

学习，学习！根据实际情况来说，楼主不会仅仅看过这么一个电子书就敢去实施了吧？如果有什么好的学习资料（书啊什么的），烦请分享一下！！！

根据实际情况来说，我确实是看了这么个电子书就去实施Scrum了，没有别的什么参考资料。不过如果追究起来的话，在九年软件开发经历中，待过无固定流程的开发项目组，看过别的团队实施XP，亲自参与过CMMI5和较重的瀑布式开发方法所指导的项目，对RUP也有了解（现在的公司流程就采用裁剪过的RUP，不过变味了），我相信这些经历--正面的和反面的--会让我在尝试新的方法时能把握一点分寸，有的放矢。

无论是瀑布，RUP，CMMI，还是XP，SCRUM，这些都是些实践组合而已，打个比方，是一些老中医开的经典方子而已，每个方子都有各自的对症，针对不同的团队模型，项目性质，用错了不但无益反而有害。方子固然重要，组成方子的药更重要，理解这些药的用法，原理和对症是好的管理人员必须具备的素质。粗略的划分，我把这些药分为三类：对项目进度有益的，对项目质量有益的，对团队合作有益的。简要列一下：
对项目进度有益的：

• 迭代开发 -- 来自RUP
• 每日例会 -- 来自XP
• Checkpoint或milestone -- 来自瀑布方法
• 任务墙 -- 来自Scrum
• Backlog -- 来自Scrum
• 守门员 -- 来自Scrum相关资料
• 团队基准能力度量 -- 来自CMMI
• ...

对项目质量有益的：

• 单元测试 -- 来自XP
• Code Review -- 不知到来自哪里
• Double Check -- 我们自创的，对项目关键发布制品进行复核
• Checklist -- 不知到来自哪里，记录所有项目开发中犯过的错误
• 缺陷密度，质量度量 -- 来自CMMI
• ...

对团队合作有益的：

• Sprint会议 -- 来自Scrum
• 结对编程 -- 来自XP
• Sprint回顾 -- 来自Scrum
• ...

这是我的分类而已，每个人可以有自己的分类标准。这里关键的思路是：吸取每种开发方法，开发模型，开发框架中的有益实践，然后根据所在的团队结构，项目类型，存在问题进行对症下药。

大家经常在争论哪种开发方法更好，我觉得，每种方法都藏着智慧在里面，把精华部分拿出来，理解清楚，做头脑清楚的老中医，才是正道。

对各种药进行分类划分,很不错的方法,深入理解药品的药性,找到项目过程中的症结,开出合适的药方.
开药方也要小步的来,plan-do-check-action.随时调整,才是王道.

69 楼 squall140 2010-06-04  

其实我认为小团队的话，这种管理思想是尤为可以借鉴的

小团队易于沟通，项目组之间协作便捷，人员成本低。

开发周期总体缩短。何乐而不为呢？

68 楼 joknm 2010-06-04  

管理的书籍层出不穷，各有各好，收藏，实事求事，就地取材，才是硬道理，呵呵。

67 楼 imlsq 2010-05-29  

这个帖子真长，看了一个小时才看完

我们现在也在实施Scrum。

其实大家都存在一个误区。我的体会是“以人为本”为前提，团队需要在一个民主，轻松的环境中进行迭代开发。否则无论是rup,scrum,还是瀑布式开发都会解决不了问题。

目前我们在这样实施：

1：团队8个人中，没有决对的权威，领导的人存在，大家都是一种合作关系。这个问题其实在中国是最麻烦，很多PM，或者技术经理是不愿意坦诚的和团队成员保持平等。而是希望统治他们，srcum能不能实施成功，首先那些所谓的领导最需要调整好心态，不然必然失败

2：我们以2周左右为一个sprint,master角色是轮流做的。也就是说团队中的每个成员都有机会感受到master的角色。当程序员亲自感受到做master的难处与压力时，会主动具有求变的意愿。这样几个迭代下来后，大家都愿意接受新的东西，大家都很容易达成共识，而不是由技术经理或者某个所谓的master主动定出一些规则或者规范去强制实施。

3：为了保证程序的质量，QA和开发人员虽然不是在一个部门，但是他们会在一个工作小组团队中工作。这样软件的质量一下就提上去了。每个backlog都会有QA非常严格的测试。

说了这么多，其实关键的还是人，以人为本，srum不是万能，最重要是那些所谓的项目经理，技术经理，主管等等人员调整心态，以平等的心态和团队人员一起工作，而不是以一种权威去统治他们的思想。

66 楼 dearwolf 2010-05-25  

sprite72 写道

你好。请问敏捷开发轻文档，那么随着时间的推移项目中的人员必然发生变动，如果没有详细的文档指导，后加入的人员如何快速进入团队开发，如何理解前辈们的设计思想呢？

你可以先问一下你们现在团队里面的人，他们是如何快速进入团队开发的。

65 楼 srdrm 2010-05-21  

各位在最后都谈到目标（一致）， 心态（积极，开放），责任（承担，信守诺言）

我最近也碰到了一些问题，思来想去，也认为这是最根本，最重要的。如果团队缺少这些，或不够整齐划一，统一思想，呵呵。实施什么方法都有可能不同程度打折扣，最严重的就是项目，产品失败。

如果一个具备这些条件的团队，再多的问题，都能搞定。不是吗？

lz说的“如果给我一个团队........”，非常欣赏，软件项目中的爷们。

在这里跟大家学习了，谢过lz及各位的分享

64 楼 eyejava 2010-04-03  

看来看去，团队本身才是最重要的，以前CharlesXP 的XP介绍 我也认为XP团队需要好的人才，未必是技术牛人，善于沟通、进取、发现问题、改进问题的人，由这样一群人组成的团队+一个高瞻远瞩的团队领导，用scrum中那些实践是自然而然的事情。

scrum对于这样的团队或许只是一面大旗，将他们本身有的优点都发挥出来了

现在我们的问题是没有这么一群人，公司wiki简直成了自留地，技术培训也沦为形式，上层也没有这套人员素质要求和过程改进的想法。

63 楼 一蓑烟雨任平生 2010-01-25  

至于团队合作这样的软性指标，更多是一种措辞，项目经理首先要做好定位，搞清楚哪些是自己该做的，哪些是公司该做的，你要做的就是用手上的资源把项目做好。
把业务需求理解清楚，把任务分解调度好，对客户、对上级做好沟通，减少对项目组的干扰，按时把工作做好，最终的目标是按时能拿到奖金。
目标单一，其它的都是手段，方法的引进只是为了解决最关键的问题，一次能做好一个就是成功。

62 楼 一蓑烟雨任平生 2010-01-25  

开发能否成功，在于各个角色是否明白各自应该担当的工作内容，目标要一致，我把项目的角色分为主担、辅担两类，业务开发是项目的主担，对项目负责，管理是辅担，由公司管理部门对项目的过程指标进行检查和提供帮助。两类角色都是非常必要的，只是要有侧重，尽管相互制衡，但是管理角色做的是辅助流程，不是关键路径，就是不要过早的让这些角色由“一票否决”的权力。
开发主担主要是业务分析、设计、开发和测试，实际上抓好两个关键要素就可以，一个是业务设计，一个是任务管理。任务管理的基础也是业务设计充分，不清楚不做，粒度要细，要让开发人员真正明白要做什么。之所以项目做不好，业务理解设计不充分占绝大多数，造成任务的分解做不下去，文档也写不好，一个项目业务的理解其实掌握在少数人手里面，不可能全部都清楚，是个逐步细化和知识转移的过程，这就要求每日的沟通，明白这一点，就知道怎么去做好项目，其它的都是技术手段。
至于管理控制环节，比如SCM、QA，则要尽量的让大家感觉不到他们的存在，他们只是按计划在关键节点时出现，并且随时提供支援。审核的发起由他们来做，结果的判定以业务满足和客户开发过程标准满足为主，在能力不足的情况下，不要让他们有影响项目进度的决策权，项目经理做方案，公司领导来决策。测试也直接纳入到项目经理的管理，对项目经理负责。
敏捷、Scrum等都是提供了一些很好的方法，不过做项目首先要明白做什么，这个问题解决了，方法就有用武之地。

61 楼 sprite72 2010-01-25  

你好。请问敏捷开发轻文档，那么随着时间的推移项目中的人员必然发生变动，如果没有详细的文档指导，后加入的人员如何快速进入团队开发，如何理解前辈们的设计思想呢？

60 楼 taochenpfj 2009-10-23  

ohmygodlzl 写道

to taochenpfj:
    这两天正忙着一个项目，所以回复的有点迟，见谅。对你所处的团队的情况，我只能从你的帖子中了解一二，要提出针锋相对的建议不太现实，所以我还是陈述一点自己对软件开发管理方面的看法，希望能旁敲侧击地对你有所帮助。
    虽然做了挺长时间的项目/团队管理，我个人更感兴趣的还是纯技术的工作（我现在又回到了架构师的岗位）。我认为，决定一个软件项目的成功与否的因素大的方面就是两个：适合团队的工程方法和适合需求的架构设计。
    先说工程方法。我在那份PPT中提到过，拨开各类复杂问题和工程方法的迷雾，你要实现的目标无非就是“在尽可能短的时间内完成高质量的软件开发”，这里只有两个要求，开发进度和软件质量。软件管理者要管理的核心内容，PMP提到的九大管理内容，说到底也就是这两个而已。既然问题简化了，你就可以看为了保证和跟踪开发进度，你需要引入哪些实践，为了保证软件质量降低项目风险，你要引入哪些实践----这里保守的态度是应该鼓励的，不要一下子尝试太多新东西，如果你是用Scrum，在基本的3+3+3的基础上，每个sprint引入1-2个新实践就很多了，严格遵循plan-do-check-action的方法来引入实践。再强调一下这一段我想表达的意思，如果你找不到头绪，就分析一下你的基本目标，越基本越简单越好，然后选择一个基础的起点起步，让适合团队的工程方法随着团队一起成长。
    再说一下团队。如果给我一个团队来做项目，我对这个团队的成员的要求是：他们可以没有优秀的技术能力，可以不熟悉各种软件开发工程方法，只要他们具备后面列的这些素质就可以--开放，进取，包容，责任心。当然，这个团队中还必须有一位比较资深的分析设计人员（可以是管理者自己）。技术能力可以培养，工程方法只是药方，这些都可以学的。要学习，就要求团队成员必须开放，乐于沟通会沟通（跟闷葫芦合作是一件让人抓狂的事情）；成员要有点小理想，知道自己要什么，有追求有进取心，才有工作的动力；团队合作要能够容纳不同观点，能够接受别人的工作生活习惯（比如可以忍受坐在你对面那个家伙的臭脚）；团队成员需要信守承诺，交给的任务需要负起责任（说一百做五十的家伙要不得）。要让团队成员在某种尝试上达成一致，只需要把握住一个基本问题：大家放弃了在家睡大觉逛街陪家人的机会出来工作，为了什么？我觉得钱的原因是排第一二位的，然后呢，可能是精神层面的因素，比如成就感，跟人交流合作的快乐，而这些都或多或少跟一个因素挂钩----学习的愿望。人（好吧，正常人）天生就有学习的愿望，引入一种新的工程方法本身就是一次学习的机会，不论成功与否每个人都可以从中受益----这一点明确了团队就比较容易达成一致。
    最后说一下架构设计。适合的工程方法装备起来一支高效的团队，但是如果按照一张不合理的设计图纸，一样会盖出一座危楼。这里就是架构设计的重要性，它比工程方法更多地影响到软件质量。架构设计我认为没有什么外部方法可以帮上忙，每个团队拥有一个比较资深点的分析设计人员是必须的，他需要综合把握软件系统的功能和非功能性需求，设计一个健壮的有生命力的系统。这是一个另外的领域，这里不多讲。
   最后说一句，别担心失败，也别让自己还没上路就累垮，困难都是你走向高处的垫脚石，生活就是问题叠着问题，不抛弃不放弃，呵呵。

读君一席言胜读十年书啊！真的非常感谢您的回复！曾经我的一个同事跟我说过：不要觉得你的行业里没有高手，只是你还没到那个层次，就根本看不到高手！呵呵，我不是说自己已经到了“那个层次”了，只是我幸运地碰到了高手！

对于您的建议，我会谨记在心的，尤其是最后一句，之前我也有些内心的表露，就是一种担心，项目的规模和挑战都是我没经历的，尽管我也算是做了一两个项目，但是要实施新的项目管理方法，要设计新的项目架构，心里面总是有太多的不确定性，很担心失败！对于各种项目管理实践，在我们公司又受到管理层的介入，很多实施不能顺利进行，困难不是一般的多！不过如您所说，我不会放弃的，呵呵！毕竟都走了这么长时间，我没有多少放弃的理由，我组内的信任我的同事们也不会认可我放弃的理由的！

对于您的关注重点，我也是非常感兴趣的，也很想专注的研究软件架构，有机会考考研，呵呵，争取与高手为伍！！

再次感谢您百忙之中给我回复！

59 楼 ohmygodlzl 2009-10-20  

to taochenpfj:
    这两天正忙着一个项目，所以回复的有点迟，见谅。对你所处的团队的情况，我只能从你的帖子中了解一二，要提出针锋相对的建议不太现实，所以我还是陈述一点自己对软件开发管理方面的看法，希望能旁敲侧击地对你有所帮助。
    虽然做了挺长时间的项目/团队管理，我个人更感兴趣的还是纯技术的工作（我现在又回到了架构师的岗位）。我认为，决定一个软件项目的成功与否的因素大的方面就是两个：适合团队的工程方法和适合需求的架构设计。
    先说工程方法。我在那份PPT中提到过，拨开各类复杂问题和工程方法的迷雾，你要实现的目标无非就是“在尽可能短的时间内完成高质量的软件开发”，这里只有两个要求，开发进度和软件质量。软件管理者要管理的核心内容，PMP提到的九大管理内容，说到底也就是这两个而已。既然问题简化了，你就可以看为了保证和跟踪开发进度，你需要引入哪些实践，为了保证软件质量降低项目风险，你要引入哪些实践----这里保守的态度是应该鼓励的，不要一下子尝试太多新东西，如果你是用Scrum，在基本的3+3+3的基础上，每个sprint引入1-2个新实践就很多了，严格遵循plan-do-check-action的方法来引入实践。再强调一下这一段我想表达的意思，如果你找不到头绪，就分析一下你的基本目标，越基本越简单越好，然后选择一个基础的起点起步，让适合团队的工程方法随着团队一起成长。
    再说一下团队。如果给我一个团队来做项目，我对这个团队的成员的要求是：他们可以没有优秀的技术能力，可以不熟悉各种软件开发工程方法，只要他们具备后面列的这些素质就可以--开放，进取，包容，责任心。当然，这个团队中还必须有一位比较资深的分析设计人员（可以是管理者自己）。技术能力可以培养，工程方法只是药方，这些都可以学的。要学习，就要求团队成员必须开放，乐于沟通会沟通（跟闷葫芦合作是一件让人抓狂的事情）；成员要有点小理想，知道自己要什么，有追求有进取心，才有工作的动力；团队合作要能够容纳不同观点，能够接受别人的工作生活习惯（比如可以忍受坐在你对面那个家伙的臭脚）；团队成员需要信守承诺，交给的任务需要负起责任（说一百做五十的家伙要不得）。要让团队成员在某种尝试上达成一致，只需要把握住一个基本问题：大家放弃了在家睡大觉逛街陪家人的机会出来工作，为了什么？我觉得钱的原因是排第一二位的，然后呢，可能是精神层面的因素，比如成就感，跟人交流合作的快乐，而这些都或多或少跟一个因素挂钩----学习的愿望。人（好吧，正常人）天生就有学习的愿望，引入一种新的工程方法本身就是一次学习的机会，不论成功与否每个人都可以从中受益----这一点明确了团队就比较容易达成一致。
    最后说一下架构设计。适合的工程方法装备起来一支高效的团队，但是如果按照一张不合理的设计图纸，一样会盖出一座危楼。这里就是架构设计的重要性，它比工程方法更多地影响到软件质量。架构设计我认为没有什么外部方法可以帮上忙，每个团队拥有一个比较资深点的分析设计人员是必须的，他需要综合把握软件系统的功能和非功能性需求，设计一个健壮的有生命力的系统。这是一个另外的领域，这里不多讲。
   最后说一句，别担心失败，也别让自己还没上路就累垮，困难都是你走向高处的垫脚石，生活就是问题叠着问题，不抛弃不放弃，呵呵。

58 楼 taochenpfj 2009-10-19  

dearwolf 写道

在考虑打算使用敏捷之前，你是否考虑好打算用敏捷来做哪些事情？做这些事情的目的有是什么？

我想一个项目的实施按照cmmi的流程来的话，主要就是需求、设计、编码、测试、验收，而我们现在最薄弱的环节都不明显，也就是说对于这样一个流程，我们都没有多少标准，尽管过了cmmi！

鉴于最近一段时间的学习，我想采用敏捷的方式重点突破需求管理（能主动跟客户进行沟通，不总是依赖瀑布式的理想方式），设计（大家共同参与，互相交流，不仅可以共享经验也可以共同提高，尤其是现在我们的设计处于很初级的阶段），编码和测试的话，我主要考虑了敏捷中的合作开发方式，尤其是对于我们现在系统极不稳定，bug层出不穷的情况，采用分阶段的配对编程、主动编写单元测试、代码严肃审查等方式进行！

这么多想法，这么多的域，真的有些力不从心，而且在这个过程中，还要对兄弟们进行培训，实在是想跟有经验的各位请教一下，尤其是看到了scrum这个东西，我至少可以规避一些项目实施的风险！
还是请各位多给小弟一点意见，在此借楼主这篇文章，我也在这里多多讨教一下！！

57 楼 dearwolf 2009-10-17  

在考虑打算使用敏捷之前，你是否考虑好打算用敏捷来做哪些事情？做这些事情的目的有是什么？

56 楼 taochenpfj 2009-10-16  

ohmygodlzl 写道

taochenpfj 写道

请教楼主：你们在团队协作过程中，是如何达到信息共享，经验共享，尤其是针对团队内部各成员水平参差不齐的状况作出调整的？

好多个实践跟信息共享有关，比如Sprint会议所有人（包括产品负责人和QA）都参加，需求信息共享；团队成员的座位安排在一起，大家彼此看得见听得到，工作信息共享；任务墙上的任务条可以实现项目进度信息共享...
经验共享也有多种实践，比如code review，设计review，还有我们自己组织的每日技术探讨等，结对编程也是实现经验共享的方法，不过我们还没尝试

楼主的意思，我大体理解！我的主要意思是，我的同事们对敏捷啊，模式啊，软件工程方面的知识的掌握都很参差不齐的！这是我很头疼的，我最近一两个月就是看敏捷和偶然看到你说的scrum的模式，而且我也经历过cmmi3的认证过程，对软件过程也略知一二！但是我的同事们在这方面还是有点欠缺！
我一直在考虑是否该使用敏捷（+scrum）开发方式，以及比较高一点的领域设计，我自己的经验不是很多，他们也要在这个过程里面学习，现在的问题就是：您是如何让你的团队了解这样一种理念（开发方式），如何共同提高专业技能，共同分享的学习成果？
因为我比较担心我们的新项目的实施过程变成了一次理论研究过程，这样出来的项目首先会影响项目进度，项目质量也会根据不同人的情况出现一些反差！
曾经看到书说一个研究型的团队（我不是说不要学，而是整个团队不要都专注于研究！）最好不要实施直接的开发！所以，现在我一直感到自己的压力比较大，在这个过程里，我要跟他们分享的东西太多，要教授的东西过多使得我想变成孙悟空了！！
望楼主不吝赐教，小弟不胜感激啊！！！

55 楼 taochenpfj 2009-10-16  

突然想到对于scrum中的一个重要角色：产品负责人，我们团队里还没有！！我们现在要做的软件又是根据老系统的经验和教训，开发新的框架，并做新的设计！这些设计和框架主要依据就是老系统的问题的解决！
多次查看楼主的回复，觉得风险越来越大！（我们公司的软件管理可以说是比较松散，没有章法的！没有多少经验积累！）
有形的无形的风险都不知道该怎么控制了！

54 楼 ohmygodlzl 2009-10-16  

daquan198163 写道

楼主看这个了么？关于“敏捷计划与估计的方法”的讨论
请问你们的velocity是怎么计算的？

翻了一下你提到的这个讨论，我们的做法基本跟其中Andy提到的做法相同，理想可用人天数是固定的，比如5人*10天=50人天，有效时间利用率我们按照70%来算的，这样一个两周的Sprint实际可用35人天；
任务size的时候采用《硝烟中的Scrum和XP》提到的任务纸牌方法来评估的，按照重要性从高到低排满35个人天；
如果过程中有需求变更，凡是影响到任务size的要考虑拆分某个backlog将不重要的feature延迟或者延迟其他未开始的backlog，除非极特殊情况不加班

53 楼 daquan198163 2009-10-16  

楼主看这个了么？关于“敏捷计划与估计的方法”的讨论
请问你们的velocity是怎么计算的？

52 楼 ohmygodlzl 2009-10-16  

taochenpfj 写道

请教楼主：你们在团队协作过程中，是如何达到信息共享，经验共享，尤其是针对团队内部各成员水平参差不齐的状况作出调整的？

好多个实践跟信息共享有关，比如Sprint会议所有人（包括产品负责人和QA）都参加，需求信息共享；团队成员的座位安排在一起，大家彼此看得见听得到，工作信息共享；任务墙上的任务条可以实现项目进度信息共享...
经验共享也有多种实践，比如code review，设计review，还有我们自己组织的每日技术探讨等，结对编程也是实现经验共享的方法，不过我们还没尝试