作者介绍
刘华（Kenneth）,汇丰软件开发（广东）有限公司软件工程经理，拥有16年以上的软件开发经验，10年以上的项目和团队管理经验。
曾担任多个优选敏捷团队的技术主管。负责所在部门的敏捷以及DevOps转型，包括敏捷及DevOps培训、转型驱动、工具和实践落实。
2008年开始接触敏捷开发，起步于极限编程，是公司早期敏捷布道者。
熟悉极限编程、Scrum、看板方法、测试驱动开发、持续集成、行为驱动开发、实例化需求等。
个人书评
硝烟中的敏捷转型之旅，以小说体的形式讲述了从传统开发转向敏捷开发的过程。
从传统开发转向敏捷开发不光是概念上的，更加是思想、流程以及行动上的转变。有很多的所谓敏捷开发都只是停留在概念上或口号上，并没有实际的行动。
如果你看过《凤凰项目》的话，那么你会对这本书所写的内容并不陌生，相对于《凤凰项目》来说，这本书更加符合国内的情况，但是描述的手法与《凤凰项目》还是有差别的，毕竟《凤凰项目》的其中一位作者前身是特约撰稿人，这一点本书的作者是比不了的。但是，依然不影响对这本书核心内容的理解。
0.引子
本文在前面的几个章节中，以人物对话的方式简单的阐述了几个常见的问题，软件开发中最重要的是什么：要搞清楚用户到底想要什么。在开发的过程中，经常出现的是我们认为用户想要什么，而在交付的时候却发现根本不是用户想要的。
敏捷开发与DevOps到底有什么区别吗？敏捷开发的目的是打通业务、开发、测试之间的墙。而DevOps打通的是开发团队与运维团队之间的墙。
在交付的过程中，需要注意两个关键点：前置时间、周期时间。IT部门关心的是周期时间，而业务部门关心的则是前置时间。要打破这个僵局需要双方共同的协商，而协商的方式即是采用“用户故事地图”与MVP的方式。将所提的需求按照是否能构建一个完整的故事地图为优先级，而在实现时要遵守MVP的原则“最小可用产品”。
1.极限编程
极限编程的12个具体实践：
1、计划游戏：把需求拆分成一个个独立的用户故事，在开始时，让用户对用户故事进行排序再交付团队估算哪些故事可以在这个迭代里开发。在迭代的过程中注意，只对当前迭代进行计划。因为用户随时会提出新的需求。
2、小型发布：每个迭代后，所开发的用户故事都可以发布或展示。
3、现场客户：用户与客户要在一起，持续参与项目。
4、测试驱动开发：在编程前根据用户故事的需求写好测试，通过测试来验证是否满足需求。此过程最好是自动化。
5、持续集成：更频繁的集成，最好每天甚至每次有代码提交时就集成一次。尽早暴露问题才能及时的修复。
6、重构：在自动测试和持续集成的保障下，重构就有了保障，当出现任何问题的时候，可以立即回滚。
7、代码集体所有权：要在有自动化测试和持续集成的保障下。
8、简单设计：不要为了可扩展性，把目前不需要的功能加入软件。
9、结对编程：两人对设计、测试以及编程进行讨论，确保过程共同讨论。
10、每周只工作40小时
11、系统隐喻：记录需求时，用团队和客户都可以理解的语言。
12、编码规范：有一套团队认可的规范。
极限编辑的5个核心价值：
沟通
简单
反馈
勇气
谦逊
2.如何转变
说了这么多，如何让一个用户去转变思想？其实，在任何一个领域有一套方法或者说是一套模式是通用的。1、说明对对方的好处。2、简化流程。3、鼓励使用新流程。要让用户清楚的明白转变新方式之后的既得利益，并且在他使用后可以很容易的看到成果。最后采用合适的鼓励方式送用户一程，推动他来到新的世界。以前传统的方式犹如用户的舒适区，人性就是喜欢在舒适区待着，当进行转变时也就意味着要走出舒适区，而这个转变对用户来说如果没有足够的动力是很难进行的。
很多事情的转变是需要思想上的转变而不单单止于形式或方法。在传统的项目上我们很容易会说“XXX的项目重要”，“XXX项目上的优先级要高”，“我们要集中火力把XXX项目上的事情都处理了”。在敏捷开发中，思想的转变就在于我们已经不再以项目为单位进行计划了，已经转向了为业务的整体最高价值。由于可以做的持续交付，开发人员开发的新功能可以很快的上线，所以也会很快的产生效益，所以从效益与价值的角度上来说，哪个需求可以实现最高的价值，那么谁的优化级将是最高的。
3.掌握关键点
Ⅰ.在敏捷开发的过程中，交付的文档可以遵循如下的内容：
1、需求描述：格式可以为“作为......（谁），我想要......（做什么），为了......（为什么）”，其实就是用语言来描述了一个用例图。
2、确认理解：复述需求的理解并要求对方确认。
3、问为什么：询问为什么需要权及为什么现在就需要。这样可以更加的方便开发人员理解需求以及他的重要性。
4、验收条件：可以使用测试用例。
5、详细设计与实现：通过上面的描述已理清需求，可以将设计与实现记录下来。
6、集成测试结果
7、用户验收测试
8、上线备忘。是否有一些额外步骤
Ⅱ.优先级的分类
加急类。时效性特别强的需求，或者对产品重大担缺陷的修复。
固定交付日期类。要安排一定的产能来处理这些请求。并在开发的过程中不断的评估了解进度，如有必要，这类的请求可以升级为加急类。
标准类。大部分的产能都应归类到此。无需评估，按先进先出的顺利处理，如果超过两周的工作量，建议先进行拆分。
无形类。主要是针对一些用户价值有限的附加功能。
Ⅲ.关键链
在任务开展之前要对任务中的关键链做评估，因为非关键链任务的提前完成对整个项目并没有帮助，而且关键链中的关键点也同样要保护好，在《凤凰项目》一书也曾经提到过，而且需要注意的是，这个关键点可能是一个明确的任务，也有可能是一个关键性的人物，或物资等。“关键链”与“关键路径”并不完全相同，他们之间最大的区别是关键链考虑了资源冲突。把安全时间从每个任务中转移出来的前提是，每个任务所需要的资源都能聚焦在当前任务上，所以若在单个项目中运用关键链，如果所需资源与其他项目有冲突，依然不能达到效果。我们要从全局角度考虑来规划关键链和关键资源。
4.最终目的
说一千道一万，最终的目的是要实现常态化。我们做了敏捷开发不是目的，目的是要做到持久交付。
