敏捷發生在團隊中，是為了使團隊更好地適應新信息，而不是執行預先制定的計劃。因此，需要管理團隊與開發團隊協作，實時快速地定義產品，而敏捷看板便能把整個開發流程可視化。什么是敏捷管理看板圖呢？它能解決哪些業務問題？一起來看一下吧。

隨著移動互聯網、軟件即服務（SaaS）和基于云計算的快速發展，你需要加快你的產品開發周期，將重點工作放在定義核心功能集的前端。

你可以從敏捷軟件開發思想中借鑒一些最佳實踐，并將這些實踐應用于團隊管理中。

敏捷思想最開始是通過17位軟件開發領導者合作編寫的敏捷宣言（Agile Manifesto）脫穎而出的。

敏捷宣言提出了十二項敏捷原則，表達了敏捷開發的精神。

隨后，敏捷逐漸演變成為一套框架和實踐，例如：Scrum、沖刺、每日站立會議、燃盡圖等等。

但是，這些具體的實踐對于敏捷來說并不是必須的。

敏捷是一組有利于授權團隊的原則，這些團隊被授予創新和創造滿足客戶需求的產品的自由。

相比傳統開發模式，敏捷團隊要具備更多的決策權。

敏捷發生在團隊中，它更多是為了使團隊更好地適應新信息，而不是執行預先制定的計劃。

這就產生了一種方法：管理團隊與開發團隊協作，實時快速地定義產品。

你可能會在4-6周內定義大型產品，并從組織中汲取最佳思維，讓又快又好成為可能。

01 什么是敏捷管理看板圖？

看板源于豐田生產系統和精益生產，是一種可視化流程管理系統。

主要描述團隊在生產什么、何時生產及生產多少。

在敏捷方法中，看板（Kanban）是一個動態的管理工具，可以顯示項目中每項工作的流動性，并且可以識別瓶頸。

看板也是一種信息發射源，用于展示信息，它要放置在團隊成員路過就能看到的地方。

常見的看板類型有物理看板和電子看板：

• 物理看板易于創建，只需要一塊白板或一面墻，利用物理看板可以將團隊成員從工位拉離并形成所需的集會；
• 電子看板有隨時可訪問的顯著優點，對于分布式團隊特別有效，而且能將每項工作信息和相關討論保存，使數據不丟失。

看板的作用是把整個開發流程可視化。

這種最佳實踐提升了基于sprint開發方法的基本要素，并將其應用于產品開發的前端，也就是通常所說的概念或定義階段。

盡管管理團隊的代表（常說的客戶代表）不是全職在開發中工作，但訪問是廣泛可用的。

沖刺過程是通過采用產品營銷提出的一頁紙概念定義來啟動的，并由管理團隊的代表（通常是營銷副總裁或 CMO）塑造。

這將被帶入與核心團隊（4-6名，包括質量和用戶體驗）和管理團隊（3-5名負責監督業務部門的 C 級經理）的工作會議中。

工作會議的結果是完善和擴展的產品概念描述。

這組要求分為三組：

1. 候選：是那些尚未討論的要求；
2. 進行中：是那些已經提出但尚未完成（或缺乏完全同意）的要求；
3. 已定義：團隊開始著手處理開放的需求，并與客戶代表一起迭代定義。

在第一次會議后不超過兩周的時間里，團隊重新聚在一起審查“候選”和“處理中”的要求，目標是在一兩次會議中將所有這些都轉換為“已定義”。

這個過程通常會再重復一次，然后項目就可以進入開發階段了。

02 這種方法有什么好處？

創建引人注目的產品定義是任何企業都需要解決的最困難的任務之一，這種方法可以幫助提高速度和質量。

它提高了定義速度，因為開發和管理之間的緊密迭代循環減少了間隔時間的記憶損失。

此外，它設定了團隊的時間限制與期望。

而且定義的質量更好，因為你擁有組織的集體智慧，而不僅僅是少數聰明人進行權衡。

此外，管理團隊將傾向于引入更多的跨職能需求，從而確保定義“整體產品”，而不僅僅是核心功能集。

03 解決哪些業務問題？

這種方法最重要的好處是它可以幫助組織快速開發真正困難的平臺程序。

它還具有為產品創建共同愿景的附加作用，當需要進行進一步權衡時，這確實有助于下游。

有哪些注意事項？

在給定的組織中實施該方法之前，應檢查許多考慮因素。

這不能替代獲得客戶的聲音，直接從客戶（和渠道合作伙伴）那里收集需求非常有必要。

其次，這是資源密集型的，因此大多數組織會承受太多壓力，無法讓所有正在開發的程序都遵循這種方法。

在這種情況下，執行團隊可能需要標記具有非常適合此方法的屬性的程序（大范圍、涉及子系統的平臺、新的世界或公司的新程序）。

04 案例分析

一家最大的公司正計劃在明年秋季推出新的員工評級和評估系統。

由 IT 項目負責人、人力資源經理和項目經理組成的設計團隊在全國范圍內舉辦了三場需求收集研討會。

此外，他們還創建了“原樣”和“未來”流程設計，并向管理層提出了一系列建議。

但在第三次管理審查和六個月的工作之后，他們似乎并沒有比開始時更接近。

其中一家企業的負責人建議采用敏捷管理方法，因為他們看到它在幫助其部門進行產品開發方面非常有效。

這位業務部門的負責人同意成為團隊的一員，而不是法官，并同意與設計團隊密切合作。

在六周內，到第三次會議結束時，就項目的整體愿景達成了完全一致。

那時起草了一份工作聲明，用于尋找軟件供應商和集成合作伙伴。

項目定義階段結束，正式開發階段拉開帷幕。

IT 項目負責人將其描述為他所從事的任何項目中恢復最快的項目之一，并表示考慮到高層管理人員的參與，這些要求可能會堅持下去。

上表源自看板制造過程（準時制），在每個步驟的列中指示。

表中有三列及時顯示給定快照的需求狀態。

這是第一次定義會話后項目的快照：

• 第一列描述已知但未定義的要求；
• 第二列列出了那些已經討論過但尚未完成的要求；
• 最后一列代表團隊同意完成或完全定義的要求。

上面的圖表顯示了未定義需求隨時間的進展或燃盡。

縱軸是未定義需求的數量，橫軸是會話編號。

理想的圖表將從左側未定義的需求總數開始，然后在第三次會話時下降到零。

這讓團隊成員有進步感，并幫助他們盡快專注于完成質量定義。