Contents
  1. 1. Agile 是什麼?
  2. 2. Scrum 是什麼?
    1. 2.1. Scrum流程
    2. 2.2. Scrum角色
    3. 2.3. Scrum product
    4. 2.4. Scrum meetings
  3. 3. Workshop活動
  4. 4. 心得

3/12參加了Girls in Tech——Taiwan舉辦,Agile Community in Taiwan協辦的Agile & Scrum workshop,這活動主要是透過Paper Prototyping Game來認識Agile,體驗Scrum的開發過程,講者是Jonathan Chen。本篇文章主要記錄自己學習Scrum的筆記(從軟體工程的角度,只會講到簡單的概念),及參加workshop發生的事情及心得。

Agile 是什麼?

我想先談談軟體工程的目的,其實就是希望在有限的時間及成本內,開發出有價值的軟體,其中包含的重點:

    1. 將產品做對 : 開發出真正符合user需求的產品
    2. 將品質做好 : 開發出讓user滿意的產品(包含好用的介面、架構等)
而所使用到的相關知識與技術這裡不討論,這邊只講比較大範圍的概念——軟體開發流程。


軟體開發流程 (又稱軟體開發方法或生命週期)是:「一個產品從起始到完成,如何被進行計畫的模型。」。
模型有很多種,以往最常見的是瀑布式,它的概念是強調開發過程需要有完整的規劃、分析、設計、測試及文件等管理與控制,來確保開發出有價值的軟體,它適用於需求明確的專案。但是問題在於,客戶通常自己也不清楚明確的需求是什麼,所以需求常常一變再變,導致開發成本增加。

Agile開發方法,目的一樣是希望開發出有價值的軟體,但與以往不同的是強調「擁抱改變及迅速的反應改變」,它的價值觀包含以下四點( “>” 是代表,__的重要性大於__):

    1. 個人價值與團隊良好的互動 > 開發流程與工具
開發流程(指引開發的步驟)、開發工具(協助開發工作)皆有助於開發出有價值的軟體,然而成功最關鍵的還是團隊良好的溝通合作,及團隊各成員發揮個人專長及價值。
    2. 可使用的軟體 > 詳細的文件
文件訂得再詳細,但系統錯誤百出的話,開發出來的軟體還是沒有價值。
    3. 與客戶(使用者)合作 > 契約協商
契約訂得再詳細,可能還是會有沒想到或考慮(定義)不清楚的部分,密切的與客戶溝通合作,才能開發出有價值的軟體
    4. 迅速的反應改變 > 跟隨計畫

事前做好開發計畫是必要的,但也要理解需求是會改變的,需求改變很正常,當需求改變時,就要接受改變並提出相對的反應,而不是一昧的按照原計劃執行。

Scrum 是什麼?

Scrum是實現Agile的一種方法架構(所以還有其他不同的實現方法),它強調的概念有:

    1. 提早開始 : 提早做軟體測試、提早驗收測試劇本,這樣也較能提早發現軟體開發中的問題。
    2. 頻繁遞送產出 : 只要做出一部分的產品,就送給客戶或user檢視,充分溝通,確保掌握客戶的需求。
    3. 反覆評估目標 : 不斷的評估產出是否有達到預定的目標,這樣能提早發現問題,及時解決,也能據此發現開發流程的問題,促進改善。
    4. 反覆確認滿意度 : 在送出部分產品給客戶檢視的同時,不斷的與客戶確認滿意度,才能確保開發出有價值的軟體

以下針對Agile的四點價值觀去說明Scrum實現的方式,會先簡略描述項目,再簡單介紹各個部分:

    1. 個人價值與團隊良好的互動 : 個人價值的部分,Scrum定義了Scrum角色(及其負責的工作),而在團隊良好互動這方面,Scrum有會議機制稱Scrum meetings
Scrum角色分成四種 : 客戶、產品擁有者(Product Owner)、Scrum Master、開發團隊成員
Scrum meetings也分成四種 : Sprint planning、Daily Scrum、Sprint review、Sprint retrospective。
    2. 可使用的軟體 > 詳細的文件 : Scrum與以往不同的是,以Scrum product來紀錄。
Scrum product : 這邊只會簡單講三種,Product backlog、User stories、Sprint backlog。
    3. 與客戶(使用者)合作 : 在Scrum中,強調要頻繁遞送部分產出給客戶且反覆確認滿意度。
這部分就是上一段提到的Scrum概念2 & 4。
    4. 迅速的反應改變 > 跟隨計畫 : Scrum面對改變的機制之一,就是反覆式的發展(分成多次開發週期,每個週期稱為一個Sprint,每個Sprint時間長短依情況而訂,可能2~4週),而整個流程稱為Scrum流程,流程圖如下圖所示。

Scrum流程

Scrum開發流程會一直反覆多次開發週期(Sprint),直到專案結束或完成所有stories。


以下針對上一段畫虛線的部分做簡單的介紹,為了方便說明,不會按照上面的順序來講。

Scrum角色

角色分成四種(後三者稱為Scrum team):
    1. 客戶
    2. 產品擁有者(Product Owner, PO) 1人 : 是專案的聯絡窗口,負責的專案開發之產品要能為公司帶來利益,也負責開發團隊(請看4.)在開發過程中對產品設計與實作的相關決策,包括定義產品功能、工作項目的優先順序等,簡單來說就是Build the right thing(做對的產品)。
    3. Scrum Master(SM) 1人 : 負責協助建立Scrum meetings,追蹤開發最新進度,並擔任Scrum team的溝通橋樑,且確保開發團隊專注投入開發(需要協助排除相關的障礙與不必要的干擾),簡單來說就是Build it fast。
    4. 開發團隊成員(Development team member, DTM) : 負責專案產品的實現,包括分析、設計、寫程式與測試,簡單來說就是Build the thing right(把產品做對)。

Scrum product

這邊只會簡單講三種:
    1. 產品待辦清單(Product backlog) : 紀錄產品需求的特性(features,常用2. user story形式來描述產品功能)、開發的優先權重、預估完成時間等等。
    2. 使用者故事(User stories) : 會以這樣的格式組成,As a __, I need __, so that __. 以講者舉的例子來說:As a 在台北上班的通勤族, I need 警告我最後一班公車要來了, so that 我可以趕得及回家(這是一個App的產品功能,這只是舉例,實際上可以訂得再更詳細些)。
    3. 工作任務待辦清單(Sprint backlog) : 由Product backlog的產品特性與user stories分解成許多不同的工作任務(task)。以剛剛App的例子來說,可能會分成: 設計公車班次的資料庫、設計資料結構、設計類別架構、撰寫與測試程式等等。

其他項還有包括user stories的檢驗準則、story point(表示該user story特性或一個task的大小,是相對比較值,沒有單位)、Burdown chart、Velocity。

Scrum meetings

會議分成四種,以下只簡單描述:
    1. Sprint planning : 在Sprint planning中,會從Product backlog產品特性選出若干stories,再將選中的stories分解成Sprint backlog(許多不同的tasks),且PO與DTM討論決定tasks優先順序,並決定此Sprint中要做哪些tasks。會議時間約四小時。
    而會議程序是,一開始會指定Product backlog產品特性的優先權重,將優先權重大的產品特性分解成user stories,並且會指定每個特性、user story的大小(用story point表示),來建立相對的stories開發的時間大小。
    2. Daily Scrum meeting: 每天開15分鐘,且站著討論,DTM逐一說三個項目——昨天完成哪些tasks?今天準備做什麼tasks?有遇到困難嗎?說完,SM才回應。會把tasks分成to do, doing, done。
    3. Sprint review : 當次Sprint即將結束前,會向PO展示已完成的功能及產品特性,由PO驗收並表達滿意度,會議中會評估產出是否有達到預定的目標,並互相討論。會議時間約兩小時。
    4. Sprint retrospective : Scrum流程中,每個Sprint的最後一個活動,會議時間約15~30分鐘,會議的重點是要讓整個scrum team持續改進。由SM主持,檢討該Sprint中任何事情(包括團隊溝通與合作上的問題、是否遵守會議時間、成員是否均有貢獻等等),哪些做得很好、哪些需要改善。

Workshop活動


我超期待參加這個活動,由於本身就很想了解Scrum,也和朋友聊過有這類的遊戲可以體驗Scrum的開發流程,所以一看到這活動就毫不猶豫地參加了。
活動當天,很早就準備好囉,所以提早了幾分鐘到,一走進去就是報到處,Girls in Tech——Taiwan的Program Lead說我像大二生 XD。 由於早到的關係,還沒什麼人來,所以位置很空,不過第一桌已經坐了兩個人。平常上課都坐一、二排的我(正常來說 XD),這次當然也不例外,去坐了第一桌,離講者最近的地方。一坐下之後,我就馬上和旁邊的女生(Bambi)聊天,原來她現在在唸交大研究所,研究UX相關,而大學是念資工!!有種找到同好的感覺 :D



然後越來越多人來,不知不覺整間都坐滿人了(我們這桌多了一個男生),workshop也開始了。

一剛開始,講者要我們同桌的人自我介紹,大家自介完之後才發現,除了我和旁邊的女生之外,其他都是已經在上班的社會人士(其他桌”感覺”也是),雖然已經料想到,但沒想到比例這麼懸殊!不過我已經有類似的合作經驗,所以很期待接下來的事情。

講者介紹一些Agile和Scrum概念之後,馬上就要進行scrum流程了!!同一桌的人就是一組scrum team,我們這組花六秒就決定了PO和SM(各用三秒),多虧我們PO的一句話”大家三秒之後,指出一個人”,而我們這組大家想法都一致,都指到同一人XD,所以整個很順利!!

活動中,每組要做出一款App(用paper prototype形式),而且要跟著Scrum流程來run整個開發流程,我們這組要做的主題是:一日捷運生活圈App (User story我忘了…),主要是透過捷運地圖來介紹捷運站附近的景點、有什麼節慶活動,讓搭乘大眾運輸的旅客或使用者方便規劃一天之內的小旅行。

下圖是我們的Product backlog與Sprint backlog(因為我是活動結束才拍,所以tasks都移到done了XD),我負責後端部分(所有和資料庫及程式相關的部分,包括景點分類),不過paper prototype不需要資料庫和程式,所以實際上只有做景點分類這部分,而Bambi負責前端(使用者介面)。


我覺得我們這組很幸運!!因為我們組的SM帶來的雜誌剛好有捷運地圖(活動之前我翻一翻,剛好看到)及一些景點的介紹,所以剛好全部用上了!!!

而且我們各成員負責的事情剛好都是自己的專長 : PO本身是PM; SM本身就了解Scrum,也已經run過scrum; Bambi就是唸UX的; 我研究所領域是資料庫和推薦系統(包括景點推薦,這部分常常會講到景點分類,所以我知道大概有哪些)。

因為workshop的時間關係,活動中每個項目的時間都很短,三分鐘的Daily scrum meeting,三分鐘的工作時間,然後循環三次(一個sprint)。每組的paper prototype都做得很趕,而我們這組也是,印象很深刻的是在第二次Daily scrum meeting,我報告我整理的景點分類後,詢問PO有沒有哪邊需要修改或再加入的部分,PO馬上說有,我以為是分類太少,但結果是被刪到只剩下兩個,因為怕做不完,然後大家瘋狂的幫前端弄介面的東西,剪景點照片、弄膠水…等等,循環三次後,馬上Sprint review了(demo App)。

這次demo app比較特別的是,我們要demo給別組的人看,如果他們覺得App 好,就會簽名,每組要到10個簽名才算及格。而demo這部分(下面是一些截圖),因為我們的PO實在太厲害(我和Bambi一直讚嘆連連),demo得活潑有趣,所以很快就超過10個簽名,然後我們也去看了每組的demo,都做得不錯,有一組我覺得很棒,他們主題是”幫使用者找出,他要去的地方離哪個捷運出口最近”,我和Bambi都覺得這非常有用!!。



Sprint review結束後,就是Sprint retrospective,我們檢討在這Sprint中哪些做得很好,哪些需要改進。
在好的部分,我們列出很多 :
    1. 我們team一致認為大家在團隊溝通與合作上表現都非常好,有問題就會馬上提問,有任何不清楚的地方,也會進一步詢問及確認,工作上也都有盡責任,也會互相幫忙,大家合作得非常愉快。
    2. App的prototype介面很棒,有圖且又是彩色的(我們是所有組中唯一彩色介面的),demo時還有人稱讚我們的介面,這真的要感謝我們SM帶來豐富的旅遊雜誌,也感謝Bambi的介面設計及大家的幫忙。
    3. App demo得活潑有趣,這完全要感謝我們的PO,一邊demo還能和使用者互動,這方式真的很棒。在最後的心得分享中,還有別組的人說我們demo的方式很好,讓他學到了!!

需要改進的部分:

    細節少,豐富性不足。這部分,PO當時因為怕做不完,所以砍掉了很多東西(我們最原始的Product backlog列出的項目更多,但後來有些拿掉了),這在實際做產品時,是有必要這麼做,但我們都忘了我們只是做prototype,只要有個樣子就好。這部分在看其他組demo時,就有感覺到,雖然其他組其實也都沒做完,但是有想到的部分都有放進去。只可惜workshop時間只有三小時,只有跑一個sprint,要不然可以再改進的。

心得

覺得這次的活動很棒,讓我學到好多,而且不小心玩得太開心了,那種開心感覺可以興奮很久!!!

我很喜歡Agile & Scrum本身的價值觀與概念,雖然我還沒到公司裡真正的上班過,但以前在課堂內或課堂外,都有開發經歷或團隊合作的經驗,一個team要把東西做好,團隊合作真的是最關鍵的,團隊成員之間要有良好的互動、要能良好的溝通!!而我覺得不僅僅是在”軟體開發”上,其他有關於團隊合作的事情上,都是如此!我認為要能和別人有良好的合作與溝通,有一項很重要的是「同理心」,能站在對方的立場思考,不論是對團隊成員還是客戶(使用者)都是!!這是我以前擔任小主管及舉辦自己開發的App試用活動時學到的東西。而在和客戶(user)確認滿意度、充分溝通這部分,也是非常重要,這麼做才能確保掌握user的需求!!回想起大學時,我的App試用活動,我在試用活動第一天就邀請使用者給我feedback,有收到一些不錯的建議,而我趕在一個晚上內把功能update,讓使用者馬上就能用到想要的功能,幸好有多做這步溝通,最後使用滿意度還不錯。後來思考Scrum反覆式的開發週期,覺得這設計很棒!!能提早發現問題,及時解決、反應改變,而這個想法,似乎也能用在測試新idea上(不是幫別人開發出產品,而是自己有新idea,自己開發出來)!!

這次worshop中,很高興認識到我們這組的組員,這次的合作,認真覺得團隊合作的感覺很棒!!
活動過後,又再研讀scrum,覺得越來越了解了!! 希望學到的這些對以後工作上有幫助!而當然還有許多需要學習的地方,再繼續加油!!

最後,感謝講者Jonathan Chen,帶給我們很棒的體驗,也謝謝舉辦單位Girls in Tech——TaiwanAgile Community in Taiwan

活動結束後,大家的合照,我在右邊,穿紅色外套 :目

File from Girls in Tech——Taiwan FB



參考資料:
Agile software development wiki, 軟體開發流程, Workshop上課講義, 現代軟體工程