顯示具有 Scrum教學 標籤的文章。 顯示所有文章
顯示具有 Scrum教學 標籤的文章。 顯示所有文章

9/02/2019

Scrum的缺點 (成為主管的31堂課)



當手上有榔頭,看到任何東西都像釘子 -- Abraham Maslow 1966
------

過去數年來Scrum明顯成為Agile軟體開發裡最常被討論跟使用的方法。

當然也有不少文章討論scrum的缺點(請參考這裡)。然而,Scrum是個在agile development範疇內的方法論,它是個很好的參考軟體開發流程的工具,而這工具有其「特性」,無所謂好與壞,當然就無所謂優點與缺點。

然而,這些特性不可否認,需要對該工具有一定的認知,特別是一些「預設要知道的事情」,以免誤用。舉例來說,當你使用榔頭的時候,大概會知道它是用來釘釘子,而不是拿來釘螺絲。此外,你也會大概猜到,右手拿榔頭左手扶著釘子時,要記得不要敲到自己的手指。

以下Scrum缺點(特性),也是常見的陷阱僅供參考。


(1) 團隊成員對Scrum的了解必須一致,工作能力最好也要差不多。


Scrum的運作中,高度依賴成員的自主性。Scrum Master雖然很重要,但僅在於Scrum本身的運作。對於任務完成的定義以及任務的品質,還是靠所有成員的能力。

換言之,如果有人技術能力特別糟糕,或者技術能力雖好,但對於Scrum的運用與瞭解和大家都不一樣,那麼有可能會有意想不到的長時間磨合期。


(2) Scrum並不會真正加快速度,只是讓速度透明,讓大家專注重要的事情。

許多企業導入scrum的目的是為了加速產出。事實上,Scrum並不會加快「某件事情的速度」。Scrum會讓事情變得透明,同時也讓團隊進行的速度變透明,讓大家更容易專注於正確的事情上。

整體來說,Scrum會減少各種不必要的浪費,讓整個專案效率提升,但就個別事情的速度而言,Scrum並不會提升。換言之,軟體工程師仍然需要有自己的方式來提升個人效率。


(3) Scrum並不會解決工作內容的相依性 


傳統的專案管理方法論,常常會提供類似甘特圖的工具。然而,Scrum方法論專注於某件任務(story)的完成,而隱含著希望每個任務的相依性,會在團隊成員的「成熟考慮」下被處理完成。

換言之,有相依性的工作就是有相依性的工作,軟體開發團隊還是必須要有自己的方式解決相依性。使用scrum並不表示相依性消失,也並不表示當有個寫得很獨立的story產出時,就一定會跟其他工作無關。這些都還是得靠團隊來處理。無論是使用Jira還是agilefant還是任何工具,都應該有自己的處理相依性的方式。


8/15/2018

Scrum: 三件不能少的事



Scrum是敏捷開發原則下,目前在軟體產業裡常見的方法論。而由於Scrum只是個方法論,並沒有所謂的標準,各個組織的應用方式皆有不同。常見的應用(practice),例如:spint-kick-off-meeting, daily standup, burn down chart, planning poker, retrospective。

零零總總的practice中,哪些最為重要當然眾說紛紜。考慮到Scrum的真正精神,以下三件事情是「最基本要有的」。也就說,如果這三件事情做不到,那麼其他事情做到也沒有用。


(1) 每個Sprint有交付具體產出


Scrum的Sprint都要有具體「可交付」的產出。sprint的開始,就應該以「結果」為計畫的導向,而此結果必須要是可交付的產出。

有些團隊會以Sprint長度不夠為理由,設定一個「並不能交付」的milestone作為該sprint的產出。如此一來會有幾個問題:(1) sprint結束的檢討,並不基於產出的事實 (2) kick-off下一個sprint的意義不大,因為前一個sprint並沒有真正可在市場衡量的產出 (3) PO會有充足的理由不參加demo以及下一個sprint的kick-off,畢竟這個sprint沒有有意義的產出,而如此一來PO就很容易不真正加入團隊。

Sprint不見得要固定長度,請參考這裡。 


(2) PO有確實加入Scrum團隊


Scrum團隊成員有三個角色,team member, scrum master, product owner。其中最容易不在的人,就是product owner。許多軟體開發團隊,product owner就是PM。但無論如何,Product owner必須要真實參與團隊。

所謂真實,指的是所有standup應該參加,在團隊運作過程,能夠回答該sprint的需求問題,並確實知道sprint中間「不應該做的事情」以及sprint開頭結尾「應該做的事情」

更重要的是PO加入團隊之後,DOD(definition of done)的標準才會具有「市場一致性」。舉例來說,不成熟的軟體研發人員常會對事情做完有不同的定義:
「程式寫完只是還沒review,所以還沒merge」
「程式寫完測試也沒問題,只是QA還沒通過」
「功能搞定了,QA也沒問題,只是還沒...」

PO確實加入後,可以讓事情做完的定義,統一在於「可準備交付到市場」。換言之,所有和程式設計相關的工作:測試,相關文件,環境設定,certificate等等都會以「可準備交付到市場」為原則。沒有這個原則,跑Scrum很難達到預計效果,要達到這個原則,最基本的就是PO需要確實投入團隊。


(3) 每個Sprint結束之後有確實地檢討(Retrospective meeting)


這世界上沒有完美的團隊,也沒有不用修正的軟體開發方法論。每個sprint的確實檢討,是修正團隊,讓團隊趨於一致的唯一方式,而非強加訴諸任何規矩。請參考這裡

確實的檢討並不容易,要做到兩件事情:
(a) 基於事實檢討   
(b) 不檢討不在場的人事物 


基於事實的檢討


檢討的內容必須基於事實,不是基於感覺與想像。感覺和想像的情況如下:
「我感覺好像有點慢」
「不知道怎麼講耶 但這個事情不應該這樣做」

事實的情況舉例如下:
「這個sprint我們沒有按照當時說好的DOD的定義,所以有XX與XX項目,本來說完成了,後來隔幾天又說沒完成」


不檢討不在場的人事物 


檢討確實是對事不對人,然而,事情都是人做的,不可能不檢討「人的做法」。不檢討「人的做法」只是鄉愿。

不過,要避免檢討不在場的人。
例如「因為UI/UX之前給的東西不正確,導致我們要重做某些事情」如果UI/UX是同一個scrum團隊,那麼檢討此項目當然可以。但要是不是同團隊就沒有意義。
因為,Scrum的檢討會議目的是產生「團隊要改善的項目」,而不是去讓非團隊的人改善。

Scrum的學習必然是從實際的經驗獲得,但經驗的獲得又必須從知識學習的取得為基礎,要成為看似不錯的Scrum專家不難,但要實際應用於專案中,並取得可重複成功的結果就不這麼容易了。





7/02/2016

如何學習Scrum


如何學習Scrum?

端看學習Scrum的真正目的,有三種方式可供參考:(1) 網路資源 (2) 收費課程 (3) 實際經驗


(1) 網路資源


很簡單,費用幾乎為零。

下載這兩個pdf,接下來,先不要上網查專有名詞,也暫先不要查字典,好好的先花時間看完。

* Scrum-institute 的 training pdf
* m-plaza 的 Scrum Guide pdf

然後,隨意上網找一些相關資料閱讀佐證即可。也可以自己做個類似這樣的簡單學習計畫

不確定自己有沒有學會?可以考慮花29美金考一下證照看看,請參考Scrum證照這篇

假如是剛畢業的大學碩士學生,英文閱讀沒有太大障礙的話,大概8-16小時應該可以完成。


(2) 收費課程 <- 不推薦


也很簡單,但是要花錢,大概7,000~20,000不等。


在google搜尋[scrum 認證課程],出現起碼5個不同的教育機構,其價格從7,000到20,000台幣不等,時間通常大約是2整天左右。衡量自己的時間和財務狀況,挑選離家近的參加即可。

這類型的收費課程通常會協助考取證照。在此並不推薦這個方式考取非技術專業之證照。

(3) 實際經驗


非常難!要花的成本看起來很高,不過他通常伴隨工作經驗的成長。

(a)基本作法:


首先必須要先參與開發團隊一陣子,在此期間必須要先用方法(1) 網路資源。用以了解Scrum的基本精神。

然後,只要運氣不要太差,加上自己的努力,有朝一日會變成專案經理,或者是團隊領導者的角色。接下來,由於自己已經擔任領導者角色,就在自己領導的團隊中,以務實的方式執行Scrum。其中一定會遇到阻礙,每當你碾平一個障礙,就更多一層對務實的認識。

基本作法其實也是最佳作法,如果是一個已經有足夠技術背景的人,而有意識的朝這個方向前進,在台灣大概3-5年就可以有很好的成果。


(b) 突破性作法:

和所有專案管理技能一樣,當不能付諸現實的時候,技能的本身就沒有意義。就像籃球教練沒有籃球隊可以教,沒有籃球比賽可以參與的時候,籃球教練等於沒有付諸實踐的意義。

要有突破性作法的原因在於:

* 企業組織長久以來沒有真正agile的精神
* 在創新小公司任職,架構混亂,以完成事情為優先
* 自己並不是團隊領導,但希望能改變團隊
* 剛畢業,沒有領導管理經驗
* ...


然而,在這些外在因素不利的情況下,如何有Scrum實際經驗?(突破性方式的概念可參考這篇。)

簡要的說,自己起頭一個專案,無論是跨界虛擬專案,還是開源(open source)專案,還是到便宜的外包市場找南亞工程師加入的專案。當自己開啟專案時,自然就可以確定,如果要採行Scrum,不可能會有其他外界因素,所有成功與否的因素都在於自己。當然也是靠自己來碾平困難。

一旦個人的能力提昇,自然就越能貢獻現在的團隊,現在的組織,更容易體會團隊合作的可貴。