將團隊遷移到可視化項目管理軟件

自2000年代中期，“Scrum”項目管理（PM）一直統治著軟件開發方法。它的迭代結構、頻繁會議和清晰的層次結構使其成為受頻繁變化的客戶需求和條件管制的行業的明顯選擇。因此，大多數團隊習慣基于 Scrum項目管理應用管理開發過程。 

但是，有新玩家——可視化項目管理軟件進入該領域，盡管沒有那么普及但是帶來很多功能。可視化項目管理是精益生產的現代表現，是早期 Kanban工具，盡管它不等同于兩者中的任何一個。不像人工方法，可視化項目管理軟件從多個方法中吸收元素，以便自動化和簡化現有工作流程。打包成虛擬系統，同時提供實時更新、自定義訪問控制、數據分析等等相對應的優勢。

對采用可視化項目管理感興趣的團隊 Leader往往欣賞其價值，但是不能確定如何克服遷移帶來的挑戰。本文將為團隊平滑過渡和最大化新系統價值羅列最佳實踐。

它如何不同于 Scrum

隨著 Scrum的發展，團隊成員在 Sprint階段往往真正以筒倉的形式開發項目。他們在 Sprint結束時或者每日站立會議中協作、分享進度，這需要每天抽出時間。通過實時進度的使用和任務可視化，可視化項目管理為整個 Sprint提供徹底的透明度。雖然這不能徹底消除對專用會議的需求，但是將會減少多余或者不必要的會議——那些僅僅用于讓人們“了解最新情況”的會議。

同樣可視化項目管理不太強調完成可交付的產品增量，更強調在時間盒內工作在一個合理生產力水平。這意味著單個故事質量重于絕對進度。許多時候，可視化項目管理軟件甚至會限制某段時間特定團隊成員擁有的在制品（WIP）的數量（這能在許多基于 Kanban 的系統中發現，他們用“卡片”移動單個任務通過可復用的工作流程）。重要的是，每次 Sprint生產出可工作的 Backlog項目，但這并不意味著數量勝過質量；團隊成員應該能夠以最佳生產力工作，給予每個 Backlog項應有的時間和關注度。

為什么一些開發人員不喜歡

可視化項目管理其根源在于“ 精益生產 ”—— Toyota開發的管理系統，廣泛用在制造業，用于減少浪費。鑒于流水作業線制造業跟軟件開發行業之間的細微差別和復雜性，兩者之間的隱式并行令很多開發人員感到厭惡。并且這是事實：強迫一些變化無常的事情比如軟件開發，使用嚴格的模型不會生產出積極的成果。

過分簡單化的 Kanban平臺往往是單維度的，不能提供開發團隊需要的復雜度，從而保持對用戶體驗、應用、產品測試結果和不斷重新定義商業價值的市場的響應。

這些肯定是有效關注點，但重要的是，需要注意并非所有可視化項目管理應用都受限于基本 Kanban。許多已經證明在軟件行業（比如 Atlassian JIRA 、 Microsoft Visual Studio 和 Axosoft ）有用的可視化工具，在開發團隊習慣使用的 Scrum的基礎上，結合了 Kanban和精益生產最好的方面，這也是一些用戶稱它們為“Scrum-ban”的原因。這些混合的項目管理系統結合強大的可視化工具給團隊提供了 Backlog、特性測試、代碼庫和用戶故事的全面控制，和從一個集中、響應式的接口工作的能力。 

但是即使你熱衷可視化項目管理理論，實施一個新系統可能看上去令人生畏。需要完成授權、數據傳輸和集成，更別說培訓你的團隊適應新的工作管理風格。這不是在公園散步，但是如果有一個可靠的策略，切換到可視化項目管理就不會妨礙團隊的生產力。

這里有六個技巧可以實現無縫和無痛過渡。

1. 設立明確、切合實際的期望：由于實時可視化工具將不可避免地意味著更大的透明度和整個團隊的問責制，確保在 Sprint期間為每個開發人員設定明確的目標。你的期望應該是切合實際的，應該考慮 Sprint的長度和每個團隊成員能夠處理的工作量。
2. 確保靈活：精益到可視化項目管理能夠提供的靈活度，比如將卡片移到不同“泳道”或改變指定用戶和子任務的能力。這將有助于團隊避免流水作業線的心態。
3. 使用可視化工作流程隔離問題領域：例如，你是否注意到故事多次地被“卡”在測試階段或者因為不滿意的實現重新進入后面的 Sprint，使用根源分析確定瓶頸或冗余的原因。
4. 重新考慮你計劃故事的方式：與其在 Sprint期間將用戶故事推給團隊成員，不如讓他們從 Backlog中挑選故事，填充自己的泳道。這將給開發人員更多的自治和大大減少 Sprint會議所需的時間；你只需要計算故事的總數量，在設置的時間內保持團隊忙碌，當所有或大部分故事被挑選后重新聚集團隊成員。
5. 確保可視化板能夠反映你的工作流程：不要讓可視化項目管理的新穎轉移你的注意力。緊跟團隊熟悉的最佳軟件開發生命周期。這將幫助他們更快地適應并認清投資回報率。
6. 讓遠程工作人員參與：開發團隊成員（或者整個交接團隊）在不同時區不同國家工作并不罕見。可視化項目管理平臺可以是個強大的工具，能夠讓遠程團隊看到最新的團隊進度，給你監控他們工作的能力。

案例研究

很多組織已經在使用可視化項目管理工具，以改善他們的團隊工作流程和提高品質和吞吐量的質量。下面是最新的案例：

西門子醫療服務

西門子醫療服務是全球企業醫療保健 IT解決方案的供應商，包括軟件開發、安裝、托管、集成和為醫院跟較大型聯合執業團體（group practice）的外包服務。他們的開發運營集中在賓夕法尼亞州，橫跨約50個團隊，同時在印度和歐洲也有資產。

2005年，西門子 HS開始使用 Scrum和極限編程框架來實現自己的目標，包括 Scrum團隊、Sprint、評審、回顧和一套成熟的 Backlog流程。他們把敏捷/Scrum作為主要的項目管理工具，經過六年的使用后，在沒有巨大加班壓力的前提下，他們仍然會遇到發布截止日期的麻煩。

西門子敏捷開發負責人 Bennet Vallet說，他們決定在工作流程中引入 Kanban技術以解決這些挑戰。“雖然常規 Scrum/XP提供了很多優秀實踐，西門子仍然在有能力實現可預測成果方面面臨關鍵差距，運行效率中持續改進的勢頭和質量步履蹣跚，”他去年二月寫道，“再者，基于相對故事點數的度量指標和速度圖不能為該規模的版本開發管理提供足夠的洞察力。”

他們在轉型中賭上了一切，在跨團隊和時區并在項目管理層面部署了 Kanban。

西門子團隊確實可以在 Sprint期間利用一些溫和的可視化工作，比如速度圖和燃盡圖，但是他們發現由于故事類型的不同，這些工具給出的都是不準確的讀取。另一方面 Kanban通過專注持續流和在制品，帶來了可預測性和“整個價值流系統性問題和模式的洞見。”

Vallet發現 Kanban有助于他們更好地具體化持續改進心態，通過限制在制品滿足發布截止日期，并促進協作環境的建立。即使是他們的海外團隊在 Sprint期間也感受到了更高的參與度和緊跟步伐。他們的周期時間降至43天或者更少——提高了40%——并保持在一個可預測的范圍內。

Vallet告訴 InfoQ在第一年中他的團隊成果是如此的正面以至于他說服領導將所有產品線遷移至可視化項目管理，這會影響三個不同大陸的40個團隊。

重要的是要注意西門子實施的是 Kanban的混合和更多傳統敏捷技術，比如增量故事開發，頻繁測試，持續集成（CI），和跨職能 Scrum團隊以實現其積極的成果。盡管備受詬病，“制造業”心態有時已經融入到軟件開發中，西門子 HS的一個重大發現是：流程改進需要可預測性。

BBC全球

這一里程碑式的2009年的 研究 是由9人團隊完成的，在 BBC全球內12個月內審查精益生產和 Kanban對軟件開發流程的影響。該研究由 IEEE工程管理贊助，由 Peter Middleton和 David Joyce指揮。Peter Middleton是 Lean Software Strategies的作者，David Joyce是 ThoughtWorks的首席顧問和系統思考家。

BBC團隊——從歷史上來講習慣敏捷/Scrum開發——從使用兩個中央 Kanban板和四個“信息輻射器”開始，這些都是開發團隊進度的大型可視化顯示工具。團隊被指揮在這些板上記錄所有進行中的故事，并不再從事任何未記錄的任務。

跟西門子團隊類似，BBC全球團隊開始注意到從基于推的時間盒方法向新方法轉變是緩慢的，在新方法中只要生產力允許他們就會挑選 新的工作——換句話說就是限制在制品。Joyce和 Middleton注意到周期時間更加一致，和更好的實現持續改進的能力，因此他們認為新可視化項目管理框架是成功的。

可測量的成果：

• 交付時間提升37%
• 交付的一致性上漲47%
• 客戶報告的缺陷下降24%

與之前 Scrum-only方法（回顧僅僅提供不確定的項目交付的總結）相比，BBC團隊實現了傳說中的“持續改進（Kaizen）”天堂。

盡管不是對每個團隊而言，但是可視化項目管理工具可以提供開發生命周期內更大的靈活性和通過更智能的任務分配提高整個產品的品質。成功的遷移并不需要工作流程和業務優先級的全面檢修——只有仔細、有意識的策略和自發的意愿才能收獲回報。

關于作者

Aleksandr Peterson 是 TechnologyAdvice 的技術分析師。他涉及 gamifiction、CRM、項目管理和其它新興業務技術。你可以在 LinkedIn 上聯系他。

查看英文原文： Migrating Your Team to Visual Project Management Software