|
如果说，上面谈到的这两点还应该算是人类各种分工制度共有的“必要的恶”，软件开发中的分工还有一种特有的弊端：细致的分工与“重量级方法论”之间有很强的亲和性，倾向于导致更高的开发成本和开发风险。service.mypm.net 对于产品设计和系统构架设计来说，将决策权集中在产品经理和系统架构师手中，意味着一种集权式的专制体制。这也要假设，这些负责人对产品或系统构架具备了充分的、无遗漏的了解。整个系统从他们头脑中的理念萌芽演化，再通过文档等介质，最终被实现为软件产品。如果产品经理确实能够从一开始就清晰、完整地把握客户需求，选定的开发平台、技术对系统架构师也不存在任何难点，那么类似的集权制可能是合理而且高效的。但软件开发往往充满革新和变数，客户需求一日千变，开发技术也日新月异，大量不确定因素的引入，使集权体制变得非常可疑。如果需求和设计无法自顶向下、一步到位的给出，而是需要多次反复、迭代才能渐趋完善，那么一个多级的、细分工的开发体制与扁平的、粗分工的体制相比，就需要更大的初期代价（initial investment），更多的文档和交流，并缺乏后者灵活、自适应的应变能力。pmp.mypm.net blog.mypm.net 极限编程（XP）方法论，就在很大程度上抵制了上面提到的分工体制。talent.mypm.net XP开发过程中用“素材（user stories）”取代了需求规格设计书（SRS）。一组由“客户”粗略书写的素材，直接由程序员加以评估和实现，并根据现场客户（on-site customer）意见修改。因此上面所说的产品经理角色，就被客户和程序员之间的合作完全取代了：无须产品经理给出细化、明晰的需求，只要程序员体会素材中的意思，做出实现，再通过客户反馈逐次迭代，就能获得不错的系统。pmp.mypm.net 而系统架构师在XP方法论中也没有容身之处。系统构架不再是充分设计的产物，而是一个不断演进、不断完善过程的结果。具体的决策权留给了程序员自身，团队中的顶尖程序员不再充当系统架构师，而是担任“教练（coach）”的角色，启发新手自己找到合适的构架，并在确实困难的时候扮演救火者。bbs.mypm.net 事实上，传统的“按照蓝图设计建筑物”的隐喻在XP方法论中失去了价值。对比一下《人月神话》和《XP Explained》中“architect”一词的出现频率（在后者中我只发现了两次，而且用的都是否定意义），我们就可以发现这种态度上的变化。取而代之的是某种自适应的、渐进式的开发过程。因此，很难说XP方法论中包含完整意义上的“产品设计”或“系统构架设计”工作。service.mypm.net 相对而言，项目控制工作仍然在XP方法论中具有重要意义。只是这里更强调，程序员的身上的责任是他/她主动接受而来的，而不是强加的（accepted responsibility, not given），因此对于任务的分配、项目进度的估算都由程序员首先决策，而不是由管理者直接指派。项目管理者被称为“跟踪员（tracker）”。他/她负责监督项目进度，并通过各种衡量尺度，及时地将情况反映给开发者自身（比如提示目前的开发进度是提前还是落后于时间表）。这样的职责被形象地比喻为“镜子（mirror）”。项目管理者联盟 3。从表面上看，XP方法论似乎抵制了传统的分工体制。但是，仔细考察就能发现，这里仍保留着对“商业”、“技术”和“管理”三种职责的划分，而“客户”、“教练/顾问”和“跟踪员”身上也还存有一些我们熟悉的角色的痕迹。只不过，决策权被最大限度地交给了实际开发人员。这是一种“轻装上阵（travel light）”式的开发体制。受益于扁平的权力结构，开发者能够以最小的初期代价开始开发，并及时反馈客户意见和变更需求。转自项目管理者联盟 在此我乐意给XP方法论和传统分工体制的区别做一个浅显的哲学解释。柏拉图以来的一派哲学认为理念/本质（eidos）先于、而且高于实际事物。以建筑为例，抽象、初始的蓝图中蕴含了建筑物的整个存在。本质主义倾向于认为本质是静止而奥妙的，只能为少数人所领会，而把握了本质，也就穷尽了事物的一切方面和一切发展可能。由此，传统的集权式分工体制就对应于这种本质主义态度。转自项目管理者联盟 另一方面，不少人也认为，很多事物无本质可言，事物并非在初始、根源中就蕴含了其后的所有变数，而是一直处于偶然、不可预知的演进之中。如果一个事物渐趋完善，那也不是因为它达到了自身的本质，而是在反复尝试-修改之中，在对于外界变化的不断自适应调整之中逐步发展的结果。显然，XP方法论更接近于这种非本质主义的渐进论态度。项目管理者联盟 不同哲学态度之间的争论，似乎已经有两千年以上的历史，至今仍是教授们热衷的论文题目。在实践中，人们可能在某些场景下偏爱本质论，在其他地方则倒向渐进论。无论如何，二者都已成为我们重要的思想资源。而不同方法论之间的优劣看似比这更为显而易见。通常的论调是，随着新方法论的问世，旧方法论也失去了原来的价值。软件行业在方法论上的逐新倾向，似乎与时尚女性对衣着的关注属于同一个病理学范畴。项目管理者联盟 而以我个人所见，不同方法论的有效性，只能根据具体情形判断。XP方法论对变化的拥抱和对轻装上阵的强调固然可喜，但是，在不少场合，它的分工原则也是可疑、甚至成问题的。比如说，XP开发过程中“客户”扮演着非常重要的角色。而一旦缺乏现场客户的支持，或是客户不具备完成“素材”的能力，自适应的需求获取就很难奏效。再如，与集中决策相比，分散决策虽然能够鼓舞士气，但产品的概念完整性和技术构架的一致性都会受到威胁。一个专职的产品经理肯定会比客户、程序员的合作更能有效地设计出简洁、明确的人机交互模式。转自项目管理者联盟 也许，在需求不确定的场合，或是当团队中没有哪个开发者在产品设计/系统构架设计方面有足够经验时，采用XP模式开发是规避风险的最优选择。在变数较大的情形下，如果沿用传统的重量级方法论，势必大量的前期文档、设计工作在多次迭代中被抛弃，从而导致高昂的投入。但是，当业务需求清晰，团队较为成熟时，传统的分工体制不失为稳健、高效的工作模式。另外，不同的开发领域也会对分工产生不同形式的要求。游戏开发的团队构成肯定与嵌入式开发不同，这二者又都与企业应用开发相差很远。如果根据某个先验的“软件”定义，而推导出所有这些领域都共通的方法论原则，那只能是上面提到的“本质主义”幽灵对我们心智的一次最新侵袭。项目管理者联盟 就我个人熟悉的企业应用领域而言，一个优秀的领域专家/产品经理能保证较高的成功率。另外，快速原型法（而不是简单的user stories）、迭代式的发布计划（而不是一步到位）、成熟的技术框架（而不是每次都从头设计）和温和的项目管理（而不是盲目施加压力）能起到正面作用。如果允许比喻的话（就像我们在其他拙于描述的场合做的那样），我感到与写诗、谈恋爱或练气功相比，这个领域的软件开发更接近于写长篇小说、设计建筑或拍电影的过程。项目管理者联盟 这是我的意见。training.mypm.net 项目管理者联盟
|
