本文是第二部分(第一部分)。

作为个体的人

人们常常选择性的忽略了软件开发和实际过程是由一个一个的个体的人来完成的；然而人都有弱点，容易犯错，有固定的失败模式/成功模式，以及通用的行为模式：

1. 人们的行为通常是难以预测的
2. 人性本身有些固有的失败模式
3. 总有一些方式比另外一些方式更容易让人们共同工作，即使对同样一群人
4. 有很多模式引起失败，那么什么样的方式才能达成成功?

人的行为模式

人的行为总是非线性的并且比一般的物理实体复杂的多；给予双倍的奖励，或者双倍的惩罚，甚至于双倍的时间，都不能确定的提高一个人的思考速度/思考质量/编程设计输出。一个每周工作40个小时的人可能在下周工作60个小时就可以得到双倍的进展，但是接下来一周再工作60个小时，可能不仅不能维持之前双倍的效率，可能反而不及最初正常的效率，因为人们会产生疲惫。

人的行为会突然发生偶然的变化，某某可能突然对测试工作发生兴趣；一个偶然的小事儿可能导致一个高级工程师的离开等；某个工程师可能在一种情况下显得特别容易沟通而换了一种环境则会变得难以沟通。人们协作的方式也可能有巨大的差异，不同的文化背景可能青睐于不同的沟通方式；直接或者保守在不同的文化氛围中显得完全不同。真因为这些不可避免的差异，所以才有各种各样的技术方法被发明出来，然后，没有一种方法是绝对有效的。这个结论是明显的，然后人们往往容易忽略之，而盲目的鼓吹某种方法是正确的方式并且期望所有人按照这种方式来工作。

人的行为在很多方面表现出巨大的不同，并不意味着一些通用的方法就没有意义；还是有些东西在很大的范围内行之有效的。基于此，我们就可以在承认人与人之间巨大差异的基础上来建立大家认可的方法，但是并不能由此期望人们的具体行为会趋同或者可以严格预测。

有效的过程方法的意义在于：

1. 允许人们更容易地表述他们的想法
2. 可以完成一个人无法独立完成的工作
3. 将复杂而又繁琐的工作自动化
4. 使得人们的相互沟通更容易

失败模式

有如下五种比较普遍的失败模式：

1. 人们总是会犯错 – 简单但又常常被人们忽略；敏捷和迭代开发的巨大进步意义就在于承认人总是会出错，但是通过一连串小的错误来及早暴露风险；持续不断的解决问题而不是固守详细周密的计划 – 没有错误的计划似乎只存在于真空之中
2. 倾向于保守谨慎 在最终结果一致的情况下，同样的问题通过不同的方式呈现出来，人们的反应却有可能大不相同。当我没可能获得比较高的潜在收益的时候，人们总是倾向于去冒险，然后在可能失去某些东西的时候，人们则会倾向于选择更保守的方式。一个有很多瀑布模式成功经验的manager（其实这些成功的经验有多大程度上算作成功就很难考量）在一个初级的工程师提出尝试迭代开发的模式的时候可能持激烈的反对态度；他可能更愿意采用传统的策略，能产生“确定“的输出而不是”可能产生更大收益“但是又”看起来奇怪“的方式
3. 习惯的不一致性 如果人们总能保持一致，那么就不会有减肥/锻炼的问题。问题是我们从来不缺少方法实践，缺少的恰恰是实践这些方法
4. 倾向于发明新的东西而不是研究已有的方案 大概跟人们接受的教育有关 – 鼓励原创的论文/独立完成的作业等等；而不是团队工作。很多时候人们需要更好的重用已有的成果而不是自己从头发明一切
5. 自律和适当容忍的妥协 强调高度的自律往往是一厢情愿，然后过度的妥协又容易导致越来越多的混乱。项目经理可能对严格要求团队遵循某个方法实践所带来的副作用感到惊讶。譬如XP实践强调结对编程和Coach，然后很多Team在实践的过程中却将重构的工作丢下不理，等待更高级的工程师去做

某些方式总是比其它的更好

尽管人与人之间的差异是巨大的，然而总有一些方法是更有效的。人们倾向于做的更好，如果他们

1. 从具体的例子开始
2. 从容易处理的东西开始着手
3. 从已有的东西入手寻找替代/优化的方式

还有一些方法也更容易让人们取得积极的进展：

1. 通过观察和学习的同时做工作
2. 支持精力集中的思考并同时支持积极的沟通 – 设置安静时间和公共沟通区域来加强沟通
3. 根据人们的长处进行任务分配
4. 选择最好的人才
5. 激励方式的选择 – 开发人员的工作激情/成就感/贡献荣誉感觉
6. 清晰有效的反馈 – 越及时效果越好

寻找成功模式

作者长期面试成功项目团队的经验中，如下的申明频繁的出现： 一小部分人在关键的时间介入，作出了一切需要做的工作。看起来是很随意的描述，然而更仔细的审视发现，如下的一些成功因素慢慢浮现出来:

1. 擅长于四处观望式的扫视 – 设计文档未必需要每一个细节都和实现保持一致，只要大致结构的一致即可。做维护工作的开发者就可以通过快速的浏览找到需要的部分，剩下的就是具体怎么做了，细节的准确意义并没有想的那么大了。文档只需要保持足够的精确即可，能完成主要的工作，使得人们不用费很大功夫就可以找到对应的细节即可。Tech Lead仅仅需要大致看一下问题大概在什么地方并知道其它工程师去做即可，而不是处理每一个细节
2. 人们持续不断的学习 – 敏捷过程提出的持续改进就是这么一个思想，回顾当前迭代中那些值得改进的，持续的需西和发现不足，人们就能不断的进步。
3. 可以改变的韧性 – 通过团队的集体氛围来慢慢提高个体的韧性，使之适应并改变 – 当然并不是每个个人都可适应这个过程，然后他就会离开
4. 主动承担和贡献

融合这些成功的因素

是否有融合这些成功因素的方法存在？自组织团队的想法给出了一种思路，但是实现的过程自然是充满崎岖的。需要培养这样的氛围，每个人都需要能够第一时间发现系统中的错误，不管这个人的职位和角色是什么；他将错误传递到能够正确纠正错误的人的成本往往决定了整个项目的成本。

平衡各种策略

很多时候看起来很好的策略并不意味着在大部分情况都是好的 – 譬如让一个Team的成员坐在一起。PMDOI认为，我们可以通过具体情况具体分析的策略/工具和方法来真正提高效率和可靠性。一个真正好的策略需要平衡各种足够好的基本策略，将其打包调整其中的某些不合时宜的做法。想想人们常说的，坐在一起的团队和面对面的沟通总是能达到最好的效果；但是为了达到真正高效的沟通(因为这才是最高优先级的事情),我们还需考虑到：

1. 人们有时候需要安静的思考和集中注意力的工作
2. 有时候需要进行一些安静的对话来交换一些深思熟虑的意见
3. 有时候需要放松的心态学习一些新的语言/工具等

Osmotic Communication要求人们做的足够的近以便周围人的谈话都很容易被听清楚，这样有什么问题就可以马上作出反应；信息传递的成本几乎为零。这样一些复杂的问题可能会被周围的专家以最快的速度解决。然后Cone of Silence策略则提出了一种相反的做法：一个或者多个团队成员坐得距离其它人远远的从而可以排除沟通干扰。但是这种策略也有典型的适用场合，譬如Tech Leader本来应该用于安排解决艰难负责的问题，然而由于周围的人不断得分散其注意力，导致复杂的问题没有被解决，进度不断被延误，进而导致情况更加恶化。Cockburn认为，相互沟通的两个人的距离超过一辆公交车的长度时，沟通的效果就会急剧下降。

策略的平衡意味着，安排座位的时候需要考虑某些负面的影响 – 有些时候需要将人们适度分隔开来而不是聚越来越多的人在一个大的空间。当周围的噪音和干扰越来越大的时候，人们容易觉得压抑和头疼，很多重要的工作都无法正常的完成。每一种策略都有一定的限制；明智的决策什么时候Osmotic Communication是有效的，什么时候它因为人太多而失去意义是个重要的事情。

待续。