國外機構 Digital.ai 曾在2021年發布《第十五次敏捷狀態報告》，報告顯示：自疫情發生以來，采用敏捷的軟件開發團隊有顯著增長，從2020年的37%增加到了2021年的84%。除此以外，從敏捷狀態調查的早期開始，工具支持一直是決定敏捷成功的關鍵因素。
1. Scrum 簡介
Scrum一個是用于開發和維護復雜產品的框架，特別是對于那些有著清晰 Roadmap 的特性開發團隊，以便于按照固定的節奏提交價值增量，Scrum更加有完整的套路。
完整的Scrum框架包括：3個角色、3個工件、5個活動和5個價值觀：
- 3個角色：Scrum Master、Product Owner、Team
- 3個工件：Product Backlog、Sprint Backblog、Increment
- 5個活動：Sprint、Sprint planning meeting、Daily standup meeting、Sprint review、Retrospective meeting
- 5個價值觀：專注、勇氣、公開、承諾、尊重
本文將通過實際測評體驗研發管理榜評分最高的敏捷項目管理工具 PingCode 對 Scrum 框架的支持，以及項目管理全過程。（PingCode）
2. 敏捷開發項目實施的全流程
為了讓大家更好的理解，我們將按照一個標準Scrum流程為大家介紹說明：
標準Scrum流程
2.1 產品目標（愿景）管理
該環節痛點：很多研發團隊成員只知道低頭做事，完全不知道自己要打造什么樣的產品，整個團隊無法形成合力；
一個新項目往往是由愿景開始，愿景也可以認為是目標。
雖然敏捷開發憑借其在產品交付速度、質量、風控等方面的顯著優勢，逐漸在軟件開發模式中占據主流，但大量問題仍然阻礙著企業的敏捷實踐。其中，研發團隊及其所在公司過于看重技術和流程，未能建立“上下同欲”的目標感，就是研發團隊經常面臨的問題之一。
在 PingCode 有一款專門為目標管理服務的子產品（Goals），它能夠幫助項目團隊進行目標管理，具體介紹如下：
- 建立上下同欲的目標感：基于公開透明、層層對齊的團隊目標和個人目標，每個成員都有機會融入進企業的整體戰略中，提升成員的內驅力；
- 建立可視化的目標管理過程并與研發工作數據連接：Goals 不僅可實時查看目標進度，目標還支持添加關聯多個項目的工作項，并查看項目研發進度，從而定位給目標進度帶來風險的具體項目；
目標管理同樣是很大的話題，詳細介紹就不在這里展開。
2.2 需求代辦列表管理
該環節痛點：很多團隊經常面臨需求描述、需求優先級及排期問題；
在產品愿景確定之后，團隊將進行市場調研等活動，并根據愿景、需求調研逐步構建需求代辦列表——需求池管理；
在需求收集和需求管理的過程中，產研團隊經常會遭遇兩類問題：
- 需求描述的問題：需求信息不清晰、不完整；
- 需求的優先級及排期問題：什么樣的功能能對用戶產生最大的價值，這是需求管理中最重要的問題；
而以上問題你都能在 PingCode 找到比較好的解決方案：
- 獲取清晰完整的需求信息，還原用戶場景：為了幫助產研團隊更好的用戶洞察，PingCode 為用戶提供了統一的需求、缺陷和建議反饋通道，其中就包括Web Portal、小程序、郵件、Webhook等渠道。產研團隊可以根據需求自定義工單頁面，以及與需求提交人直接溝通，盡可能的完善需求信息。在需求收集后，團隊可以按照史詩/特性/用戶故事分級管理需求。
- 基于數據洞察實現科學的需求優先級評審排期：PingCode 能夠幫助團隊整合工作量、價值、投票數、信心指數、影響程度，以及其他客戶自定義的維度等信息。在評審過程中，團隊將綜合各維度信息確定每個需求的權重分數，需求經過評審之后通過計算的權重分數確定需求排期，以實現科學的優先級管理。
2.3 產品路線規劃
過去產品總監沒有固定的工具進行產品規劃，或者使用Excel，細化調整費時費力，且與研發其他環節的工具割裂；
根據產品代辦列表和產品部門的細化，產品愿景的實現路徑慢慢清晰起來，并因此形成較為清晰的產品路線圖規劃。
產品路線圖是產品需求在時間軸上的總體視圖，它是產品需求與其完成時間的概覽，可以使用產品路線圖來對需求進行分類、排定優先級，然后確定發布時間表。產品路線圖宏觀的展示了產品的發展方向以及開發團隊何時實現目標。
有效的路線圖不僅是一個強調產品發布和功能的時間表：它是一個動態的文檔，產品負責人會在項目進行過程中根據實際情況不斷更新，所以在創建產品路線圖的初期，對需求、工作量、優先級、完成時間的估算不要求也無法很精確，這些內容都是隨著項目進行不斷細化調整的。
而在過去很多團隊都沒有專業的工具進行產品規劃，或者使用Excel，無論是細化調整還是內部外部的共享都費時費力，且與研發其他環節的工具割裂；
PingCode Ship 是一款專門為產品管理而打造的子產品，使用它能夠有效避免以上的問題，比如能夠根據你需求的評審排期結果自動生成產品路線圖，并選擇性同步給需求提出方以及內部團隊，反饋需求進度。
除此以外，也不會像Excel那樣存在多個版本的問題，而且PingCode 8 個子產品、研發管理各環節都是相互打通。
2.4 迭代計劃
過去很多敏捷團隊可能都面臨著開發計劃頻繁變動，經常有臨時任務插隊，團隊成員的工作狀態被頻繁打破等問題；
根據路線圖，產研團隊將需要規劃項目/產品版本及發布范圍。
然而在很多敏捷團隊，可能都遭遇過迭代計劃頻繁變動，經常有臨時任務插隊，團隊成員的工作狀態被頻繁打破等問題；
從實踐角度來說，解決這些問題需要團隊在迭代前有著清晰的規劃，并確定迭代時間和目標，將需求拆解的足夠細，與業務方達成協議，在迭代后根據準確的度量來發現問題持續改進；
而從工具的角度來看，PingCode Project 則更有助于以上實踐方法的落地，比如：
在迭代開始前，團隊可以將已梳理完成且優先級高的用戶故事規劃到迭代看板內，并規劃出項目/產品版本及發布范圍，讓發布更有計劃；
在迭代會議，則能夠幫助產研團隊更好的確定迭代時間和目標，細化用戶故事為更小的開發任務，提供敏捷估算器輔助估算故事點，規劃形成Sprint Backlog，填寫預估工時。（燃盡圖我們將在下面講到）
Sprint Backlog
將用戶故事細化成更小的開發任務
2.5 開始迭代
過去產研團隊在各個開發環節的工具中頻繁切換，且低價值、重復性、手動性任務團隊浪費較多時間；
在開始迭代后，如何解決各環節工具中頻繁切換，讓團隊有更多的時間專注在有價值的任務成為很多團隊提升效能不可回避的問題。
開發關聯：PingCode 除本身覆蓋項目管理全生命周期的能力外，還通過應用市場與其他工具集成，所以迭代過程中的代碼、持續集成、測試用例、缺陷、文檔等，都可關聯對應需求，信息在需求頁面均可統一獲取；
自動化能力：如果迭代過程中，某個需求下的子任務都完成了，PingCode Flow 將自動改變該需求的狀態，類似的場景還有很多，就比如自動創建分支、自動配置頁面權限等等；PingCode 提供了非常多的自動化規則模板，同時用戶也可以自行創建。
工時統計：除此以外，PingCode 也支持團隊在迭代過程中填寫、統計預估工時、實際工時，形成項目/團隊工時統計視圖；
2.6 每日站會
該環節痛點： 在以往，敏捷團隊可能更多是使用Excel定時統計需求進度，費時費力還容易出錯。
每日站會核心是圍繞以下三個問題展開：
- 昨天我做了什么事情幫助開發團隊達成Sprint目標？
- 今天我要做什么幫助開發團隊達成Sprint目標？
- 是否有任何障礙在阻礙我或開發團隊達成Sprint目標？
但每日站會不是任務指派的會議，也不是報告的會議，而是為了溝通狀態、減少其他會議、發現開發過程中需要移除的障礙、促進快速地做決策、提高開發團隊的持續改、優化開發團隊達成Sprint目標的可能性。
以往這一環節，團隊可能更多是使用 Excel 定時統計需求進度，但這種方式費時費力還容易出錯。
在 PingCode ，團隊可以通過任務板/故事板，查看每個成員正在處理的任務，確認迭代范圍變化情況，快速掌握團隊進展。
除此以外，團隊還可以通過迭代概覽、迭代燃氣圖等統計報表，查看當前迭代進度，識別迭代風險。
2.7 迭代評審
迭代評審會議在 Sprint 快結束時舉行 ，這個事件是讓開發團隊展示他們在Sprint中取得的成就，根據DoD“完成的定義”和驗收標準，驗證增量。
所以，當任務負責人演示工作成果時，可能會提出一些缺陷，而這個時候團隊可以直接在用戶故事上直接創建缺陷/Bug，并確定Bug緊急度。
2.8 迭代回顧
該環節痛點：以往可能缺乏可靠的研發數據作為持續改進的基礎；
回顧會議專注于團隊和團隊的流程，它一般圍繞以下三個問題展開：
- 我們在上一個Sprint中哪里做得好？
- 上一個Sprint我們哪里做得不夠好？
- 我們的改進計劃是什么？
使用 PingCode 后，產研團隊完全可以不憑借經驗感覺和有限的數據分析復盤，因為 PingCode 不僅每個Scrum 項目內有針對該項目的報表。
還具備專門為效能度量而打造的子產品Insight，提供自動采集效能數據能力和體系化效能指標體系，能夠幫助敏捷團隊基于準確數據進行持續改進。
除此以外，在迭代回顧會召開過程中，團隊還可以借助 PingCode 將“當前迭代做的好、不好及需要改進的計劃”，記錄進迭代回顧板，做到持續跟進。
至此，一個完整的 Scrum 迭代過程就基本結束。
通過對敏捷框架的逐一盤點，敏捷項目管理各環節痛點的對應，大家也能基本了解PingCode 這款工具對敏捷開發項目管理的支持程度，是否能滿足自己需求。當然這些也僅是我們團隊的測評，是否滿足其他團隊，還需大家親自體驗。
推薦閱讀：
了解敏捷開發：什么是敏捷開發？ – 知乎 | 瀑布與敏捷的區別 – 知乎| 敏捷宣言及相關解讀 – 知乎 |敏捷開發框架有哪些 – 知乎 | 敏捷開發中的Scrum模式介紹 – 知乎 | 敏捷開發項目管理到底行不行？ – 知乎 | 待續…
落地敏捷開發： Scrum vs Kanban如何選擇？ – 知乎 |國內外最著名的10個敏捷開發項目管理工具盤點 – 知乎 | 實戰規模化敏捷：從8人到100多人的敏捷之路 – 知乎 | 百人左右團隊如何做好敏捷開發？ – 知乎 | 待續…
版權聲明：本文內容由互聯網用戶自發貢獻，該文觀點僅代表作者本人。本站僅提供信息存儲空間服務，不擁有所有權，不承擔相關法律責任。如發現本站有涉嫌抄襲侵權/違法違規的內容， 請發送郵件至 舉報，一經查實，本站將立刻刪除。