构建之法第四周小结（6,7,9,10）

一 敏捷流程

敏捷方法是从上个世纪90年代开始发展起来的一组方法学的总称，包括极限编程等。2004年以后，很多500强的公司开始应用敏捷，例如HP,Microsoft，IBM等。敏捷开发（Agile Development）是一种以人为核心、迭代、循环渐进的开发方法。

作为CMM神话(The Mythical CMM）崩溃后被引入的一套新的软件开发模式，这几年来被广泛引起关注，并被寄予厚望。看了一下敏捷开发宣言——个体和交流>过程和工具,可以工作的软件>面面俱到的文档,客户合作>合同谈判.响应变化>遵循计划虽然右项也有价值，但是一些软件界的专家认为左项具有更大的价值。

敏捷开发包括很多方法，例如XP和FDD，同重量级的文档驱动的开发过程相比较，敏捷方法在灵活性等方面更有吸引力。这个方法的创始人强调了在软件实践过程中的变更而不是孤立的进行一些实践。

很多方法很难独立的使用。如:测试驱动的开发，结对开发，计划调整周期以及持续改进，不过，后来的结果证实，这些方法都取得了成功。 使用这些方法并不能保证一定成功。开发者的经验和技术仍旧是影响开发结果的最主要因素。对于合适的人，基于敏捷原则的开发方法可以产生更好的结果，同时形成一个愉快地、有激情的工作环境。

敏捷是一种态度而不是一个流程，是一种氛围而不是方法。敏捷项目管理强调的是沟通：与客户之间的沟通、项目成员之间的沟通。基于这一思路，敏捷项目管理更重视与“人”的作用，要求项目的组织形式具有以下特点：

1，很强的文化适应性。 2，最低限度的规则，鼓励自我组织，并结合自律以遵守哪些规则。 3，很好的协作和沟通环境。

从以上三点来看，敏捷项目管理对人的限制很低，软件产品的最终质量更多的取决与软件开发人员的素质和态度，而不是软件的开发过程和开发设备，这也是软件业与传统行业差距最大的地方。敏捷项目管理的最终着眼点便是如何提高软件开发人员的素质和如何激发软件开发软件的热情，从而提高最终软件的质量。但采用敏捷项目管理，也必然要求项目成员具有更高的专业技能和专业素养。

软件开发的最终着眼点是如何满足用户的需求。这些需求通常是复杂的、模糊的，甚至是不确定的。敏捷需求管理采用增量交付的软件开发流程，借助其与客户持续沟通的特点，不断的校准软件的开发防线，逼近用户的最终需求，使最终开发出来的软件满足客户的要求。

当然，敏捷方法也有其弊端，经验不足是一个很常见的致命缺陷。只有少数公司在为大型项目和复杂的开发组织提供敏捷实现方面具有广泛而深入的经验。我们看到，许多参与小型敏捷工作的公司虽然在小型 “Scrum 团队” 的水平上做得非常出色，但却没有能力理解、处理和解决当前组织中存在的现有组织性和文化方面的障碍。或者，他们留给有周密打算的开发团队的只是自己的设备，并希望开发团队借助书籍或一点点训练就能开始实现敏捷。一个小团队人数超过20人，随着经验的积累，他们已经看到，这种配置无法正常工作。管理负责人建议他们将措施范围分解成三个小团队，并建立另外两个团队工作室。仅仅是这一个调整，情况就开始好转。另一个客户分配给敏捷项目的所有核心团队成员都是兼职。如果有一些经验丰富的顾问，就会告诉他们，敏捷需要一个专门的团队，以实现真正协作的效益和更高的团队生产力。

敏捷团队可能会说，他们希望独处，但如果高层没有人支持他们，或者没有人知道他们正在做的好东西，那么他们也只能到此为止了。如果没有一个规划来明确定义相关措施，并提供敏捷性制约因素的处理和解决（例如，瀑布流程的检查点，来自其他必要实体的支持），那么定义相关措施就会变得更难，需要为这些措施配备工作人员和资金，管理障碍并维持持续的高层支持。若干个缺乏规划的 IBM 客户已经看到他们的措施被降级为宗教的骂战。在这些情况下，总是现状获胜，因为敏捷为组织带来了风险。

 

二  MSF

 

MSF是一套大型系统开发指南,它描述了如何用组队模型、过程模型和应用模型来开发Client/Server结构的应用程序，是在微软的工具和技术的基础上建立并开发分布式企业系统应用的参考。1994年，基于微软产品开发的经验和教训以及微软微软咨询服务的业务经验，微软推出了Microsoft?解决方案框架 Microsoft Solution Framework (MSF)。当时的MSF只是这些经验教训的松散集合。在以后的几年中，MSF 进一步吸收了微软各个部门和微软的合作伙伴在实际项目中的经验，在2002年，随着Visual Studio.Net 的发布，微软发布了一系列关于MSF 3.0的白皮书，针对MSF 3.0 的大规模培训也在中国开始。 2006年，MSF 4.0 随着Visual Studio Team Foundation 2005 发布。它增加了不少敏捷开发的内容，并且明确刻画了团队典型的流程和在新的团队协作软件包VSTS 中的应用。

MSF基本原则包括以下9条：

1、推动信息共享与沟通（Foster open communication）

2、为共同的远景工作（Work toward a shared vision）

3、充分授权和信任（Empower team members）

4、各司其职，对项目共同负责（Establish clear accountability and shared responsibility）

5、重视商业价值（Focus on delivering business value）

6、保持敏捷，预期变化（Stay agile, expect change）

7、投资质量（Invest in quality）

8、学习所有的经验（Learn from all experiences）

9、与顾客合作（Partner with internal and external customers）

沟通与合作依然是最主要的，MSF的团队模型和过程模型也是建立在这一基础上的。

MSF团队模型

MSF中每个子团队在项目中的作用和关注的问题分别对应着项目中不同的六个方面(产品管理、程序管理、开发、测试、发布管理、用户体验)。它们每个子团队的角色都代表了对项目的一种视角，没有哪一个人或角色能完全代表所有的不同质量目标。在此，MSF把角色与责任结合起来了。

由于在软件项目中每一个方面的失败均会导致整个软件项目的失败。因而，MSF团队模型中，在工作层面上也没有上下级的关系。每个子团队都对最终的软件质量的一部分负责。子团队成员内部，对子团队本身负责，实现该角色的质量目标。角色之间相互依赖，相互合作。它们之间通过“沟通”机制相互共享项目信息。

MSF团队中，各子团队的工作和职责相互依赖，这种相互的依赖性会鼓励子团队成员对由其他子团队工作做出评论和贡献，以确保该子团队成员所有的知识、能力、经验能够被应用到解决方案里。项目的成功，属于所有的子团队成员。他们共同分享一个成功的项目所带来的荣誉和回报。即使是一个不太成功的项目，也能做到全心投入并从中吸取教训，以完善他们的专长。

 

三 项目经理

项目经理是具体项目工作的管理者，他们在工作中不断提升自己的领导才华，同时该职业又是一个权利与责任并存的职业， 他们主要对项目进行背景调查，收集整理项目相关资料，进行需求策划，撰写项目调查报告和信息综述，对项目组成部分或模块进行完整系统设计，联系项目相关单位和相关技术专家，制定项目可行性研究报告，协同配合制定和申报立项报告材料，组织项目团队完成项目任务，保证项目的完成时间和完成质量。