传统的软件开发组织模式中（尤其是大型软件产品）通常按照产品的部件来组织的(component team)。Team中所有的人都是该部件的专才。这种组织方式的核心问题是每个team都是围绕组件工作，而不是真正的围绕customer value。从而产生很多问题，例如过份的设计，专门的测试部门，无法解开的依赖关系，资源的浪费等等。
在繁捷开发中主张功能团队（feature team）。Team是多功能的，他们围绕着完整的customer feature做所有需要的工作，不论完成这个feature需要用到哪些component，哪些技能（需求分析、设计、编码、测试）。并且到底做什么feature是由客户的优先级决定的，而不是team本身的能力范围。这样就可以实现迭代开发。很多人，包括很多宣扬繁捷开发的人，会简单的把这种情况描述为“所有的人能做所有的事”。也就是说把所有的人都变成generalist。
然而事实往往远非这样的简单。
软件产品是复杂的（complex），这种复杂性存在于软件各个组件的细节当中，任何对这种复杂的不敬和无知都早晚有一天会反扑回来，使得软件变得混乱（chaotic）（软件的复杂理论）。我的经验是，在一个大型的软件产品当中寥寥几个胆敢声称“所有的人能做所有的事”的人，要么是天才，要么是受了“达克效应”的影响。
并且，在Capers Jones的研究中发现，“专才”的表现远远超越了“通才”。
看来，又是一个需要中庸之道出马的问题。“专才”或是“通才”也许都不是解决问题的好方法，需要一个平衡点。
在Bas Vodde和Craig Larman合著的新书《Scaling Lean & Agile Development》中有专门关于组建feature team的一章，有得下载。其中给出了很多实用的建议。虽然，我认为Bas本身已经有点落入了“所有的人能做所有的事”的魔道，但也不过是离“中庸”左了一点。
书中提到“generalizing specialist”，即承认specialist的重要性，又鼓励扩展范围，同时关注customer value，尽量提高人员的利用率。并且提出在大型的项目中，按照相近的需求能力范围，以requirement area的方式来进行较高层次的组织。这样，尽量的发挥feature team的能力，减少人力空置的浪费，又减少了不断切换知识的浪费。
从管理的角度来讲，这也有很重要的指导意义。要为新人创造成为某一方面specialist的机会，鼓励specialist扩展技能。同时又要引导员工关注customer value。并不是所有的技能都会永远是创造客户价值的热点，而人的时间和精力是有限的。员工往往希望成为某方面的specialist从而获得职业安全感，这并无可厚非，也有积极一面。然而为了创造更多的客户价值往往需要进行取舍。最终还是要把对员工作的要求提高到“craftsman”的水平上来。
这样就又带来了一个新的管理问题：“要不要事先计划人员的能力分布呢？”如果不计划，就会出现对热点需求缺少准备的问题；如果计划了，就违反了Lean Thinking中“减小库存”的要求（把员工事先学好的能力想像成库存）。关于这个问题，Craig Larman认为，这种事先的计划还是必要的，这是一种必要的付出。然而Bas Vodde却对此有很极端的看法，他认为事先学习和用到了再学是一样的。对于Bas的想法很难理解，下次遇到他要再次好好请教一下，然后来专门来写写这个主题。
最后，不一定恰当的引用Craig Larman对“关注客户价值”的一个比喻：
“Watch the baton, not the runners.”
(解释一下：baton:接力棒，runner：接力运动员。在接力比赛中baton就是我们要deliver的value，提高每个runner的利用率对最后的结果并没什么帮助，每个人只跑一百和每个人都跑400是一样的。)
博文
没有评论:
发表评论