H.E.'s Blog

一个杰出的开发者必须打消任何个人英雄主义的想法，因为这让你不能在项目中与他人保持同样的等级，会让你孤立，让你难以去接受别人给你的意见与忠告，同时违背了敏捷态度的初衷。

一共成功的管理者必须打消任何成员都是一个“组件”可以任意调配的想法，因为让你失去对成员之间信任，失去他们对你的归属感。
 

上图中，虽然右项也很有价值，但是我们认为左项更有价值。

# 个体和交互 胜过 过程和工具
我的废话：成功的项目中，缺少不了一批出色的成员，出色的成员少不了正确的工作态度和过硬的技能。
一个优秀的成员(开发成员)往往未必是一个技术水平高超的人，但一定是与成员合作/沟通、与客户合作/沟通有出色表现的人。

接纳项目以后，千万别忙着搭建环境、设计系统架构，应该先组建团队，然后在去搭建环境，项目的系统架构与采用的关键技术需要经过所有成员的讨论和评审，最后才能通过定案。

在以往的面试过程中，我问一位面试者为什么项目中需要采用Hibernate框架，回答道：项目经理让我们用的。我将立刻换入另外一个话题中。

# 可以工作的软件 胜过 面面俱到的文档
我的废话：执行软件项目没有任何文档是一件很可怕，很可疑的事情，但是过多，过盛的文档将比没有文档更加可怕，因为你将需要付出代码与文档同步的代价，实践告诉我们大多数团队往往很难确保文档与代码的一致性，如果代码与文档之间失去同步性，那就成了一堆复杂的谎言。

在代码中能看见无处不在的注释说明，甚至能渗透到程序中的每个函数与方法，将会降低将来系统重构的成本。如果再加上，一份 剪短紧要 图文并茂的文档长期活跃在每个成员的邮件中，他价值大于沉睡于服务器中面面俱到的文档。

# 客户合作(协同)  胜过  合同谈判
我的废话：闭门造车，出门不合 这样的现象辙说明了产品根本无法满足客户的需求，软件开发在过程会遇到种种现象与问题。有些问题就连客户都无法预计。在开发期间需要你紧密的和客户保持反顾，把每个阶段完成的工作发布出去给客户进行演示，并且聆听客户的建议。开发团队和客户的协同工作才是最好的合同。

时时刻刻要让客户知道你在为他忙什么？通过沟通与反顾，你可以尽快的调整项目计划的优先级别。总比等到项目验收的时候让客户说出种种对产品抱怨，让你的团队去返工要好的多吧。记住，你的客户就是敏捷团队中的一员 ！

# 相应变化 胜过 遵循计划
我的废话：客户的实际生产服务器和在开发人员机器、公司内部测试服务器上运行的代码都是相同的，但是产生的效果是截然不同的。这将导致客户会对现在的成品提出新的需求。

响应变化和新需求的能力往往会导致这个项目的成败， 应该从2个方面去考虑：
1、对于项目上线后遇到的风险有哪些补救的措施，一般经验告诉我们至少要列出10条不同种类的措施，如果你不能列出10条以上，那么说明你将遇到的风险更大。

2、还应该知道在将来的：1-3个星期内，2个月内还可以实现客户的哪些需求，至于1年可以粗略的估计一下就可以了。需要和客户一同瞻望一下远景，分为 短期，中期，长期。

话外音：软件复杂度有三个主要因素：业务、技术和人员。

–end–