敏捷开发学习小记
最近买了一本介绍敏捷开发的书，《敏捷软件开发——原则、模式与实践》
作者是个大拿级别的人物，Uncle Bob
这两天有空就读几页
这是本理论性较强的书，所以读完后印象不会很深（但读书时绝对不会打瞌睡，这可是本bible似的的书啊）
所以读到经典之处、会心一笑之处，需要及时记下自己的理解，以便将来翻阅
敏捷一词来源于2001年初美国犹他州雪鸟滑雪圣地的一次敏捷方法发起者和实践者的聚会，正式这帮人组成了“敏捷联盟”。
该会议起草了敏捷软件开发宣言，其中最重要的部分就是对一些与会者一致同意的软件开发价值观的表述：
- 人和交互 重于 过程和工具。
- 可以工作的软件 重于求全责备的文档。
- 客户协作重于合同谈判。
- 随时应对变化重于循规蹈矩。
第一点很容易理解，强调人以及人与人之间的交互。在大学的软件工程课上，主要介绍了两种开发方式：瀑布式和迭代式。
敏捷开发区别于瀑布式的特征很明显，敏捷开发是以一种迭代的方式推进的。
而敏捷开发与迭代式开发的区别在哪呢？重视交互应该是最明显的区别之一吧（暂且加上之一）
敏捷开发提倡结对编程，就是常说的pair programming，这增加了两个人之间交互的机会
更甚的是，结对的两个人通常在一天内会更换，就是说你上午跟A结对，下午可能跟B结对。
另外敏捷开发更适用于小型团队，在一个办公室工作，属于那种通信基本靠吼的状态，当然团队成员之间的交互会更方便。
另外敏捷开发强调用户（或用户代表）要与开发团队在一起工作，便于及时沟通交流。
还有一个好处，就是有利于团队中知识的迅速传播。即使有人离开团队，另外的人也能完成相应的工作。
（在微软这样的大型公司，通讯方式中邮件站很大比重，当然这样也有好处，不会打断团队成员的思维。敏捷方式在这里并不是非常合适）
因此，“人与交互”被列为敏捷开发价值观之一，并排在第一位。
第二点也比较容易理解，就是客户常说的“少整那些虚的，我只要看到能用的软件”
这条价值观能安抚客户的情绪，增加客户对团队的信任。
如果按照瀑布式流程，客户可能在签订开发合同3个月后，看到的还只是各种文档（需求文档、设计文档、详细设计文档等等）
客户心理肯定不踏实。并不是说瀑布式一定不好，而是客户不懂这些，他们只要看到能用的东西
第三点也很容易理解，“协作”VS“谈判”
在第一点中说的交互也包括开发人员与客户的交互。
在第二点中说过如果采取瀑布式，那么客户可能在3个月内什么都看不到，除了一堆文档
这时候，客户心理没底，肯定要与团队进行“谈判”。。。
所以第三点强调与客户之间的协作。这里说的客户，可能是客户代表，也可能是公司内的业务人员
这里是要把客户当做朋友关系相处。
这里我体会很深，我们公司一直提倡客户派人员到我们团队中来，一起工作。
客户也很愿意，为了保障项目的进度，为了监督我们不偷懒。。。
当然，这样对改善与客户的关系也非常有帮助，尤其在中国这个“关系型”社会，意义重大
第四点理解起来也容易，在大学软件工程课上，老师说在瀑布式开发中，需求修改的时间越靠后，成本越大
所以需求分析人员的压力很大。。。
由于敏捷开发是迭代式的，通常迭代周期是2个星期，因此很容易相应新需求或是对旧需求的修改。
当然，在一个迭代计划（2星期）制定后并进行开发，就不能修改了。
如果是新需求的话，就在制定下一个迭代计划时考虑。
如果是对旧需求的修改，那也在制定下一个迭代计划时考虑，只不过是作为新需求的方式提出。什么意思呢，就是说先提出一个需求，然后再修改，这就相当于提出了两个需求。我细想了下，这有一个非常现实的意义，两个需求就是收两份钱啊。。。即使不会多付钱，那客户也是知道开发团队多做了一件事情
按照我上面的理解，我们公司倒还真是个敏捷型的，除了不是结对编程
不过我们也是一个小型团队，在一个办公室，通讯基本靠吼
看来这本书是买对了，对以后的工作肯定能提供不少指导