第 5 章 与敏捷的初恋故事
1、极限编程的12个具体实践
1）计划游戏
主张把整个项目拆分成从几天到几个星期的若干个迭代，把需求拆分成一个个独立的用户故事，放在Backlog里。
在每个迭代开始时，用户对用户故事进行排序，然后交付团队通过估算确定哪些用户故事可以在这个迭代里开发。
永远只对当前迭代进行计划，因为用户可能随时提出新的需求，产生的新用户故事放到后面的迭代中。
2）小型发布
每个迭代后，所开发的用户故事都可以发布或展示给用户，获取反馈，用户甚至可以提出新的用户故事放在后面的迭代中。
3）现场客户
用户应该和交付团队始终在一起，持续参与到项目中，阐明用户故事的具体需求和用户故事优先级，给与交付团队及时的反馈。
4）测试驱动开发
主张在编程前就根据用户故事的需求写好测试，通过测试来验证编程代码是否满足需求。
如果可能，测试应该是自动化的。
当我们为每一个用户故事都准备了自动化测试时，并可以一次性执行所有的自动化测试时，这些测试便为系统构造了一个“安全网”，它们是系统内部质量的基石。
5）持续集成
集成应该更频繁，最好每天甚至每次有代码提交时就集成一次。
集成包括编译、运行所有自动化测试、打包等，尽早暴露问题并及时修复问题，防微杜渐。
团队每天都应该监测持续集成的结果并维护持续集成的成果。
6）重构
不改变功能和外部行为而优化代码的可读性、质量和性能一直是程序员想做但不敢做的事情。
有了自动化测试和持续集成，重构便有了强大的保障，一旦重构后出现测试失败，便立即回滚代码。
7）代码集体所有权
在自动化测试和持续集成的保障下，任何人都可以对代码进行重构。
8）简单设计
传统的设计要求有前瞻性，要充分考虑今后的扩展性，但是这会为系统设计带来复杂性。
当原来的需求出现变更时，为原始需求埋下的复杂设计不但不会为虚无的未来带来收益，还直接影响了当下的开发效率和质量，过度设计是软件开发的几大罪行之一。
提出简单设计，永远只为当前要做的需求进行最简单的设计。
不要为了程序的可扩展性，把目前不需要的功能加入软件。如果设计确实不能满足需要，在自动化测试和持续集成的保障下，完全可以通过重构来解决。
9）结对编程
主张两个人结对在同一台计算机前来完成编程，一次性完成编程与评审。
这个过程其实包含两个人对设计、测试以及编程的讨论，确保这几个过程都要共同讨论。
然后配合自动化单元测试，完美解决事后评审的效率和效果问题。
10）每周只工作40小时
开发是一个脑力工作过程，前一天加班势必导致后一天的效率低下，得不偿失。
11）系统隐喻
记录用户故事需求时，用交付团队和客户都能理解的语言编写。
12）编码规范
有一套整个团队都认可的规范。在结对编程、重构和集体所有权等实践中都应落实这些规范。
它们是一个有机整体，互相配合、相得益彰。
计划游戏和小型发布确保开发可以更早开始和迭代式的持续交付。
现场客户和系统隐喻确保客户和交付团队都明白在做什么。
代码规范、结对编程、测试驱动和持续集成确保了简单设计、重构和集体代码所有权的可行性。
2、极限编程的 5 个核心价值
沟通、简单、反馈、勇气和谦逊。
更强调面对面沟通、简化设计与实践、面对当下以及避免重复和浪费。
3、花在需求上的时间越多，所剩的开发时间就越少，我们需要更早地开始开发，而不是更晚。
4、经验也告诉我们，用户在用户验收测试时改需求是完全不可避免的，与其惧怕和回避，不如直面和拥抱。
本章知识点小结：
· 极限编程及其12个实践。
网友评论