读书笔记 -《高效程序猿的45个习惯-敏捷开发修炼之道》

Posted 2020-09-23

《高效程序猿的45个习惯-敏捷开发修炼之道》

一本2010年出版的书，当时敏捷还仅仅是在国外開始流行，像我这样的菜鸟级根本听都没听过。这次通读了这本书。受益良多。回想自己的职业生涯，多是漫无目的的瞎混，为了生活而生活而已。

通过这本书才算对敏捷有了初步的了解，并有意向敏捷进行实践。愿此文可结识很多其它敏捷的先行者。带领我进入敏捷的世界。

第一章. 敏捷--高效软件开发之道

名言：  无论路走了多远。错了就要又一次返回   -- 土耳其谚语

敏捷开发宣言

1.  个体和交互 > 过程和工具

2. 可工作的软件 > 面面俱到的文档

3. 客户协作 > 合同谈判

4. 响应变化 > 遵循计划

   
   

尽管右项也有价值，但我们觉得左项具有更大的价值

工具方法

• 精辟概括：敏捷开发就是在一高度协作的环境中，不断地使用反馈进行自我调整和完好

小提示

• 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. 把握开发节奏

• 时间盒：设定一个短时的期限，为任务设定不能延长的终于期限。

  
  

• 解决任务，在一切变得一团糟之前：保持事件之间稳定反复的间隔，更easy解决觉的反复任务

读后感：往往在这一方面做的很不够。当初定下的时间总是会找出各种理由来说服自己

---

第四章 交付用户想要的软件

名言：  没有不论什么计划在遇敌后还可以继续运行 —— 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. —— 战略设计与战术设计

• 做到精确 ： 假设你自己都不清楚所谈论的东西，就根本不可能精确的描写叙述它。

  —— 约翰 · 冯 · 诺依曼
  

• 好的设计是一张地图。它也会进化：设计指引你向正确的方向前进，它不是殖民地，它不应该标识详细的路线。你不要被设计（或者设计师）操纵。

读后感：控制欲强的人做到这项可不easy。

放下，让其自由成长。

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
  

• 基于真实工作的评估： 让团队和客户一起，真正地在当前项目中工作。做详细实际的评估。由客户控制他们要的功能和预算。

读后感：对于传统的客户这个可不easy被接受。须要与客户进行全面的沟通。多数情况下应该是採用一些折中方案。

---

第五章 敏捷反馈

名言：  一步行动。胜过千万专家的意见。—— 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必备的能力。是与用户有效沟通的必要途径，敏捷开发注重交互、反馈，及时通报是实现这二个方面的重要方式。

全书读后感：本书看起来是一个个的习惯。事实上就是敏捷开发一个个的准则。

尽管所有做到并不easy，但还是层次清楚的阐述出了敏捷的本质、原则。

与传统的开发管理不同，敏捷是近年来风靡世界的方式。

敏捷为开发带来了一种全新的思路，一切以简单、交互、反馈、測试为基础。仅仅为打造出有质量、用户认可的项目，而不是传统管理中的成本、效率、风险。敏捷适用于那些追求质量而不是时间、成本的项目。

尽管不同传统项目管理，但也不是全然不顾成本、风险。传统管理中一但前期需求调研失误带来的风险也是巨大的，而敏捷通过小而频繁的公布、获取用户反馈是保障项目是朝着用户期望的方向前进的，这无疑是减少了项目的风险。如书中所说。卫星轨道就是通过频繁不断的微小调整才会与预定轨道最接近。从而达到目的地。

測试、部署自己主动化也是敏捷的重要特性，打造一个可重用的測试、部署方案是通向敏捷的必经之路。TDD & UnitTest保障项目内部粒度质量，从而保证了项目的总体质量。

使用FIT能够保证了项目的核心业务不偏离。

最后。一个优秀协作的团队才是敏捷开发的价值所在，是项目的保障所在。个人的力量是有限的，团队的力量是无限的。

Kevin Xiao 

2014-08-30 18:00