Scrum项目前的动员与准备

　　Scrum实践：《硝烟中的Scrum和XP》http://www.educity.cn/pm/594948.html

 

阅读《构建之法》第6~7章读后感：

      首先，介绍了敏捷的流程。“敏捷流程”是一系列价值观和方法论的集合。它的优点有：个体和交互胜过过程和工具；可以工作的软件胜过面面俱到的文档；客户合作合同谈判 ；响应变化遵循计划；虽然右项也有价值，但是我们认为左项具有更大的价值。然后是，敏捷开发原则。原则有十二条，大概意思如下：1、我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意；2、即使到了开发的后期，也欢迎改变需求，敏捷过程利用变化来为客户创造竞争优势；3、经常性的交付可以工作的软件，交付的间隔可以从几周到几个月，交付的时间间隔越短越好；4、在整个项目开发期间，业务人员和开发人员必须天天都在一起工作；5、围绕被激励起来的人个来构建项目，给他们提供所需要的环境和支持，并且信任他们能够完成工作；6、在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈；7、工作的软件是首要进度度量标准；8、敏捷过程提可持续的开发速度，责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度；9、不断地关注优秀的技能和好的设计会增强敏捷能力；10、简单--使未完成的工作最大化的艺术--是根本的；11、最好的构架、需求和设计出自与自组织的团队；12、每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。最后是，敏捷流程概述。以Scrum为例，而Scrum分三步走，即Product Backlog、Sprint Backlog、Sprint。

      然后，描述了敏捷流程的问题和解法。很详细的陈述了敏捷流程中可能会遇到的一些问题，以及相应的解决方法。

      接下来，介绍了敏捷的团队。创建敏捷的软件开发团队并不像表面看起来那么容易。很多管理人员和团队主管会雇佣技术合格的人组成团队，扔给他们某种敏捷过程，然后就希望所有事情都像书上说的那样有效。这种方法不仅不现实，而且非常容易失败。对于想要为团队确立什么样的文化，每个人都有自己的想法。除非管理人员雇佣自己非常熟悉的人，否则就很难将文化的愿景变为现实。我们很早就发现以下重要特征：拥有客户的视角、有效地协作、通过事实管理，以及专注于执行等等。具体执行了这些原则的团队就具备了成功的条件。执行这些核心原则的团队成员会表现出大量良好的行为，诸如向客户提问、像客户那样思考、愿意请求帮助、愿意帮助他人、根据具体的事实而不是个人意见来做决定，以及努力交付完成的代码。

     再接下来，讲述了敏捷总结。很多项目都处在一种需求和实施方案都大致确定，但是在很多程度上都存在着变动的危险境地。在这种情况下,敏捷方法能够帮助团队高效进行反馈，领导项目走向成功，并且避免高风险和不确定性。软件开发是更加复杂任务的一个最佳示例。但是，要清楚一点，很难真正做到敏捷，而且，敏捷并不一定是最合适的方式。你自己不要成为一个布道者，多关注自己的项目，根据项目的实际情况决定哪个方法是最合适的。有时候，敏捷不一定是最好的方法，但是如果你发现项目的需求不是很稳定的时候，敏捷将会是一个很好的选择。

      最后，详细讲述了敏捷的故事。敏捷团队依靠变化来获取活力。团队几乎不进行预先设计，因此，不需要一个成熟的初始设计。他们更愿意保持设计尽可能的干净、简单，并使用许多单元测试和验收测试作为支援。这保持了设计的灵活性、易于理解性。团队利用这种灵活性，持续地改进设计，以便于每次迭代结束生成的系统都具有最适合于那次迭代中需求的设计。

      但我对第六章6.1节敏捷的流程仍存在着不解。令我很困惑的是：源代码是不是一个模型，更重要的是，它是不是一个敏捷模型？这是一个普遍的哲学问题，我相信有很多的相关学者提出过疑问，同时也自己给出了答案。这里引用一个资深的学者的回答：“如果你是在我这篇文章之外问我这个问题，我会回答说，是，源代码是一个模型，虽然是一个高度细节化的模型，因为它是软件的一个抽象。同时我还认为，优秀的代码是一个敏捷模型。但在这里，我还需要把两者区分开来，源代码和敏捷模型还是有区别的——敏捷模型帮助你得到源代码。”而这个答案也解决了我的困惑，所以在这里要感谢这个回答的作者。 

 

      首先，简述了MSF的历史。MSF是一组建立、开发和实现分布式企业系统应用的工作模型、开发准则和应用指南。它帮助企业融合商业和技术的目标，降低采用新技术后系统整体的费用，以及成功的应用微软技术整合商业过程的方法。1994年，基于微软产品开发的经验和教训以及微软微软咨询服务的业务经验，微软推出了解决方案框架 Microsoft Solution Framework (MSF)。当时的MSF只是这些经验教训的松散集合。2006年，MSF 4.0 随着Visual Studio Team Foundation 2005 发布，它增加了不少敏捷开发的内容，并且明确刻画了团队典型的流程和在新的团队协作软件包VSTS 中的应用。我们可以不用管MSF 演化的细节，要记住所有模式都不是一成不变的，关键是要掌握变化的原因。

      然后，详细的陈述了MSF基本原则。MSF的核心有八个基本原则：1、推动开放的沟通 ；2、为共同的前景而工作； 3、充分授权和信任 ；4、各司其职，对项目共同负责；5、重视商业价值；6、保持敏捷，预期变化 ；7、质量投资；8、学习所有的经验。MSF是一个框架结构，它不是一成不变的。相反，MSF会随我们从微软的客户和合作伙伴那里的学习而不断的发展和完善，新的思想和准则会不断地被引进MSF。这些发展将适应技术的更新、商业需求的变化，并支持构建更好的软件解决方案。

     接着，描述了MSF团队模型。MSF将一个项目中不同阶段的工作人员分为六个角色,通过这六个角色,项目可以得以迅速、完善地实施。这也体现了项目开发的六个重要质量指标,它们在全球是一致的。这六个角色分别是:产品经理、程序管理员、用户教育、开发者、测试人员、后勤人员。

     再接着，陈述了MSF过程模型。MSF过程模型解释了如何基于：范围、进度和资源，规划和控制面向结果的项目。它是基于四个可见里程碑交互的、允许修改的过程模型。过程模型中的“设计”阶段在面向商业解决方案内容，结合过程模型、组队模型和应用模型的组件方案设计过程中，进行了详细的介绍。

     最后，讲述了MSF开发模式。首先介绍了MSF敏捷开发模式。MSF吸取了敏捷开发模式的优点，更强调与用户的交流；质量更是防范于未然、重视在实战条件下的质量；精简过程，直奔主题。然后再介绍了MSF CMMI开发模式。MSF 也支持CMMI的开发模式。其关注点在于评估及改善软件公司的开发过程能力，提供过程质量指导原则，协助开发者持续改善开发技能与软件质量，进而提升软件公司的软件开发管理能力，达到提高软件性能、缩短开发周期、降低开发成本及保证质量等目的。

     但我对第七章7.3节MSF团队模型仍存在着不解。令我很困惑的是：MSF团队中是不是只有开发者要写代码，其他角色的人是不是不需要写代码？查询了很多资料，但是还是不清楚。所以，希望知道答案的人解答一下。愿闻其详，谢谢。

 

对Scrum的理解：

Scrum中文网--什么是Scrum?

     Scrum 是一个用于开发和维持复杂产品的框架 ，是一个增量的、迭代的开发过程，通常用于敏捷软件开发。Scrum包括了一系列实践和预定义角色的过程骨架。Scrum中的主要角色包括同项目经理类似的Scrum主管角色负责维护过程和任务，产品负责人代表利益所有者，开发团队包括了所有开发人员。虽然Scrum是为管理软件开发项目而开发的，它同样可以用于运行软件维护团队，或者作为计划管理方法：Scrum of Scrums。在每一次冲刺（一个15到30 天周期 ，长度由开发团队决定），开发团队创建可用的（可以随时推出）软件的一个增量。每一个冲刺所要实现的特性来自产品目标， 产品目标是指按照优先级排列的需要完成的工作的概要的需求（目标）。哪些订单项（目标项目）会被加入一次冲刺，由冲刺计划会议决定。 在会议中，产品负责人告诉开发团队他需要完成产品订单中的哪些订单项。开发团队决定在下一次冲刺中他们能够承诺完成多少订单项。 在冲刺的过程中，没有人能够变更冲刺订单（sprint backlog），这意味着在一个冲刺中需求是被冻结的。

Scrum认证体系：

     虽然Scrum认证有很多好处，但对绝大多数的软件工程师来说，都不会特地去拿个Scrum证书回来，一来是因为没必要，还有就是Scrum证书也不是那么容易拿下的，如果不是十分需要的话，建议还是不要去认证。当然，如果你很这个实力并且胸怀大志的话，那就去认证吧，毕竟这是对能力的肯定。对于我本人来说，我是绝对不会去弄Scrum认证的，毕竟自己能力有限，知道自己不可能成功，所以没必要浪费时间和精力。

Scrum实践：《硝烟中的Scrum和XP》

      这本书写得很好，很详细的介绍了Scrum开发中遇到的问题，还尝试了XP实践一一体验不同方式的持续构建、结对编程、测试驱动开发等，阐述了如何结合使用XP与Serum。而这对正在实施Serum敏捷软件开发的读者具有一定的参考价值和指导作用。当然Serum不能解决问题，真正解决问题还是要靠开发团队自己。出色的团队最重要的是有良好的素质，这些素质包括进取心、责任心、良好的习惯、热情，其次才是技术、流程。而scrum提供了一套实践方法，帮助软件团队养成良好的习惯，所以团队可以根据scrum提供的方法去实践。scrum精髓在于“检查并适应”，在三个角色、三种仪式（sprint计划、sprint回顾、每日例会）、三种制品（backlog、sprint backlog、燃尽图）的基础上，可以根据公司和项目情况，因地制宜的引入任何有利于缩短开发周期、提高产品质量的实践。还有，Scrum 注重的是管理和组织实践，而XP 关注的是实际的编程实践。

 

 

 

                                                                                                                                  注：本文引用了一些相关的学术用语，该文章并非全是出自作者之手。