我的总结
- 对于功能, 业务, 代码逻辑, 不要只停留在表面, 要进一步地去思考为什么
- 保持开放的心态, 尊重他人的意见, 勇于承认自己的"不知道". 去思考他人为什么这么想
- 保持学习, 拥抱变化
- 有时间观念, 把控项目进度. 控制有规律的开发节奏, 不要让自己经常加班. 每天下班都能完成一天的任务.
- 让真正的软件用户做决策, 保持定期沟通, 让用户一直确认自己想要的东西
- 让工具替代人力, 实现自动化
- 控制代码质量, 简单, 清晰, 内聚
- 团队内部保持沟通 – 站会, 及时反映变化. 遇到问题及时求救, 保持向上反馈. 不要辜负人家的预期
深入思考, 保持开发, 拥抱变化, 保持沟通, 注重质量, 保持学习, 自动化.
书本原文
深度思考问题
“拙劣的代码工人会这样不假思索地改完代码，然后快速转向下一个问题。 优秀的程序员会挖掘更深一层，尽力去理解为什么这里必须要加1，更重要的是，他会想明白会产生什么其他影响。”
“在一本流行的管理图书《第五项修炼》中，作者建议，在理解一个问题的时候，需要渐次地问5个以上的“为什么”。这听起来就像退回到了4岁，那时对一切都充满着好奇。它是很好的方式，进一步挖掘简单直白的答案，通过这个路线，设想就会更加接近事实真相。”
当你问“为什么”的时候，也许你会被反问：“为什么你问这个问题？”在提问之前，想好你提问的理由，这会有助于你问出恰当的问题。
保持开发, 承认自己的不知道
“这个，我不知道”是一个好的起点，应该由此进行更进一步的调查，而不应在此戛然结束。”
“如果你对答案不满意，那么看看你是否可以改变问题。”
“作为第1步的理解代码，往往是最难的。如果别人给你的代码很容易理解，接下来的工作就省心多了”
尊重他人的意见
“孤立非常危险，不要让开发人员完全孤立地编写代码（见第155页，习惯40）。如果团队成员花些时间阅读其他同事写的代码，他们就能确保代码是可读和可理解的，并且不会随意加入这些“+1或-1”的代码。阅读代码的频率越高越好。实行代码复审 ，不仅有助于代码更好理解，而且是发现bug最有效的方法之一。”
“用Les Brown的一句话说就是：“你不需要很出色才能起步，但是你必须起步才能变得很出色。”
“如果你是一个有远见的人，就一定要特别尊重别人的意见。你是一个掌舵者，一定要把握方向，深思熟虑，吸取各方的意见。”
保持学习
“谁会帮助你保持步伐前进呢？在一个企业化的社会中，只有一个人会为你负责——你自己。是否能跟上变化，完全取决于你自己”
“跟踪技术变化 。你不需要精通所有技术，但需要清楚知道行业的动向，从而规划你的项目和职业生涯”
拥抱变化, 交付用户想要的软件
“敏捷的根本之一就是拥抱变化。既然变化是永恒的，你有可能一直使用相同的技术和工具吗？”
“真正的敌人是变化。软件开发如战争，形势的变化快速而又剧烈。固守昨天的计划而无视环境的变化会带来灾难。”
“不要在前期做大量的设计”并不是说不要设计。只是说在没有经过真正的代码验证之前，不要陷入太多的设计任务。当对设计一无所知的时候，投入编码也是一件危险的事”
时间观念
“许多的敏捷技巧来源于时间盒——设定一个短时的期限，为任务设定不能延长的最终期限。你可以选择放弃其他方面的任务，但是最终期限是不变的。你可能不知道完成所有的任务需要多少个时间盒，但每个时间盒必须是短期的、有限的，并且要完成具体的目标”
“如果在你工作的时候没有一个固定的最终期限（例如一天的结束），就应该好好想想了。它会让你的工作有一个节奏，在每天下班的时候，提交所有的工作，开心地收工。这样，明天就能开始新的内容，解决下一系列难题”
“有人说，上帝发明了时间，就是为了防止所有事情同时发生。因此我们需要更具远见，保持不同的开发节奏，这样敏捷项目的所有事情就不会突然同时发生，也不会随机发生，时间也不会不可预知。”
让真正的用户做决策
“记录客户做出的决定，并注明原因。好记性不如烂笔头”
“不要随意假设低级别的问题不会影响他们的业务。如果能影响他们的业务，就是有价值的问题。”
“因而，你只有一个选择：要么现在就让用户做决定，要么现在就开始开发，迟些让用户决定，不过要付出较高的成本。如果你在开发阶段回避这些问题，就增加了风险，但是你要能越早解决这些问题，就越有可能避免繁重的重新设计和编码。甚至在接近项目最终期限的时候，也能避免与日俱增的时间压力。”
“开发者（及项目经理）能做的一个最重要的决定就是：判断哪些是自己决定不了的，应该让企业主做决定。你不需要自己给业务上的关键问题做决定。毕竟，那不是你的事情。如果遇到了一个问题，会影响到系统的行为或者如何使用系统，把这个问题告诉业务负责人”
“没有人的思想和观点可以及时冻结，特别是项目的客户。就算是他们已经告诉你想要的东西了，他们的期望和想法还是在不停地进化——特别是当他们在使用新系统的部分功能时，他们才开始意识到它的影响和可能发生的问题。这就是人的本性。”
“你生产出了他们曾经要求过的软件，但却不是他们现在真正想要的。那最后的结果就是：惊讶、震惊和失望，而不是满意。 ”
分析技术的利弊
“每一门技术都会有优点和缺点，无论它是开源的还是商业产品、框架、工具或者语言，一定要清楚它的利弊。”
控制迭代
“迭代开发是，在小且重复的周期里，你完成各种开发任务：分析、设计、实现、测试和获得反馈，所以叫作迭代”
“每个工作日，每个团队成员会重新评估完成一个任务还需要多少小时。不管怎么样，只要所有任务的评估总和超过了一个迭代剩余的时间，那么任务就必须移到下一个迭代中开发”
单元测试, 控制代码质量
“单元测试能及时提供反馈 。你的代码会重复得到锻炼。但若修改或者重写了代码，测试用例就会检查你是否破坏了已有的功能。你可以快速得到反馈，并很容易地修复它们。
单元测试让你的代码更加健壮 。测试帮助你全面思考代码的行为，帮你练习正面、反面以及异常情况。
单元测试是有用的设计工具 。正如我们在实践20中谈论到的，单元测试有助于实现简单的、注重实效的设计。
单元测试是让你自信的后台 。你测试代码，了解它在各种不同条件下的行为。这会让你在面对新的任务、时间紧迫的巨大压力之下，找到自信。
单元测试是解决问题时的探测器 。单元测试就像是测试印制电路板的示波镜。当问题出现的时候，你可以快速地给代码发送一个脉冲信号。这为你提供[…]”
“如果不是真正需要它的时候，你就不应该实现这个功能。基于这一点，现在还没有足够的理由表示你需要Player 这个类”
“开发人员在完成任务时，可能会难以抵挡诱惑为节省时间而走“捷径”。然而，这些“捷径”往往只会推迟问题的爆发时间，而不是把它彻底解决掉”
“项目是以增量式方式进行开发的，写程序时也应该进行增量式编程
“源代码可以被读懂，不是因为其中的注释，而应该是由于它本身优雅而清晰——变量名运用正确、空格使用得当、逻辑分离清晰，以及表达式非常简洁。”
“这时要扪心自问，是不是真的需要用它，以及它将如何帮你解决眼前的问题。问问自己，是不是特定的问题强迫你使用这个解决方案。不要让自己被迫进行过分设计，也不要将代码过分复杂化。”
“内聚性用来评估一个组件（包、模块或配件）中成员的功能相关性。内聚程度高，表明各个成员共同完成了一个功能特性或是一组功能特性”
成为自己产品的用户
“很多成功的公司都是靠着“吃自己的狗食”活着。也就是说，如果要让你的产品尽可能地好，自己先要积极地使用它。”
度量项目进度
“所以，我们不应该去计算工作量完成的百分比，而应该测定还剩下多少工作量没有完成。如果你最初估计这个任务需要40个小时，在开发了35个小时之后，你认为还需要另外30个小时的工作。那就得到了很重要的度量结果（这里诚实非常重要，隐瞒真相毫无意义）。”
“奇怪的是，它花费的时间很可能要比最初估计时间长。没有关系，我们希望这能作为下一次的参考。在为下一个任务估计工作量时，可以根据这次经验调整评估。如果你低估了一个任务，评估是2天，它最后花费了6天，那么系数就是3。除非是异常情况，否则你应该对下次估计乘以系数3。你的评估会波动一段时间，有时候过低估计，有时候过高估计。但随着时间的推移，你的评估会与事实接近，你也会对任务所花费的时间有更清楚的认识。”
团队合作
“既然整个团队都是项目工作的一部分，我们希望实行代码集体所有制 （见第155页），以保证任何团队成员的缺席不会对项目造成影响”
“对于初学者来说，准备好后再共享代码才是有礼貌的做法（见第162页），这样才不会用未完成的工作来给团队成员造成麻烦。当准备好之后，我们应该与其他团队成员一起做代码复查
“坐着开的会议通常会持续更久，大部分人不喜欢站着进行长时间的谈话。”
“通常，立会都是在每个工作日的早些时候，且大家都在上班时举行。但是不要把它安排为上班后的第一件事。要让大家有机会从刚才混乱的交通状况中恢复状态，喝点咖啡，删除一些垃圾邮件什么的。要保证会议结束后有足够的时间，让大家在午餐之前做不少工作，同时也不要开始得过早，让每个人都巴不得赶紧结束会议，去喝点东西。一般来说，在大家到公司之后的半个小时到一个小时之内举行，是个不错的选择。”
“如果觉得立会是在浪费时间，那可能是大家还没有形成真正的团队意识。这并不是坏事，有利于针对问题进行改进。”
“当多人同时开发时，代码会被频繁地检查、重构以及维护。如果需要修复bug，任何一名开发人员都可以完成这项工作。同时有两个或两个以上的人，可以处理应用中不同部分的代码，可以让项目的日程安排也变得更为容易。”
“另一方面，知道别人将会接过自己的代码，就意味着自己要更守规矩。当知道别人在注意时，一定会更加小心。”
费曼学习法
“通过详细解释自己知道的东西，可以使自己的理解更深入。当别人提出问题时，也可以发现不同的角度。也许可以发现一些新技巧——听到一个声音这样告诉自己：“我以前还没有这样思考过这个问题”
“为团队成员在寻求帮助之前陷入某个问题的时间设定一个时限，一个小时应该是不错的选择”
“如果有人还是没有任何线索，那就给更多提示吧（或者甚至是答案）。如果有人提出来某些想法，不妨帮他们分析每种想法的优劣之处。如果有人给出的答案或解决方法更好，那就从中汲取经验，然后分享你的体会吧。这对双方来说都是极佳的学习经验。”
“用问题来回答问题，可以引导提问的人走上正确的道路。
如果有人真的陷入胶着状态，就不要折磨他们了。告诉他们答案，再解释为什么是这样。”
“同样的功能，不同开发人员的代码实现可能不同。差异并不意味着不好。除非你可以让某段代码明确变得更好，否则不要随意批评别人的代码。”
及时向上反馈
“及时通报进展与问题，有情况发生时，就不会让别人感到突然，而且他们也很愿意了解目前的进展状况。他们会知道何时应提供帮助，而且你也获得了他们的信任”
“接受一个任务，也就意味着做出了要准时交付的承诺”
慢慢来
“有句老话说得好：“你可以把马带到水边……但是你不能强迫它使用你最钟爱的代码编辑器。” You can lead a horse to water, but you can make him drink.