/ 程式

身為軟體工程師 跑 Scrum 時需要注意的二三事

Scrum 這個專案管理的原則,近年來相當火紅,怎麼運作就不再多作介紹了,去 google 就有一大堆相當專業的評論。

如果你要繼續讀下去,希望你對 Scrum 是有基本了解的。但假使你有點懶得,也可以參考下面這張圖,希望能讓你 30 秒了解 Scrum 想要達到什麼。

scrumInOnePic

基本上 Scrum 想讓團隊能夠把重心放在開發出第一版非常破爛的原型,業界稱作 POC (Proof of Concept)。對老闆或投資人來說,他們希望能看到一個「好像能賺錢的東西」,所以破爛沒關係,達到目的就好。

過了第一關之後,應該就能關關難過關關過,再不斷針對細節作 refactor。

接下來,就是管理的事了。

所以簡單說 Scrum,有三個重點:

  • 團隊的重心
  • 潦草但有力的願景
  • 管理

你為何要讀這篇?

大部分坊間的說明都是從營運者的角度切入,再不然是在說服管理階層:這樣的方式有什麼好處。從底層團隊成員作為出發點的介紹比較少。

另一方面,Scrum 的哲學非常強調團隊成員間的同步(sync up),如果 PO(Project Owner)和成員間沒有達成一定共識,造成某一方遷就一方,就容易造成運作上發生問題。

所以如果你是管理方面的人員,了解從工程師角度在運作 Scrum 會產生的問題,在協調團隊內部的協同時就比較容易找出共識。

如果你是軟體工程師,避免掉下面提到的這些小問題,或是試著採用一些原則,你會讓團隊運作的更順暢。

我不是 scrum 專家,只是想聊聊在這樣的遊戲規則下,擔任一顆齒輪之後,一些小小的心得。

好,我們開始吧:

了解你的專案前提

上面舉的開發全新產品的例子,只是團隊的某一種模式而已。事實上,軟體專案有各種不同的性質,除了上面提的開發之外,一個 scrum 團隊也有可能主要是在作維護的工作,這個時候,Scrum 的策略就會比較偏向求穩,而不是求突破。

當然,這件事就交給 PO 來擔心就好,但即使身為工程師,了解專案的性質是必要的。

除此之外,專案主軸也是要考慮的前提之一,有的專案是要作出一個給 end user 的產品,例如:一個線上糾共乘的服務;有些則是著重在開發技術面的東西,例如:人聲辨識功能,有資料庫並提供 sdk 或 api 供串接。

這兩種類型的專案,在運作時所圍繞的重心會有所不同。所以當在 planning 時要發表意見時,或是在決定 story 的主題之前,記得先問問自己:「現在 Scrum 團隊在處理的專案,是怎麼樣的一個性質」。

不要把 backlog 當作你自己的記事本

有需要處理的事情,立馬開張票記下來。一來方便自己追蹤,二來團隊成員也可以知道自己接下來會做的事。

乍看之下很合理,事實上大錯特錯!!

backlog 是以專案的角度出發,來看還有多少事情要作,並不是用來看這個團隊裡的哪個人要作多少事。所以 backlog 只會是跟產品面向有關,或者實作及驗證是不同兩方的票。

這樣子有人會問,這樣怎麼追蹤團隊中個人的進度呢??靠的是 Daily standup。

dailyStandup

Daily standup 時,每個人主要講述三件事:

昨天做了什麼?今天打算作什麼?有什麼需要跟其他成員協調或告知的事情?

很神奇的,如果每天花一分鐘從嘴巴講出上述三件事,自然而然會對工作進度更加的嚴謹。這也難怪,如果你是個守信用的人,假設晚上發現明天 daily standup 時無法做到今天所說要做的事,那在明天報告前是拚死也要趕出來的。

也因為這是每天進行的,所以每個成員的工作情況是可以共同掌握的。既然這樣,還需要用 backlog 來追蹤工作進度嗎?

完成階段性目標,而不是做了多少事

有開過車嗎?當你坐上駕駛座,準備用導航的時候,你會輸入的是「要去的目的地」,而不是我「準備要開幾公里」吧?

所以重點是對這個專案做到了什麼,而不是我花了多少努力在上面

另一個要強調的部分是「階段性」。

Scrum 就是希望每個 sprint 都有明確的階段性目標,這個目標也是所有團隊成員需要共同了解的。

那為了達成這個目標,一個 sprint 之間,團隊成員做了多少事?說真的,如果我是 PO,我一點都不在乎。

正確的 Demo

除了 daily standup,整個團隊間可以共同溝通的另一個時機是在 sprint review / demo 的時候。

在團隊目標為新創產品的情況下,成員的屬性會相當多元。以前端工程師來說,就可能會跟包括 UX、後端及行銷的部分界接。甚至,前端自己本身譬如 web 及 mobile 間也會有要串接的情況。

所以在 demo 的時候,必須要很清楚是知道:「這個 demo 是要給誰看的!

findUAndDemo

舉個例子:這個 sprint,前端工程師根據 UX 人員的設計,定義了埋 log 的機制,在 demo 時,就一定要針對 UX 人員作 demo,確定對方有了解實作的結果。

這說明了在定義 story 時,有個推薦的模版:

"As a XXX, I want A to do YYY"

你如果是 "A" 的話,上面的 "XXX",就是你 demo 時該傳達的對象。把上面的例子套進去就會是這樣:

"As a UX designer, I want Client to record user event"

所以 client 做了 record user event 之後,要向 UX designer 報告。

埋 log 這件事,跟後端也有關係,因為前端的資料會往後送;行銷人員更是在意,因為是他們是這個功能的終極使用者。所以爾後會有兩個 story:

"As a Client, I want Backend to record user event"

"As a Marketing Guy, I want to see user event records"

所以當 backend 實作完後,就要向 client 這邊作 demo。而行銷人員這邊,是 end to end 的情況,算是一個全盤驗收。

試著釐清你該 demo 的對象吧!如果你抱持著這種想法:「我 demo 的東西,就是全團隊都需要知道的」。相信我,這只會讓你的 demo 毫無重點。

善用你 Repo 的 Readme 及 issue 系統

身為工程師,在實作 PO 開出來的需求之前,常常需要先作一些 survey 或者額外花時間開發會用到的 library。類似這樣相當技術性的東西需要被紀錄時,該怎麼作呢?

先想想什麼情況這些技術性的東西會被用到?

就是在其他人需要用到這項技術的時候啊!(這句好像廢話 lol)

相較於 Scrum 的 issue 是以專案為主軸,技術方面的主軸就是以技術本身為主,這種情況,issue 不開在 repo 上面怎麼說得過去?

當需要這項技術的人要來 clone repository 的時候,可以看 readme 或者透過歷史 issue 來了解這項技術的演進過程。這個時候你叫他回去翻 JIRA(註一) issue?

Imgur
Imgur

當然你想要在 JIRA 上紀錄你作過這件事也是可以,但請先確定你 repository 上的 readme 其他人也看得懂!

在管理別人之前,先學會服從

越好的團隊,就會搭配更好的工程師。所謂「能力越強,自尊越高」,優秀的工程師,通常都是自負到你會有點想一拳灌下去這樣。

所以如果你是如同頂級球員或當紅藝人的工程師,那 PO 就會是領隊的教練或是經紀人。

當然有領導魅力的 PO 會讓事情進行的更順利,但換個角度,好配合的成員也是讓事情事半功倍的要素之一。

一般的工程師,是沒有上面形容的那麼誇張,但多少還是對自己有一定的自信,不然怎麼能寫出洋洋灑灑一大堆程式碼呢?

但想像一下你是交響樂團裡的一名樂手,而且你技藝高超,樂團指定你作 solo,但無論如何,當你在演奏的時候,脫拍或即興是絕對不被允許的。(所以我還是比較喜愛爵士多些

為什麼?

因為樂團要做的就是照指揮的意思來詮釋曲目,如果你有自己的想法的話,當你是指揮時愛怎麼表現都行。

雖然說當個好樂手和成為指揮不是正相關,但是明確知道你在團隊中扮演的角色,絕對是讓你成為好團員的關鍵,而日後有機會成為管理層級的人的話,也比較懂得過來人的辛苦。

我們是 Scrum TEAM

最後用這段 Netflix 在員工教育訓練中的一頁來作結:

We are not a family, we are more like a pro sport team.

netflixWords
(不好意思是簡體的)

註一:JIRA 是由 Atlassian 公司所出的 issue tracking 系統。基本上,已經是 issue tracking system 的同義詞。
身為軟體工程師 跑 Scrum 時需要注意的二三事
Share this