團隊的開發(fā)人員撇開需求沉浸在想象中的“完美”程序中；測試人員迷茫的點擊著按鈕試圖搞明白這到底是個什么功能；設計師造出了沒有盡頭的樓梯，更糟的是，客戶愛上了這個設計；團隊領導四處救火，力有不逮。種種跡象表明，我們得打破分工帶來的壁壘，建設全功能團隊——大多數人能完成大多數種類工作的團隊。
    在一次閑聊中，女友的母親說起實習大夫必須輪崗一年才會進行分科學習，我質疑道：“對于致力于心臟病治療的醫(yī)生來說，他豈不是在不相干的學習上浪費了一年時間么？”，她母親笑著說：“不這么作，你怎么確信病人的確患有心臟病呢？”。不知道為什么，我眼前突然浮現出這樣的場景?測試人員在怯生生的詢問：“這是一個缺陷么（而不是操作系統(tǒng)/瀏覽器的限制）？”。

     亞當·斯密于1973年在描述大頭針工廠的專業(yè)化生產時提出了社會分工的好處：提高熟練程度、減少任務切換時的開銷、便于機器的應用。我們似乎可以非常自然得推導出重復設計、重復編碼、重復測試可以增加相應崗位員工技術熟練度，提升效率，并由此提升企業(yè)的盈利能力。

      然而市場的不斷變化讓重復生產的美夢不在，切換任務變得越來越頻繁。IT公司不是大頭針工廠，知識工作者畢竟有別與體力勞動者，在勞動主體發(fā)生變化的過程中有兩件事情的差異被放大了：一是局部優(yōu)化與整體優(yōu)化的差異，二是正確的做事與做作正確的事情的差異。

  有一道數學題，假設每個開發(fā)人員每天可以完成一個功能，測試人員每天可以測試2個功能，團隊由3名開發(fā)人員和1名測試人員組成，那么一周內通過測試的功能最多為多少個？

  大多數人的第一反應是5（天）x2（功能/天）=10功能，下面的表格會告訴你，由于負載不均衡，測試人員在周一沒有功能可測，團隊其實無法在一周內交付10個功能。

表一）

 那么我們改變一下條件，假設團隊中有4個開發(fā)人員，并且開發(fā)人員可以參與測試，結果會怎樣呢？

表二）

我們最終能夠交付13點，產量提高了60%， 如果我們只留下三名全能人員：

表三）

居然比3個開發(fā)人員和1個測試的人員組合還多交付兩個功能！

 我們當然有理由質疑第二題的假設：“開發(fā)人員可以勝任測試人員的職位”。又或者繼續(xù)討論迭代二的數據變化。我對此的的回答是：

 第一，以我的觀察來看開發(fā)人員之所以不進行測試工作，不是能力不允許，而是主觀上認為測試工作是簡單、重復而枯燥的，不愿意作。客觀上開發(fā)人員們比較貴也更難于培養(yǎng)，組織層面不允許這樣的“浪費”。

  對測試工作的偏見客觀上促成了大量不具備技術能力的人選擇測試工程師作為職業(yè)，而技能不足則一步導致了測試工作傾向于簡單重復。測試人員在很大程度上無法判斷什么是正確的事情（作正確的事），從而更傾向于熟練的按照腳本進行操作（正確的做事）。

  第二，我的關注點不在交付8點還是10點，我希望這個例子能夠引發(fā)大家對于均衡生產的思考。

  軟件的需求和實現可以被細化，但它畢竟不是大頭針，需求和實現間往往呈現出關聯與依賴，換言之，局部效率的增加無法直接轉換為整體效率的增加。而整體效率的優(yōu)化往往依賴于均衡生產（參考表三），即消除生產的波峰(過度生產)和波谷（生產不足），避免任務時松時緊，松時生產力浪費（周一時專職測試人員），緊時加班加點，粗制濫造。

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

 擰螺絲的卓別林
    不難發(fā)現，對分工以及個體效率的迷信已經深刻