Scrum 开发方法的实施
Scrum是基于过程控制理论的经验方法，倡导自组织团队；其运行框架核心是迭代增量型并行开发，也是“适应性”的软件开发方法。Scrum提供了高度可视化的用于管理软件开发复杂性管理的敏捷项目管理的实践框架或敏捷过程，可以用于对现存软件工程实践的包装，提高软件生产率，改善沟通和合作的方法，使人们协作并注重业务目标。现在Scrum已被众多的软件企业使用，其中不乏有业界知名企业，如Microsoft 、IBM、Google和Nokia等。
作为一名Scrum教练，笔者经常被问到有关Scrum实施以及敏捷开发方面的各类问题，现总结如下，供对此方法有兴趣和有疑问的读者参考。
一问：Scrum的核心特征是什么？
一答：基于功能开发而组成的多功能、自组织团队；高度柔性的可视化敏捷项目管理自适应框架；以及支持增量并行开发的30天时间盒迭代。
二问：哪类项目可以使用Scrum?
二答：最初Scrum使用于需求难以预测的复杂商务应用产品的开发，但经过10多年的发展，它被应用于所有领域的软件中，从生命攸关的软件到更为随意的软件，都可以使用Scrum。在使用Scrum时，无需讨论工件是什么以及它们的数量，而是讨论需要严谨到什么程度。作为一个指导原则，由整个Scrum团队来决定正规性的程度，并尽可能地低。当然，这需要有丰富的实践经验来判断。
三问：Scrum团队一定是7个人吗？
三答：在Scrum中有3个基本的角色：产品所有者Product Owner、开发团队Development Team和ScrumMaster。Scrum团队通常有5～9个成员，典型一个Scrum团队应当有7个成员。但可以由多个团队完成一个项目，即使用Scrum of Scrums实践规则进行拓展项目团队规模：每一个Scrum Team同样有一个代表，通常是Scrum Master，参与Scrum of Scrums会议协调多个Scrum Teams的工作，这些会议类似于Daily Scrum Meeting，但每周召开一次。
四问：看上去Scrum非常简单，可以给我们更简化地总结一下吗？
四答：是的，Scrum看上去确实很简单，可以把Scrum总结得非常简单：
团队和项目出资人创建一个团队需要做的所有事情的列表。这可以是一个任务的列表或者特性的列表。这就是Product Backlog。
每个月，团队都努力实现列表最顶端的任务，这一部分是他们估计需要一个月完成的工作。他们把它展开成一个详细的任务列表，叫做Sprint Backlog。这个团队承诺在月底向出资人演示或交付结果。
每天，团队都面对面地开5～10分钟的会，彼此更新各自的状态和排除使他们减慢的路障。这个叫Daily stand-up meeting。
指定一个特别的人担任Scrum Master，这个人的任务是排除或安排别人排除在例会上这个团队提到的任何路障。
但是它的实践执行并不简单，需要获得关键的自适应和坚持Scrum核心价值观——承诺、专注、公开、敬重和勇气。
五问：我们认为，坚守一定的Scrum Meeting模式是必要的；但是执行一段时间后觉得很困难，有些人甚至觉得“恶心”，你对此怎么看？
五答：每天举行15～20分钟左右的Scrum meeting是Scrum和项目的心脏。如果出现这一问题，我估计是软件团队倾向于在现有的项目管理方法下诠释Scrum，没有充分理解自我管理、涌现机制、可视性和评估/适应循环的根本原则。
按照“定义的”参考框架去执行Scrum的实践，忽视了从控制转向授权、从命令转向协作，Scrum Master很可能将“自上次Scrum Meeting会后的一天里我做了什么？”理解为“检查团队成员是否完成上次Scrum Meeting中他所布置的任务”，将“从现在到下次Scrum Meeting的一天我将做什么”理解为“告诉团队人员从现在到下次Scrum Meeting的一天应做什么”，将“在工作中遇到了哪些障碍”理解为“他将审核是否能帮助团队完成目标”。而团队成员把Scrum Meeting理解为按顺序报告工作情况的会议。
坚持以下7个基本原则，将有利于有效执行Scrum Meeting：
1 团队信仰自我管理和支持自我管理。
2 他们作为团队共同承诺Sprint目标。
3 他们认识到沟通的重要性，并且通过Daily Scrum Meeting推动沟通。
4 他们理解和拥抱贯穿整个Sprint周期的必要的日常任务变更，相互依赖的会议规则，每日会议允许团队成员管理和响应变化。
5 团队有一位卓有成效的Scrum Master或得到他们授权的领导来决策和问责。
6 团队认为工作可视化很重要，透明改进团队和组织其他团队之间的关系，从而得到更高层次的信任和协作。
7 团队将Daily Scrum Meeting回顾与其他里程碑相联系使会议尽可能有效。
六问：用什么来判断软件团队在真正实施Scrum?
六答：对这一问题，Scrum创始人之一Jeff Sutherland用诺基亚测试的8个判断条件来判定是否在真正执行Scrum。这8个判断条件是：
1 你们有固定的迭代周期么？你们的迭代周期是否以某个特定的时间开始并以某个固定的时间结束，且迭代周期必须少于6周？（回答否定的则不符合迭代开发原则）
2 在每个迭代周期结束时，你们能提供可以工作的软件么？（回答否定的则不符合迭代开发原则）
3 在迭代开始之前，你们是否需要必须有一个完整细致的需求说明？（回答肯定的则不符合迭代开发原则）
4 是否将测试作为迭代增量开发的一部分，在开发过程中进行测试？（回答否定的则不符合迭代开发原则）
接下来，用4个附加的Scrum规则来判断是否实现了Scrum：
1 你们是否有产品所有者？是不是有人可以代表客户和你们一起工作？
2 如果有产品所有者的话，他们是否能提供待开发的产品Backlog？且此产品Backlog是否按照优先级来排序的？是否估算过开发这些功能的所需时间？
3 团队在开发过程中是否使用了Burndown图来展示工作量变化、跟踪进度、推算团队开发速度？
4 在迭代过程中，是否能保证项目经理不干涉团队工作？
通过以上8点基本上就可以确定，团队是否真正地实现了Scrum。
七问：在Scrum中我怎样去度量团队绩效？
七答：你可以通过速度去度量团队绩效，即在一个Sprint中将需求转化为软件功能的能力。可以是一个Sprint中完成多少Product Backlog Item（包括功能和非功能需求及其他议题），或者转化为1个合适单位货币如10000完成多少Product Backlog Item。
八问：在Scrum中我怎样去度量个人绩效？
八答：你不能度量个人绩效，只能度量整个Scrum团队的绩效。Scrum是自我管理的团队，而不是个人组成的组。当然，可能你的软件组织要求这么做，这确实是个棘手的问题，我也没有好的解决方案。对于软件组织这一层面，我建议你首先把度量的焦点聚焦于你生产的软件、真正的开发功能和软件组织用于改进基准和市场价值的能力。而项目这一级别，我建议将完整的个人检查过程简化为3个问题：你对增加组织的价值有什么帮助？你做了什么使客户高兴？你的同事怎么看待你？可以请同事来评估个人贡献，并列出1～10的等级。在Daily Scrum Meeting上，你可以看到谁有贡献，谁没有。
九问：在Sprint期间，如何去修改一个缺陷？
九答：Scrum团队的目标之一是在发现缺陷的Sprint中就修复它们。在他们逐渐精通采用30天迭代周期以后，尤其是通过对自动化测试的利用，他们能够达到这个目标。当Scrumt团队成员做出对某项编码任务的估计时，这个估计值就包含了用于修复在实现过程中发现的缺陷的时间，否则就应该确定和估计一个独立的任务（“修复缺陷”）即缺陷作为Product Backlog Item处理。我的偏好是只确定一项任务，但是在它通过所有的测试之前不认为已经完成。
后来发现的（或者在发现它的迭代中没有修复 的）缺陷应该按照与Product Backlog一样的方法来对待。应该按照与Product Backlog一样的方法确定缺陷修复工作的优先级，分配到后续的某次迭代中。只要超出一次迭代的范围，就不再有什么缺陷的概念。修复一个缺陷和增加一个功能只是一件事的两种说法。另外，如果现有团队还需要维护现有产品时，则需要提醒软件团队在做计划时拿出专门的时间处理那种需要马上响应的缺陷修改任务。
十问：Scrum的局限性是什么，实施中需要注意什么？
十答：我们都知道Scrum只是一种敏捷管理的一种实践框架（Framework），任何方法都有其边界和局限性，套用业界流行的一个说法就是“没有银弹”。Scrum为软件开发管理只定义了一个高层次的、易于操作与遵循的非常小的实践集，Scrum避免了说软件团队应该如何开发软件，它坚持认为：人们在自己的工作中和处理问题时，应该像一个成熟的成年人一样，因此它并不涉及具体的软件开发技术和人员沟通、期望管理、问题冲突等管理技能，这些都需要其他相关理论和技能来补充，另外，如同其他项目一样，需要软件团队在其业务领域的专业能力来确保软件项目的成功。
Scrum源于美国软件界，对国内实施强调自组织管理的Scrum需要破除可能习惯于听命行事的组织环境，建立自我约束、自我组织和实现的工作管理方式和组织环境，同时根据Scrum背后的科学原理则可以根据特定的情形进行调整。建议最初时，按Scrum提供的实践框架执行，然后，当积累了丰富实践经验后再根据Scrum提供的避免做什么的说明视实际情形进行调整，到最后，不要在乎自己是否执行Scrum或是其他什么敏捷方法，也就是达到从心所欲不逾矩。
十一问：Scrum中如何看待文档，或是对待写文档的问题有何建议？
十一答：这一问题屡屡被提及的是有着非常现实背景，软件组织或软件项目都需要一些软件文档，而在Scrum中没有规定具体的做法。我认为软件文档主要的作用在于理解、沟通和管理要构建的软件，需要交付给用户和软件组织为了方便维护软件和知识产权方面考虑用作保存和传递知识的作用，特殊软件需要满足法律法规的要求。
因此，第一、是否需要文档，标准是该文档是否增值，坚持精益原则，消除不必要的浪费，比如如果设计人员和专家坐在一起，就可以免去设计文档，而是在白板上粗略地勾勒草图，然后用照片记录白板上的图或用可打印的白板将其打印出来。第二，假设该文档只是符合规定（法律、审计或是客户等其他原因的强制需求）的需要，则可以考虑安排部分项目时间交给非核心人员编写文档，避免影响软件开发核心工作的开展。第三，对于理解和沟通所要构建软件的关键文档，原则上用自动化的代码文档工具如Doxygen、JavaDoc或NDoc等，在必要时产生符合代码标准的自解释的源代码文档，并创建自文档化的软件UML图模型。另外，用简明扼要的1～2页的软件架构文档，描述软件的架构，为新来的开发者表示出关键构件和接口。第四，不要奢求需求是完美的，设计文档能够与代码同步更新，或项目计划与项目状态完全匹配，需求文档能够满足后续开发需要即可，总之，软件文档符合精益（Lean）、易理解（Mean）和足够（Enough）的要求，确信在当前环境能够严格地保证沟通需要。还有一个有趣的现象是技术人员基本上都讨厌写文档，但需要指出的是编写精益易理解足够的文档也是职业软件开发者的一项基本功，当然同时，也要避免为了文档而文档，它意味着用于项目的每个文档都应该证明是对项目有意义的。
十二问：Scrum与流行的RUP有什么异同？
十二答：这个问题网上好象有专文论述，这里根据我的自己的实践体会简单地说一下，Scrum与RUP都强调需求导向、迭代增量开发和风险驱动，两者可以结合使用。Scrum与RUP的侧重点不同，其中一个表现Scrum反对预定义的过程和预见性的步骤，RUP会有一些可选的但又需要预先定义的活动，如与需求分析、测试等相关的活动，并有先后顺序。需求管理方面Scrum由Product owner管理，RUP则由需求工程师管理；可视化建模方面，scrum团队自定，通常进行敏捷建模，RUP倡导可视化建模；软件体系结构方面，Scrum软件组织或团队自定，RUP则由软件体系中心确定；迭代周期方面，Scrum迭代周期推荐30天，RUP推荐2～6周。
十三问：一提起敏捷方法，为什么通常将Scrum与XP一并谈论？
十三答：这大概是XP与Scrum是敏捷方法中被业界采用最为广泛的原因吧。另外，一个值得注意的原因是两者都聚焦于信息价值流和信息沟通，除了迭代长度稍有差别外，大多数Scrum实践与XP是兼容且相互补充，Scrum侧重于项目管理和人，XP有许多工程技术实践，两者相得宜彰。Scrum这种强调项目管理价值与实践而不在乎需求、实现等工程技术用作其他软件开发方法包装器的特征，具有高度适应性和柔性是其他敏捷方法不具有的，因此，它很容易与其他方法进行组合，或者作为其他方法的补充，这一点不是它的弱点，而应当看作其长处。
十四问：我们公司采用CMM/CMMI进行软件过程改进，是否适合实施Scrum？
十四答：CMM/CMMI与Scrum或敏捷方法之间的关系是常常被人们关心或经常提起的一个有趣的话题。2002年Scrum创始人 各级ken Schwaber与美国卡内基。梅隆大学软件工程研究所SEI的Paulk Mark曾经评估Scrum如何实现CMM的关键过程域，结论是Scrum实践规则可以满足CMM2级全部和CMM3即的大部分关键过程域。事实上，国内外都有利用Scrum通过CMM/CMMI评估的案例。
通常认为CMM/CMMI之间的区别在于：关注目标不同，CMM/CMMI关注组织级，Scrum关注项目级；基础假设不同，CMM/CMMI假设软件开发可预测与可重复，符合统计过程控制，优化放在最后，Scrum假设软件开发是自适应，高度复杂，需要基于过程控制理论的经验方法，优化一开始就进行。
业界有一个流行观点是将Scrum纳入到一个已经通过CMM/CMMI 3或更高级别评估的组织，看起来比将一个Scrum项目改为CMMI更简单。同时，一些实施Scrum或其他敏捷方法的软件组织对CMMI评估没有兴趣，把CMMI评估看作浪费金钱，也就是说，他们不需要CMMI评估来获得合同，但获得这一评估却需要耗费金钱和时间，我的看法是在现实商业环境中的软件组织是否需要组合CMM/CMMI和Scrum主要不在于理论或其背后的软件哲学理念，而在于业务运作环境所需考虑的优先级。假设您需要组合两者并有通过CMMI评估需要，关键在于找到一个理解如何灵活使用CMMI模型又理解Scrum的CMMI主任评估师。
十五问：如何引入和执行Scrum?
十五答：对于第一个项目建议在一个有执行Scrum经验丰富的专家指导下进行。在试点项目的选择上Scrum的创始人鼓励选择最为困难和关键的项目，我个人建议是如果试点项目团队有强烈意愿并获得高层支持是完全可以的。否则，试点项目应该是构建真实的、具有合理的、客观的商业目标的软件，团队规模6～8人为宜，以避免一开始就使用Scrum of Scrums，项目长度通常2～6个月为宜。在项目启动后，外部的项目管理者和潜在使用Scrum的可以邀请其观摩Daily Scrum Meeting、Sprint Planning Meeting 、Sprint Review Meeting和Sprint Retrospective Meeting。最终，Scrum的实践扩展至软件组织的最高层，每一层都基于团队，高层管理者每月组织一次Scrum meeting就可以了。
十六问：Scrum的迭代Sprint周期一定是30天吗？
十六答：Scrum的目标是在一系列（3～8个）短期的时间框（time box）内交付尽可能多的优质软件。其中时间框被（固定时间间隔）称为Sprint，典型地，其将持续大约一个月30天的时间。但在许多公司已缩短至两个2周或更短。我建议刚开始实施Scrum时Sprint周期最好固定为30天，随着经验积累可以根据实际进行调整期Spint周期为2～4周。
十七问：Sprint的长度取决于哪些因素？
十七答：绝大多数的迭代增量开发方法推荐1～6周的长度。Scrum推荐其迭代Sprint的长度为30天。确实需要调整时，考虑发布的总时间长度、不确定性的多少、获得反馈的难易、优先级可以保持多久不变时间长度、迭代系统开销、紧迫感产生有多快等因素。这里需要特别指出的是国内有企业一开始就执行2周为Sprint周期的企业，因为其执行短周期迭代开发的基础设施（如软件配置管理和自动化测试的基本实践不扎实）不到位而导致退化为瀑布开发的案例。
十八问：导致Scrum项目失败的主要原因是什么？
十八答：导致失败的主要原因是软件团队不是自组织团队，团队由项目经理或Scrum Master进行指导和组织。其次，Product Owner或客户不参与每次迭代，不进行需求优先级划分，不参与每次演示，并且不为下一迭代选择具有最高商业价值的项。另外，在迭代期内给团队成员追加新的需求或额外的任务。
十九问：您如何看待Scrum Master认证培训？
十九答：敏捷联盟推出Scrum Master认证培训即Scrum Certified Master，事实上其敏捷联盟内部对此也有一些争论。我个人认为您如果有机会参加由那些真正理解Scrum的人负责的为期2天的培训自然是件好事。但我认为把它叫做“认证”会带来一些错误的认识，比如国内外都有参加了Scrum认证后就认为自己是Scrum Certified Master，然后在软件组织内执行Scrum最后导致失败的案例。要真正达到通常意义上的认证，至少你必须进入软件团队，用Scrum工作方式几个月的实践才行，倘若没有任何软件开发经历和理解Scrum背后的哲学体系，仅是接受2天的培训而去推广Scrum，后果不堪设想。另外，如果纯粹为了就业或是获得证书什么的，我认为没有必要参加目前还相对昂贵的认证培训，看看类似的认证培训效用就可以知道了。相信任何理性的软件组织都更看重的是实践能力而非仅仅通过2天培训换来的一纸证书。在这里我特别声明我并不反对任何人任何时候参加任何机构举办的Scrum Master认证培训。
二十问：对于刚刚学习和实施Scrum者有没有可以推荐的读物？
二十答：书籍方面目前主要有由Scrum创始人Ken Schwaber主笔的三本书：《Agile Software Development with Scrum》、《Agile Project Management with Scrum》和《The Enterprise and Scrum》。其中《Agile Software Development with Scrum》还得到了Beedle和Sutherland的协助，国内出了影印版中文名为《敏捷软件开发——使用Scrum过程》。《Agile Project Management with Scrum》出了中文版，中文名为《Scrum 敏捷项目管理》，《The Enterprise and Scrum》也已引入英文版。另外著名技术网站infoQ有2本迷你书。我个人倾向推荐《Agile Software Development with Scrum》。
此外，我个人认为在精力和时间允许的情况下最好对Scrum产生重大影响的一些书籍和文章进行研读，这样可以更深入理解Scrum和领悟其自适应与自组织的精髓。
本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/zhujjcn/archive/2009/06/10/4257253.aspx
作为一名Scrum教练，笔者经常被问到有关Scrum实施以及敏捷开发方面的各类问题，现总结如下，供对此方法有兴趣和有疑问的读者参考。
一问：Scrum的核心特征是什么？
一答：基于功能开发而组成的多功能、自组织团队；高度柔性的可视化敏捷项目管理自适应框架；以及支持增量并行开发的30天时间盒迭代。
二问：哪类项目可以使用Scrum?
二答：最初Scrum使用于需求难以预测的复杂商务应用产品的开发，但经过10多年的发展，它被应用于所有领域的软件中，从生命攸关的软件到更为随意的软件，都可以使用Scrum。在使用Scrum时，无需讨论工件是什么以及它们的数量，而是讨论需要严谨到什么程度。作为一个指导原则，由整个Scrum团队来决定正规性的程度，并尽可能地低。当然，这需要有丰富的实践经验来判断。
三问：Scrum团队一定是7个人吗？
三答：在Scrum中有3个基本的角色：产品所有者Product Owner、开发团队Development Team和ScrumMaster。Scrum团队通常有5～9个成员，典型一个Scrum团队应当有7个成员。但可以由多个团队完成一个项目，即使用Scrum of Scrums实践规则进行拓展项目团队规模：每一个Scrum Team同样有一个代表，通常是Scrum Master，参与Scrum of Scrums会议协调多个Scrum Teams的工作，这些会议类似于Daily Scrum Meeting，但每周召开一次。
四问：看上去Scrum非常简单，可以给我们更简化地总结一下吗？
四答：是的，Scrum看上去确实很简单，可以把Scrum总结得非常简单：
团队和项目出资人创建一个团队需要做的所有事情的列表。这可以是一个任务的列表或者特性的列表。这就是Product Backlog。
每个月，团队都努力实现列表最顶端的任务，这一部分是他们估计需要一个月完成的工作。他们把它展开成一个详细的任务列表，叫做Sprint Backlog。这个团队承诺在月底向出资人演示或交付结果。
每天，团队都面对面地开5～10分钟的会，彼此更新各自的状态和排除使他们减慢的路障。这个叫Daily stand-up meeting。
指定一个特别的人担任Scrum Master，这个人的任务是排除或安排别人排除在例会上这个团队提到的任何路障。
但是它的实践执行并不简单，需要获得关键的自适应和坚持Scrum核心价值观——承诺、专注、公开、敬重和勇气。
五问：我们认为，坚守一定的Scrum Meeting模式是必要的；但是执行一段时间后觉得很困难，有些人甚至觉得“恶心”，你对此怎么看？
五答：每天举行15～20分钟左右的Scrum meeting是Scrum和项目的心脏。如果出现这一问题，我估计是软件团队倾向于在现有的项目管理方法下诠释Scrum，没有充分理解自我管理、涌现机制、可视性和评估/适应循环的根本原则。
按照“定义的”参考框架去执行Scrum的实践，忽视了从控制转向授权、从命令转向协作，Scrum Master很可能将“自上次Scrum Meeting会后的一天里我做了什么？”理解为“检查团队成员是否完成上次Scrum Meeting中他所布置的任务”，将“从现在到下次Scrum Meeting的一天我将做什么”理解为“告诉团队人员从现在到下次Scrum Meeting的一天应做什么”，将“在工作中遇到了哪些障碍”理解为“他将审核是否能帮助团队完成目标”。而团队成员把Scrum Meeting理解为按顺序报告工作情况的会议。
坚持以下7个基本原则，将有利于有效执行Scrum Meeting：
1 团队信仰自我管理和支持自我管理。
2 他们作为团队共同承诺Sprint目标。
3 他们认识到沟通的重要性，并且通过Daily Scrum Meeting推动沟通。
4 他们理解和拥抱贯穿整个Sprint周期的必要的日常任务变更，相互依赖的会议规则，每日会议允许团队成员管理和响应变化。
5 团队有一位卓有成效的Scrum Master或得到他们授权的领导来决策和问责。
6 团队认为工作可视化很重要，透明改进团队和组织其他团队之间的关系，从而得到更高层次的信任和协作。
7 团队将Daily Scrum Meeting回顾与其他里程碑相联系使会议尽可能有效。
六问：用什么来判断软件团队在真正实施Scrum?
六答：对这一问题，Scrum创始人之一Jeff Sutherland用诺基亚测试的8个判断条件来判定是否在真正执行Scrum。这8个判断条件是：
1 你们有固定的迭代周期么？你们的迭代周期是否以某个特定的时间开始并以某个固定的时间结束，且迭代周期必须少于6周？（回答否定的则不符合迭代开发原则）
2 在每个迭代周期结束时，你们能提供可以工作的软件么？（回答否定的则不符合迭代开发原则）
3 在迭代开始之前，你们是否需要必须有一个完整细致的需求说明？（回答肯定的则不符合迭代开发原则）
4 是否将测试作为迭代增量开发的一部分，在开发过程中进行测试？（回答否定的则不符合迭代开发原则）
接下来，用4个附加的Scrum规则来判断是否实现了Scrum：
1 你们是否有产品所有者？是不是有人可以代表客户和你们一起工作？
2 如果有产品所有者的话，他们是否能提供待开发的产品Backlog？且此产品Backlog是否按照优先级来排序的？是否估算过开发这些功能的所需时间？
3 团队在开发过程中是否使用了Burndown图来展示工作量变化、跟踪进度、推算团队开发速度？
4 在迭代过程中，是否能保证项目经理不干涉团队工作？
通过以上8点基本上就可以确定，团队是否真正地实现了Scrum。
七问：在Scrum中我怎样去度量团队绩效？
七答：你可以通过速度去度量团队绩效，即在一个Sprint中将需求转化为软件功能的能力。可以是一个Sprint中完成多少Product Backlog Item（包括功能和非功能需求及其他议题），或者转化为1个合适单位货币如10000完成多少Product Backlog Item。
八问：在Scrum中我怎样去度量个人绩效？
八答：你不能度量个人绩效，只能度量整个Scrum团队的绩效。Scrum是自我管理的团队，而不是个人组成的组。当然，可能你的软件组织要求这么做，这确实是个棘手的问题，我也没有好的解决方案。对于软件组织这一层面，我建议你首先把度量的焦点聚焦于你生产的软件、真正的开发功能和软件组织用于改进基准和市场价值的能力。而项目这一级别，我建议将完整的个人检查过程简化为3个问题：你对增加组织的价值有什么帮助？你做了什么使客户高兴？你的同事怎么看待你？可以请同事来评估个人贡献，并列出1～10的等级。在Daily Scrum Meeting上，你可以看到谁有贡献，谁没有。
九问：在Sprint期间，如何去修改一个缺陷？
九答：Scrum团队的目标之一是在发现缺陷的Sprint中就修复它们。在他们逐渐精通采用30天迭代周期以后，尤其是通过对自动化测试的利用，他们能够达到这个目标。当Scrumt团队成员做出对某项编码任务的估计时，这个估计值就包含了用于修复在实现过程中发现的缺陷的时间，否则就应该确定和估计一个独立的任务（“修复缺陷”）即缺陷作为Product Backlog Item处理。我的偏好是只确定一项任务，但是在它通过所有的测试之前不认为已经完成。
后来发现的（或者在发现它的迭代中没有修复 的）缺陷应该按照与Product Backlog一样的方法来对待。应该按照与Product Backlog一样的方法确定缺陷修复工作的优先级，分配到后续的某次迭代中。只要超出一次迭代的范围，就不再有什么缺陷的概念。修复一个缺陷和增加一个功能只是一件事的两种说法。另外，如果现有团队还需要维护现有产品时，则需要提醒软件团队在做计划时拿出专门的时间处理那种需要马上响应的缺陷修改任务。
十问：Scrum的局限性是什么，实施中需要注意什么？
十答：我们都知道Scrum只是一种敏捷管理的一种实践框架（Framework），任何方法都有其边界和局限性，套用业界流行的一个说法就是“没有银弹”。Scrum为软件开发管理只定义了一个高层次的、易于操作与遵循的非常小的实践集，Scrum避免了说软件团队应该如何开发软件，它坚持认为：人们在自己的工作中和处理问题时，应该像一个成熟的成年人一样，因此它并不涉及具体的软件开发技术和人员沟通、期望管理、问题冲突等管理技能，这些都需要其他相关理论和技能来补充，另外，如同其他项目一样，需要软件团队在其业务领域的专业能力来确保软件项目的成功。
Scrum源于美国软件界，对国内实施强调自组织管理的Scrum需要破除可能习惯于听命行事的组织环境，建立自我约束、自我组织和实现的工作管理方式和组织环境，同时根据Scrum背后的科学原理则可以根据特定的情形进行调整。建议最初时，按Scrum提供的实践框架执行，然后，当积累了丰富实践经验后再根据Scrum提供的避免做什么的说明视实际情形进行调整，到最后，不要在乎自己是否执行Scrum或是其他什么敏捷方法，也就是达到从心所欲不逾矩。
十一问：Scrum中如何看待文档，或是对待写文档的问题有何建议？
十一答：这一问题屡屡被提及的是有着非常现实背景，软件组织或软件项目都需要一些软件文档，而在Scrum中没有规定具体的做法。我认为软件文档主要的作用在于理解、沟通和管理要构建的软件，需要交付给用户和软件组织为了方便维护软件和知识产权方面考虑用作保存和传递知识的作用，特殊软件需要满足法律法规的要求。
因此，第一、是否需要文档，标准是该文档是否增值，坚持精益原则，消除不必要的浪费，比如如果设计人员和专家坐在一起，就可以免去设计文档，而是在白板上粗略地勾勒草图，然后用照片记录白板上的图或用可打印的白板将其打印出来。第二，假设该文档只是符合规定（法律、审计或是客户等其他原因的强制需求）的需要，则可以考虑安排部分项目时间交给非核心人员编写文档，避免影响软件开发核心工作的开展。第三，对于理解和沟通所要构建软件的关键文档，原则上用自动化的代码文档工具如Doxygen、JavaDoc或NDoc等，在必要时产生符合代码标准的自解释的源代码文档，并创建自文档化的软件UML图模型。另外，用简明扼要的1～2页的软件架构文档，描述软件的架构，为新来的开发者表示出关键构件和接口。第四，不要奢求需求是完美的，设计文档能够与代码同步更新，或项目计划与项目状态完全匹配，需求文档能够满足后续开发需要即可，总之，软件文档符合精益（Lean）、易理解（Mean）和足够（Enough）的要求，确信在当前环境能够严格地保证沟通需要。还有一个有趣的现象是技术人员基本上都讨厌写文档，但需要指出的是编写精益易理解足够的文档也是职业软件开发者的一项基本功，当然同时，也要避免为了文档而文档，它意味着用于项目的每个文档都应该证明是对项目有意义的。
十二问：Scrum与流行的RUP有什么异同？
十二答：这个问题网上好象有专文论述，这里根据我的自己的实践体会简单地说一下，Scrum与RUP都强调需求导向、迭代增量开发和风险驱动，两者可以结合使用。Scrum与RUP的侧重点不同，其中一个表现Scrum反对预定义的过程和预见性的步骤，RUP会有一些可选的但又需要预先定义的活动，如与需求分析、测试等相关的活动，并有先后顺序。需求管理方面Scrum由Product owner管理，RUP则由需求工程师管理；可视化建模方面，scrum团队自定，通常进行敏捷建模，RUP倡导可视化建模；软件体系结构方面，Scrum软件组织或团队自定，RUP则由软件体系中心确定；迭代周期方面，Scrum迭代周期推荐30天，RUP推荐2～6周。
十三问：一提起敏捷方法，为什么通常将Scrum与XP一并谈论？
十三答：这大概是XP与Scrum是敏捷方法中被业界采用最为广泛的原因吧。另外，一个值得注意的原因是两者都聚焦于信息价值流和信息沟通，除了迭代长度稍有差别外，大多数Scrum实践与XP是兼容且相互补充，Scrum侧重于项目管理和人，XP有许多工程技术实践，两者相得宜彰。Scrum这种强调项目管理价值与实践而不在乎需求、实现等工程技术用作其他软件开发方法包装器的特征，具有高度适应性和柔性是其他敏捷方法不具有的，因此，它很容易与其他方法进行组合，或者作为其他方法的补充，这一点不是它的弱点，而应当看作其长处。
十四问：我们公司采用CMM/CMMI进行软件过程改进，是否适合实施Scrum？
十四答：CMM/CMMI与Scrum或敏捷方法之间的关系是常常被人们关心或经常提起的一个有趣的话题。2002年Scrum创始人 各级ken Schwaber与美国卡内基。梅隆大学软件工程研究所SEI的Paulk Mark曾经评估Scrum如何实现CMM的关键过程域，结论是Scrum实践规则可以满足CMM2级全部和CMM3即的大部分关键过程域。事实上，国内外都有利用Scrum通过CMM/CMMI评估的案例。
通常认为CMM/CMMI之间的区别在于：关注目标不同，CMM/CMMI关注组织级，Scrum关注项目级；基础假设不同，CMM/CMMI假设软件开发可预测与可重复，符合统计过程控制，优化放在最后，Scrum假设软件开发是自适应，高度复杂，需要基于过程控制理论的经验方法，优化一开始就进行。
业界有一个流行观点是将Scrum纳入到一个已经通过CMM/CMMI 3或更高级别评估的组织，看起来比将一个Scrum项目改为CMMI更简单。同时，一些实施Scrum或其他敏捷方法的软件组织对CMMI评估没有兴趣，把CMMI评估看作浪费金钱，也就是说，他们不需要CMMI评估来获得合同，但获得这一评估却需要耗费金钱和时间，我的看法是在现实商业环境中的软件组织是否需要组合CMM/CMMI和Scrum主要不在于理论或其背后的软件哲学理念，而在于业务运作环境所需考虑的优先级。假设您需要组合两者并有通过CMMI评估需要，关键在于找到一个理解如何灵活使用CMMI模型又理解Scrum的CMMI主任评估师。
十五问：如何引入和执行Scrum?
十五答：对于第一个项目建议在一个有执行Scrum经验丰富的专家指导下进行。在试点项目的选择上Scrum的创始人鼓励选择最为困难和关键的项目，我个人建议是如果试点项目团队有强烈意愿并获得高层支持是完全可以的。否则，试点项目应该是构建真实的、具有合理的、客观的商业目标的软件，团队规模6～8人为宜，以避免一开始就使用Scrum of Scrums，项目长度通常2～6个月为宜。在项目启动后，外部的项目管理者和潜在使用Scrum的可以邀请其观摩Daily Scrum Meeting、Sprint Planning Meeting 、Sprint Review Meeting和Sprint Retrospective Meeting。最终，Scrum的实践扩展至软件组织的最高层，每一层都基于团队，高层管理者每月组织一次Scrum meeting就可以了。
十六问：Scrum的迭代Sprint周期一定是30天吗？
十六答：Scrum的目标是在一系列（3～8个）短期的时间框（time box）内交付尽可能多的优质软件。其中时间框被（固定时间间隔）称为Sprint，典型地，其将持续大约一个月30天的时间。但在许多公司已缩短至两个2周或更短。我建议刚开始实施Scrum时Sprint周期最好固定为30天，随着经验积累可以根据实际进行调整期Spint周期为2～4周。
十七问：Sprint的长度取决于哪些因素？
十七答：绝大多数的迭代增量开发方法推荐1～6周的长度。Scrum推荐其迭代Sprint的长度为30天。确实需要调整时，考虑发布的总时间长度、不确定性的多少、获得反馈的难易、优先级可以保持多久不变时间长度、迭代系统开销、紧迫感产生有多快等因素。这里需要特别指出的是国内有企业一开始就执行2周为Sprint周期的企业，因为其执行短周期迭代开发的基础设施（如软件配置管理和自动化测试的基本实践不扎实）不到位而导致退化为瀑布开发的案例。
十八问：导致Scrum项目失败的主要原因是什么？
十八答：导致失败的主要原因是软件团队不是自组织团队，团队由项目经理或Scrum Master进行指导和组织。其次，Product Owner或客户不参与每次迭代，不进行需求优先级划分，不参与每次演示，并且不为下一迭代选择具有最高商业价值的项。另外，在迭代期内给团队成员追加新的需求或额外的任务。
十九问：您如何看待Scrum Master认证培训？
十九答：敏捷联盟推出Scrum Master认证培训即Scrum Certified Master，事实上其敏捷联盟内部对此也有一些争论。我个人认为您如果有机会参加由那些真正理解Scrum的人负责的为期2天的培训自然是件好事。但我认为把它叫做“认证”会带来一些错误的认识，比如国内外都有参加了Scrum认证后就认为自己是Scrum Certified Master，然后在软件组织内执行Scrum最后导致失败的案例。要真正达到通常意义上的认证，至少你必须进入软件团队，用Scrum工作方式几个月的实践才行，倘若没有任何软件开发经历和理解Scrum背后的哲学体系，仅是接受2天的培训而去推广Scrum，后果不堪设想。另外，如果纯粹为了就业或是获得证书什么的，我认为没有必要参加目前还相对昂贵的认证培训，看看类似的认证培训效用就可以知道了。相信任何理性的软件组织都更看重的是实践能力而非仅仅通过2天培训换来的一纸证书。在这里我特别声明我并不反对任何人任何时候参加任何机构举办的Scrum Master认证培训。
二十问：对于刚刚学习和实施Scrum者有没有可以推荐的读物？
二十答：书籍方面目前主要有由Scrum创始人Ken Schwaber主笔的三本书：《Agile Software Development with Scrum》、《Agile Project Management with Scrum》和《The Enterprise and Scrum》。其中《Agile Software Development with Scrum》还得到了Beedle和Sutherland的协助，国内出了影印版中文名为《敏捷软件开发——使用Scrum过程》。《Agile Project Management with Scrum》出了中文版，中文名为《Scrum 敏捷项目管理》，《The Enterprise and Scrum》也已引入英文版。另外著名技术网站infoQ有2本迷你书。我个人倾向推荐《Agile Software Development with Scrum》。
此外，我个人认为在精力和时间允许的情况下最好对Scrum产生重大影响的一些书籍和文章进行研读，这样可以更深入理解Scrum和领悟其自适应与自组织的精髓。
本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/zhujjcn/archive/2009/06/10/4257253.aspx