不嘴砲！敏捷式(Agile)開發玩真的

敏捷式開發的流程圖大致上會長成這樣，很簡單，但問題是該如何執行?

繼日前介紹的每日站立會議執行心得，時光飛逝，一晃眼2014來了，中國新年也要到了(請不要問版主今年貴庚...)，也是再給個交代的時候了。

實際執行過的軟工方法 What we did ?

• 每日站立會議 Daily Standing Meeting
• WBS(Work Breakdown Structure)
• 持續性整合 Continuous Integration(CI)
• 自動化測試 Auto Testing
• 視覺化工作進程追蹤 Kanban
• 使用議題追蹤系統 Using issue tracking system with Microsoft Team Foundation Server(TFS)

敏捷式(Agile)開發到底是什麼鬼 What the hell is AGILE ?

以下完全是個人對敏捷式開發下的定義，不代表任何一個出處。

• 敏捷式開發不是軟工方法，敏捷只是一種心理狀態的描述、一種工作環境的意念，如果公司文化沒有敏捷的意圖或是想法存在，導入任何方法都沒有用。但軟體開發總是需要方法來協助執行，下一節會針對上述個人所使用過的軟體工程方法來成果分析。
• 敏捷注重的是大量的重複迭代(Iterator)，簡單的說，就是你的任何工作不要做完了才拿出來，千萬不要做完了才拿出來，而是時間到了就要拿出來檢視、拿出來討論、拿出來DEMO。老師在講你有沒有在聽？老師在講有沒有在聽？這可不是跳針，是強調！
• 所以敏捷團隊執行狀態比較會像是：在專案開發初期，所有成員一起制定目標，這個系統要呈現使用者什麼樣的功能、什麼樣的感覺，不一定要馬上有既定的結論，但必須把工作項目(backlog)內容及時程制定下來，然後由成員各自認養。
• 不是認養回去就算了，還得繼續把目標切割(item)透過不斷的執行、驗證、根據驗證後的感覺進行討論然後修改、再執行，這樣每次的執行、驗證、再修改、再執行就是一個 iteration。老實說這種思維很難跟沒有執行過的人、不夠經驗的開發者、長官等等解釋，沒有實際執行過真的永遠只會理解教條上那套。

那這樣一直反覆迭代，難道你心中沒有一個疑問？事情一直重複做、重複修改，哪來這樣的美國時間？這樣真的有敏捷到嗎？恭喜你，你開始要有點懂敏捷式開發了。

敏捷開發真的敏捷了嗎？

• 嚴格來說，敏捷開發並不能減少開發時程，不能減少開發時程、不能減少開發時程、不能減少開發時程。
• 那你會問？那這什麼鬼名詞，掛羊頭賣狗肉嗎？對不起，客倌是你搞錯了...從頭到尾敏捷開發沒有跟你說可以幫助開發人員減少時間，可以進一步節省時間，身為老闆的你就可以少聘一點人、火掉一些米蟲，反正台灣就愛cost down。大錯特錯！

真正被敏捷到的是產品/系統/服務本身，因為有使用者、專案經理、客戶從早期就投入產出過程，可以讓成果很精準的符合使用者需求，或是很快的投入實際市場做商業模式的驗證。

實際執行過的軟工方法心得

• 每日站立會議 Daily Standing Meeting：已介紹，需要update一下，因為團隊人數日益漸增，已經取消成員報告進度這件事情，反正個人每天都會上Google Doc做review，這個每日會議現在的主要目的是要讓大家同步關鍵技術議題、資源協調、每天讓大家說早安、啟動工作開關...
• WBS(Work Breakdown Structure)：執行後徹底失敗，這算是CMMI的方法，但由於上級主管要求個人有試著推行一段時間；最主要的失敗原因個人認為WBS的進度根本追不上iteration的速度，今天我一個iteration只有兩週(10個工作天)，但WBS光是制定可能就要花兩到三個工作天，然後一個DEMO後可能backlog就被修正，或是某個item無法精準預估時程，再來就是常常有長官壓下莫名其妙的新backlog，對一個還在找尋產品定位的開發團隊來說，WBS大概只能實踐在主管層級。By the way，WBS可能比較適合需跨團隊需要統整大批人力、時程跟目標都很明確的專案項目。
• 持續性整合 Continuous Integration(CI)：相當重要，超過一定人數(可能5人)的開發團隊，然後這團隊的系統面包含frond-end到back-end都有操刀的話，沒有CI其實會相當痛苦。想想可能你寫了兩天code、自己unit test一天，結果卻需要花兩天的時間跟其他人做integration test...
• 自動化測試 Auto Testing：搭配CI使用，CI絕對不是只拿來build code，更要在build完後直接整合auto test來驗測系統基礎功能，測試涵蓋率不用高，就會相當好用了！
• 視覺化工作進程追蹤 Kanban：應該是要在辦公室直接用塊白板貼便利貼最有效，但礙於文化因素，目前團隊只有試運行在trello
• 使用議題追蹤系統 Using issue tracking system with Microsoft Team Foundation Server(TFS)：經過上述軟工方法運行後及參與Scrum Community社群討論後，發現一套issue tracking system才是團隊運作核心，別管以上那些天花亂墜的軟工方法了，也不用花錢先到訪間上什麼Agile課程，先把你自己團隊架一套需求單(requirement)、工作單(task)、問題單(bug)追蹤管理系統再說吧！