top of page
Writer's pictureChungan Ke 柳丁

Sprint Review 是個驗收的場合?

Updated: Mar 2, 2023

分享一個業界對於敏捷(Scrum)的架構中,所謂 Sprint Review 的最大迷思:

就是 Sprint Review 是拿來做 Acceptance 的場合。


2004年的 Scrum Rules(由 Ken Schwaber 撰寫的《Agile Project Management with Scrum - ISBN: 073561993X 》)裡面只有一個觀念是跟現在的新講法(2010年之後)完全不同:

Sprint Review 時,是由 Dev Team 來主導,面對 Product OwnerStakeholders 展示當期 Sprint 所產出的 Increment,來尋求回饋與對話。他清楚明白的表示,進入 Spint Review 前,要展示的東西已經 Done (而不是來這個會議決定是否 Done )



Ken Schwaber 是敏捷(Scrum)的兩個發明人之一,在2012年出版另外一本非常暢銷的

《Essential Scrum - ISBN: 0137043295備註一 》中,Chapter 第 21 章有詳細且清楚的解釋 Sprint Review 在做什麼,Sprint Review 就是請關係人來看團隊已經完成的 Increment

,而不是用這個會議決定是否 Done、是否 Accept。


備註一:這本書是由 Mike Cohn 與 Ron Jeffries 背書的。Mike Cohn 是敏捷(Scrum)的代表人物,Ron Jeffries 是 Extreme Programming 的元老。



在2013年由 Ken SchwaberJeff Sutherland 兩位敏捷(Scrum)發明人寫的,最新版本 Scrum Guide 備註二裡,也提到 Sprint Review ,寫的非常言簡意賅:

The Scrum Team and stakeholders collaborate about what was DONE in the Sprint. (在此時,團隊展示已經在 Sprint 中“完成”的 Increment)

備註二:關於最新版本的 Scrum Guide 歷史淵源,是由三大敏捷(Scrum)組織於2014年8月共同決議,最高指導原則的Guide。三個組織分別是:Scrum Alliance、Scrum.Inc,以及Scrum.org



Jeff Sutherland(Scrum的發明人之一)在自己的公司(Scrum.Inc) ,發表過一個針對 Sprint Review 的簡報與說明(原文:https://www.scruminc.com/sprint-review/),

文中提到 Sprint Review 的精神:

If the software isn't tested and working, then its not possible to start this important feedback loop. (這個 feedback loop 就是指 Sprint Review )

前段時間我個人在上 Certified ScrumMaster 的課程時,與 Vernon Steinbaker 老師(講師簡介:https://www.scrumalliance.org/community/profile/vstinebaker中午一起用餐,也聊到這個話題。Vernon 老師分享到:功能特性並非等到 Sprint Review 來測試。Product Owner 因為要保持 Available to the team(每天至少三小時),所以任何Backlog Item 一旦可以交付做 Acceptance Test ,確認是否搞定後,應該隨時可以執行,Product Owner 應該要主導的。


另外,另一本平民暢銷書籍《Agile Project Management for Dummies - ISBN: 1118026241》中,有特別記錄一段話來提醒 Sprint Review 之前要注意的事項:

By the time you get to the Sprint Review, the Product Owner HAS ALREADY SEEN the functionality for each of the user stories and HAS AGREED that they’re COMPLETE.


總結:

針對「誰主導 Sprint Review ?誰是觀眾?」,過時的觀念裡面把 PO 放在觀眾中,Dev Team 主導這個Event,而現在真正的說法是:PO 要來主導,與 Dev Team 一起面對利害關係人


至於「Demo時拿來驗收」這個概念,是誤會了敏捷(Scrum)的基本精神,且展現了傳統瀑布理論的封建思想遺毒。


這個誤解導致實務上會遇到的壞處,分析如下:
  1. 豬(Pigs)內部造成對立,緊張態勢升高,出包時互相指責,團隊 Chemistry 被打破。一旦demo時功能沒通過測試(因為根本事先沒看過測過驗收過),PO 與 Dev Team 會成為敵人,距離拉開,這將違背 The Whole Team 的概念。

  2. Collaboration 效率大幅打折,PO 與 Dev Team 在其他利害關係人前面,原本是希望利害關係人藉此對 Increment 做回饋,卻變成了雙方的表演溝通大戰,攻防戲碼,而達成的adaptation的機率與效應也將大幅滑落。

  3. 及時提早修正的契機消失。失去原本在 Sprint 中,Dev Team 與 PO 針對產品發展方向的互動機會,同時導致無法立即驗收 Increment ,重工的機率因此大幅增加。

  4. 沒有 PO 認可的accept進度,全部成為了自high。Sprint Burndown Chart 不到 Review 時被認可的話,上面標註的數據隨時可能要重來,Velocity 便隨時有 Fluctuation 的大變動。


如果把這個場合當作是:給 PO 藉由看利害關係人對於產品的反應,來對 Stories 做accept與reject的決定,那便是完全忽略了 PO 當責的概念,也打破了 One Team 的基礎(瀑布思維封建遺毒)。這裡是給利害關係人對於已經 Done 且accepted的 Increment 一個機會,來做回饋(Feedback),讓敏捷團隊(Scrum Team)調整步伐確認方向用的。這裡是 Elicit Feedback ,所以可以 Inspect and adapt ;而不是用來 Inspect and accept。


文章同步刊登於:台灣敏捷部落臉書社群

Recent Posts

See All
bottom of page