“怎樣保證每個(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)目開(kāi)發(fā)團(tuán)隊(duì)中，項(xiàng)目經(jīng)理和部門(mén)經(jīng)理負(fù)責(zé)項(xiàng)目管理和控制。為了控制軟件開(kāi)發(fā)的進(jìn)度，效率和風(fēng)險(xiǎn)，經(jīng)理們往往要求團(tuán)隊(duì)成員提交和更新各種各樣的表格，例如日?qǐng)?bào)、周報(bào)、代碼量報(bào)告、缺陷報(bào)告等等，通過(guò)各種計(jì)劃、報(bào)告、表格來(lái)管理團(tuán)隊(duì)。但是這種方法有很多固有的弊病。

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

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

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

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

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