《高效程序员的45个习惯-敏捷开发修炼之道》
一本2010年出版的书，当时敏捷还只是在国外开始流行，像我这种菜鸟级根本听都没听过。这次通读了这本书，受益良多，回顾自己的职业生涯，多是漫无目的的瞎混，为了生活而生活而已。通过这本书才算对敏捷有了初步的了解，并有意向敏捷进行实践。愿此文可结识更多敏捷的先行者，带领我进入敏捷的世界。
第一章. 敏捷--高效软件开发之道
名言： 不管路走了多远，错了就要重新返回 -- 土耳其谚语
敏捷开发宣言
- 个体和交互 > 过程和工具
- 可工作的软件 > 面面俱到的文档
- 客户协作 > 合同谈判
- 响应变化 > 遵循计划
虽然右项也有价值，但我们认为左项具有更大的价值
工具方法
- 精辟概括：敏捷开发就是在一高度协作的环境中，不断地使用反馈进行自我调整和完善
小提示
- Continuous development , not episodic —— 开发需求持续不断，切勿时断时续
- Inject energy —— 持续注入能量
天使建议
- 先难后易：我们首先要解决困难的问题，把简单的问题留到最后
读后感：敏捷开发似乎与传统的项目管理似乎背道而驰，敏捷更注重的是交互、协作、响应、解决而非一切以成本、绩效、风险、为基础的Project manage，开发者/PM需要在项目立项时就清楚项目是否适合敏捷开发。
第二章. 态度决定一切
名言： 选定了要走的路，就是选定了它通往的目的地
读后感： 这二年，态度还是做的不错的，到目前为止各方面提高有限，仍相信只要继续努力，未来会更美好
1. 做事
- Blame doesn‘t fix bugs
- 指责不会修复bug：把矛头对准问题的解决方法，而不是人。这是真正有用处的正面效应。
读后感：记忆中《信息项目管理师》考试中对此问题的第一反映是问责。目前所接触的管理似乎也不在以问责作为第一任务，先解决、后总结才是处理的首选。
2. 欲速则不达
- Beware of land mines —— 防微杜渐
- Don‘t code in isolation —— 不要孤立的编码
- Use unit tests —— 使用单元测试
- 不要坠入快速的简单修复之中：要投入时间和精力保持代码的整洁、敞亮
读后感：这二年这方面做的严重不足，虽然有一定的测试，但感觉只是为了给自己一个借口而已。
3. 对事不对人
- Negativity kills innovation —— 消极扼杀创新
- 对事不对人：让我们骄傲的应该是解决了问题，而不是比较出谁的主意更好
集体决策的骆驼：能容纳自己并不接受的想法，表明你的头脑足够有学识。—— 亚里士多德
读后感：这点做的还算不错，但人无完人自己有时在想出了一个更好的办法时总会有经意的窃喜一下。
4. 排除万难，奋勇前进
- 做正确的事：要诚实，要有勇气去说出实情。有时，这样做很困难，所以我们要有足够的勇气。
读后感：基本已做到。
第三章 学无止境
名言： 即使你已经在正确的轨道上，但如果只是停止不前，也仍然会被淘汰出局。——
Will Rogers (美国著演员)
读后感： 自己完全没有做到。
5. 跟踪变化
- 迭代和增量式学习、了解最新行情、参加本地的用户组活动、参加研讨会议、如饥似渴的阅读
- 跟踪技术变化：你不需要精通所有技术，但需要清楚知道行的动向从而规划你的项目和职业生涯
读后感：完全的短板，近二年对外界、最新的技术、业界动态几乎完全不知，阅读更加不用说了。现已意识回来，今年的阅读书籍不断的增加中。
6. 对团队投资
总是要成为你所在的那个乐队中最差的乐手，如果你是乐队中最好的乐手，就需要重新选择乐队了。我认为这也适用于乐队之外的其他事情。—— Pat Methany (著名爵士吉他手)
- 提供你和团队学习的更好平台：通过午餐会议可以增进每个人的知识和技能，并帮助大家聚焦在一起进行沟通交流。唤起人们对技术和技巧的激情，将会对项目大有禆益。
读后感：Pat的话是否绝对正确值得怀疑？ 若每一个最优秀的乐手都离开了那么如何建立优秀的乐队呢？亲手培养出一个不断自我提高的乐队是否会更有成就感？
7. 懂得丢弃
- Expensive mental models aren‘t discarded lightly —— 根深蒂固的习惯不可能轻易就丢弃掉
- 学习新的东西，丢弃旧的东西：在学习一门新技术的时候，要丢弃附上你前进的旧习惯。毕竟，汽车要比马车车厢强得多。
读后感：技术的习惯可以更新升级，内功的更新请慎重。万变不离其宗。一切武功招式都建立在深厚的内功之上。
8. 打破沙锅问到底
- 不停的问为什么：不能为只满足于别人告诉你的表面现象。要不停地提问直到你明白问题的根源
读后感：提问要问到点子上，而不是为了问“为什么”而问，思考之后的问题才有意义
9. 把握开发节奏
- 时间盒：设定一个短时的期限，为任务设定不能延长的最终期限。
- 解决任务，在一切变得一团糟之前：保持事件之间稳定重复的间隔，更容易解决觉的重复任务
读后感：往往在这一方面做的非常不够，当初定下的时间总是会找出各种理由来说服自己
第四章 交付用户想要的软件
名言： 没有任何计划在遇敌后还能够继续执行
—— Helmuth von Moltke (德国陆军元帅,1848-1916)
读后感：在技术方面你可以选择最适合的，在业务方面需要用户的确认，越早使用自动化的测试及部署是保证质量与进度的有效工具。小而频繁的发布并获取反馈是保持项目不偏离目标的保障。正常的动态的评估工作量才能顺利的与用户沟通，保障顺利完成项目。
10. 让客户做决定
- Decide what you shouldn‘t decide. —— 决定什么不该决定
- 让你的客户做决定：开发者、经理或者业务分析师不应该做业务方面的决定。用业务负责人能够理解的语言，向他们详细解释遇到的问题，并让他们做决定。
读后感：做的还不错，但有时还是做了一些多余的决定。
11. 让设计指导而不是操控开发
- Design should be only as detailed as needed to implement. —— 设计满足实现即可，不必过于详细
- Strategic versus tactical design. —— 战略设计与战术设计
- 做到精确 ： 如果你自己都不清楚所谈论的东西，就根本不可能精确的描述它。—— 约翰 · 冯 · 诺依曼
- 好的设计是一张地图，它也会进化：设计指引你向正确的方向前进，它不是殖民地，它不应该标识具体的路线。你不要被设计（或者设计师）操纵。
读后感：控制欲强的人做到这项可不容易。放下，让其自由成长。
12. 合理的使用技术
- Blindly picking a framework is like having kids to save taxes. —— 盲目地为项目选择技术框架，就好比是为了少交税而生孩子
- Don‘t build what you can download. —— 不要开发你能下载到的东西
- 根据需要选择技术：首先决定什么是你需要的，接着为这些具体的问题评估使用技术。对任何要使用的技术，多问一些挑剔的问题，并真实地作出回答。
读后感：对自己的策略总是希望做出一些特别的东西，所以见到别人的东西第一反映就是自己实现。有些东西是可以通过下载获得，但做为学习就需要不断的code来获得更多的实践。我还并未达到别人要求的境界。
13. 保持可以发布
- Checked - in code is always ready for action. —— 已提交的代码应该随时可以行动
- 在本地运行测试 / 检出最新的代码 / 提交代码
- 保持你的项目时刻可以发布：保证你的系统随时可以编译、运行、测试并立即部署。
读后感：目前已经有所改进，还仍然需要时间积累更多的经验。
14. 提早集成，频繁集成
- Never accept big-bang inegration. —— 决不要做大爆炸式的集成
- 提早集成，频繁集成：代码集成是主要的风险来源。要想规避这个风险，只有提早集成，持续而有规律的进行集成。
读后感：这个可以做到。
15. 提早实现自动化部署
- QA should test deployment —— 质量保证人员应该测试部署过程
- 一开始就实现自动化部署应用：使用部署系统安装你的应用 ，在不同的机器上用不同的配置文件测试依赖的问题。质量保证人员要像测试应用一样测试部署。
读后感：一直想学习自动部署安装，拖了这么多年还是没有实现。今年一定要完成这个目标。
16. 使用演示获得频繁反馈
- Requirments are as fluid as ink. —— 需求就像流动的油墨
- 维护项目术语表 / 跟踪问题记录日志
- 清晰可见的开发：在开发的时候，要保持应用可见（而且客户心中也要了解）。每隔一周或者两周，邀请所有的客户，给他们演示最新完成的功能，积极获得他们的反馈。
读后感：的确是这样，不过也需要看用户的专注度及用户的时间配合等多个元素。
17. 使用短迭代，增量发布
- Show me a detailed long-term plan,and I‘ll show you a project that‘s doomed. —— 给我一份详细的长期计划，我就会给你一个注定完蛋的项目。
- 增量开发：发布带有最小却可用功能功的产品。每个增量开发中，使用1-4周左右迭代周期。
读后感：这个对于风险控制还是比较有用的。小而频繁的发布需要建立在自动测试、自动部署之上，手工测试、部署的风险及成本就大大提高了。
18. 固定的价格就意味着背叛承诺
- A fixed price guarantees a broken promise. —— 固定的价格就是保证要u
- 基于真实工作的评估： 让团队和客户一起，真正地在当前项目中工作，做具体实际的评估。由客户控制他们要的功能和预算。
读后感：对于传统的客户这个可不容易被接受。需要与客户进行全面的沟通，多数情况下应该是采用一些折中方案。
第五章 敏捷反馈
名言： 一步行动，胜过千万专家的意见。—— Bill Nye,The Science Guy 科普节目主持人
读后感：在项目的不同阶段需要有不同的策略来获得用户的反馈，项目初始阶段需要小而频繁的发布来获得前期用户的反馈、意见。项目中后期需要固定期限的发布来对用户反馈进行支持。自动化测试，部署是节约成本及保障质量的有效手段。
19. 守护天使
- Coding feedback. —— 编写产生反馈的代码
- 清楚自己要测试的内容： 确保测试是可重复的 、 测试你的边界条件、不要放过任何一个失败的测试
- http://xprogramming.com/software.htm NUnit / JUnit / HttpUnit
- 单元测试能及时提供反馈 / 单元测试让你的代码更加健壮 / 单元测试是让你自信的平台 / 单元测试是解决问题时的探测器 / 单元测试是可信的文档 / 单元测试是学习工具
- 使用自动化的单元测试：好的单元测试能够为你的代码问题提供及时的警报。如果没有到位的单元测试，不要进行代码修改。
读后感：今年的重点任务
20. 先用它再实现它
- Write tests before writing code. —— 编程之前先写测试
- Good design doesn‘t mean more classes. —— 好的设计并不意味着更多的类
- 先用它再实现它：将TDD(Test Driven Development)作为设计工作，它会为你带来更简单更有效的设计。
读后感：与19个习惯一样，TDD是今年重点的任务。需要体验TDD的快感。
21. 不同环境，就有不同问题
- Automate to save time. —— 使用自动化测试节省时间
- 不同环境，就有不同的问题：使用持续集成工具，在每一种支持的平台和环境中运行单元测试。要积极寻找问题，而不是等问题来找你。
读后感：这个以前虽然知道，但现实中还真没有遇到此类问题。这个同样是需要自动测试、自动部署来支撑。手工测试、部署会使成本大大提高。
22. 自动验收测试
- FIT：集成测试框架。http://fit.c2.com
- 为核心的业务逻辑创建测试：让你的客户单独验证这些测试，要让它们像一般的测试一样可以自动运行。
读后感：首次接受到这个概念，原来所知的验收测试一直是客户手工测试为基础的。
23. 度量真实的进度
- Focus on where you‘re going. —— 专注于你的方向
- 度量剩下的工作量：不要用不恰当的度量来欺骗自己或者团队。要评估那些需要完成的待办事项。
- Scrum方法中的sprint：在Scrum开发方法中，每个迭代被称作sprint，通常为30天时间。sprint待办事项列表是当前迭代任务列表，它会评估剩下的工作量，显示每个任务还需要多少小时可以完成。
读后感：往往工作中会给自己预期的时间上增加一段，这是正常的，因为每个任务都需要一定的缓冲时间用来应付各种不同的意外及未预计到的困难。
参考资料：scrum method - http://blog.csdn.net/xoyojank/article/details/2864542
24. 倾听用户的声音
- It‘s a bug. —— 这是一个bug。
- 每一个抱怨的背后都隐藏了一个事实：找出真相，修复真正的问题。
读后感：多数coder总是认为用户的一些反馈是无理取闹，是用户理解力差，是用户计算机技能不够所致。这些想法都是可怕的，用户对项目的各种质疑都是项目进化过程中需要解决的问题，无论是否是代码中的error还是业务操作中的issue。
第六章 敏捷编码
名言：任何一个笨蛋都能够让事情变得越来越笨重、越来越复杂、越来越极端。需要天才的指点以及许多的勇气，才能让事情向相反的方向发展。 —— John Dryden 英国诗人
读后感：编码是我们每天都需要进行的工作，编写优秀的代码是每个coder的目标，但每人对优秀代码的定义有所不同，敏捷开发对优秀代码的定义不是极其复杂、无法理解的、极致性能的代码，而是追求极简、极清晰、适当性能的代码。
25. 代码要清晰地表达意图
- Hoare谈设计软件：设计软件有两种方式，一种是设计的尽量简单，并且明显没有缺陷。另一种方式是设计的尽量复杂，并且没有明显的缺陷。—— C.A.R. Hoare 英国计算机科学家 快速排序法发明者
- PIE原则：代码必须明确说出你的意图，而且必须富有表达力。这样可以代码更易于被别人阅读和理解。代码不让人迷惑，也就减少了发生潜在错误的可能。一言以蔽之，代码应意图清晰，表达明确。
- 要编写清晰的而不是讨巧的代码：向代码阅读者明确表明你的意图。可读性差的代码一点也不聪明。
读后感：原来还是偏向于做复杂的代码，以满足小小的虚荣心，到现在才明白化繁化简的道理在coding中同样有效。
26. 用代码沟通
- Don‘t comment to cover up. —— 不要用注释来包裹你的代码。
- ndoc / Javadoc / Rdoc
- 用注释沟通：使用细心的选择、有意义的命名。用注释描述代码意图和约束。注释不能替代优秀的代码。
读后感：这点基本没有做到，目前为止还没有做出让自己满意的代码风格，注释也使用的相当少，无用的注释倒是层出不穷。需要快速的积累更多此方面的经验。
27. 动态评估取舍
- NO best solution. —— 没有最佳解决方案。
- 动态评估权衡：考虑性能、便利性、生产力、成本和上市时间。如果性能表现足够了，就将注意力放在其他因素上。不要为了感觉上的性能提升或者设计的优雅，而将设计复杂化。
读后感：总想做到完美的项目往往被人为的将设计推向了复杂。切记：物及必反，平衡为王。就如持乒乓球行走一样，想乒乓球永远在球拍中间是不可能的，只能顺应球的行为还不断调整才能前进的更远。
28. 增量式编程
- 在很短的编辑/构建/测试循环中编写代码：这要比花费长时间仅仅做编写代码的工作要好得多。可以创建更加清晰、简单、易于维护的代码。
读后感：TDD的理念就是不断的修改、不断的测试，边测边改，再测再改的习惯将大大提前每一小段代码的质量，从而保证整体的质量。
29. 保持简单
- Simple is not simplistic. —— 简单不是简陋。
- 开发可以工作的、最简单的解决方案：除非有不可辩驳的原因，否则不要使用模式、原则和高难度技术之类的原因。
读后感：设计模式是为了解决某一类问题的解决方案，如果你的问题只是特例的、没有共性及可重用性的尽量不要使用设计模式来增加项目的复杂度。
30. 编写内聚的代码
- 让类的功能尽量集中，让组件尽量小：要避免创建很大的类或组件，也不要创建无所不包的大杂烩类。
读后感：将各种独立的功能分离出来，将粒度控制到一个合适的级别，才更利于复用代码。
31. 告知，不要询问
- Keep commands separate form queries. —— 将命令与查询分离开来。
- 告知，不要询问：不要抢别人的对象或是组件的工作。告诉它做什么，然后盯着你自己的职责就好了。
读后感：不要为了省事而将其它类或组件的工作分配给了自己，这样不利于整体项目的控制与设计。会让其它感人困惑。
32. 根据契约进行替换
- Liskov替换原则（里氏替换原则，设计模式的七个原则之一）：任何继承后得到的派生类对象，必须可民替换任何被使用的基类对象，而且使用者不必知道任何差异。换句话说，就是某段代码如果使用了基类中的方法，就必须能够使用派生类的对象，并且自己不必进行任何修改。
- 继承是OO建模和编程中被滥用最多的概念之一。如果违反了Liskov替换原则，继承层次可能仍然可以提供代码的可重用性，但是将会推动可扩展性。
- Use inheritance for is-a; use delegation for has-a or uses-a. —— 针对is-a关系使用继承；针对has-a或uses-a关系使用委托。
- 通过替换代码来扩展系统：通过替换遵循组件代码到代码库中，而且其他代码对此一无所知，它们还获得了新的或改进后的功能。
读后感：滥用继承也是我这二年来最经常犯的错误之一，继承虽好但一定要想清楚再使用，Liskov原则是非常有用的，它保证了扩展性及正确性，不遵循该原则是非常危险的，不要迫不得已万不可在派生类中违反该原则。
第七章 敏捷调试
名言：你也许会对木匠那毫无差错的的工作印象深刻。但我向你保证，事实不是这样的。真正的高手只是知道如何亡羊补牢。——
JeffMiller，家具制造者、作家
读后感：分离法一个适用于万事万物的解决方案。错误信息是非常宝贵的，获取一次错误的信息有时会变的非常困难，记录下所有的错误信息将为排除项目隐藏的bug非常有用的，只有重现错误了才能解决错误，而错误信息就是我们重现错误的最好工具。
33. 记录问题解决日志
- Don‘t get burned twice. —— 不要在同一处跌倒两次。
- 维护一个问题及其解决方案的日志：保留解决方案是修复问题过程的一部分，以后发生相同或类似问题时，就可以很快找到并使用了。
读后感：好处主要有二点：1. 人脑不可能永远把所有的错误、解决过程清晰的记忆下来，日志可以在我们记忆模糊时有效的做出提示。2. 用于分享给团队成员，提醒团队不要重复犯错。
34. 警告就是错误
- 将警告视为错误：签入带有警告的代码，就跟签入有错误或者没有通过的代码是一样的，都是极差的做法。签入要创建工具中的代码不应该产生任何警告信息。
读后感：这点其在是汗颜。目前的项目中哪个没有一、二百个警告呢？ 革命尚未成功，同志仍需努力。
35. 对问题各个击破
- Prototype to isolate. —— 用原型进行分离。
- 对问题这各个击破：在解决问题时，要将问题域与周边隔离开，特别是在大型应用中。
读后感：调试中最常用的也是最简单的方法——分离法。化复杂为简单，变多维为一维。
36. 报告所有异常
- 处理或是向上传播所有的异常：不要将它们压制不管，就算是临时这样做也不行，在写代码要估计到会发生的问题。
读后感：与警告问题一样，代码中有太多的catch掉的exception了。
37. 提供有用的错误信息
- 区分错误类型：程序缺陷 / 环境问题 / 用户错误
- 展示有用的错误信息：提供更易于查找错误细节的方式。发生问题时，要展示出尽量多的支持细节，不过别让用户陷入其中。
读后感：制作或使用一个日志类，来将错误都详细记录下来吧。但用户界面只需要做出友好的提示就可，不必将异常的细节给用户，普通用户也是看不懂的。
第八章 敏捷协作
名言：我不仅发挥了自己的全部能力，还将我所仰仗的人的能力发挥到极致。—— 伍德罗 · 威尔逊，美国第28任总统（1856-1924）
读后感：注重交互、协作、反馈的敏捷开发，对于协作自然是重中之重，优秀的协作可以放大团队成员的能力，三个臭皮匠胜过诸葛亮。形成一个良好协作氛围也需要用户、资源、管理者的支持，一个优秀协作团队是难能可贵的，带来的回报同样也是丰厚的。
38. 定期安排会面时间
- 猪与鸡：Scrum将团队成员与非团队成员这种角色命名为猪和鸡。团队成员是猪，非团队成员（管理层、支持人员、QA等）是鸡。来自一则寓言：讲的是农村里的动物打算一起开饭店，并且准备用熏肉和鸡蛋作为早餐提供。对于鸡来说，当然是要参与进来了，可对于猪来说，可就是放血投入了。只有“猪”才被允许参与Scrum的每日立会。
- 使用立会：立会可以让团队达成共识。保证会议矮小精焊不跑题。
读后感：确实每日的晨会可以提醒团队已经进入工作状态，并且可以在团队之间有个非常好的沟通效果，及时的调整成员间差异让团队达成共识。但会议一定要简短有目的性，过长的立会只会让团队心生厌倦。
39. 架构师必须写代码
- You can‘t code in PowerPoint. —— 不可能在PowerPoint幻灯片中进行编程。
- 可逆性：《程序员修炼之道》中指出不存在所谓的最终决策。没有哪个决策做出之后就是板上钉钉了。实际上，就时间性来看，不妨把每个重要的决策，都看作沙上堆砌城堡，它们都是在变化之前所做出的预先规划。
- 新系统的设计者：新系统的设计者必须要亲自投入到实现中去。—— Donald Knuth 计算机科学大师 经典著作《计算机程序设计艺术》
- 优秀的设计从积极的程序员那里开始演化：积极的编程可以带来深入的理解。不要使用不愿意编程的架构师——不知道系统的真实情况，是无法展开设计的。
读后感：架构师是离不开编程的，架构师编程的角度必须站的更高，看的更全面。离开了coding的架构师就是在流沙里建高楼一样不靠谱。
40. 实行代码集体所有制
- 要强调代码的集体所有制：让开发人员轮换完成系统不同领域中不同模块的不同任务。
读后感：团队间互相交换模块任务应该是提高团队整体实力的方式之一，但需要资源支撑，毕竟一个不熟悉该模块的coder来做该模块是需要更多的时间来理解模块中的业务，但同时也可以检验该模块是否设计的合理、简单。
41. 成为指导者
- Knowledge grows when given. —— 教学相长。
- 成为指导者：分享自己的知识很有趣——付出的同时便有收获。还可以激励别人获得更好的成果，而且提升了整个团队的实力。
读后感：将自己的知识输出的时候本身就是一个组织的过程，将知识组织之后会对它理解的更深，会得到平时无法得到的灵感或触动。既可以帮助他人/团队提升,获得别人的认可，也是自己提升、自我认可的一种非常好的方式。
42. 允许大家自己想办法
- 给别人解决问题的机会：指给他们正确的方向，而不是直接提供解决方案，每个人都能从中学到不少东西。
读后感：授人鱼不如授人渔。你的方法不一定就是最好的，最好的方法永远是下一个。留别人思考的空间，也留给自己学习的空间。
43. 准备好后再共享代码
- 代码不执行提交操作的其他安全选择：使用远程访问 、随身携带、使用带有底座扩展的笔记本电脑、使用源代码控制系统的特性
- 准备好再共享代码：绝不要提交尚未完成的代码。故意签入编译未通过的或是没有通过单元测试的代码，对项目来说，应被视作玩忽职守的犯罪行为。
读后感：目前.net平台下的敏捷开发平台TFS中已经提供了“搁置集”工具来将暂时不能进行提交的代码进行保留，以便下次继续工作。
44. 做代码复查
- 代码复查和缺陷移除：要深藏不露的程序bug，正式地进行代码检查，其效果是任何已知形式测试的两倍，而且是移除80%缺陷的唯一已知方法。 —— Capers Jones的《估算软件成本》
- 复查方式：通宵复查 、 捡抬游戏、结对编程
- 复查所有的代码：对于提升代码质量和降低错误率来说，代码复查是无价之宝。如果以正确的方式进行，复查可以产生非常实用而高效的成果。要让不同的开发人员在每个任务完成后复查代码。
读后感：复查的作用是不可忽视的，同时也是需要资源来实现的，在项目的CPS中就应该有所预留复查的Effi，并与相关人员沟通好复查的重要性、必要性。当然复查不是流水线时过走场，需要复查人员对项目进行有效的思考后，目的性明确的工作。
45. 及时通报进度与问题
- 及时通报进展与问题：发布进展善，新的想法和目前正在关注的主题。不要等着别人来问项目状态如何。
读后感：及时汇状况是PM必备的能力，是与用户有效沟通的必要途径，敏捷开发注重交互、反馈，及时通报是实现这二个方面的重要方式。
全书读后感：本书看起来是一个个的习惯，其实就是敏捷开发一个个的准则。虽然全部做到并不容易，但还是层次清楚的阐述出了敏捷的本质、原则。与传统的开发管理不同，敏捷是近年来风靡世界的方式。敏捷为开发带来了一种全新的思路，一切以简单、交互、反馈、测试为基础，只为打造出有质量、用户认可的项目，而不是传统管理中的成本、效率、风险。敏捷适用于那些追求质量而不是时间、成本的项目。
虽然不同传统项目管理，但也不是完全不顾成本、风险。传统管理中一但前期需求调研失误带来的风险也是巨大的，而敏捷通过小而频繁的发布、获取用户反馈是保障项目是朝着用户期望的方向前进的，这无疑是降低了项目的风险。如书中所说，卫星轨道就是通过频繁不断的微小调整才会与预定轨道最接近，从而达到目的地。
测试、部署自动化也是敏捷的重要特性，打造一个可重用的测试、部署方案是通向敏捷的必经之路。TDD
& UnitTest保障项目内部粒度质量，从而保证了项目的整体质量。使用FIT可以保证了项目的核心业务不偏离。
最后，一个优秀协作的团队才是敏捷开发的价值所在，是项目的保障所在。个人的力量是有限的，团队的力量是无限的。
Kevin Xiao
2014-08-30 18:00