《精益开发与看板方法》—1-3-7 着眼整体（See the whole）

1-3-7  着眼整体（See the whole）

一个系统的好坏不是由单一组件来决定的，也不是各部分的总和，还要加上各部分相互的协作能力。

── 玛丽&汤姆·波彭迪克

这一段话拿来描述由人所组成的开发团队也十分适用，一个产能好的开发团队需要的不只是几个出色的工程师，团队的协作能力也是效能的一大因素。

局部优化易造成舍本逐末

开发团队需要注重全局，要避免局部优化！这里所谓的“局部优化”，是指单位与单位之间或公司与公司之间协作开发时，会刻意夸大自己在合作事件上的重要性，这种做法会让自己做的那一部分增加被重视的比例而失去凝聚整个系统的重要性。当然，这种想法也适用于开发团队，大家都强调自己开发这部分的重要性，也一样会造成局部性能的受重视，而失去兼顾全体的性能。同样也会发生在个人身上，如果人们在开发一个系统时，处处都优先考虑自己的专业兴趣而忽略整体性的考虑，则产品就会出现局部优化，导致共同利益受到损害。

在开发上过度注意细节、在的执行上也都可能会发生局部优化。

l   因为过度注意细节而容易产生局部优化
运用连续目标来修正短视可能是最有效的方式。为团队制定一系列目标，可以让团队不过度注重于细节，能够自动克服这种容易让人不能自拔的陷阱。举例来说，移动设备 UI 显示的重要性是不容忽视的，当大家对显示画面都有意见的时候（人的审美观是很难一致的），团队就很容易落入一改再改的现象而耽误进度；如果能紧守目标，让网页真正要表达的意图能够明确传达给用户，目的就可以算达成了，也就不会因为局部因素而耽搁进度。
在敏捷迭代开发所采取的方式是，让细节被较短的循环所约束。每一个迭代之间以达成既定目标为前提，就不怕过于注重细节而产生局部优化的现象。运用目标来驱动实操，可以避免过于关心细节而造成局部优化的问题。

l   因为考绩的因素而容易产生局部优化
2014年日本索尼企业的巨大亏损，该公司宣称是因为不正确的考绩方式所造成的，而这已经不是第一起因为考绩方式而导致企业失去竞争力的公司了（外传微软总裁鲍默尔也是因为不正确的考绩方式而导致微软战斗力下滑）。管理学上著名的霍桑效应（Hawthorne Effect）是指由于受到额外的关注而引起努力或绩效提升的情况，正好可以说明员工因为考绩方式而造成员工为了求得好的考绩刻意去做有利于考绩却无助于生产力的工作。

l   因为合约的因素而容易产生局部优化
签约的目的是保证一方能够相信另一方会履行合约的内容。签约的方式可能是固定价格的合约、可能是多阶段的合约或是目标成本的合约，但考虑只有一个，即交付完整的产品。

其实客户需要的不是软件，他们要的是解决他们的问题。

但合约的内容将牵引着双方走向合约上可以确认的项目去做开发。在项目的时限结束时，客户会得到合约上验收项目的组合，而不是一个完整的、用来解决他们问题的系统软件。这就是跟着合约走的问题，到最后你只会依据验收的项目一股脑儿完成项目，完成的部分就只有验收项目的部分，合约会带你局部优化软件。

那敏捷又能如何处理合约呢？敏捷式合约，当客户尝试过第一次与敏捷开发团队的合同之后，在下一次签约时，对签约的内容就变得不是那么在意，真正重要的是如何把需求描述完整。因为我们把开发工作切分成一个个的小周期，而每一个周期的产出客户都看得见，而且还可以就展示的结果反馈意见，让产品适当加入真正需要的功能或者是变更设计。用来配合一个一个迭代开发的是指定需求（Product Backlog）的优先级别。

让需求有优先级别，彻底瓦解局部优化

很多正在学习 Scrum 的人士都容易忽略确定需求优先级别的重要性。将这些需求积累起来一个一个做下去，每每做完一些需求客户就可以看到成果，满意的话，就继续做下去，不满意，就变更需求。这样做下去的结果应该预期到，那就是还没来得及把需求全部做完，客户大概已经急着要求先上线，因为你已经解决了他的问题！