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

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

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

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

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

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

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

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

相比傳統(tǒng)開發(fā)模式，敏捷團隊要具備更多的決策權。

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

這就產(chǎn)生了一種方法：管理團隊與開發(fā)團隊協(xié)作，實時快速地定義產(chǎn)品。

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

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

看板源于豐田生產(chǎn)系統(tǒng)和精益生產(chǎn)，是一種可視化流程管理系統(tǒng)。

主要描述團隊在生產(chǎn)什么、何時生產(chǎn)及生產(chǎn)多少。

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

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

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

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

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

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

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

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

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

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

這組要求分為三組：

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

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

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

02 這種方法有什么好處？

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

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

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

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

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

03 解決哪些業(yè)務問題？

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

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

有哪些注意事項？

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

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

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

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

04 案例分析

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

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

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

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

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

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

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

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

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

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

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

表中有三列及時顯示給定快照的需求狀態(tài)。

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

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

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

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

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

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