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