去年一整年所在的项目组都在推行所谓的“敏捷”。“敏捷”并不是一个新鲜的东西，记得几年前公司就曾经请 ThoughtWorks 的咨询老师来培训过，当时我也被派去参加，只记得培训老师带大家喊口号似的诵读“敏捷宣言”，用一个简单的例子介绍演示 TDD，以及最后分组在白板纸上贴小卡片了。这次公司重又请了咨询老师们深度入驻项目组，手把手指导如何按敏捷的方式运作项目。不敢贸然下结论说最终的效果到底是不是真的“敏捷”了，是不是更好了，但是的确在这个过程中，团队内各种角色对自己和项目的思考会更主动、更深刻了。从这个角度去看，也许也还是挺不错的。
迫于团队内组织的“读书会”的压力，看完了敏捷创始人 Robert C. Martin 所写的《敏捷整洁之道——回归本源》一书。在过去实施敏捷的过程中，总会感觉有不少流于形式，或者控制不了的东西，敏捷搞的轰轰烈烈却似乎最总效果没有太大变化。看这本书也正是想探寻下自己遇到的这些困惑，敏捷专家对此有何见解。我觉得自己从来都不是一个理论派，不喜欢按照所谓的专家老师的套路生搬硬套，而是倾向于按自己的感觉去做具体的事情。看这本书，其实自己是抱着一些“尽信书不如无书”的不屑和挑衅的意味的。以下零散的笔记，没有是非对错，并非真理谎言，只是自己个人读书的时候的一些感悟和困惑的片段。
计划赶不上变化？响应变化？
敏捷既不解决计划赶不上变化的现状，也不是无止尽的响应变化的策略。
关于提供项目数据
- 持续的迭代
- 产出数据（怎样采集、分析利用数据？）
- 戳破幻想
- 调整管理铁十字：质量、速度、成本、完成的平衡
关于历史债务
- 新增人手往往不能能提高生产率
- 存量代码是更欠打的“导师”，新员工将学习旧代码并推测该团队的工作方式，继续制造债务（如何合适的处理架构设计上的历史债务？）
- 在运作的旧有系统的基础上推到重来、重新设计，往往很少能真正部署上线并解决问题
- 可自动化的测试用例都应该自动化
关于业务实践
- 采用“故事点”来估算团队容量（相对的“故事点”如何在持续运作的多个迭代中能趋于相对一致（最初的“黄金故事”）？从这个角度来看，“人天”是否依然是更明确的一种“故事点”？）
- 验收测试，自动化，持续构建
关于技术实践
- 依照 TDD 规则编写可测试的代码（赞同理念，但所谓的形式上的要求感觉荒唐）
- 有勇气去清理陈旧混乱的代码
- 重构：改善代码结构，但不改变由测试定义的行为（在既有的缺乏测试用例的现实情况下，重构如何切入？）
- 大型重构：不会专门预留时间，而是小步迁移代码（还是同样的问题：没有大量的用例保障的情况下，如何切入？）
- 结对：不需事先安排、强制结对，形式自由，防止知识孤岛