Posted on 2009-06-13 16:31
mingj 閱讀(4055)
評論(0) 編輯 收藏 所屬分類:
agile 敏捷 、
PM 項目管理
(節選自本人翻譯中的《ThoughtWorks Anthology》一書的第7章“What Is an Iteration Manager Anyway?”)
7.3 迭代經理不做什么
迭代經理(IM)并不是項目經理(PM)。與項目經理不同,迭代經理需要在工作第一線,與團隊成員一起面對每日的工作活動。如果你是迭代經理,就把項目預算、資源管理、承諾、以及大層面上的問題留給項目經理。只關注團隊!
此外,迭代經理只是一名項目成員,而不是人力經理或者資源經理。迭代經理不負責給團隊成員寫年度總結。這可能會影響他們的中心任務,即保持一個中立的態度——既維護團隊的權利,又保持團隊關注于對客戶優先級最高的功能。團隊成員不應該絞盡腦汁以求給迭代經理留下好印象,而應該是在需要幫助的時候要求迭代經理給予幫助。
迭代經理也不是客戶。通常由團隊中的商務分析師或者架構師扮演客戶,這取決于故事的性質,或者真實客戶的可獲性。但是,迭代經理不應該扮演客戶,如果他們作為客戶來下決定,就無法幫助團隊恰如其分地解決問題。
最后,迭代經理不保證技術的完整性,也不保證對標準的遵守,抑或提供技術基礎支持(例如,對構建、部署或者數據庫的支持)。項目的實現活動,比如協調多個項目、協調部署或者演示,通常是技術負責人或者首席商務分析師來處理。
7.4 迭代經理與團隊
雖然沒有明確規定,但是迭代經理要承擔一些日常職責。下面列舉了其中一些:
- 收集花在故事開發上的時間
- 使交付過程中的瓶頸顯現出來
- 向客戶匯報團隊狀態
- 解決在每日站立會議上提出的問題、阻塞和障礙
- 控制所有流向團隊的工作,管理工作的分派以保持一個可持續的速度
收集單個故事的實際所花時間可以得到很多測量指標。收集這些時間,和其他不同的數據點比較,有助于迭代經理提高團隊的產出。首先,比較迭代內已完成故事的實際所花時間和故事的點數,迭代經理就可以知道團隊有多少時間花在真正的交付故事上面,又有多少花在團隊會議和其他活動上面。其次,比較項目已完成故事的實際所花時間和團隊計劃的項目時間,迭代經理就可以明白團隊的產能,以及團隊對于項目的可用度。最后,比較已完成故事的實際所花時間和故事的預估時間,可以得到故事評估的準確度。上述所有的測量指標在不同的環境下都很有用,迭代經理用它們來幫助團隊形成一個穩定的交付速度。
穩定的交付速度是計算未來迭代團隊產能的基礎。有了團隊在每次迭代里面經過充分測試的產出物和每位團隊成員的計劃可用率,迭代經理可以基于實際的已驗證的數據來規劃團隊的產能。產能是不受團隊支配的,也不會因為明確的交付時間就自動達到。產能是預先計劃的,這樣團隊成員才能自我管理好。如果交付速度與業務需求不同步,可以調整其他的項目杠桿,但仍然需要使用實際的產出物來預測將來的產能。
很多測量指標和精心地排列故事墻能識別出項目的瓶頸。假設一個故事預估的工作量是一天,但在經過三天開發以后,卻還擺放在故事墻的開發欄里面:這說明遇到了瓶頸需要團隊一起討論。Fred George創造了一種成功的測量指標,就是手指圖。這種圖表使用了堆積圖,每塊區域分別代表了迭代周期中的一個階段。每天更新故事的狀態,團隊可以觀察到圖上每個區域的增長,以及交付周期中故事的流轉。當圖上的所有區域成比例地增長時,這些區域就能形成手指的形狀。當圖上某塊區域與其他相比不成比例時(比如說“等待開發”區域比“開發”區域寬),團隊能發現瓶頸的存在。此時,團隊可以討論如何消除瓶頸以使團隊的交付速度回復穩定。
在每日站立會議上面,迭代經理排除掉不必要的干擾,保持團隊成員使用正確的方式:過去24小時做了什么,接下來的24個小時準備做什么,遇到了什么障礙。迭代經理留心傾聽每人的任務項和當天需要排除的障礙,這樣團隊成員可以完成故事。如果有人在每日站立會議上霸占時間,談論標準匯報內容之外的東西,迭代經理需要帶領團隊重新回到關注點上面。通常的做法是建議那人在站立會議之后做一個較大的問題解答。
7.5 迭代經理與客戶
正如前面討論的,測量標準可以幫助迭代經理判斷團隊可持續的速度。這允許團隊定期做出承諾,并最終兌現。但是,為了團隊成員能維持承諾,迭代經理必須保持客戶在迭代階段不去更改故事。迭代經理要像守門人,幫助客戶對即將來臨的工作排列優先級,而不是經常更改優先級使得團隊無所適從。
作為守門人,迭代經理保護團隊不受分心之擾,也防衛客戶不經意間影響團隊的生產率。在迭代之外,客戶可以而且應該不斷地更改優先級。直到迭代開始之前,所有影響決定的因素都是可以改動的,而且要經常介紹新的信息。
項目中即時決定的概念并不是一個全新的概念。由豐田知識工程發展而成的精益開發系統在多方案同步進行的開發工程方面已經有多年的成功經驗。多方案同步進行的開發工程被描述成“很謹慎地延遲決定,直到必須做出決定;努力維持各種可能的選項,盡可能延遲決定至開發團隊收集到足夠的決策支持信息,而不是為了所謂的果斷而快速排除其他選項,從而更快地達到最優方案。”
--未完待續--