“怎樣保證每個團隊成員高效地工作，使組織產(chǎn)生大的效益”是每一個經(jīng)理大的挑戰(zhàn)。通常經(jīng)理們會采取以下兩種手段:

    告訴團隊成員該做什么（Command and Control）
    團隊成員根據(jù)設(shè)定好的原則，自己決定下一步該做什么（Self-organizing）

在很多軟件項目開發(fā)團隊中，項目經(jīng)理和部門經(jīng)理負責(zé)項目管理和控制。為了控制軟件開發(fā)的進度，效率和風(fēng)險，經(jīng)理們往往要求團隊成員提交和更新各種各樣的表格，例如日報、周報、代碼量報告、缺陷報告等等，通過各種計劃、報告、表格來管理團隊。但是這種方法有很多固有的弊病。

    首先，數(shù)據(jù)不準(zhǔn)確。例如在日報中，一般要求提交任務(wù)完成百分比。這個數(shù)字很多時候是團隊成員拍腦袋想出來的。任務(wù)完成90%后，剩下的10%需要更多的時間完成的情況在很多團隊中也屢見不鮮。
    其次，數(shù)據(jù)不及時。除了項目文件，經(jīng)理們沒有辦法了解項目的具體運行狀況，進度，只有通過日報或者周報。任務(wù)分配也不及時，團隊內(nèi)部工作量也不均衡。
    再次，衡量標(biāo)準(zhǔn)不恰當(dāng)。
        用代碼量作為衡量Dev生產(chǎn)率的標(biāo)準(zhǔn)本來是不恰當(dāng)?shù)�。這使團隊成員單純追求代碼量而不停的復(fù)制拷貝，不關(guān)心系統(tǒng)架構(gòu)所要求的代碼簡潔，架構(gòu)清晰。
        用缺陷作為衡量Dev工作效率的標(biāo)準(zhǔn)也是不恰當(dāng)?shù)�。軟件開發(fā)并不僅僅是編寫代碼，更重要的是溝通問題。絕大多數(shù)缺陷其實是由需求不明確或者是溝通的不充分和不準(zhǔn)確導(dǎo)致的。用缺陷率作為標(biāo)準(zhǔn)會導(dǎo)致團員成員之間的矛盾，互相指責(zé)，推卸責(zé)任。
    再次，信息不透明，不直觀。報告往往不是團隊成員直接可見的，需要登錄到網(wǎng)站，或者訪問Source Control或者共享文件夾的某個文件（往往是有權(quán)限控制的）。這些信息不會直接展示給大家，他們總是需要一路點擊過去。
    后，過多的無效工作。團隊成員要花費很多時間和精力在更新及維護報告上面，但這些工作并沒有業(yè)務(wù)價值。

在處理復(fù)雜像軟件開發(fā)這類復(fù)雜問題的時候，使用Command&Control方式效率十分低下。很多情況下即使是有經(jīng)驗的經(jīng)理，由于他不在現(xiàn)場，不掌握全部具體情況，也很難做出準(zhǔn)確的判斷，有效地指揮團隊成員工作。而第二種管理方式（Self-organizing）在解決復(fù)雜問題時要有效得多。在復(fù)雜的環(huán)境中，可以通過訓(xùn)練及培訓(xùn)使團隊成員掌握工作的基本原則，把責(zé)任下放給第一線的工作人員，由他們根據(jù)不斷變化的實際情況，不斷地調(diào) 整，完成團隊任務(wù)。軍隊也是類似，在戰(zhàn)斗過程中，作為戰(zhàn)斗指揮的上級極少直接指揮每個士兵戰(zhàn)斗。人員和班組是自我管理，根據(jù)現(xiàn)實情況和戰(zhàn)略目標(biāo)動態(tài)調(diào)整 戰(zhàn)術(shù)。這也是絕大多數(shù)的敏捷方法論都在強調(diào)團隊的自我管理的原因。

怎樣在軟件開發(fā)中實現(xiàn)團隊的自我管理？怎樣讓團隊找到自身的問題？怎樣實時地反映項目的進度？團隊成員怎樣知道每天應(yīng)該做什么？為了解決這些問題，我們的經(jīng)驗是日常開發(fā)中建立一個基于拉動式生產(chǎn)方式的信息化工作空間。

    首先，我們的日常開發(fā)以Scrum為基本框架，并特別強調(diào)團隊的自我管理。具體做法是：
        短迭代。每兩個星期一個Sprint。每個Sprint給幾個客戶做演示。產(chǎn)品負責(zé)人會根據(jù)演示的反饋以及原先的發(fā)布計劃重新整理Product Backlog，并由此產(chǎn)生下一個Sprint的計劃。因此團隊的每個Sprint的任務(wù)是由業(yè)務(wù)驅(qū)動的。
        用戶故事。產(chǎn)品負責(zé)人會在計劃會議開始之前整理成用戶故事。產(chǎn)品負責(zé)人在整理用戶故事過程中會注意收集真正客戶想要的東西，理解客 戶的意愿，而不是業(yè)務(wù)以及技術(shù)上怎樣實現(xiàn)。在計劃會議會議中，給團隊成員解釋需求，團隊成員會根據(jù)對需求的理解提出可能的方案（當(dāng)然也有可能是多個方 案），分出任務(wù)，對任務(wù)做出估計。但是這些估計也是比較粗略的，很多時候需求還是不能很明確，但是一般達到大家能夠?qū)τ脩艄适掠幸粋�基本的理解，能夠開始 著手，能夠做出大體的估計的程度可以。在Sprint過程中，還會不斷發(fā)現(xiàn)新的需求，或者采用或者否決一些方案。這些都是每個Scrum團隊在 Sprint中動態(tài)調(diào)整的。
        迭代開始時，避免任務(wù)分配到個人。在計劃會議會議中，用計劃游戲，每個人都參與估計，每個人都要求理解用戶故事。在Sprint 中，每個成員根據(jù)一些簡單的原則來認領(lǐng)任務(wù)（比如從上到下優(yōu)先級，不超過大并發(fā)任務(wù)數(shù)）。通過結(jié)對編程、Wiki等一些知識共享的手段，多數(shù)人很快能勝任各種任務(wù)。
        周期性的例會（每日例會、Scrum of Scrum）。在例會中團隊成員匯報進度（做了什么），承諾（根據(jù)當(dāng)前情況，下一步要做什么），需求（有哪些困難，需要其他成員或者組織的幫助）。團隊會 重新估計剩下的任務(wù)，如果需要，項目成員和產(chǎn)品負責(zé)人一起調(diào)整Sprint Backlog。
    其次，合理使用信息輻射器（Information Radiator，另見The Ideal Agile Workspace），我們目前使用的信息輻射器包括：
        Sprint Backlog，這是整個項目團隊自我管理的核心。實時反映項目的狀況。通過Sprint Backlog可以了解到任務(wù)分配，項目進展（燃盡圖），缺陷，困難等等。Sprint Backlog上的不同類任務(wù)用不同顏色區(qū)分，一目了然。很容易可以了解任務(wù)分配，Sprint的瓶頸以及困難（用紅色表示）在哪里。
        故事墻，較為長期的開發(fā)計劃。
        Build Monitor，一般包括一個紅綠燈，一個大屏幕顯示器。紅綠燈監(jiān)控主分支的持續(xù)集成系統(tǒng)的狀況，如果構(gòu)建失敗（可能 原因包括編譯錯誤，單元測試問題，冒煙測試以及回歸測試問題等），立刻顯示紅燈，同時也會發(fā)出聲音（XXXX project is "still" btoken）。大屏幕顯示器主要是反映一些大家主要關(guān)注的持續(xù)集成項目的狀態(tài)。其實如果采取按組件做分支的方式，每個Scrum Team還可以有一個熔巖燈，用來監(jiān)控團隊分支的狀態(tài)。
        各種白板，團隊成員可以用白板對具體需求，具體模塊架構(gòu)以及其實現(xiàn)進行討論。然后將白板的內(nèi)容作公示，指導(dǎo)團隊成員的日常開發(fā)。如果發(fā)現(xiàn)問題，隨時修改白板的內(nèi)容。
        團隊日歷，主要是表明一些重要的日期以及成員請假情況。
        系統(tǒng)框架圖，招貼畫。團隊成員可以了解整個系統(tǒng)的高層次的系統(tǒng)架構(gòu)。
    除了這些，還可以考慮加下面的一些內(nèi)容
        各種手繪表格。用于過程改進或者其他作用的手繪表格，常見的例子有在回顧會議里面發(fā)現(xiàn)的問題；測試用例數(shù)目；測試覆蓋率；結(jié)對編程輪換表；要重構(gòu)的函數(shù)；Burnup Chart等。
        產(chǎn)品愿景，團隊成員對具體開發(fā)中遇到的問題，需要做決定的時候，能夠基于愿景做出取舍。
        系統(tǒng)詞匯表，統(tǒng)一語言和隱喻。只有開發(fā)團隊和客戶用同樣的語言，才會減少溝通中的誤解。
        團隊可根據(jù)自身的需求設(shè)計更多的信息輻射器。

筆者的體會是，信息化工作空間的關(guān)鍵是信息，終目的是使任何人只要進入一個團隊的工作區(qū)域，可以立刻了解項目的進度，項目的運行情況，現(xiàn)有的問 題，每個人現(xiàn)在的任務(wù)，一些團隊需要改進的地方等等。大家每天來上班，只要看一下板，立刻知道自己該做什么。不光是團隊成員，一些 Stakeholder也可以到工作區(qū)域去看一看信息輻射器，了解新的狀況。即使Stakeholder不能到現(xiàn)場，只要經(jīng)常發(fā)送一些照片，或者經(jīng)常參 加一些演示，效果也會不錯。實現(xiàn)信息化工作空間的前提是團隊成員要坐在一起，如果不能坐在一起，那只能通過一些電子手段進行同步。當(dāng)然信息輻射器也不能太 多，太多也會導(dǎo)致混亂。

很多的敏捷方法論（Scrum、XP、Lean）都提倡團隊的自我管理。而信息化工作空間則是保證我們團隊自我管理的核心實踐。