再談 Scrum But

為何再談 Scrum But 呢?

雖然只是一個反面的字眼,但實在有它的重要性存在! 如果再給我一次顧問相同團隊的機會,我一定不會讓他們把 Scrum But 當成只是拿來博君一笑的不重要話題,因為"檢討“在我們累積經驗的過程中佔著重要的比例。 下面有一些自我提醒,團隊可以拿來檢討及測試自己 Scrum But 的程度,非常適合 Scrum 團隊拿來做自我檢視時採用,請參考:

(無招勝有招。你所遭遇到的情況可能跟下面所說的不見得相同,所以這些個教條僅供參考)

 

※ 如果在站立會議的時候,團隊成員分別向 ScrumMaster 報告自己的狀態,請留意貴團隊執行的可能是 Scrum But.

在 Scrum中,團隊不是為 ScrumMaster在工作;相反的ScrumMaster是為團隊工作。

好的Scrum Master會立刻提醒團隊應該向大家報告才是,

但也會默默記住那些人需要做敏捷程度的提升。

※ 如果你的開發人員不斷超越測試人員的進度,你可能是 Scrum But.

在一個 Sprint中,團隊自我管理並對工作共同負責,讓他們相互超越是正向的競爭

會提升戰力,但只有在流程順暢協調下

才能在短時間內達成任務。

※ 如果你的開發團隊沒有進行應該有的文件製作,甚至缺少文件製作,你可能是 Scrum But.

很多人誤解 Scrum甚至認為敏捷開發是不用製作文件的,這是嚴重的誤解,

請參考一下《 實例化需求》

※ 如果你的 Sprint Demo 會議失敗了,你可能是 Scrum But.

 雖然失敗乃兵家常事,團隊不可能每次demo都成功的不得了,

但ScrumMaster的職責就是要協助團隊盡早發現問題

避免這種在客戶面前的失敗。

※ 如果你的團隊成員都不敢嘗試新的想法,因為他們害怕可能會失敗,你可能是 Scrum But.

程式設計本來就是一種經驗主義,在嘗試與失敗中成長是在所難免的。

失敗是累積經驗的必經過程。

 ※ 如果你的回顧會議開成了對人不對事的情形,你可能是 Scrum But.

回顧會議應該著眼於你的工作以及團隊如何在一起協同合作的方式,

要經常思考如何善用工具它來達成你的任務才是。

※ 如果你堅持先將所有的使用者需求都先詳細的定義清楚,再來開始你的第一個Sprint,你可能是 Scrum But.

傳統的開發方式總是習慣把需求都搞清楚了才開工,

但現在的開發團隊都知道需求必須隨著市場的異動而改變,

只是有些老闆或主管還是有這種不知道是該稱讚還是該罵的習慣。

※ 如果你經常堅持於維持原來的發布計劃而不做變通,你可能是 Scrum But.

Scrum 是一種經驗主義,有很多時候我們會以一種嘗試看看的心態來進行開發作業,

所以變通是一種不可或缺的屬性。

※ 如果你將數據指標看得比表現得優異更重的話,你可能是 Scrum But.

在執行Scrum的時候我們經常可以收集到許多的數據,不論是burndown 或是

CFD圖都有著大量的數據可以做參考,但請務必堅守它只是做參考的原則。

※ 如果你凡事都要通過管理階層來做決定的話,你可能是 Scrum But.

Scrum 團隊必須是一個能夠自我管理的團隊,

也只有經由這種自我管理所產生的責任感才可能,

才能讓團隊進取而主動。

※ 如果你依據成員的角色,主動指派工做事項給團隊的成員,你可能是 Scrum But.

Scrum 的團隊是自我組織的,團隊成員會因為他們有能力這麼做,

而自動做出貢獻,不應該由任何人所指派。

※ 如果您對 Scrum團隊教條式的使用以上所列的這些個項目來制定規則的話,你可能是 Scrum But.

敏捷的有效來自於遵循它的原則,而 Scrum則是關於實施這些原則的精實框架。

上面所列出來的項目只是用來強調這些原則用的。拿來當作規則,

強制採用它,就完全不符合敏捷的精神了。

只有持續追求改善才是最佳做法。

唯有堅守目標、持續改進,才能發揮Scrum克服複雜專案的功能

我們很難做到百分之百的 Scrum 開發,或許做到七成或許是八成,但這不是重點,真正最重要的是持續改進

Scrum 團隊的一個共同目標是,讓整個團隊在 Sprint之內完成所承諾要完成的工作項目。也就是;採用漸進式累積的方式來完成任務,不是一次決生死的傳統、都預先計畫好了的工作方式。我們都曉得寫程式是一種學習的過程,而團隊開發本身也是一種團隊的學習模式,必需透過不斷的演進讓團隊越做越好,越能適應專案的變化,就越能提供給客戶市場上真正的需求。

(參考自 You May Be a Scrum-But )

Scrum But …

如果你在執行Scrum 但却因為某些因素而必須放棄或違背部份 Scrum 的準則時,就稱之為: Scrum but.

(Scrum 的發明人之一Ken Schwaber 的說法是: Scrum … but…, 他同時在 scrum.org 網站上談到如何處理這種情況。)

反對者: 敏捷開發堅持不要 Scrum but
當開發團隊採用一種來"半套的方式“,不去採用敏捷開發法的一些準則,則結果非常可能是得不到敏捷的效果,反而造成專案開發失敗是很有可能的事情。因此呼籲想要採用敏捷開發的團隊,一旦你決定採用某種開發法時(例如: Scrum)就請務必依照他的準則來實行,否則很容易招致失敗。這並不是該方法無效,而是你沒有按步就班的去執行它,自然就容易失敗了(聽起來好像蠻合情合理的)。

※ 這是一個充滿爭議的話題!如果一定要按步就班的堅守原則的話,又好像違背了敏捷的初衷? 失去敏捷所謂的高適應性了。(透明化、檢驗、適應性是 Scrum 的三個支柱 Three pillars)

 .

因此有了另一派說詞的誕生

實在是因為某種原因,促使我們必須放棄某些有用的角色、規範或方法。而尋求其他的解決之道,當然,有時候只是一種短暫的措施,隨後會盡快的回復到正常的開發方式。所以就有了:

ScrumBut 的專有語法:  

(ScrumBut)  (Reason)  (Workaround)

範例:

»  (We use Scrum, but)  (having a Daily Scrum every day is too much overhead,)  (so we only have one per week.)

»  (我們使用Scrum,但是) (回顧會議實在太浪費時間了,) (所以我們每二個Sprint 才會進行一次。)

»  (我們使用Scrum,但是) (我們的功能實在太大需要較多的開發時間來建立,) (所以我們每個Sprint 長達六周。)

 »  (我們使用Scrum,但是) (我們的專案實在太大需要很多的開發人員,) (所以我們有一個20人的Scrum團隊。)

.

我們使用 Scrum,也修改了Scrum (ScrumButs and Modifying Scrum)

Scrum.org 是少數敏捷開發法中願意主動來面對這個充滿爭議的論點。

由大處著眼來看待他的話;由於軟體開發沒有銀子彈存在,因此也當然沒有放諸四海皆準的開發方法,對於個別的軟體開發方法,實在沒有必要削足適履勉強照單全收的道理。

由小處著手來看待他的話;每一種軟體開發方法都有他一定的組成元素與架構,務必要相互搭配才會有它的效益產生,任意去改變組合當然會壞了他的效用,若是因此而招致失敗,自然不在話下。

.

敏捷開發是經驗主義

所謂的經驗主義也就是依照所觀察到的現象來做為分析的依據。 必須通過實驗研究而後才去進行理論推導。因此經驗在這裡就顯得十分的可貴,這也正是所有的敏捷開發法幾乎都做持續改進的原因,因為他們都是從一次又一次的過程中得到回饋,再來進行修正吸取經驗,然後再以此為依據進行持續改善的。

所以每做一次便可以得到一次的經驗,以這個觀點來看上面的爭執,便可以發現其實二者沒有太大的差別,只要「做一次便知道了」,重點是要會吸取經驗再做修正。當遇到非改不可的情境時,就改一次來試試看啊! 結果自然會告訴我們是對與錯。然後再來修正就是了。若是不敢嘗試才是不敏捷的做法。但若是遇到不能反覆的環境怎麼辦呢? 遇到只能嘗試一次的情境時,怎麼辦呢! 我會建議先對環境做出改變,讓他具有執行敏捷開發的基礎再來嘗試吧!

小規模的漸進式改善模式,一直是敏捷開發藉以取得回饋再作改進的方法(也是一種機會),是基於勇敢果決的精神,用來迅速累積經驗的做法。說得簡單了,如果你還有疑惑的話,請參考 Mike Cohn 的《 Scrum 敏捷軟件開發》,類似的敏捷觀念充徹全書。是我每次遇到瓶頸時就去翻閱的圖書,推薦給大家。

.

持續追求

在教室之外,便要面臨真實世界的挑戰,理論跟實際要做起來還真不是那麼回事兒。有空的時候,去執行一下 ScrumButt 的測試,他會在結尾時給你一個分數,然後告訴你平均值是 51分,請你參考。Run個二、三回試試看你能拿到幾分,分數的意義當然不大,但一旁的百分比才比較有意義,他透露出來一般的平均值,試著看看字自己在哪一個區間,回顧一下,還挺有意思的。

scrumButt

.

這種測試當然不會很準確,但我們都知道它的意義,就是要提醒我們去持續追求理想。

.