之前和朋友談天, 他說在執行 Scrum 時遇到一些困難, 讓他覺得 Scrum 似乎並不是那麼美好. 讓我們來看看他遇到了什麼困境:
1. 基本消費額太高
在每個 sprint 中, Scrum 要進行 planning meeting, daily standup meeting, review meeting 和 retrospective, 很多人在抱怨都一直在開會, 2 周的 iteration 其實不是兩周, 可能只剩下 7-8 天而已. 如果再加上要參加別人的 review, 或是公司的會議, 那其實沒有多少時間在工作上面.
在實施 Scrum 時, 最常遇到的一個狀況, 就是忽然說有急件, 希望團隊可以趕快處理.
根據 Scrum 的定義, 在 iteration 中途, 是不能再加功能, 也不能變更iteration 的長短.
最近選舉到了, 都是一堆候選人的新聞. 其中看到有人在 FB 上 po 某個候選人所的話, 他提到了, 施政必須重視使用者經驗. 也就是任何政策的制定, 應以方便民眾使用或方便民間部門做事為出發點, 而非方便政府管理或方便公務員好做事
先不管這個候選人怎樣, 但是我想到的是, 這個情況不只在公家單位有這樣的思維, 我們自己開發產品, 或是在推廣敏捷時, 是不是也犯了同樣的問題.
有些人提到, 為什麼大家執行 Scrum 感覺起來差這麼多? 這是一個很有趣的問題.
首先, 先跟大家澄清, Scrum 只是個 framework, 因為在這個 framework 下你可以選擇自己的實施方式.
例如: Scrum 要求要有 product backlog, 並且裡面的需求要照優先順序排好. 這些是 Scrum 要求的. 但是他並沒有說 product backlog 要怎麼寫, 你可以用 SRS, use case 或者 user story, 只要你排好優先順序, 並且可以在一個 iteration 內完成. 我想就可以了.
有人常問說, 如何檢查到底 scrum 到底有多深入, 這裡有份簡單的檢查清單
1. 我們有產品負責人,scrummaster和開發團隊嗎？
2. 我們有排好順序的產品需求清單嗎?
在進行 scrum 時, 有一個常見困擾大家的問題, 就是什麼叫做一個功能已經完成. 如果不是真的做完, 或者做完的結果並不是讓人滿意, 我們需要早點知道, 以做出因應的事情.
那我們會怎麼處理呢? 常見的做法如下:
在 Scrum 中有個 review meeting, 是在 sprint 最後時舉行, 在這個會議中通常要進行 demo, 來展示所完成的功能. 可是有些人發現即使 demo 完後, 產品還是無法 release, 這是怎麼回事?
個人覺得 review meeting 的作用應該是以下事情
1. 檢視功能是否客戶要的
昨天在 Lean Coffee 聚會時, 有人問到當 sprint 時間要到, 可是 story 還沒做完, 是否要結束. 這是一個很好的問題, 因為這是一開始執行 scrum 的團隊, 必定會遭遇的問題, 即使是很有經驗的團隊也會碰到.
首先, 我們先來看如果延長會有什麼問題:
1. 有可能不知道什麼時候會結束
scrum 最大的問題，是無法在iteration 內徹底完成預計完成的功能。
大多以為程式寫完就好，可是往往無法通過測試，需要花大量時間在修復bug,或是重工來處理誤解或遺漏的功能。無法儘可能的一次到位。
因此如何讓在開發時, 就能寫出正確的程式碼，和符合客戶需求的功能，是團隊改進的主要方向。
站立會議的時間?
在 SCRUM 中站立會議是, 每天同步資訊和及時解決問題不可或缺的元素. 因此你需要固定好開會時間, 開會的地點, 以方便會議的進行, 和讓大家養成習慣.
通常書上或是blog上, 會說這會議的時間最後在早上, 也就是一天開始的時候. 這時候大家來談昨天做了甚麼, 今天要做甚麼, 以及遭遇了什麼問題, 會是有意義的, 因為時機點和這三個問題是相配合的. 因此我也對此不成文的規定, 堅定不移.
可是隨著所帶領的專案越多, 或者說遭遇更多不同的團隊後, 覺得一早開站立會議似乎不見得都適用.
在台灣很多高科技公司是責任制, 也就是可能上班不用打卡, 可是可能要做到半夜. 對於這樣的團隊, 若是你還規定 9 點或是 9 點半開站立會議, 似乎對於團隊士氣是種打擊. 也許站在專案經理的角度, 你想要求團隊成員有較長的工作時間, 並且加上Scrum 站立會議問題和時間的搭配性, 因此你可能會堅持在這個時候開會.
隨著時間的轉移, 越來越體會到士氣高昂的團隊, 和有品質的工作時間, 是遠遠比一早開會還重要.
回顧會議的重要性 (The importance of retrospectve meeting)
上週五, 我們團隊招開了第一次回顧會議, 個人覺得效果很好, 把平時沒說的話都說了出來, 或許不見得沒有保留, 但至少跨出了第一步.
你可能會很驚訝, 為何會是第一次? Scrum不是每次sprint完後都要舉行一次回顧會議?
是的. 這是目前我們的困境. 我們專案是由兩個小組所組成, 平時溝通並不是很密切, 兩個小組在不同樓層, 不同的軟體開發流程(一個waterfall like, 一個scrum like), 不完全相同的老闆, 因此彼此累積了不少問題.
很多時候我們都急著想要去交付東西, 急著趕上進度, 可是卻沒有時間思考. 沒時間問問自己, 做這些事情有幫助我們的產品大賣嗎? 那些是顧客要的嗎? 或者如何驗證那些是客戶要的?
甚麼時候不適合使用scrum
When Not to Use Scrum
http://www.scrumcrazy.com/When+Not+to+Use+Scrum
author: Charles Bradley
很多人常常問我, 甚麼狀況下不適合使用scrum. 因為很多人認為他們的project, 適不適合使用scrum的.
組織影響學習結果
最近在看蕭老師所寫的"讓脈絡思考創新"一書, 其中有一段話讓我感觸深刻.
他提到在分析脈絡時, 要考量組織的作為. 因為組織的所發展出來的運行原則, 會影響創新運行的有效性.
就像武俠小說中的屠龍刀, 一般人拿到只能耍耍花槍, 只是一把鈍兵器. 當武林高手拿到後, 應用他原先的內功或招式, 才能變成一把真正的寶刀.
拿到推行 scrum 這件事情上面, 也有同樣的結果.
目前台灣有那些Scrum的教育訓練課程
小弟特地上網查了一下, 發現目前在台灣, 對於Scrum or Agile的相關訓練, 還真是少的可憐.
1.XP/Agile敏捷式開發實作班
小弟開的課程.
http://www.iiiedu.org.tw/ites/AgileXP.htm
Ken Schwaber 和 Jeff Sutherland對Scrum Guide的修正
Ken Schwaber and Jeff Sutherland Release Updated Scrum Guide
http://www.infoq.com/news/2011/07/UpdatedScrumGuide
Ken Schwaber 和 Jeff Sutherland 在2010二月時, 對Scrum Guide 做了一些更新, 它是一份獨立的檔案, 並沒有整合到原先的 Scrum Guide.
在這分文件中, 提到有些改變很有趣:
