OOPAA

（節選自本人翻譯中的《ThoughtWorks Anthology》一書的第7章“What Is an Iteration Manager Anyway?”）

第7章 迭代經理是什么角色？

行業日新月異，敏捷、迭代式和迭代這些熱門詞已是“飛入尋常百姓家”，一個定義模糊的新角色——迭代經理，也浮出水面。這是新一代的項目經理么？抑或是美其名的團隊帶頭人？又或者是管理上的一個新階層？誰會被冠以這個“經理”頭銜？

本文將著重闡述迭代經理作為軟件團隊成員的工作內容和價值。我們將分析迭代經理的職責范圍，同時討論作為一個不可或缺的角色，迭代經理在面對組織和文化挑戰的情況下，如何維持一個健康的工作環境。

7.1 什么是迭代經理？

通常在大型的敏捷團隊里面，項目經理不可能同時關注項目團隊每次迭代的成功，和整個項目最終的成功。2000年，有一個項目團隊困擾于甄選高優先級的工作，最終的解決辦法是選出一個人以一個穩定的節奏給交付團隊提供持續的高優先級的功能“流”：這就是迭代經理（IM）的雛形。

在迭代式開發的世界里，總是需要有人對項目團隊提供支持，促進與業務客戶的日常交流，使整個團隊保持關注于高優先級的工作。ThoughtWorks的高級架構師Fred George把迭代經理描述成“面向內部的管理角色。迭代經理負責保證故事在團隊中流動的順暢，這涉及到合理分配任務、在技能需求改變的時候建議更換團隊成員。”

7.2 怎樣成為一個好的迭代經理？

迭代經理可以來自不同的能力背景——可以是技術能力（加上很強的人際能力！），也可以是分析能力（加上很強的人際能力！），甚至他們也可以從業務專家或者行政專家（加上很強的人際能力！）里面產生。他們必須擁有前瞻思考、樂觀進取的態度和擁抱變化的才能。每天，這些面向內部的推動者使用他們的才能協助交付團隊使之逐步完善。

比如，一旦明確了迭代的工作量，迭代經理就需要在迭代的整個過程中跟蹤團隊的進展，從實際出發，積極地在團隊內部貫徹流程的改進。想象一下在站立會議上面，迭代經理聽到開發人員說他已經在一個故事上面工作了三天，而這個故事原本估計是一天的工作量。因為要對每個團隊成員的日常活動和迭代的進度負責，迭代經理需要去挖掘這個被低估故事的細節。如果迭代經理不能很快判斷故事的真實狀態，立即與客戶就迭代計劃的潛在變更進行溝通，團隊就有可能面臨承諾失信的風險。迭代經理可以從詢問如下問題開始：

• 開發人員弄清楚了故事的范圍嗎？
• 故事任務在最初的評估之后是否發生了變化？如果發生了，是如何變化的？
• 開發人員是否需要業務分析人員或者客戶的幫助，以更好地理解故事所要求的完成結果？
• 開發人員是否需要向技術負責人尋求幫助？
• 是否有什么事情阻礙了開發人員完成故事（換句話說，是否存在硬件、軟件，甚至基礎設施的問題）？
• 是否開發人員又被分派了另外一個項目，或者參加了太多瑣碎的會議導致無法完成故事？

上述問題只是一個例子，說明為了保持團隊按照預定的進度前進，向客戶匯報項目的每日狀態，迭代經理可能要承擔的工作。每天，迭代經理都必須傾聽團隊的需要并且響應。其主要職責就是培養一臺潤滑良好的“機器”，能依據要求的質量在項目范圍內交付功能。

迭代經理應該在技術熟練度和業務知識之間達到一個平衡。Mary和Tom Poppendieck寫到敏捷領袖應該“同時對客戶和技術都具有深刻的理解，這樣才能贏得開發團隊的尊重。”良好的溝通技巧是必須的。迭代經理的職責之一就是維護開發團隊與客戶，以及與管理階層之間的關系。

同時，迭代經理必須推動、堅持和保障團隊成員的權利。對于很多敏捷團隊，這些權利來自于開發人員的“權利法案” ，經過了整個團隊的同意。通常迭代經理都需要協助團隊以確保這些權利得到了堅持。

通常這都是以在團隊內部以及團隊之間加強交流的方式出現。大部分的開發人員都不習慣于直接與客戶交流，或者對故事的完成程度給出直接的判斷。迭代經理通常需要提供數據、圖表和圖形的示例來推動開放的交流。

迭代經理也必須維護客戶的權利。每次這樣的誘惑——團隊成員不按照優先級高低的順序進行開發——稍微露出端倪，迭代經理就要作為客戶代理人出現。還記得么，客戶有權利只為那些符合他們所期望的優先級順序的工作買單？整個過程自始至終，迭代經理都必須保持一個中立的態度。

－－未完待續－－