最近在學習實踐精益Kanban方法，結合自己團隊實踐Srum的經歷，整理些資料二者的差異。相較于Scrum, 我更推崇精益Kaban。

Agile是一套理論和原則，就像天邊的北極星。Devops是一種軟件開發(fā)和運維團隊間自動化和集成過程的方法。當實現Agile和Devops方法時，Kanban和Scrum提供了管理這些復雜工作的不同的實踐。
簡單來說，Kanban和Scrum是進行敏捷開發(fā)或項目管理工作的兩個不同的策略或者方法論。

• Kanban方法意味著持續(xù)性與更好的流暢性。
• Scrum則是基于更短，更加結構化的工作沖刺。

Scrum：一種結構化的敏捷方式

Scrum源自于橄欖球的一種爭球方式。現在作為一種迭代式增量軟件開發(fā)過程，通常應用于敏捷軟件開發(fā)。Scrum將工作分解成較小的功能單元，并在周期性固定的時間段內持續(xù)的交付。

• 把組織細分成小組、跨功能、自我組織團隊。
• 把工作細分成細小、實在的交付成果，交排人員負責需求清單以及跟據重要性排優(yōu)先級別，由團隊估算每個項目相對工量。
• 把整個開發(fā)時間分成固定時長的短迭代（通常于一至四星期），在每個迭代后演示新增可發(fā)布功能。
• 優(yōu)化發(fā)布以及跟客戶一起更新優(yōu)先級別，基于每個迭代后發(fā)布的觀察。
• 優(yōu)化過程，在每個迭代之后進行回顧

在我們考慮考慮采用SCRUM之前，先問自己一個問題：整個開發(fā)團隊是否是專職團隊，并且負責該項目。
SCRUM團隊會承諾每個Sprint結束都會交付產品或者價值。如果你的團隊成員有肯能去做別的其他項目，那么SCRUM團隊無法承諾每個Sprint的交付。另外，在選擇SCRUM時，還需要考慮以下方面：

• 節(jié)奏

SCRUM強調的是快速交付，在每個Sprint結束時交付用戶可用的可交付物，每個Sprint一般2周最多4周，有著清晰的開始和結束時間。該框架的背后思想是利用短的時間段強迫把復雜任務分解為小的user story.

• 關鍵指標

衡量一個SCRUM團隊表現的關鍵指標是velocity（效率），即在一個Sprint中交付的story points的數量。該指標用以指導后續(xù)Sprint中可以承諾完成的story points。想象一下，如果一個團隊每個Sprint中平均完成35個storypoints，那么后續(xù)的sprint中我們不會完成45個story points.

• 應對變化

一般情況下，SCRUM團隊盡量不要在Sprint過程中進行范圍變更。如果團隊通過客戶反饋發(fā)現他們正在開發(fā)的功能沒有他們認為的那么有價值，這種情況下需要變更該Sprint的開發(fā)范圍，以便優(yōu)先交付對客戶最優(yōu)價值的功能或價值。

Kanban：一種持續(xù)改善，變化靈活的過程

Kanban方法最初起源于豐田的JIT（Just In Time），之后作為一種高效管理軟件開發(fā)流程的技術和思想應用于互聯網行業(yè)。Kanban方法以價值流動為核心，不斷發(fā)現團隊中的瓶頸工序，進行改進，使價值流動更加順暢和快速。

**工作流程形象化 **

• 把工作細分成任務，寫在卡紙上，貼在墻上
• 把欄命名好，來顯示任務在工作流程中的狀況

限制“在制品”（work in progress，簡稱 WIP）

• 明確設定限制在每個狀態(tài)下同一時間能有多少工作任務

度量生產周期（即完成一個任務的平均時間），優(yōu)化開發(fā)過程，縮短開發(fā)周期和使它更易于預測。

發(fā)布方式

• 看板過程中，軟件更新只要完成就可以隨時發(fā)布，沒有一個周期或者提前決定的日期。理論上，看板并不需要預先確定一個時間點來交付一個任務或者軟件更新。如果一個特性完成，無論早晚，都無需像SCRUM過程那樣等到Sprint結束再發(fā)布。

角色

• 整個團隊對看板負責。有些團隊可能需要一個敏捷教練的角色來幫助看板過程的順利進行，但是不像SCRUM一樣，有一個看板master, 來保證每件事情都平穩(wěn)運行。看板過程中，整個團隊相互協作，來負責交付看板上的每個任務。

關鍵指標

• 循環(huán)周期（Cycle Time）是看板過程的一種重要指標。它指的是一個工作項從開發(fā)到結束所花費的平均時間。工作項循環(huán)周期的改善意味著團隊的成功。

看板團隊經常用來分析項目進展狀況的工作是累計流圖（CFD）。它可以用來表示每個狀態(tài)下的工作項的數量，從而幫助識別出限制工作流的瓶頸。

應對變化

• 看板的工作流可以任何時候進行變更。任何時候都可以添加新的工作項，也可以暫停或刪除正在進行中的項目，這一切取決有優(yōu)先級。而且，如果團隊交付能力發(fā)生變化，可以重新設定WIP（Work In Progress）限制，工作項也可以被隨之調整。

比較差別，探索適合自己的方法

在團隊的項目管理實踐中，我們往往將二者的優(yōu)勢結合起來綜合的使用，以便幫助團隊更好的完成目標，而不是為了使用方法而使用方法。

相同點：

• 兩者都符合精益和敏捷思考
• 兩者使用"拉動式"安排日程
• 兩者限制開發(fā)中工作數目
• 兩者是透過透明度來驅動過程開進
• 兩者集中提早及衡常的付運軟件
• 兩者基于自我組織團隊
• 兩者要求把工作細分
• 在兩個情況下發(fā)布計劃都是基于經驗數據（速度／開發(fā)周期）持續(xù)優(yōu)化

不同點：

系統范圍

在討論Scrum和看板之前，有必要澄清系統范圍。在Scrum里，系統范圍由產品的定義和完成的定義決定；而在看板里，看板系統的邊界定義了系統范圍。

• Scrum的運作是圍繞產品的，每個迭代開始從產品待辦列表挑選進入下一個迭代的故事，迭代結束將故事做到完成。故事的范圍是由產品的定義決定的，故事在產品的范圍內是端到端的。完成的定義體現的是故事可交付的程度，也就定義了價值流的終點。

• 看板(Kanban)系統的邊界定義了價值流的范圍，由此決定故事的范圍。故事會流過整個看板系統，其終點狀態(tài)完成的定義也就相當于Scrum中完成的定義。

需要指出的是Scrum的系統范圍定義通常是基于組織結構的，它涉及到產品的定義和團隊的組建，產品待辦列表要與團隊相對應，因此系統邊界相對嚴格；而看板的系統范圍定義只是基于在統一的看板系統做可視化和管理流動，因此系統邊界相對寬松。這也跟兩者不同的變革導入思路有關。

兩者都有一個思想去盡可能地擴展系統范圍，以利于管理整體的價值流動和實現。只是體現出來的對Scrum而言是產品定義的擴展和完成定義的擴展，而對看板而言是看板系統邊界的擴展。

在我看來，無論Scrum還是看板，都希望幫助到價值交付和持續(xù)改進，但是它們采取了不同的方式。最顯著的差別在于Scrum采用迭代而看板采用流。

Introduction to Jira Software Boards | Atlassian

價值交付

• Scrum和看板都致力于最大化價值交付，無論是采用迭代還是流，關鍵都在于減少在制品。在制品由進行中故事的個數和故事的大小決定。
• 當采用迭代時，限制故事的個數是間接的，迭代長度間接限制了故事的個數。當采用流時，限制故事的個數卻是直接的。

故事的大小是另一個影響在制品多少的因素。迭代會推動故事的拆分，因為在迭代結束時要求能夠將故事完成。然而，把故事拆得過小會使拆分變得不自然（也就是為了拆而拆），反而降低了那些拆分出來故事的價值。故事不能被無限地拆分，一個故事在有價值的前提下能拆多小通常存在自然的限制。采用迭代有可能會人為地破環(huán)故事的自然大小和完整性，而采用流則會更遵照故事自然的顆粒度。

持續(xù)改進

Scrum和看板都致力于持續(xù)改進，無論是采用迭代還是流，關鍵都在于創(chuàng)造合適的挑戰(zhàn)來驅動改進。當改進目標達成后，改進就會陷入停滯，而持續(xù)改進卻需要永不停歇。Scrum和看板都是通過提升目標來再次創(chuàng)造合適的挑戰(zhàn)以使改進繼續(xù)，但是提升目標的方式卻不同。

Scrum里最重要的改進目標是在迭代結束做到完成。這里有兩個變量，迭代長度和完成的定義。當通過改進做到迭代結束完成后，我們會看完成的定義是否可以擴展。擴展后的完成定義產生了新的挑戰(zhàn)，從而提供了繼續(xù)改進的動力。當完成的定義已經達到可以交付時，我們會看是否可以縮短迭代長度，這又能驅動進一步的改進。

看板的改進目標一方面來自于直接的在制品減少。通過在制品限制的降低，系統中更多問題會被暴露出來，從而驅動改進。另一個重要的因素是圍繞前置時間的改進，前置時間的縮短對價值交付和提升靈活性都有幫助，因此是很好的改進目標。

變革導入

最后想說說的是關于Scrum和看板的變革思路, 根本在于改善（小變化）和改革（大變化）的平衡。當引入過大變化，由此產生的挑戰(zhàn)過大，結果適得其反。當過于保守引入過小變化，又使變化過于緩慢，甚至逐步喪失了改革的能力。

Scrum的有效運作需要組織設計，它的第一步在我看來是改革，然后由每個迭代回顧驅動持續(xù)改進。看板尊重現有的組織結構，從現狀出發(fā)，因此它的第一步更接近改善，然后也是持續(xù)改進。對兩者而言持續(xù)改進理論上引發(fā)改善或者改革都有可能，實際中發(fā)生更多的是改善。

當變革涉及系統范圍的擴展時，Scrum要求組織結構的改變，而看板要求的最小改變只是放在統一的看板上進行可視化管理，因此更能反映“可能的藝術”。而當現有的組織結構制約了協作模式并最終影響到價值流動時，組織結構仍然需要被突破。

先導入Scrum還是 Kanban?

從屬性上來看:

Scrum 容易探討未知，處理復雜項目，拿來開發(fā)新東西威力無比。
Kanban 是教我們如何自我檢討，可以迅速消除浪費，而得到好的效能。

如果你是開發(fā)團隊，當然是先從Kanban 開始。
先檢討團隊的基本動作，整頓好了再來開始作新的東西，從事開發(fā)的動作，自然減少浪費。這是精益Lean 的好處。
(有太多開發(fā)團隊，只曉得一意往前沖刺，忽略了自己在開發(fā)上的浪費，這會造成很難走得久遠，尤其是Startup的團隊尤其如是。)

如果你是運維團隊，當然是先從Kanban 開始。
視覺化是最大的亮點，團隊可以看見工作上的維護流程是一件相當有價值的事，針對個人亦是如此，人們常常因為養(yǎng)成習慣了，就一直持續(xù)做同樣的事情，很少會有機會回過頭來檢討，哪里做得浪費了應該改進。
看板方法的第一步: 視覺化。正是團隊可以拿來持續(xù)改進的基礎。這一點對維護工做更顯得珍貴。

如果你是測試團隊，當然是先從Kanban 開始。
看的見以后才可以減少猜測的比例。測試團隊在擬定測試計劃之前，一定要對待測的產品或程序有足夠的了解，才可能寫出實用的測試案例，不至于浪費大量的測試資源，或做了過多的重復性測試。

你可能覺得奇怪，為什么都是Kanban Method 先行呢?
其實原因很簡單，因為它"單純“，不是簡單喔! 它沒有想像上的簡單，因為它可以演進得很有深度，但是它的目的很單純，就是追求效能。不像Scrum 的目的，是要來應付復雜的項目開發(fā)作業(yè)，基本上的方向就完全不一樣的

相較于Scrum, 我更推崇Kanban, 因為限制少，推動Kanban的過程本身其實是定義團隊流程規(guī)則的過程，不需要特定的角色，容易理解和接受。

將看板方法融入Scrum的開發(fā)過程才是上策
看板方法是一種流程控制，他不是一種具有完備基礎的方法學，雖然他的潛在發(fā)展相當可觀，但目前他仍只是一種提供我們產出高效能的流程控制法而已。
他缺少需求描述、沒有完備的會議規(guī)劃、少了團隊職責分配，少了很多很多軟件開發(fā)上該有的措施，這一點讓他看起來十分空泛，但就是這個特性也讓他十分適合融入其它開法方法中，尤其是Scrum。

看板方法之父 David J. Anderson 是在Microsoft 公司推行敏捷開發(fā)法 Scrum 的時候發(fā)明看板方法的。他原本的目的只是要求能夠在最少阻力之下順利在組職中推行敏捷式的開發(fā)方法而已。卻由于他熟悉限制理論的運作而開創(chuàng)了看板方法Kanban Method。做出了對敏捷開發(fā)的精益Lean 一支的重大貢獻。
也就是這樣的典故，讓看板方法Kanban Method可以十分容易的融入到Scrum的開發(fā)過程。

著名的《 Essential Scrum 》 的作者Kenneth S. Rubin(它是2013年Amazon 敏捷理論最暢銷書)，書中就大量的采用 WIP(Work-In-Process)的觀念，實際的運用在工作看板上面。讓Scrum在開發(fā)流程上減少了許多的浪費現象。

看板方法先行
因為它可以減少組織在推行敏捷上的阻力，它能讓工程師以最好的節(jié)奏持續(xù)進行開發(fā)工作。又能將精益觀念帶入團隊運作。
融入Scrum的開發(fā)過程
因為看板方法的流程控制方式是用來提升Scrum運行時的效能，讓 Scrum 能真正用來克服復雜的軟件程序開發(fā)過程。

Scrum 的目的在解決復雜的軟件開發(fā)作業(yè)
許多人誤把Scrum 當成加速軟件開發(fā)的銀子彈。這是錯的!

它的目的不在加速開發(fā)(加速開發(fā)工作是開發(fā)工具的廣告詞)，它的目的是在解決復雜的軟件開發(fā)作業(yè)，讓它提高成功率。在協助團隊能夠提供給客戶真正要的產品，且讓他在市場上具有實際的競爭力。這一點也正好是看板方法所缺少的。

開發(fā)團隊千萬別因為實施了看板方法而誤以為需要把 Scrum 拋棄了，這是一種錯誤的想法，讓他們相輔相成才能有更大的效益。

先導入 Scrum還是 Kanban? 二者之間并沒有沖突存在，都是通往敏捷開發(fā)的路徑，就看你現在最需要的是那一樣，那一樣就先來吧

• 已經在使用 Scrum 作開發(fā)工作的人士，學習 Kanban Method 可以讓他們進入精益的領域，有所依據的持續(xù)追求更好的效能。
• 先學會Kanban 方法 再跨足 Scrum 的人呢? 則可以看到敏捷開發(fā)在處理復雜問題上的具體方法，真正懂得去追求效能之外的正確性與方向。

實踐分享 - 結合業(yè)務性質，持續(xù)改進，適應外部變化

基于團隊業(yè)務情況（服務交付類型），結合自己對兩者的理解，以及實踐中遇到的問題，畫了如下圖：

我們遇到的問題：

• 需求不固定，經常面臨隨時插入高優(yōu)先級需求
• 客戶反饋需要快速解決，特別是阻塞性的
• 資源緊張，負責平臺模塊多，業(yè)務差異較大

探索改進過程

1. 混亂期，團隊新組建，需求沒有得到有效跟蹤
2. 建設期，逐步開始通過Jira跟蹤需求，嘗試敏捷Scrum, 各種站會，評審會，評估故事點等實踐，此時外部需求可控，從2周迭代發(fā)布（小瀑布）逐步過渡到隨時可發(fā)布狀態(tài) （伴隨著建立了分支模型，分支模型也隨之調整了兩版，建立了和環(huán)境對應的持續(xù)交付流水線）
3. 問題期，業(yè)務壓力大，各種Scrum會議感覺作用不大，團隊成員不需要參與所有需求評審，PO需要多個業(yè)務板塊切換準備需求
4. 調整期，推動研發(fā)人員專職負責某個模塊，負責整體迭代把控，拆分成迭代火車，各負其責，把sprin當作一個個專題需求火車
5. 改進期，雖然劃分了責任邊界，但是外部需求/事務增加，積壓嚴重（狀態(tài)更新不及時），無法從宏觀了解整體情況（整個看板都是滿的），所以嘗試使用Kanban方法，梳理業(yè)務流程，在原有流程不變情況下，明確定義團隊協作規(guī)則，制定不同緯度/角色關注的看板，同時建立個人/團隊儀表盤，關注動態(tài)變化
   1. 需求看板 - 研發(fā)/產品經理關注
   2. Scrum迭代看板 （專注于內部開發(fā)迭代）- 研發(fā)同學關注
   3. 客戶問題看板 （劃分優(yōu)先級泳道）
   4. 缺陷看板 - 測試同學關注
   5. 運維/運營看板 - 包括技術債務，改進，支持事項等
   6. 整體全局看板

經過上述過程，團隊逐步向 “自組織“團隊演化，”分工有序“，簡化花里胡哨的Scrum儀式, sprint變成了業(yè)務發(fā)布火車（劃分迭代范圍之用），把整個團隊跑迭代變成了2-3人的“按照業(yè)務領域劃分的迭代”，放棄了故事點評估（實踐證明似乎不太適合我們），相比于scrum偏重于迭代間的改進，我們更看重需求交付速度，不希望有擠壓，降低外部插入的需求或事項帶來的干擾，讓成員更專注。

總結

• Kanban主要用來可視化你的工作，限制在制品，使其最大效率的流動。Kanban團隊聚焦在減少花在項目（或者用戶故事）上的從開始到結束的時間。他們通過Kanban board 來實現它并持續(xù)改進他們的工作流。

• Scrum通過設置稱為沖刺（Sprint）的間隔去承諾需要承載的軟件開發(fā)。它的目標是通過搜集和集成客戶反饋去創(chuàng)造一個產品的快速學習環(huán)。Scrum團隊采取特定的角色，創(chuàng)造特定的工件，執(zhí)行特定的儀式來保持事情的推進。

**	Scrum	Kanban
規(guī)劃	它有固定的計劃。它專注于規(guī)劃。它從 sprint 計劃開始，以 sprint 回顧結束。召開每日會議，以便團隊了解接下來的步驟、優(yōu)先級以及從先前步驟中獲得的經驗。	它沒有固定的計劃，也沒有舉行日常會議。在看板中，隨時可能發(fā)生變化，即頻繁發(fā)生變化。
時間線	在 Scrum 中，我們處理具有固定持續(xù)時間的沖刺，這意味著經過一些固定時間后，我們將向客戶交付一些東西。	看板沒有沖刺的概念，因此它沒有將產品交付給客戶的固定時間表。
任務估計	在沖刺計劃期間，決定從產品待辦列表中提取多少活動并添加到沖刺待辦列表中。例如，如果沖刺是兩周，那么選擇活動的數量，使它們可以在沖刺內完成，即在兩周內完成。	它不估計任務。
Scrum Master	在 Scrum 方法論中，我們有一名 Scrum 主管負責管理團隊并每天主持會議。	在看板方法論中，我們沒有任何 Scrum Master。交付有價值的產品是每個人的責任。
適用性	這種方法適用于大型項目，因為大型項目可以分為多個沖刺。	主要適用于小型項目。
不斷變化	在 Scrum 中，可以在較短的沖刺中輕松適應不斷的變化。	如果發(fā)生任何重大變化，那么看板方法就會失敗。
成本	在 Scrum 中，任務是估計的，即在一個 sprint 中進行固定數量的活動，因此項目的總成本最小。	在看板中，沒有估算任務，因此項目的總成本不準確。
角色和職責	在 Scrum 中，Scrum Master 為團隊成員分配了特定的角色，而產品負責人則告訴團隊成員必須工作的產品目標。	沒有為團隊成員分配預定義的角色。所有團隊成員都有責任合作交付有價值的產品。
生產力衡量	生產力是通過使用周期時間或完成整個項目從開始到結束所花費的時間來衡量的。	生產力是通過沖刺速度來衡量的。
發(fā)布方法	每個沖刺結束后的小版本。	它提供持續(xù)交付。

區(qū)別一：實施過程中關注核心的區(qū)別

Scrum實施的核心可以概括為“化繁為簡”，從幾個維度解釋下：

1. 團隊角色的定義，將團隊人員定義為三個角色，Scrum Master（主要負責消除障礙，帶領團隊運作）、Product Owner（主要負責描繪產品遠景，定義優(yōu)先級）、Scrum Team（主要負責實現產品）
2. 工作任務的拆分，將產品需求拆分成小的用戶故事，并評估優(yōu)先級
3. 時間的拆分，將項目周期拆分成固定時長的迭代周期，每個迭代交付一部分可驗收的功能，通常迭代長度為1到4周

Kanban方法在實施的過程中更多關注的是可視化的價值流動，從幾個維度解釋下：

1. 拉動式生產，下游工作完成后，主動拉動上游的任務移動
2. 限制WIP（work in progress），明確設定限制每個狀態(tài)下，同一時間內有多少工作量，減少同一狀態(tài)同一時間內，任務和價值的堆積
3. 可視化的價值流動通常是端到端的流動，直觀的反映用戶的價值（通常是可交付的用戶需求），并且反映出在價值流動過程中的瓶頸和問題，不斷為團隊改善提供依據

區(qū)別二：限制WIP數量的方式不同

Scrum與Kanban方法都會限制在制品數量，不過限制方式有所不同，

• Kanban方法限制的更加直接，同一狀態(tài)同一時間內的工作任務有最大限制；
• Scrum是間接性的通過迭代（sprint）來限制。限制WIP的核心目的是加速交付用戶需求的價值流動。

區(qū)別三：對任務變更管理的不同

在Kanban方法的中，下游任務完成后（有顯式化的拖動規(guī)則），即可拉動上游任務下移，同時，只要生產力允許，即可新增需求。

在Scrum方法下，當每個迭代的sprint Backlog確認后，當前迭代是不允許新增需求的，新增加的需求可以體現在下個迭代的sprint backlog中。

區(qū)別四：改進依據的不同

• Scrum是以生產率作為計劃和改進的依據，以迭代（sprint）數據作為依據，分析迭代的相關數據（包括生產率、完成率等）；
• Kanban方法是使用生產周期作為計劃和過程改進的依據。

Scrum和Kanban方法作為即敏捷又精益的典型代表，除了上述不同外，還存在很多相同點：

1. 二者都和敏捷與精益相對應。敏捷中的持續(xù)改進思想在Scrum和Kanban都有所體現，而且是很核心的一個內容；精益中的拉動式生產在Scrum和Kanban中也都分別覆蓋，Kanban方法體現的更加直接，下游直接拉動上游的工作任務。
2. 二者都關注盡早的交付價值，盡可能頻繁的發(fā)布可使用的軟件。Scrum將整個項目周期拆分成多個迭代，每個迭代發(fā)布可驗收的軟件；Kanban方法在每個功能開發(fā)測試完成后就可以進行部署和發(fā)布。
3. 團隊狀態(tài)都直觀的反應在Scrum board和Kanban Board上，方便找到問題和瓶頸，并進行改善。

案例

比較了Scrum與Kanban方法之后，如何結合二者在團隊中進行項目管理實踐呢？這里提供一個案例，從迭代、版本、變更、改進四個方面來介紹

迭代：在Kanban方法中，并未規(guī)定明確的迭代，而在Scrum中是規(guī)定了固定的迭代周期。在我們的團隊中，迭代周期從一月一迭代，逐步變?yōu)橐辉聝傻浆F在的兩個自然周一個迭代，完全固化了迭代周期的概念。

將復雜開發(fā)周期很長的開發(fā)任務，分解成多個迭代周期，每個迭代周期交付一些可驗收的軟件或者功能。有利于減少風險，并更好的適應變化，及時的根據反饋調整工作目標。

版本：在迭代中，我們以排入版本計劃的功能點（story）作為工作重點，排入版本的story為交互已經完成的功能點（story），這些功能點可以直接進入開發(fā)和測試環(huán)節(jié)。這些story便是我們當前迭代可以交付的功能或者軟件。與此同時，產品、交互和視覺同學會繼續(xù)拉取需求池中的功能點，開始進行設計，準備下個迭代版本中的內容。使整個價值流動更加順暢。

變更：對待變更，我們同樣有自己的一套流程規(guī)范，既沒有像Kanban方法一樣，只要生產力允許，便可以新增需求；也沒有像Scrum一樣，版本內容確定，當前迭代基本不允許變更。
在實際過程中，當存在緊急需求，由產品經理發(fā)起，和各個角色進行評估風險和對現有版本的影響，并采取相應措施降低由于需求變更對整個系統產生的影響，最后由項目經理發(fā)出變更通知的郵件。

改進：我們改進的依據之一是團隊數據，由于我們所有的任務都是通過JIRA進行管理，可以方便的拿個團隊各種數據，包括：總工作量、總完成工作量、完成率、有效工作量、有效工作率、bug數、bug率等，對這些數據進行分析，發(fā)現團隊的問題，幫助團隊進行改進。