我傾向于認為亞當·斯密對勞動分工論述的假設是：需求穩(wěn)定，簡單生產。對于IT領域來講，這些假設還成立么？

擰螺絲的卓別林
不難發(fā)現(xiàn)，對分工以及個體效率的迷信已經深刻的影響著IT領域。分工的端倪在招聘時已經顯現(xiàn)，即便對于差異不大的畢業(yè)生們，雇主也會根據(jù)其極有限的技能，用不同的標準進行測試(Java， .Net， PHP等)，并在入職后將其冠以前端工程師，后端工程師，測試工程師，支持工程師等不同的頭銜，甚至可能在其可見的職業(yè)生涯中專門負責某個文件的維護。

整體效率的優(yōu)化要求IT團隊消除技能壁壘，培養(yǎng)多面手，根據(jù)計劃的的變動，彈性地調整任務，達到各角色和流程之間的平衡。對于IT企業(yè)來說，變化從招聘時必須開始。找到擁有學習熱情、學習能力、學習習慣的人變成了當務之急，員工是否掌握了某種算法、語言或者工具應當從準入條件降格為對于其學習能力和熱情的一種（不是一種）證明。

整體效率的優(yōu)化要求員工必須持續(xù)學習、成長，興趣無疑是成長的催化劑，然而喪失意義的工作卻在不斷扼殺人的興趣。丹?艾瑞里在怪誕行為學里著述到：

勞動者與他自己的生產活動、勞動目標以及生產過程相分離。這使工作成為非自發(fā)性的活動，因此勞動者無法對勞動產生認同或者領略到勞動的意義，而缺少了意義，專業(yè)人員可能覺得自己好像電影《摩登時代》中查理·卓別林扮演的角色，一切都由工廠的齒輪控制，他們根本不會有全心全意工作的愿望 。

如果員工成長是必須的，那么，幫助員工認識到工作的全貌也是必須的。角色輪換是一個很好的解決方案。在項目內部通過角色互換，不限角色的結對工作，加強不同角色，不同模塊間的知識傳遞，打破技術壁壘，幫助員工從不同視角理解項目，鍛煉技能，進而增加團隊均衡生產的能力。

在我看來，進行角色輪換的大阻礙在于編程能力的普遍缺乏，大多數(shù)的測試、需求分析工作（鑒于大多數(shù)團隊所處的地位，需求分析師實在言過其實，更精確的名字是需求整理師），迭代管理，簡單的客戶交流，學習曲線都非常低，任何成員都可以在師傅的帶領下迅速掌握工作要點，然而編寫程序卻是個例外，即便對于基礎良好的新人，在經驗豐富的導師帶領下，也需要2個月左右才可能寫出比較體面的單元測試、較為面向對象的程序。在分工的體制下，用別的角色輪換開發(fā)人員幾乎是個死局。

非常奇怪，IT領域如此的看重抽象能力和邏輯分析能力，可為佐證的是層出不窮的建模語言，模式，領域模型，架構。然而能訓練抽象能力和分析能力的一項活動，卻僅僅有選擇性的開展，這是不是意味著我們認為IT項目可以在大多數(shù)人無法（也沒有能力）達成共識的情況下順利展開并成功交付呢？在我看來，編寫程序不僅僅是一項技能，一種思考方式，還承擔著構造IT團隊成員間共同經驗區(qū)，提高交流效率的目的。

一個值得從其它行業(yè)借鑒的經驗是首先展開基礎素質培養(yǎng)，再進入領域培養(yǎng)專業(yè)素養(yǎng)，換言之，避免過早的分工，所有新人從編程開始職業(yè)生涯，在公司的體制層面促成每個新人都能經歷力所能及的所有角色。在具有了一定的基本素質后，在員工對工作內容和自身興趣有了充分的了解后，根據(jù)個人意愿進入領域發(fā)展專業(yè)技能，興趣將成為員工成長的內在動力，而良好的基本素質將使員工有能力在專業(yè)崗位上施展自己的想法。

同時公司應當鼓勵員工跨界工作，《應用Selenium和Ruby進行面向領域的Web測試》的作者是擁有卓越能力的開發(fā)人員，他曾經進行了相當長時間的測試工作，在其它人抱怨自動化界面測試難于維護時，他的抽象能力、分析能力已經幫他提煉出測試模式，識別出缺陷，找到了優(yōu)雅高效的工作方式并誕生了這篇的文章。

丹·艾瑞所言于我心有戚戚焉。

知行合一
在過去9個月間我們在團隊中進行了建設全功能團隊的初步實踐，在分享具體實踐前，我希望下面的總結性數(shù)據(jù)能幫助你獲得一些背景知識。

項目處理的是期貨交易領域，使用的技術棧是C#， ASP.NET MVC。團隊主要由八名開發(fā)人員以及兩名測試人員組成（其中一名測試人員在項目中期加入），其中4位是畢業(yè)生，3位具備工作經驗，但剛剛加入Thoughtworks，只有一位開發(fā)人員具備.Net開發(fā)經驗。

下面是全部35周的燃盡圖，黑色實線代表項目的范圍，綠色實線代表開發(fā)完成的速度，藍色實線代表測試完成的速度，每周為一個迭代。