1、借助信息化工作空間實現(xiàn)高效的團隊自我管理 “怎樣保證每個團隊成員高效地工作，使組織產生最大的效益”是每一個經理最大的挑戰(zhàn)。通常經理們會采取以下兩種手段: 告知團隊成員該做什么(Command and Control) 團隊成員依據(jù)設定好的原則，自己打算下一步該做什么(Self-organizing) 在許多軟件項目開發(fā)團隊中，項目經理和部門經理負責項目管理和掌握。為了掌握軟件開發(fā)的進度，效率和風險，經理們往往要求團隊成員提交和更新各種各樣的表格，例如日報、周報、代碼量報告、缺陷報告等等，通過各種計劃、報告、表格來管理團隊。但是這種方法有許多固有的弊病。 首先，數(shù)據(jù)不精確。例如在日報中，一般要求

2、提交任務完成百分比。這個數(shù)字許多時候是團隊成員拍腦袋想出來的。任務完成90%后，剩下的10%需要更多的時間完成的狀況在許多團隊中也屢見不鮮。 其次，數(shù)據(jù)不準時。除了項目文件，經理們沒有方法了解項目的詳細運行狀況，進度，只有通過日報或者周報。任務安排也不準時，團隊內部工作量也不均衡。 再次，衡量標準不恰當。 用代碼量作為衡量Dev生產率的標準原來就是不恰當?shù)?。這使團隊成員單純追求代碼量而不停的復制拷貝，不關心優(yōu)秀系統(tǒng)架構所要求的代碼簡潔，架構清楚。 用缺陷作為衡量Dev工作效率的標準也是不恰當?shù)?。軟件開發(fā)并不僅僅是編寫代碼，更重要的是溝通問題。絕大多數(shù)缺陷其實是由需求不明確或者是溝通的不充分和不

3、精確導致的。用缺陷率作為標準會導致團員成員之間的矛盾，相互指責，推卸責任。 再次，信息不透明，不直觀。報告往往不是團隊成員直接可見的，需要登錄到網站，或者訪問Source Control或者共享文件夾的某個文件(往往是有權限掌握的)。這些信息不會直接展示給大家，他們總是需要一路點擊過去。 最終，過多的無效工作。團隊成員要花費許多時間和精力在更新及維護報告上面，但這些工作并沒有業(yè)務價值。 在處理復雜像軟件開發(fā)這類復雜問題的時候，使用Command&Control方式效率非常低下。許多狀況下即使是最有經驗的經理，由于他不在現(xiàn)場，不把握全部詳細狀況，也很難做出精確的推斷，有效地指揮團隊成員工

4、作。而第二種管理方式(Self-organizing)在解決復雜問題時就要有效得多。在復雜的環(huán)境中，可以通過訓練及培訓使團隊成員把握工作的基本原則，把責任下放給第一線的工作人員，由他們依據(jù)不斷變化的實際狀況，不斷地調 整，完成團隊任務。軍隊也是類似，在戰(zhàn)斗過程中，作為戰(zhàn)斗指揮的上級極少直接指揮每個士兵戰(zhàn)斗。人員和班組就是自我管理，依據(jù)現(xiàn)實狀況和戰(zhàn)略目標動態(tài)調整 戰(zhàn)術。這也是絕大多數(shù)的機敏方法論都在強調團隊的自我管理的原因。 怎樣在軟件開發(fā)中實現(xiàn)團隊的自我管理?怎樣讓團隊找到自身的問題?怎樣實時地反映項目的進度?團隊成員怎樣知道每天應當做什么?為了解決這些問題，我們的經驗是日常開發(fā)中建立一個基于

5、拉動式生產方式的信息化工作空間。 首先，我們的日常開發(fā)以Scrum為基本框架，并特殊強調團隊的自我管理。詳細做法是： 短迭代。每兩個星期一個Sprint。每個Sprint給幾個客戶做演示。產品負責人會依據(jù)演示的反饋以及原先的發(fā)布計劃重新整理Product Backlog，并由此產生下一個Sprint的計劃。因此團隊的每個Sprint的任務是由業(yè)務驅動的。 用戶故事。產品負責人會在計劃會議開頭之前整理成用戶故事。產品負責人在整理用戶故事過程中會留意收集真正客戶想要的東西，理解客 戶的意愿，而不是業(yè)務以及技術上怎樣實現(xiàn)。在計劃會議會議中，給團隊成員解釋需求，團隊成員會依據(jù)對需求的理解提出可能的方案(當然也有可能是多個方 案)，分出任務，對任務做出估計。但是這些估計也是比較粗略的，許多時候需求還是不能很明確，但是一般達到大家能夠對用戶故事有一個基本的理解，能夠開頭 著手，能夠做出大體的估計的程度就可以。在Sprint過程中，還會不斷發(fā)覺新的需求，或者采用或者拒絕一些方案。這些都是每個Scrum團隊在 Sprint中動態(tài)調整的。 迭代開頭時，避免任務安排到個人。在計劃會議會議中，用計劃游玩，每個人都參與估計，每個人都要求理解用戶故事