如何判断团队是否真正实施Scrum -- Scrum方法二十问 （二）

<script type="text/javascript"><!--
google_ad_client = "pub-1926348199765453";
/* 文章底部 */
google_ad_slot = "3855136352";
google_ad_width = 336;
google_ad_height = 280;
//-->
</script>
<script type="text/javascript" src="http://pagead2.googlesyndication.com/pagead/show_ads.js">
</script>

   十一问：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和领悟其自适应与自组织的精髓。如被誉为世界知识管理运动之父的Takeuchi和Nonaka的原创性文章《The
New New Product Development Game》和知识管理三部曲之一的《The Knowledge-Creating
Company》（中文版名为《创造知识的企业》）、遗传算法之父和复杂性新科学的先驱者之一Holland的《Hidden
Order》（中文版名为《隐秩序》）和《Emergence》（中文版名为《涌现》）。

如何判断团队是否真正实施Scrum -- Scrum方法二十问 （一）

<script type="text/javascript"><!--
google_ad_client = "pub-1926348199765453";
/* 文章顶部 */
google_ad_slot = "0385006797";
google_ad_width = 728;
google_ad_height = 90;
//-->
</script>
<script type="text/javascript" src="http://pagead2.googlesyndication.com/pagead/show_ads.js">
</script>