只會用傳統開發模式?10分鐘教你玩轉敏捷!

語言: CN / TW / HK

什麼是敏捷開發

我們一般習慣用瀑布模型,它以文件為驅動,將軟體生命週期劃分為固定的六個基本活動,並且規定了它們自上而下、相互銜接的次序,如同瀑布流水,逐級下落。

那什麼是敏捷開發呢?敏捷開發是一種以人為核心、迭代、循序漸進的開發方法,它能應對快速的需求變化,以交付客戶滿意的軟體為最終目標,其中 Scrum 就是實現敏捷開發的標準和流程之一。

Scrum

Scrum 主要術語

  • 產品建議表(Product Backlog):整個專案被切分成許多Backlog並形成研發團隊的原始工作任務池;

  • 使用者故事(User Story):團隊從技術的角度對Backlog的一種細化與分解並可投入開發的產物;

  • 任務(Task):比User Story粒度更小的任務;

  • 每日的工作會議(Sprint Daily Standup Meeting);

  • 看板(Kanban):一個可以寫字的白板,用於展現專案進度等;

  • 時間燃盡圖(Burning Down Chart):用於管理任務的進度,剩餘量工作的一張圖。

Scrum 的三個角色

  • 產品負責人:需求方,提出需求,能對功能流程,業務流程拍板的人。

  • 團隊負責人:負責解決團隊問題,領導專案。

  • 專案執行人員:開發專案一般包括前後端開發、UI、QA等。

Scrum 的三個工件

  • 產品建議表(Product Backlog):頭腦風暴,如果產品負責人對產品需求非常清楚,就可以省略這個步驟,開發一個原則“先緊後松”, 必須先把需求瞭解清楚,這裡產品負責人可以召集技術團隊對其需求進行公開徵求意見,最後輸出一個產品建議表。

  • 產品需求表(Release Backlog):產品負責人對產品建議表進行篩選,做減法提煉最核心的需求。在確定了需求後,這個時候由團隊負責人進行輸出技術方案文件,這裡就和傳統的瀑布流一樣了,該有的文件都必須有了,必須由團隊負責人和產品負責人確定好需求,包括業務邏輯,功能流程等。

  • 時間燃盡圖(Burning Down Chart):時間燃盡圖是 Scrum 的精華,通過該表格可以視覺化任務的時間進度,每天按照任務完成度更新剩餘時間,或者增加時間(例如發現一個技術難點,團隊成員請假等要增加開發時間)。

Scrum 運作框架

前方高能,這個圖非常重要!!! 掌握了這個,就知道敏捷是怎麼玩的,裡面包含 4 個階段(需求梳理、任務拆分、迭代開發和總結回顧)和 5 個會議(需求評審會、計劃會、每日站會、演示會和回顧會)。

什麼,還是看不懂這個圖?我簡單串一下:

  • 需求梳理:我們開始和產品梳理出需求,將需求落入需求池,然後再將這次需要迭代的需求,通過需求評審會進行評審;

  • 任務拆分:需求評審完畢後,我們會再開一個計劃會,對任務進行拆分,即初步評估每項任務的工時,然後根據大家的時間,將任務拆分到本次迭代中;

  • 迭代開發:本次迭代任務確定後,進入迭代開發,我們會通過每日站會,保證專案進度;

  • 總結回顧:開發完後,會開個演示會(評審會),業務方會驗收產品,專案全部結束後,會再開個回顧會(反思會),總結專案經驗。

大家可能會說,這還不簡單,那我拋 2 個問題:

  1. 任務拆分中,你都沒進行方案設計,是如何評估工時的呢?

  2. 本週五專案上線了,你可能連下個迭代的需求都不知道,下週一你能正常開下一期的迭代會麼?

這兩個問題,你要是能回答上來,證明你專案管理還有些本事,後面的實戰會告訴你答案。

專案實戰

敏捷的基礎其實不難,但是當結合具體實踐,還是會遇到很多問題,我之前帶領團隊同學走敏捷,也是摸爬滾打幾個月,才把這套敏捷流程跑通,下面就以之前做的海外電商 ShareSave 專案為原型,給大家講講我們如何實踐敏捷。

需求池

為了明確 ShareSave 存在哪些問題,團隊成員通過頭腦風暴的方式,將自己的想法通過卡片的方式展現出來,然後進行投票篩選,流程如下:

  • 核心流程:產品負責人先將 ShareSave 整個的拼團流程,包括開團、分享、下載和支付等12個核心流程,用藍色卡片貼成一條水平直線;

  • 優缺點描述:大家對對這12個核心流程,說明每個流程存在的優點和缺點,優點用綠色卡片表示、缺點用黃色卡片表示;

  • 情感曲線圖:根據優缺點卡片個數及重要程度,將綠色卡片多的流程上移動,並將黃色卡片多的流程下移,形成一條上下波動的曲線;代表使用者使用產品時的心情曲線,越高代表體驗越好,越低代表體驗越差;

  • 流程建議:針對曲線中突出的問題,大家給出自己的想法和改進意見,通過紅色卡片表示;

  • 投票表決:團隊成員每人5票,用綠色圓點表示,然後貼到紅色的卡片上,票數最多的紅色卡片就是比較好的建議。

溫馨提示:這個只是收集需求的一種方式,大家可以借鑑這種玩法,很有意思,當然我們也可以跳過需求收集,讓產品和業務方確定需求即可。

產品負責人根據 ShareSave 目前的“痛點”,結合團隊成員的意見,並結合運營和競品調研,輸出如下產品代辦列表。需要重點強調一點,為了更好滿足整個迭代的節奏,產品負責人需要整理出至少滿足2個迭代的需求,來保證整個專案的正常迭代開發。

產品負責人對產品代辦列表進行篩選,做減法提煉最核心的需求,在輸出產品需求表的過程中,產品負責人需要和專案負責人進行溝通,確保梳理的需求能基本滿足一個迭代,同時專案負責人也需要對需求進行初步的方案評估,包括業務邏輯和核心功能流程,如果發現有些需求的工作量比較大,需要對需求進行拆分和取捨。這個流程會比較長,可能會反覆幾次,最後就會輸出最終的產品需求表。

任務拆分&日常迭代

梳理完本次迭代的需求後,會舉行迭代會議,該迭代會議主要有3個主要事情:

  • 決定本迭代要做哪些需求,也就是 What To Do;

  • 將需求進行任務拆分,並將任務錄入 TB,每個任務需要明確責任人,也就是 How To Do,以及 Who To Do;

  • 對任務進行排期,確定任務是否有人力瓶頸,如果存在人力瓶頸,調整任務優先順序,將不緊急的列入下一個迭代。

迭代會結束後,大家將自己的任務寫入卡片,然後貼到任務看板上,任務看板,我們有如下3條規定:

  • 看板中任務進度的更新,全部通過團隊成員自己維護;

  • 通過每日站會,實時更新看板中的任務進度,並周知任務下游的同學;

  • RD 提測前,需要進行“冒煙自測”( DoD 之一),然後才能提測給 QA。

衝刺燃盡圖是 scrum 的精華之一,通過該圖表可以視覺化任務的時間進度,如果實線在虛線下面,表示任務完成度超前,如果實線在虛線上面,表示任務有延期風險。

每日站會是為整個團隊最有效的溝通方式,會議不超過 15 分鐘,需要回答以下 3 個問題:

  1. 你昨天做了什麼?

  2. 今天打算做什麼?

  3. 有沒遇到什麼困難?

驗收&總結

當迭代結束,且在產品正式交付前,需要全隊成員進行迭代評審,即對產品功能進行演示,然後團隊成員會充當使用者的角色,體驗本次迭代完成的所有的功能,並給出相關建議。

當迭代評審結束後,需要對本次迭代進行迭代回顧,為了避免會議過多,我們團隊每兩個迭代進行一次回顧,回顧時間一般 1 小時左右,本次分享的回顧方式為“海星迴顧”。

溫馨提示:總結回顧的方式很多種,“海星迴顧”是一種玩法,你也可以百度更多玩法。

“海星迴顧”是將一個平面區域劃分為5個象限,形狀類似於海星,包括以下5個方面的內容:

  • 繼續保持——團隊做的好,並且能從中發現價值的活動;

  • 少做一些——一些已經做了的,雖然能看到一些收穫,但是寧可少做一點的事;

  • 多做一些——一些已經做了的,而且已經被確信做的多就能帶來更大的收益的事;

  • 停止做——那些不能帶來收益,甚至更糟,正在阻礙團隊前進的事;

  • 開始做——一個全新的想法,或從其他地方看到,並且能幫助團隊的想法。

團隊成員以輪流發言的方式,將每個人的想法通過卡片的方式貼到對應的象限,大家對上述觀點進行投票(卡片上的小綠點),並選出核心的建議(卡片上的小紅點),最後由專案負責人總結並討論改進的地方,由大家一起給出問題的解決方案。

教你如何控制迭代節奏

如果一輪迭代完畢之後,再開始梳理第二輪迭代的需求,那麼第二輪迭代在進入開發前,估計還需要花費至少 3 天的時間去梳理需求、UI 互動以及方案評估等。目前我們的迭代週期為 2 周,為了解決兩個迭代的時間銜接問題,我們團隊制定了一套迭代日曆,全是大家摸索出來的:

  • 迭代第一週週二,開始開迭代計劃會,拆分需求,確認排期;

  • 迭代第二週週二,專案負責人需要提前評估下一輪迭代的需求,然後讓 UI 出互動設計、RD 評估設計方案;

  • 迭代第二週週五,專案負責人需要確定下一輪迭代需求的初步方案,便於在迭代計劃會時,能準確並快速進行任務拆分,提前規避風險;

  • 對於回顧會,為了儘量少打擾大家,我們是每 2 個迭代回顧一次。

通過這個迭代日曆,就可以回答最開始提的兩個問題,我們是在第二週進行方案設計,第三週週一就可以直接開迭代會,所以能完美銜接兩個迭代,且能避免沒有進行方案設計,就隨意給出專案排期的情況。

敏捷是萬金油麼

敏捷如果用好了,真的可以提高產研效率,擁抱變化、快速迭代,但是敏捷也不是萬金油,需要滿足天時地利人和,條件有些苛刻,下面是一些經驗之談:

  • 老闆大力支援:這個是一切的前提,比如我們之前是老闆大力推廣敏捷,全部門就能搞起來,後來老闆方向變了,敏捷就不搞了;

  • 專案能支援小步迭代:敏捷比較適合探索類的專案、或者是 APP 之類的迭代快的專案,因為需求非常容易變更、任務好拆分;如果是傳統專案,需求一開始就定好了,任務也不好拆,你就還是老實用瀑布模型吧;

  • 團隊成員閉環:敏捷的團隊成員,需要全部 follow 到該專案中,因為迭代節奏很快,任何一個人不可能再去搞別的專案,否則他會成為敏捷的瓶頸;

  • 團隊成員目標一致:因為迭代節奏非常快,所以產品、研發、測試和UI必須目標一致,如果有任何一位同學心不齊,敏捷也很難搞起來。

我理解的敏捷,更像是一把利刃,用好了能威力無比!但是這把利刃並不是所有人都用得好,也不是任何場景都需要這把利刃,很多時候,我們只需要一把菜刀。

寫在最後

如果要問我這 7 年的工作,哪段時光最讓我懷念,我肯定會告訴你,就是我帶領 ShareSave 團隊做敏捷的那段時光。

我們有一個非常優秀的產品經理(俊傑),一個非常細心的測試小姐姐(卓玲),一個對技術有強烈追求的 H5 前端(小瑞),一個對專案有超強責任心的 Android 小妹(亞楠),一個超讚的 UI 設計師(康康),我們不是為了做專案而做專案,而是發自內心的想把這個產品做好。有時大家都是產品、有時大家都會幫忙一起測試,大家目標如一,所向披靡!