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