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

英文原书名 《Practices of an Agile Developer : Working in the Real World》

“选定了要走的路，就是选定了它通往的目的地。”

“即使你已经在正确的轨道上，但如果只是停止不前，也仍然会被淘汰出局。”

“百言不如一行,千虑不如一动”

1、态度决定一切

将注意力集中在处理做事上。
处理问题时要对事不对人：否定他人无助于事；尊重他人，提出疑虑并进行讨论。

2、唯一不变的就是变化

“唯有变化是永恒的”

3、把握开发节奏

随意安排的工作计划，没有任何规律，让人根本不知道明天会发生什么。

控制时间，保持开发节奏，是为了避免问题堆积，防止所有事情同时发生。

4、让设计指导而不是操纵开发

当前阶段的设计只是基于你目前对需求的理解，一旦开始编码，一切都会改变。

设计可以分2个层面：战略与战术。
前期的设计属于战略，通常只有在没有深入理解需求的时候需要这样的设计。
它应该只描述总体的战略，不应该深入到具体的细节。

“如果你自己都不清楚所谈论的东西，就根本不可能精确的描述它。”

一个故事：
在1804年，Lewis和Clark进行了横穿美国的壮举，他们的“设计”就是穿越蛮荒。
但是，他们不知道在穿越殖民地时会遇到什么样的问题。他们只知道自己的目标和约束条件，但是不知道旅途的细节。
软件项目的设计也与此类似。在没有穿越殖民地的时候，你不可能知道会出现什么情况。
所以，不要事先浪费时间规划如何徒步穿越河流，只有当你走到河岸边的时候，才能真正评估和规划如何穿越。
只有到那时，你才开始真正的战术设计。

“好的设计应该是正确的，而不是精确的。”

“计划是没有价值的，但计划的过程是必不可少的。”

5、使用短迭代，增量发布

软件开发不是精细的制造业，而是创新活动。规划几年之后客户才能真正使用的项目，注定是行不通的。

软件在被开发出来之前是不确定的，在开发过程总是存在着变化，
短迭代可以防止在错误的道路上走的太远，这样可以及时发现错误并进行纠正。

短迭代让人感觉非常专注且具效率。你能看到一个实际并且确切的目标。
严格的最终期限迫使你做出一些艰难的决策，没有遗留下长期悬而未决的问题。

如果每个迭代的时间不够用，要么是任务太大，要么是迭代的时间太短。

6、敏捷协作：定期安排会面时间

也许你个人很讨厌开会，但是沟通是项目成功的关键。

立会：站着开的会议。这可以保证会议快速进行，大部分人不喜欢站着进行长时间的谈话。

定期例会的好处：

• 让团队成员知道项目其他部分的进展。
• 帮助团队识别是否在某些事情上进行了重复劳动。
• 鼓励向前的动力：看到比尔报告的进度都在前进，会对彼此形成激励。

7、敏捷协作：架构师必须写代码

一个设计要解决的是眼前面临的特定问题，随着设计的实现，对问题的理解也会发生改变。

设计会随着时间而演进。

8、敏捷协作：及时通报进展与问题

接受一个任务，也就意味着做出了要准时交付的承诺。
不过，遇到各种问题而导致延迟，这种情况并不少见。
如果等到截止时间才发布坏消息，这就等于是为经理和技术主管提供了对你进行微观管理的机会。
他们会担心你再次让他们失望，并开始每天多次检查你的工作进度。

及时通报进展与问题，有情况发生时，就不会让别人感到突然，并且他们也很愿意了解目前的进展状况。
他们会知道何时应提供帮助，而且你也获得了他们的信任。