阅读《构建之法》6-7章有感

第六章  敏捷流程

敏捷开发宣言——
个体和交互 胜过 过程和工具
可以工作的软件 胜过 面面俱到的文档
客户合作 胜过 合同谈判
响应变化 胜过 遵循计划

以上的宣言比较抽象，基于该理念，以下是ThoughtsWork咨询公司的推崇的n个敏捷开发实践：
Iteration
迭代开发。可以工作的软件胜过面面俱到的文档。因此，敏捷开发提倡将一个完整的软件版本划分为多个迭代，每个迭代实现不同的特性。重大的、优先级高的特性优先实现，风险高的特性优先实现。在项目的早期就将软件的原型开发出来，并基于这个原型在后续的迭代不断晚上。迭代开发的好处是：尽早编码，尽早暴露项目的技术风险。尽早使客户见到可运行的软件，并提出优化意见。可以分阶段提早向不同的客户交付可用的版本。
IterationPlanningMeeting
��迭代计划会议。每个迭代启动时，召集整个开发团队，召开迭代计划会议，所有的团队成员畅所欲言，明确迭代的开发任务，解答疑惑。
Story Card/Story Wall/Feature List
在每个迭代中，架构师负责将所有的特性分解成多个Story Card。每个Story可以视为一个独立的特性。每个Story应该可以在最多1个星期内完成开发，交付提前测试（Pre-Test）。当一个迭代中的所有Story开发完毕以后，测试组再进行完整的测试。在整个测试过程中（pre-test，test），基于Daily build，测试组永远都是每天从配置库上取下最新编译的版本进行测试，开发人员也随时修改测试人员提交的问题单，并合入配置库。
敏捷开发的一个特点是开放式办公，充分沟通，包括测试人员也和开发人员一起办公。基于Story Card的开发方式，团队会在开放式办公区域放置一块白板，上面粘贴着所有的Story Card，按当前的开发状态贴在4个区域中，分别是：未开发，开发中，预测试中，测试中。Story Card的开发人员和测试人员根据开发进度在Story Wall上移动Story Card，更新Story Card的状态。这种方式可以对项目开发进度有一个非常直观的了解。
在开发人员开始开发一个Story时，ta需要找来对应的测试人员讲解Story功能，以便测试人员有一致的理解，同时开始自动化系统测试脚本的开发。
Standup Meeting
站立会议。每天早上，所有的团队成员围在Story Wall周围，开一个高效率的会议，通常不超过15分钟，汇报开发进展，提出问题，但不浪费所有人的时间立刻解决问题，而是会后个别沟通解决。
Pair Programming
结对编程是指两个开发人员结对编码。结对编程的好处是：经过两个人讨论后编写的代码比一个人独立完成会更加的完善，一些大的方向不至于出现偏差，一些细节也可以被充分考虑到。一个有经验的开发人员和一个新手结对编程，可以促进新手的成长，保证软件开发的质量。
CI/Daily Build
持续集成和每日构建能力是否足够强大是迭代开发是否成功的一个重要基础。基于每日构建。开发人员每天将编写/修改的代码及时的更新到配置库中，自动化编译程序每天至少一次自动从配置库上取下代码，执行自动化代码静态检查（如PCLint），单元测试，编译版本，安装，系统测试，动态检查（如Purify）。以上这些自动化任务执行完毕后，会输出报告，自动发送邮件给团队成员。如果其中存在着任何的问题，相关责任人应该及时的修改。
可以看到，整个开发组频繁的更新代码，出现一些问题不可避免。通过测试部又在不停地基于最新的代码进行测试。新增的问题是否能够被及时发现并消灭掉，取决于自动化单元测试和系统测试能力是否足够强大，特别是自动化系统测试能力。如果自动化测试只能验证最简单的操作，则新合入代码的隐患将很难被发现，并遗留到项目后期，形成大的风险。而实际上，提升自动化测试的覆盖率是最困难的。
Retrospect
总结和反思。每个迭代结束以后，项目组成员召开总结会议，总结好的实践和教训，并落实到后续的开发中。
ShowCase
演示。每个Story开发完成以后，开发人员叫上测试人员，演示软件功能，以便测试人员充分理解软件功能。
Refactoring
重构。因为迭代开发模式在项目早期就开发出可运行的软件原型，一开始开发出来的代码和架构不可能是最优的、面面俱到的，因此在后续的Story开发中，需要对代码和架构进行持续的重构。迭代开发对架构师要求很高。因为架构师要将一个完整的版本拆分成多个迭代，每个跌倒由拆分成很多Story，从架构的角度看，这些Story必须在是有很强的继承性，是可以不断叠加的，不至于后续开发的Story完全推翻了早期开发的代码和架构，同时也不可避免的需要对代码进行不断完善，不断重构。
TDD
测试驱动开发。正如上面讲的，迭代开发的特点是频繁合入代码，频繁发布版本。测试驱动开发是保证合入代码正常运行且不会在后期被破坏的重要手段。这里的测试主要指单元测试。

敏捷软件方法

　　对应于以人为本的敏捷项目管理和以增量交付的敏捷需求管理，敏捷软件开发提供很多具体的方法指导软件的开发实践，这些方法包括重构、结对编程、测试驱动、持续集成等，以下简要介绍重构和结对编程。

　　1，重构。

　　重构即在不改变既有代码的行为的前提下，改善代码的设计。重构的目的是为了消除代码重的“坏气味”，从而达到放置代码腐烂的目的。

　　常见的重构的手法有“重命名”、“抽出新方法”、“包装成员”、“将方法在继承层次中移动”等。

　　重构通常以设计模式作为目标，以单元测试作为保证代码正确性的手段。

　　2，结对编程

　　结对编程即两个开发人员使用一台电脑进行开发，通常是一个人操作另一个人，另一个人辅助，一段时间后，两人交换。这种看似降低了一半的开发效率开发方式具有以下优点：

　　第一，所有的决定都是有两个人共同做出的，并且所有的代码是在两个人的配合下写出的，这大大降低了Bug的产生几率，从而缩短了调试所需要的时间。

　　第二，所有的代码至少有两个人了解，这降低了代码对开发人员的依赖性，防止开发人员的离职对项目造成的影响。

　　敏捷软件开发为现代商用软件量身打造。经过这几年的发展，无论在项目的开发方式，还是在具体实践方法上，都有形成了自己的特色，与传统的开发方式分庭抗衡。

　　敏捷软件开发不是一个具体的过程，而是一个涵盖性术语(umbrella term)，用于概括具有类似基础的方式和方法。

第七章  MSF

Microsoft Solution Framework 简称MSF，是微软推荐的做软件开发的方法论，MSF在1994年开始发布，随着Visual Studio 的发布，MSF也在不断的更新，但不管怎么变，MSF方法论核心的东西还是没有多大的变化。

MSF基本原则

1、推动信息共享与沟通（Foster open communication）第一个原则，用大白话来说，就是所有信息都保留，并公开，讨论要包括所有涉及的角色，决定要公开，并告知所有人。当然，对牵涉到技术机密、安全性等信息要采取必要的保护措施。

2、为共同的远景工作（Work toward a shared vision）我们做一个产品，不管是应用软件、行业软件，还是通用软件，要明确项目的目标是什么。

（1）这个目标必须是明确的，没有二义性；

（2）这个目标不是当前就能达到，必须是通过努力才能达到的；

（3）这个目标不是空泛的，它应该对项目成员每天的工作都有指导作用。

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

授权（Empower）有两个意思：一是给某人权力和权威（Give authority to somebody：to give somebody power or authority）；二是给予某人更多自信和自尊（Inspire somebody with confidence：to give somebody a sense of confidence or self-esteem）。在一个高效的团队中，所有的成员都应该能得到充分的授权，他们有权力在自己的职权范围内按照他们自己的承诺完成任务，同时，他们也充分信任其他同事也能实现各自的承诺。类似地，团队的顾客（包括内部和外部的顾客）也认为团队能兑现承诺，并进行相应的规划。

4、各司其职，对项目共同负责（Establish clear accountability and shared responsibility）团队中的每个角色都有自己的职责，如果出了问题，这个角色就要负责任。

5、重视商业价值（Focus on delivering business value）一个项目的商业价值只有在它被成功地发布并运行时才能体现出来，所以，MSF过程模式包括了开发和发布阶段。

6、保持敏捷，预期变化（Stay agile, expect change）软件工程，唯一不变的是变化。所以干脆别幻想客户的需求会在第一时刻很明确，然后保持不会变。要注意，我们是预期变化，不是期望变化。除开外部原因，团队内部也在变化，我们对技术的掌握每天都在提高，原来认为不可能的事可能变得容易。我们对客观世界和软件系统的了解每天都在深化，原来觉得没问题的小细节忽然成了大问题。甚至原来一起打拼的同事忽然要离开……这些都要求我们团队保持敏捷的身段。

7、投资质量（Invest in quality）

对质量的重视，引起对质量的投资，引起对人、过程和工具的投资。

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

MSF在每一个里程碑结束时都要做一个“里程碑回顾”，这个回顾不必等到整个项目结束才做。这样做的好处是，大家对最近的成败都记忆犹新，能提供比较准确和全面的反馈；如果发现了错误，可以马上研究解决办法，在下一个里程碑中通过实践来验证。另外，一些好的做法可以及时得到总结和推广。

在项目结束时，MSF推荐请团队以外的专家来主持召开“事后诸葛亮”会，这样的专家会比较系统地总结团队的成功经验和失败教训，同时也客观评价团队的一些特性和团队的开发过程管理，这样能促使团队成员以客观、向前看、解决问题的心态来参加“事后诸葛亮”会，避免主观臆断或相互指责。

9、与顾客合作(Partner with internal and external customers)

 

MSF团队模型

MSF团队模型定义了小组同级成员的一些角色和职责，如图2-2所示。

MSF团队模型认为，任何技术项目都必须达到特定的关键质量目标才能够被认为是成功的项目。如果任何一个角色无法实现其目标，都将危及整个项目。因此，每个角色都被认为是同等重要的，重要的决定都要共同做出。说白了，一个项目要达到的目标很多，MSF团队模型让不同的角色去实现这些目标。在一个项目结束的时候，每个角色都问自己这样的问题——我是否达到了我的质量目标？

 

最后，比如测试团队（角色：测试）要保证“我发现的所有问题都得到解决”，那么测试团队就会做以下两件事：

 

（1）发现产品的问题；

（2）保证这些问题都得到处理。

 

要注意的是，保证这些问题都得到“处理”和得到“解决”是不一样的，有些问题目前不能得到完美的解决，但是可以有让用户满意的处理方案，项目团队不能回避这些问题。