|
2
也许我已经论证了上述三种角色分工的必要性。笼统地说，正如其他人类制度一样，分工自身也同时具有益处和代价。如果允许一个空泛的概括，分工的优点至少有：
1) 集中特定的知识、技能——想想自己左右手、左右脑的分工，我们也许就可以理解这对提高生产率的重要性；
2) 职责明确，不同职责的人为自己做出的决定负责；
3) 增进交流：各个角色之间为确保顺畅的协作，必须要求高质量的交流，这也就能使很多原本不言而喻的事情书面化、明晰化。
但分工也有其自身的弊病:
首先，不少人天性追求完满，要让他们接受分工，只完成整个工作的一个枝节部分，可能是非常痛苦的事。我记得自己刚刚参加工作后参与开发的一个系统，直到开发接近尾声，项目经理才在一次每周例会上说：“大家开发了这么久，对整个系统的用途可能还不很清楚，今天我们简单谈谈”——这时我才知道自己参与的是整个店铺系统的销售子系统的订货部分的一个底层数据模块。
另外，分工往往导致等级制度和不同角色间的疏离。既然分工的要义是把高要求的工作集中在少数人手中，在少数和大多数之间，不同的工种之间，必然会导致等级差异和隔阂。《人月神话》中也谈到，在区分了产品设计和技术实现之后，单纯的实现者会感到仅仅听命于人，常常缺乏独自开发时的“成就感”。这也是朴素的、混沌未开的开发过程一旦引入分工，就必然产生的异化。
如果说，上面谈到的这两点还应该算是人类各种分工制度共有的“必要的恶”，软件开发中的分工还有一种特有的弊端：细致的分工与“重量级方法论”之间有很强的亲和性，倾向于导致更高的开发成本和开发风险。
对于产品设计和系统构架设计来说，将决策权集中在产品经理和系统架构师手中，意味着一种集权式的专制体制。这也要假设，这些负责人对产品或系统构架具备了充分的、无遗漏的了解。整个系统从他们头脑中的理念萌芽演化，再通过文档等介质，最终被实现为软件产品。如果产品经理确实能够从一开始就清晰、完整地把握客户需求，选定的开发平台、技术对系统架构师也不存在任何难点，那么类似的集权制可能是合理而且高效的。但软件开发往往充满革新和变数，客户需求一日千变，开发技术也日新月异，大量不确定因素的引入，使集权体制变得非常可疑。如果需求和设计无法自顶向下、一步到位的给出，而是需要多次反复、迭代才能渐趋完善，那么一个多级的、细分工的开发体制与扁平的、粗分工的体制相比，就需要更大的初期代价（Initial Investment），更多的文档和交流，并缺乏后者灵活、自适应的应变能力。
极限编程（XP）方法论，就在很大程度上抵制了上面提到的分工体制。
XP开发过程中用“素材（User Stories）”取代了需求规格设计书（SRS）。一组由“客户”粗略书写的素材，直接由程序员加以评估和实现，并根据现场客户（On-site Customer）意见修改。因此上面所说的产品经理角色，就被客户和程序员之间的合作完全取代了：无须产品经理给出细化、明晰的需求，只要程序员体会素材中的意思，做出实现，再通过客户反馈逐次迭代，就能获得不错的系统。
而系统架构师在XP方法论中也没有容身之处。系统构架不再是充分设计的产物，而是一个不断演进、不断完善过程的结果。具体的决策权留给了程序员自身，团队中的顶尖程序员不再充当系统架构师，而是担任“教练（Coach）”的角色，启发新手自己找到合适的构架，并在确实困难的时候扮演救火者。
事实上，传统的“按照蓝图设计建筑物”的隐喻在XP方法论中失去了价值。对比一下《人月神话》和《XP Explained》中“Architect”一词的出现频率（在后者中我只发现了两次，而且用的都是否定意义），我们就可以发现这种态度上的变化。取而代之的是某种自适应的、渐进式的开发过程。因此，很难说XP方法论中包含完整意义上的“产品设计”或“系统构架设计”工作。
相对而言，项目控制工作仍然在XP方法论中具有重要意义。只是这里更强调，程序员身上的责任是他/她主动接受而来的，而不是强加的（Accepted Responsibility, not Given），因此对于任务的分配、项目进度的估算都由程序员首先决策，而不是由管理者直接指派。项目管理者被称为“跟踪员（Tracker）”。他/她负责监督项目进度，并通过各种衡量尺度，及时地将情况反映给开发者自身（比如提示目前的开发进度是提前还是落后于时间表）。这样的职责被形象地比喻为“镜子（Mirror）”。
<<上一页
1
2
3
4
下一页>>
| 
