這樣就不敏捷了啊

August 28 12:20~14:05

故事一

兩個月前在「逛夜市」的時候無意間看到一本談論敏捷開發的新書，書中強調可以藉由某套「武功高強的軟體」，來幫助開發人員快速導入敏捷方法。根據書中的說明，這套軟體內建了敏捷方法與Scrum範本，可以自動產生很多「報表」，滿足「管理階層」對於專案進度與成本分析的需求。更讚的是，這套軟體有「電子化工作看板（task board）」的功能，開發團隊只需要透過「瀏覽器」，就可以輸入product backlog、sprint backlog。在Daily Scrum的時候，開發團隊圍繞著投影機打出來的task board，再也不需要實體的task board了。什麼便利貼，這麼低科技又不環保的東西，丟掉、丟掉、丟掉。

丟掉便利貼與實體task board，把所有的story與task全部都電子化之後，就會有很多好處喔，例如：

• 可以支援traceability：簡單的說，就是可以知道那些工作、模組、程式碼、bug、issue等是屬於那些需求（反之亦然），或是一個大的需求被切割成那些小的需求（反之亦然）。
• 可以記錄每一個task與story的工時：只要在認領task的時候，在工具上面按下「開始施工」，工具就會幫你自動計時（迷之音：這樣鄉民們就知道要如何虛報工時了吧XD）。
• 可以自動產生很多報表。

完全丟棄實體task board有沒有缺點？不知道耶，這本書沒提到。這本書一共有三大章，其中有很多內容都在介紹如何設定、使用、與駕馭這套「武功高強的軟體」。Teddy只看了第一章身體就不太舒服有點反胃想吐而沒有繼續看下去趕快離開夜市回家休息。回家之後躺在床上思考一下，腦中浮現一個不是很重要的小疑問：

這樣就不敏捷了啊

***

故事二

導入Scrum之後，接下來要思考的問題，就是如何改善團隊的程式開發能力。以前Teddy還在「吃頭路」的時候，有一位工作上的前輩告訴Teddy，他在帶領Scrum團隊的時候，想要讓團隊成員用refactoring技巧來改善設計的品質。這位前輩堅信好的設計應該要套用很多design pattern，所以程式經過refactoring後的結果，應該是變成很多各式各樣的design pattern。問題來了，團隊的程式碼之所以設計不良，是因為團隊成員其實不懂design pattern。而這位前輩又希望團隊成員可以透過refactoring直接在現有的系統中套用很多pattern。在不懂refactoring又不懂design pattern的情況下，請問單兵該如處置？

前輩：所以說，要導入refactoring之前，要先教團隊成員design pattern，這樣系統重構後的結果才會「漂亮」。如果不懂design pattern，refactoring的步驟就會變成一次改一點、一次改一點，這樣無法做到「一步到位」，很浪費時間耶。

Teddy：單純的把duplicated code 去除也是refactoring，應該不需要先學design pattern才能把refactoring做好吧？

前輩：…（申論題，文長，勿入，直接省略…XD）

聽完前輩的看法之後，Teddy內心只有一個不是很重要的小疑問，要實施refactoring之前還要先學design pattern的話，

這樣就不敏捷了啊

***

講這麼多廢話，那到底要如何才算敏捷？歡迎參加：

名額有限，報名網址請按我。

***

友藏內心獨白：不要搞到敏捷都不敏捷了。