在采用繁捷开发的组织当中，一个经常让人困惑的问题是“我们到底需要通才(generalist)还是专才(specialist)？”
传统的软件开发组织模式中（尤其是大型软件产品）通常按照产品的部件来组织的(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是一样的。)
冬天的白桦林 我的博客已搬家：http://terryyin.blogbus.com 这里不会再更新了 
懂太多的人花心，当不了好工人。至于管理者最好是除了管理什么都不懂。
先捧一個，老棍兒還是很適合寫文章的嘛！大師們在無數的項目實踐之上驗證了我的想法（再自捧一個）：真正的程序員不僅關注新技術，更以滿足客戶需求為快樂。對于Bas的想法我很理解而且一直就這么做，不管什么東西，等要用了在學。這樣學習才有目的。我在527的時候（整的好像兵工廠似的），有句舍內名言：這東西我不會也不想學，因為我覺得沒用。我比Bas的想法更極端，我認為事先學習和用到了再學是不一樣的，用到了再學效果更好。但是什么時候是“用到了”？這就因人而異了，全靠自己是否意識到了要用。熟練的人會提前意識到，就會開始學習，而在旁人眼里可能就是事先學習。用到了再學時間來不及？這是可以訓練的。我覺得我是在數年的短平快項目中練出來了，或者是逼出來的。學習無非就是看書查資料。先找到相關的一大堆書，其中90%只看目錄，剩下的也沒有從頭看到尾，而是挑著讀。我從頭讀到尾的估計也就是Larman大師的那本吧（有機會跟大師說說，讓他虛榮虛榮）。至于查資料，就一句話：沒有google我會死。總之就是快一個字，快速閱讀，快速領悟。然后在用的過程中不斷學習，當你覺得必要的時候。這也是iterative。不過還是跟性格，習慣有關，有人就喜歡正正經經讀書甚至還要做個筆記啥的才行。作為管理者也不能逼人太甚，要因材下套。我這種做法很容易導致一知半解，要是再沒有點兒自知之明的話會誤事。我覺得我還是有自知之明的，你看我都這么說了嘛。所以我只留言不寫文章，因為誤導了讀者我負不起責。
如此一来又谈到人的问题，如果全靠要用之时才学习，那么是否会有“书到用时方知少”的感觉，是否company愿意支付这个费用，是否customer能否等待你的学习曲线，是否我们的员工有足够的学习新技能的能力呢？从市场的角度来看，你暂时不具备而又很快需要的技能很可能在外部市场上已经存在，那么相比给自己员工学习的机会成本和从外部市场直接雇佣的开销相比，我看，绝大部分的管理人员都会选择后者吧，毕竟那才是成本效益比更高的选择。而这样的话，又取决于企业文化，如果企业文化倾向于培养自己的人员，那么另外一家信奉取之即用的公司也许就能更快地适应市场需求推出客户立刻想要的功能，那么哪种企业更容易生存呢？
这里边有两个变量：X影响改变员工技能成本的因素、Y解决问题的手段。很多因素影响改变员工技能的成本：*员工原有的基础技能水平*采用的平台*工作的领域*原有代码的质量*也许还有Yi Xu兄提的企业文化当客户价值驱动的员工能力需求发生变化时可采取的解决方案也不止一两种：1. 不变化2. 事先计划3. 按需转换4. 重新招人如果X和Y一起变化，这问题是永远没答案的。所以只能说在一定的X的情况下，什么样的Y是最好的选择。除非你能证明Y和X没有相关性。
管理这个话题太严重了，需要很多商业细菌。
“商业细菌”是什么？
有我认识的通才么？如果没有，那么对我来说还不算一个问题