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

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

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

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

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

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

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

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

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