2010年5月1日：“敏捷的团队合作”
我用Scrum已经7年了，而后面6年我一直写关于它的文章。Scrum的概念太吸引人了——规则多变、自我管理的团队在短而固定的周期内周而复始地进行一系列小环节（或功能）工作，并不断提升水平。很多微软团队的成功都来自于此。让人犯昏的是高层的项目经理与团队层的Scrum工程师仍存在严重隔阂。
很多高层及中层的项目经理认为Scrum是混乱的、随意的、危险的并毫无意义的，会使大家对计划失去信心；而很多Scrum迷认为项目计划是种浪费，会引起混乱，毫无价值，只是让不切实际的高层管理者设计个看似完美的计划表以自我满足。结果怎样？他们都错了，而认为他人无知就是愚昧者自作聪明，那么就是，双方都无知。
Scrum是按计划加载的，比起我在微软所见到的其他项目管理方法，它更高效并精确地跟踪数据（除了TSP，在少数团队中使用）。同样，高层项目计划对于项目规模的成功把控、协同合作及萌生宏观上的创造力是很重要的。如果你着眼于小处，Scrum就足够。如果你只想比你的竞争对手提供更低质量且不用太顾及客户价值的产品，或者只想在你局部的范围内微观管理所有工程状态，那么只要项目计划足够就可以。如果你着眼全局并想高效地提供高质量且丰富的客户价值，那你就需要在高级项目计划与Scrum间找到平衡。
作者注：功能小组一个有趣的Scrum变体。这种组织方式最先源自于Microsoft Office的项目开发。就像Scrum团队，功能小组是规则多变并能自我管理的团队，在一个很短的周期内他们周而复始地进行一系列小环节（功能模块）工作。虽然他们可能也会开些常务性会议，但他们并不仅仅是照搬Scrum模式——固定周期迅步法及频繁的重复规划。不过，功能小组已经成为了很多微软团队工作的一种主要方式，它们能高效地执行一项简洁的软件工程过程。
我尊重你否定我的权力
为什么在高层的项目经理及Scrum迷之间会存在如此隔阂呢？几年前，在该章对于管理失当的介绍中我已有所提及。
项目管理在不同的规模、不同的抽象概念中有不同的表现形式。有下面几种：团队或功能层次（大概10人左右）、项目层次（50~5 000人为一个特定版本工作）以及产品层次（由执行官领导的多个版本开发）。敏捷开发在团队层次很适用，传统方法在项目层次中很适用，而长期的战略性计划方法在产品层次很适用。然而，人们很少同时在不同层次工作，实际上，每个人总是会分年段地在这些层次间工作。所以人们常常认为某一层次的高效方法应该应用到其他层次上，悲剧就这样产生了。准则就是：小型、紧凑的团队跟大型松散的组织运作方式不同，相应地应选择适合你的方法。
你不能期望注重过程管理的传统方法很好地应用在小团队上，就像你不能期望动态的应急计划应用于大型机构。如要在其间搭起桥梁，你必须明白各方的目标及它们相互间的需求是什么。让我们来摆平它们。
计划什么都不是，也什么都是
高层次项目计划（愿景、架构、时间表以及风险管理）就是：
设定一个共同不变的愿景使大型的机构有序运作。没有一个共同不变的愿景，你要保持长期的成功只能是碰运气。是的，跟客户进行反复沟通是会带来可观的价值，且可能跟企业长期价值方向一致，但主要还是要依赖于共同不变的愿景。
做好团队间对接使愿景具有可行性。一个共同不变的愿景使企业机构间拥有一个共同的目标。当然，你不用地图或高速公路就可以从西雅图开车至纽约——但是那样会花费你很长的时间才到达那儿。
实现对合作伙伴的承诺。大型、成熟且成功的公司需要有一个与合作伙伴的良好关系才能使承诺得以实现。如果你希望愿景能带来现实价值，你就需要伙伴公司的合作。这就意味着承诺是双方相互的，金钱就存在于你与他之间。
发现并解决可能会破坏承诺的问题。很多基于伙伴关系的大型工程项目包括了互相依赖性、风险性及双方的合作。很多项目可能夭折或最终失败，甚至于已经实施行将大功告成的项目。你必须为成功或失败做好准备，在项目受挫前发现及解决问题确实是项艰难的工作。
项目规划者、构建者以及中间管理者需要Scrum团队来有效协调以适应共同的愿景，遵守他们之间的协定（或者相应地调整协定），完成他们间的承诺（或者相应地更改约定），并且在问题发生时把它摆上桌面并解决它。
我会照顾好自己
好的，我们已经有了共同的愿景、相互间的协定、承诺以及一个风险控制计划。现在我们只需要照单行事，是不是？你是来自哪个空间的？在我的世界，变化无时无刻不在，工作进展很可能就在其中一步戛然而止。
在上层的抽象概念中，计划可能达成一致并让人感觉良好，但是在底层，还有很多细节需要处理。当着手于细节的时候差异性及复杂性就来了，项目规划者、架构师及中间管理者就会不断通过召开进展情况及工程设计会议，再不断增加项目经费，发现瓶颈问题等方法从微观层面应对变化，从而在不断的摸索中艰难前行。或者他们就信任工程师让他们自己从细节处解决问题。
敏捷方法如Scrum能快速高效调整以适应突发细节并改变状态。这种流程及项目经费的精减有利于工程进展及客户关注的满足工程进展需要的解决方法得以实现。这并不是说Scrum团队不制订宏观计划——只是说他们是禀着一种不断努力的态度，步步为营，以实现共同愿景。
Scrum团队需要项目计划者设定一个共同愿景、相互间的协定以及指定必要的资源，然后就放手让他们干。愿景一旦达成，多方协定得以遵守，资源到位，项目计划者就放宽心了。自我管理的Scrum团队可以快速解决大量问题，项目计划者、中间管理者必须学习、接受它，还需要及时包容。
作者注：很多项目规划者及中层管理者对于要信任一个自我管理的团队感到很担心，有三种办法消除这些恐惧：
1）持续跟踪数据——快速浏览一下与估计值相当的数据负载，浏览一下优先级别、工作的进展、遇到的问题、工作的效率及已完成的工作。
2）每星期或每天召开一次Scrum会议——只要15分钟，与所有的Scrum团队主管讨论遇到的问题及预审进展。
3）为Scrum团队的决定设置底线，当某项决定影响到两个以上Scrum团队的时候，就必须由项目团队或架构团队来审核。
太高兴了
项目计划者与Scrum工程师应该互相包容（精诚团结）。他们完成各自的任务。项目计划者为Scrum团队设立了方向，Scrum团队使项目计划者只用专心关注于整体规划，而他们以一种快速的、灵活的、反复的过程提供了高质量的、可用性的、面向客户的具体信息。
项目计划者与Scrum工程师在一个大型的具有宏观视野的项目中扮演着重要角色，担心或拒绝对方的工作是不可原谅的。我们对双方相互间的角色及目标理解得越透彻，那么我们就越能为客户带来令人愉悦的新颖体验。
作者注：当你没有权衡好项目规划与自我管理团队之间的关系时，会出现什么情况呢？明摆着的是，苹果及谷歌提供了很有趣的例子。
苹果自顶层开始以项目规划为导向，然后在基层进行微观管理。其结果是他们的产品很有创意，但限制了他们商业的纵深度。
谷歌则全是细碎化的自我管理团队，其结果是快速地提供了类目繁多、品种多样的服务，但这些服务之间彼此脱节，缺乏一致的能凌驾于公司常态之上的战略图景。
虽然这样说有些言过其实，不过还是很有启发性。当然，苹果与谷歌已相当成功，即使他们有这样的缺陷。在不变的项目规划及高效的自我管理团队之间取得平衡，使得微软对于他们更具竞争力。
