十一问：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就可以了。