[創意菜色] 嘗試導入 Agile 敏捷開發的心路歷程

2015-11-07

2224
0
Agile
2016-02-19

在上週末從 David Ko 的 Agile 敏捷專案管理實務班結業後，覺得有點後悔，倒不是課程不好，而是後悔自己沒有多跟同學分享我們 Team 這三年來嘗試導入 Agile 的心路歷程，真的是血淚交織啊！

有一些 Agile Method 我們團隊是 run 失敗的，有一些 run 得算是成功的，我想我們 Team 的這些經驗應該可以給想走上 Agile 這條路的人一些幫助，很後悔沒有跟同組的同學分享，只能透過這篇文章來分享一下我們 Team 的經驗。（實際上是91大把我一推入坑的）

敏捷宣言

既然文章是講敏捷開發，不免俗地要提一下敏捷宣言。

個人與互動　重於　流程與工具
可用的軟體　重於　詳盡的文件
與客戶合作　重於　合約協商
回應變化　重於　遵循計劃

撞牆期

剛聽到敏捷開發的時候，自己心裡覺得「哇嗚！有一個方法可以讓開發變更快耶！太好了！」，好像找到了苦海明燈一樣，馬上就想要來用用看，這個時候我們連 Agile、Scrum、XP 都還搞不清楚，甚至以為 Agile = Scrum，而當時最夯的就是 Scrum，那當然就是挑它來用用看了！

我們 Team 就開始有模有樣地在白板上畫了一個看板，把我們現在手上的 task 用一張一張的便利貼貼上去，Daily Standup Meeting 是吧！大家就開始每天早上對主管報告當前的進度。

結果過了三~四個禮拜之後，看板上的便利貼全部都集中到同一個人身上，因為當時我們 Team 的 task 是會從 A 同事流到 B 同事手上，進度全卡在同一個人身上，其他人沒事做。

那 Daily Stanup Meeting 呢！？有準時開的話應該會知道進度開始落後了吧，就可以開始做處理啦！

不過事實上是這樣的，Daily Standup Meeting 在準時地持續了一個禮拜之後，因為剛好主管連續三天早上都有會議不在辦公室，那三天就沒有召開，而主管回來之後的第四天，主管正忙於處理其他事情也沒有召開，就這樣我們 Team 就再也沒有開過 Daily Standup Meeting 了。

回想這一切我們 Team 當時就像 Cargo Cult 一樣，Scrum 的初體驗宣告失敗！！

無力期

在 Scrum 的初體驗宣告失敗之後，我們 Team 就再也沒有人提過 Scrum，各自回到自己每個人的個人習慣，而每個人的產出也因為每個人的習慣不同，品質也跟著參差不齊、時好時壞。

bug 常常都是在功能上線之後被使用者發現，而 Ctrl+C、Ctrl+V 則是大家最常用的快捷鍵。

在某一次的某個 project，主管跟我們 Team 說這個 project 很急而且很重要，必須要在一個月之內完成 ooo 功能、xxx 功能、bla bla…，在分配完工作之後大家就開始埋頭苦幹，就在我跟你說開發好了你一測有問題、你跟我說開發好了我一測有問題的狀態之下，好不容易所有的功能都測通了，而 Deadline 也到了，系統就這麼上線了。

系統沒有奇蹟地在上線那天就又下線了，雖然後來經過修修補補在一個禮拜後穩定了，不過這個 project 算是失敗了，之後，主管要我們每個人寫 project 失敗的原因，大家都寫了一些進會議室開始輪流報告，其中一位同事覺得大家報告的內容都是在針對他，就這麼跟主管吵了起來，沒有意外地這位同事在一個月後就離職了。

面對愈來愈快的需求變化，我們 Team 的反應能力是愈來愈差，而主管除了檢討之外也束手無策！

反省期

因緣際會之下我開始接 Team Leader，雖然考慮了一些時日，不過我覺得我們 Team 還是有救的，面對一個每個人的能力有強有弱的團隊（台灣大部分的中小企業應該都是這樣的團隊）要貫穿一個理念或一種文化，得讓每個人對這個理念或文化有所感覺，很顯然之前我們 Team 對 Agile 沒有感覺，大家不知道搞這些東西到底要幹嘛？？

Daily Standup Meeting？事情都做不完了，還要我每天開會！
便利貼看板？把要做的事情寫一寫貼上去，也沒有做得比較快啊！

自覺如果再 run 一次 Scrum 的結果應該也會慘不忍睹，於是我開始研究 Agile、Scrum、XP…這些 term 的差異，以及這些 Agile Pratice 其背後要解決的問題及限制。

在土法練鋼、自宮閉關一陣子之後（其實沒有多久，兩個禮拜而已。），對於 Agile 有了較為清楚的輪廓，套一句 Ruddy 老師說的話「將別人的經驗轉化為自己的經驗最好的方法，就是看書！」

推薦大家幾本書藉

起步期(1)

我思考起步的第一件事情，是要把團隊成員的 production code 的品質提高到一定的水準，如何得知一支程式是好或壞？寫程式測試它是最好的方式！

我選了一個 project 來推 UnitTest 這件事情，在 project 開始之前，先跟專案成員做教育訓練，先示範 UnitTest 的寫法，以及分享一些工具給專案成員，讓寫 UnitTest 能夠少一些障礙。

project 開始之後，會請對需求掌握度比較高的專案成員預先做簡單的設計，做出一張類似這樣的 Class Diagram，內容只有 Business Layer 及 Data Access Layer 的 Interfaces、Methods，除此之外就沒有其他細節了。

這張 Class Diagram 也因為很簡單，所以它很好維護跟修改，而第一個版本也不用設計太多，掌握多少需求就做多少設計，還沒有發生的需求就設計進去是被禁止的，隨著需求變動增減，這張圖也會跟著變動增減。

不過有的人會問：「沒有細節要怎麼實作？」

其實我這樣做有一個目的，就是逼迫專案成員踏出溝通的第一步 - 開口，與其有時間在那邊等，不如趕快開口去問、與其抱怨別人設計不好，不如參與討論提出建議。

下面是我鼓勵我們的 Team Member 多開口時，跟 Team Member 說的：

我們常聽到「用講的比唱的好聽！」(既然比較好聽，那為何不用講的？)
我們也常聽到「用說的比較快！」(既然比較快，那為何不用說的？)

另外 Leader 也不是沒事做，至少要做這兩件事：

Review 專案成員的 UnitTest，適時地給出建議。
Review Class Diagram 有沒有 Over Design？

這種感覺就好像戰爭的時候，一堆軍官圍著一張地圖在討論作戰方式，討論完就各自帶著指令散開執行任務去了，你有看過戰爭的時候指揮官躲在辦公室寫作戰細則交代每個兵該做什麼的嗎？應該沒有吧！？

而且我也不太相信在戰場上士兵要清槍的時候，是照著口令喊「清槍開始、清槍蹲下…」。

起步期(2)

起步的第二件事情其實是在自動化這件事情上，在上一個 project 推行 UnitTest 之後，很多 bug 都在專案成員自己的 UnitTest 上被抓到，為了再加一層保護，以及讓專案成員能夠更專心在 production code 上，在上完91大的自動測試與TDD 實務開發(使用C#)之後，看到課堂結尾的 Jenkins，覺得應該是時機了，就花了一個禮拜的時間將 Jenkins 架設完畢，準備在下一個 project 來使用。

有關 Jenkins 的架設，可以參考我關於 Jenkins 的一系列文章。

下一個 project 除了延續上一個 project 所推行的項目之外，還請大家去理會 Jenkins 的 Notification，而且這次的 project 還使用 SpecFlow(Cucumber for .NET) 這個工具來撰寫整合測試的腳本，如果 UI 是 Web 的，則搭配使用 SeleniumHQ 來產生操作步驟的 script。

Leader 也多了一件事要做：

關注 CI Server 丟出來的 Notification 的處理狀況。

革命尚未成功

到目前為止，我是沒有去問 Team Member 跟以前比起來感覺如何？現在我們 Team 也只有走到這樣子而已，跟敏捷宣言講的內容比起來，其實還有一段距離，一部分是因為 Team 以外的文化要扭轉不是一件容易的事，一部分則是我們 Team 的基本功還得 up up，我們 Team 能做到哪就做到哪，不過至少除了「與客戶合作　重於　合約協商」之外，其他的部分我們 Team 都沾上邊了。

或許我用的方法不像正規的 Agile Pratice 那樣的完整、紮實，但是…

有講錯的地方歡迎各位先進補充跟指正，有任何問題可以直接在下面回應。（不過我比較喜歡當面溝通，順便洗腦…XD）

軟體主廚的程式料理廚房

軟體跟料理一樣，都變成了每人每天的生活必需品。