敏捷开发修炼之道——高效程序员的45个习惯二（态度决定一切）

传统的软件开发图书一般先介绍一个项目的角色配置，然后是你需要产生那些工件——文档、任务清单、甘特图等，接着就是规则制度，往往是这样的。而敏捷方法的世界则有些不同。敏捷依赖人，而不是依赖于项目的甘特图和里程表，图表、集成开发环境或者设计工具，它们本身都无法产生软件，软件是从你的大脑中产生的。而它不是孤立的大脑活动，还会有许多其它方面的因素：个人情绪、办公室文化、自我主义、记忆力等。它们混为一体，态度和心情的瞬息变化都可能导致巨大的差别。

只有在对项目、工作、事业有一个专业的态度时，使用敏捷方法才会生效。如果态度不正确，那么所有的这些习惯都不管用。有了正确的态度，才可以从这些方法中完全受益。下面是一些习惯和建议：

[b](一)、做事：[/b]

指责不会修复BUG，把矛头对准问题的解决办法，而不是人。这是真正有用处的正面效应。

切身感受：勇于承认自己不知道答案，这会让人感觉放心。一个重大的错误应该被当作是一次学习而不是指责他人的机会。团队成员们在一起工作，应该互相帮助，而不是互相指责。

[b](二)、欲速则不达：[/b]

不要坠入快速的简单修复之中。要投入时间和精力保持代码的整洁、敞亮。

1、不要孤立地编码：团队成员花些时间阅读其他同事写的代码，能确保代码是可读和可理解的。实现代码复审，不仅有助于代码更好理解，而且是发现bug最有效的方法之一。

2、使用单元测试：单元测试帮助你很自然地把代码分层，分成很多可管理的小块，这样就会得到设计更好、更清晰的代码。

切身感受：在项目中，代码应该是很亮堂的，不应该有黑暗死角。你也许不知道每块代码的每个细节，或者每个算法的每个步骤，但是你对整体的相关知识有很好的了解。没有任何一块代码被警戒线或者“切勿入内”的标志隔离开。

[b](三)、对事不对人：[/b]

让我们骄傲地应该是解决了问题，而不是比较出谁的主意更好。

切身感受：一个团队能够很公正的讨论一些方案的优点和缺点，你不会因为拒绝了有太多缺陷的方案而伤害别人，也不会因为采纳了某个不甚完美（但是更好的）解决方案而被人忌恨。

平衡的艺术：

1、尽力贡献自己的好想法，如果你的想法没有被采纳也无需生气。不要因为只是想体现自己的想法而对拟定的好思路画蛇添足。

2、脱离实际的反方观点会使争论变味。若对一个想法有成见，你很容易提出一堆不太可能发生或不太实际的情形去批驳它。

3、在开始寻找最好的解决方案之前，大家对“最好”的含义要先达成共识。在开发者眼中的最好，不一定就是用户认为最好的。反之亦然。

4、只有更好，没有最好。

5、不带个人情绪并不是要盲目地接受所有的观点。用合适的词和理由去解释为什么你不赞同这个观点或方案，并提出明确的问题。

[b](四)、排除万难，奋勇前进：[/b]

做正确的事，要诚实，要有勇气去说出实情。有时，这样做很困难，所以我们要有足够的勇气。

切身感受：勇气会让人觉得有点不自在，提前鼓足勇气更需要魄力。但有些时候，它是扫除障碍的唯一途径，否则问题就会进一步恶化下去。鼓起你的勇气，这能让你从恐惧中解脱出来。

平衡的艺术：

1、如果你说天快要塌下来了，但其他团队成员都不赞同。反思一下，也许你是正确的，但你没有解释清楚自己的理由。

2、如果你说天快要塌下来了，但其他团队成员都不赞同。认真考滤一下，他们也许是对的。

3、如果设计或代码中出现了奇怪的问题，花时间去理解为什么代码会是这样的。如果你找到了解决办法，但是代码仍然令人费解，唯一的解决办法是重构代码，让它可读性更强。如果你没有马上理解那段代码，不要轻易地否定和重写他们。那不是勇气，而是鲁莽。

4、当你勇敢地站出来时，如果受到了缺乏背景知识的抉择者的抵制，你需要用他们能够听懂的话语表达。节约资金、获得更好的投资回报，避免诉讼以及增加用户利益，会让论点更有说服力。

5、如果你在压力下要对代码质量作出妥协，你可以指出，作为一名开发者，你没有职权毁坏公司的资产。