如何用 Teambition 實踐敏捷研發
今天，如果再花半年時間，去研發一個產品，當這個產品面世時，很有可能已經不能完美滿足市場需求。
今天，我們需要更加敏捷，以更敏捷的狀態，去應對外部變化。如果你對敏捷研發已經了如指掌，那麼 Teambition 敏捷研發專業模板，將是幫助你更好的實踐敏捷研發的好工具；如果你正在轉型敏捷研發，那麼承載敏捷研發方法論的 Teambition 敏捷研發專業模板將能夠幫助你快速入門敏捷研發，開始實踐；
今天我們首個專業模板——敏捷研發專業模板啟動了內測，讓我來帶大家一起看下如何來實踐 Scrum 敏捷研發。
【模擬任務場景】假設我們現在要研發一款筆記類移動端 APP，我們已經組建了我們的團隊——1個產品負責人，2位設計師，2位 IOS 工程師，2位安卓工程師，1位後端工程師，1位測試工程師，並且由我們的測試工程師擔任 Scrum Master。
首先第一件事情肯定是創建一個項目，並選擇專業模板中的敏捷研發專業模板。
項目創建完成後，將所有的9名成員加入到項目中。Teambition 敏捷研發模板主要由5個核心應用組成：需求、缺陷、迭代、日程、統計。我們通過具體的案例來看看怎麼利用這5個應用實踐敏捷研發。
建立產品訂單，並制定衝刺規劃
首先產品負責人要制定產品規劃，建立產品訂單，團隊才能基於此實現最終的商業價值。
「需求」應用就是用來維護 Scrum 中的產品訂單，以及規劃接下來幾個衝刺（迭代）的訂單。需求規劃由產品負責人核心維護，當然需要整個團隊的配合。規劃的長短因團隊而異，一般建議2-3衝刺的規劃。越近的衝刺訂單越完善，當前衝刺的訂單要求每個用戶故事都經過整個團隊的評估，並定義好 Story Point（在衝刺計劃會議完成這件事情），因為這個是開啟一個衝刺的基本前提。下圖中展示了2個衝刺的規劃，Sprint No.1 是首個衝刺，Sprint No.2 是第二個衝刺，還有一些沒有規劃的用戶故事維護在需求池。
啟動首個迭代
團隊已經到位，需求規劃也已做好，是時候開始開工了，那怎麼啟動一個迭代呢？
這個時候需要 Scrum Master 組織這個至關重要的會議——衝刺計劃會議。Scrum Master 可以實現通過「日程」應用創建好衝刺計劃會議，並提醒大家。要說這個會議是所有敏捷會議中最重要的一點也不為過，因為它是接下來幾周工作的基礎，一個好的計劃會議，基本上整個迭代算是成功了一半。通常這個會議耗時都會比較長，因為整個團隊需要將之前初步規劃的產品定義進行細化，拆解成可以執行的任務，並評估每個任務的工作量（Story Point）。如果整體工作量超出了團隊的產能，需要適當的將一些需求放到下個迭代；如果低於產能，需要將後續的需求前置。所以產品負責人需要確保儘可能多的需求處於準備好的狀態。
當所有的執行任務都定義清楚， Scrum Master 就點擊「需求」應用中的「開始迭代」按鈕，通過提示中設定好衝刺的開始和結束時間，所有規劃好的需求和缺陷會自動進入到「迭代」應用中。「迭代」應用會通過看板的形式直觀展示當前迭代內的每一個需求和缺陷的進展情況，包括子任務。右上角會提示離衝刺結束有多少天。
確保迭代按規划進行
迭代過程可以說是最耗時、最複雜的環節，所以「迭代」應用會是所有團隊成員關注最多的面板。如何確保迭代按規划進行，是 Scrum Master 最關心的問題。
除了最開始的計劃會議，儘可能多的把風險從一開始就排除，很多問題需要在執行過程中去發現和解決。每日站會就起到這樣的作用。Scrum Master 利用「日程」應用可以創建每天重複的日程來提醒團隊成員參與。團隊成員每天早上需要描述昨天做的事情，今天要做的事情，以及遇到的問題。當有問題出現，相關的人需要一起協力解決。
當然前面提到的「燃盡圖」也是一個關鍵的工具，用來判斷離衝刺目標的距離。「統計」應用中「迭代報告」分類下的「迭代進展走勢」描繪的就是當前衝刺的進展。柱狀圖描述了每天完成的任務數，折線圖描述了當天剩餘的 Story Point 數，通過和理想剩餘 Story Point 對比可以了解研髮狀態是不是理想。下面描述的場景可能稍具風險，但在可控範圍內。走勢圖下面有實際完成的任務信息，可以幫助 Scrum Master進一步了解每天有哪些任務被完成。
完成首個迭代
當迭代應用中右上角的數字變為0天，意味著衝刺結束，不管任務是不是都完成。
在真正宣告衝刺結束前，需要確保所有的研發成果經過產品負責人的評估，是不是達到了最初描繪的產品目標。當然研發過程中也可以經常向產品負責人或者利益相關者展示研發成功，避免出現偏差。所有研發成果完成評審後，Scrum Master 就可以點擊右上角的「完成迭代」按鈕，標示整個衝刺結束。
最後整個團隊還需要進行一次回顧會議，回顧這次迭代有哪些做的好，哪些做的不好，並列出下次的可執行任務，便於改進整個團隊的效能。
啟動新的迭代
接下來做什麼呢？當然是火力全開，迎接新的衝刺。Scrum 講究的就是短頻快的衝刺，每個衝刺都是環環相接，並驗證最核心的概念。
通常一個迭代都會產出一個可上線的應用版本，上線的版本在暴露到真實用戶的時候或多或少會出現一些問題，稱之為 bug 或者缺陷。所以後續的迭代中，除了需求，我們需要將另一個任務類型考慮進來——缺陷。
測試人員會在「缺陷」應用中將發現的缺陷在這裡管理，並排出優先順序，作為衝刺計劃會議任務來源之一。當然緊急度高的缺陷會第一時間修復，優先順序不高的會安排到接下來迭代修復。缺陷應用用了表格視圖，因為可以非常直觀的展示出缺陷的分類、嚴重程度、出現的平台等基本信息；同時可以快速設置執行者，確定缺陷修復版本和發布計劃。測試工程師會非常關心缺陷相關的統計，包括缺陷的年齡、缺陷變化趨勢、缺陷按照各種條件的分布情況，這一次我們也提供了針對缺陷豐富的統計。將缺陷納入到新的衝刺計劃會議中進行分析評估，便可以制定出新的迭代的可執行任務，並啟動新的迭代。
進一步了解你的團隊
想要很好的實踐敏捷其實並沒有上面描述的那麼輕鬆，每個團隊都會遇到不一樣的問題，實踐敏捷本身就是一個迭代的過程，每一次回顧都會發現一些問題，並在新的迭代中改進。不管如何，想要實踐好敏捷，最核心的是要更好的了解你的團隊，知道當前的產能如何，怎麼去提升產能。那怎麼了解呢？「統計」應用給大家提供了兩個很好的報告，一個是「迭代報告」，一個是「團隊速率報告」。
迭代報告可以幫你記錄每個迭代的一些核心數據，分別從任務維度和 Story Point 維度去統計，包括計劃要完成的量、實際完成的量、需求發生變更的量、缺陷修復的量。通過這些數據可以任務的完成度和迭代的是不是穩定。
團隊速率報告是一個很有意思的圖，柱狀圖部分描繪了整個團隊每個衝刺完成的 Story Point，折線圖描述了到當前為止累計平均完成的 Story Points。通過這兩個數據可以判斷每個階段團隊的產出是不是穩定，或者是不是逐漸提升，以及可以對整個團隊的產能有比較清晰的認知。方法論到這裡啦！當然，Teambition 會持續輸出敏捷研發相關知識，助力你和你的團隊，更好地轉型敏捷。
作者：姜翔，TeambitionProduct VP
點擊這裡，了解更多關於 Teambition 的故事
推薦閱讀：
