老翅寒暑

項目管理沙龍第十次聚會紀要

會議一開始，就有人跟我們分享了一個名詞，“分析癱瘓”，意思是不斷地追求完美，結(jié)果始終在設計狀態(tài)，無法到下一步去。詳細可參考這個 http://hi.baidu.com/parad1se/blog/item/8724472a71b87e25d52af1a3.html 和 google。與會者都有同感。而破解“分析癱瘓”的訣竅，就是“敢于行動”，因為人就是在不斷的錯誤中學習并改進的，不犯錯，當然也就談不上改進了。如果用沙龍常用的術語說，那就是“敏捷”。

今天的敏捷話題是分享AOM的敏捷過程。AOM是一個基礎平臺產(chǎn)品，在實施敏捷之前，采用周計劃的模式來管理，即每周定制計劃，組員按照計劃完成工作，并且更新自己的工作狀態(tài)。這種管理模式在需求控制，角色分工，任務分配和團隊激勵上，都存在較大的問題，所以AOM團隊想到了利用敏捷方法來改進項目管理。所以這一點上AOM和NSEC最大的不同，就是AOM是主動“擁抱敏捷”，而NSEC是“被敏捷”。

AOM有產(chǎn)品經(jīng)理（PO）的角色，負責需求的最終拍板。敏捷教練（SM）負責團隊敏捷過程的正確性和改進，但是和一般SCRUM規(guī)則不同的是，SM是項目組之外的人，且不負責項目的進度，項目的進度由項目組自己來管理。項目組依然有項目經(jīng)理（PM）的角色，但是在實行過程中，這個角色的作用被弱化了，變成了一些關鍵事務的協(xié)調(diào)人和PO的代理人。日常的進度監(jiān)控工作，則由輪換的“主持人”完成。

在產(chǎn)品的計劃會議上，AOM使用紙牌游戲的方式來對每一個任務評估point數(shù)。并且根據(jù)團隊的能力，設置sprint計劃的point總數(shù)。和NSEC不同，AOM不會在每一個sprint中預留point，而是將一些項目之外的事務變成backlog放到sprint中一起進行跟蹤。如果外部干擾太大，就要及時調(diào)整sprint中未開始的backlog，刪掉一些優(yōu)先級較低的backlog，并且用更小的backlog彌補進來，并保持sprint總的point數(shù)不變。就像長跑的時候呼吸和腳步的頻率要非常一致才能跑得很好一樣，敏捷過程也很重視“節(jié)奏”。所以AOM的sprint時間長度也基本是穩(wěn)定的，目前是兩周一個sprint，部分為三周。

在產(chǎn)品的回顧會議上，所有的問題都會被分析一遍，對于投票最多的前三項問題，會在下一個sprint中生成backlog并分配專人跟蹤和完成。其他問題，如果是規(guī)則性的，就會去更新規(guī)則。

每日站立會議上，主持人會先向大家通報一下上一個工作日的task完成情況和進度的預測，然后團隊每個人再回答一下三個問題：昨天做了什么，今天做了什么，遇到什么困難。在日常任務的跟蹤上，AOM通過紙質(zhì)的任務看板和紙質(zhì)的backlog卡來進行跟蹤，每天下班前，主持人會根據(jù)看板的進度情況，敦促當事人及時更新任務卡片，并將任務卡片的進度數(shù)據(jù)同步到ScrumWorks中（大家回憶起了讀書時候的“課代表”）。每次站立會議都會有一個人記錄會議紀要，并且將其內(nèi)容登記在wiki上，以便全體成員（包括缺席人員）備查。

主持人機制在AOM敏捷過程中占據(jù)十分重要的地位，它負責對團隊每個成員進行敏捷管理意識和能力的培養(yǎng)，通過角色輪換的方式，讓團隊成員獲得一種比本職角色更高的角度去看待軟件開發(fā)和管理，嘗試他們以前不太有機會去嘗試的團隊管理或設計方面的工作。在AOM團隊中，主持人按周輪換，除了跟進項目進度之外，還要負責控制會議的時間。

不同的會議，控制時間的基準也是不一樣的。對于計劃會議，則每個backlog的討論時間=會議計劃長度/sprint中backlog數(shù)目。對于每日例會，每個人發(fā)言時間=15分鐘/發(fā)言人數(shù)，最長沒人發(fā)言時間不超過（30分鐘/發(fā)言人數(shù)）。回顧會議上，每個問題的討論時間=會議計劃長度/問題總數(shù)。另外，對于討論和辯論，控制時間是每項討論和辯論不超過1分鐘。只要超過時間，主持人就會主動打斷，維持會議效率。

AOM同時也引入了“結(jié)對”的機制。組員自由結(jié)對，分主副手。所有的任務要兩個人同時簽名才有效，主程序員負責編碼，副手負責單元測試，并且在sprint結(jié)束之后，主副手角色調(diào)換，副手負責維護該部分代碼，包括修改bug和增強功能。這種結(jié)對延伸到項目組的每一個方面，所以每天站立會議會議紀要，也是會議主持人的結(jié)對伙伴來記錄的。

AOM的敏捷過程中，大家發(fā)現(xiàn)使用紙牌、看板、任務卡片的方式，使整個過程充滿了“游戲性”，具有很強的“參與感”。組員之間互相關心，在任務分配上更公平，工作效率更高，每項任務中的職責分工更明確，當然產(chǎn)品的質(zhì)量也更高了。而且輪換主持機制讓每個人都有更多的角色體驗，可以讓PM空出來思考更深層的問題。

目前AOM尚未在每個sprint結(jié)束之前進行show case。

與會者在講述過程中插入了很多的討論和分析，大致有如下幾個話題：

與會者首先關心的是“需求來源”問題。因為項目的特殊性，AOM的需求更多來自于團隊的拍腦袋，其次是公司內(nèi)其他項目提出的要求。與會者一致認為，不管怎樣，“有目的的手機用戶需求”是肯定的，但是需求的篩選也是值得注意的方面，要結(jié)合項目的目標來進行。比如iPhone多半可以肯定不會去實現(xiàn)什么“雙卡雙待”和“收音機”的功能。但是有時候的“拍腦袋”和“摸著石頭過河”也是不可避免的。這就要求PO充分擔負起責任來，PM也要擔當一下，比如某些需要預研才能確定做不做的技術，就要先動起來。

關于showcase，有人發(fā)現(xiàn)公司的一個怪現(xiàn)象：“產(chǎn)品的名字大家都聽過，但是長相大多都不知道”。僅從這個意義上去看，showcase的重要性也是不言而喻的。大家一致的意思是要用起來，因為它可以讓團隊充分感受到目標和時間的壓力。但是初期不一定非要每個sprint都show，在掌握方法之后慢慢提高，最終達到每個sprint都show的程度。但是一定要注意showcase是要求不要做特別的準備的，也就意味著showcase的成果就是日常工作成果。

“到底有多敏捷”是與會者提出的一個問題，有人覺得公司內(nèi)部的過程改進組織就應該來回答這種問題，通過對項目組敏捷過程的觀察，給出一個敏捷的級別，并且以此來逐步指導和提高項目組的敏捷程度。

有人關心“任務沒有人領”的問題，經(jīng)過討論，我們發(fā)現(xiàn)雖然有部分任務會存在只有某人能夠完成的情況，但是只要經(jīng)過細分，大部分任務的難度都會降下來，并降到其他人也可以認領的程度。有人發(fā)現(xiàn)如果能夠?qū)ⅰ皞€人學習計劃和任務結(jié)合起來”，是可以降低某些任務對人的依賴性的。

“如果團隊中有破壞者怎么辦”，這是有人用“六頂思考帽”的思考方式提出的問題。但是大家在討論中發(fā)現(xiàn)，利用每日例會和看板，我們很容易發(fā)現(xiàn)那些虛假的進度匯報，并且敏捷中持續(xù)的溝通，讓謊言在其中生存的難度變得極大。一旦“破壞者”被發(fā)現(xiàn)，要么被清除出團隊，要么自動離開，或者痛改前非，融入團隊。

在分析“輪換支持”機制的時候，有人舉例了IBM的60%工作，40%溝通的時間安排比例，談到了如何讓員工更多思考，聰明工作的問題。不過未展開。

敏捷其實不是一種新生的事務，無論從其指導思想，還是各種使用的工具和方法，大部分都是敏捷提出之前就已經(jīng)存在的，比如看板就是源自豐田的精益管理方法，每日例會則來自于服務行業(yè)。現(xiàn)在敏捷已經(jīng)不僅限于軟件開發(fā)，在市場銷售、公司管理都有應用案例。

最后，有人提出“敏捷管理方法如何在餐廳運用”的問題，引起了大家熱烈的討論，但是考慮到沙龍的時間，討論在一片歡樂中結(jié)束，不過我們不排除以后會抽出一個專題來討論這個問題。