不嘴砲！敏捷式(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。老實說這種思維很難跟沒有執行過的人、不夠經驗的開發者、長官等等解釋，沒有實際執行過真的永遠只會理解教條上那套。

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

軟體主管的喃喃自語：領導原則

圖片來源：www.nipic.com

大方向：

不是很喜歡主管這個詞彙，主管感覺只是在管人、管事，但其實在管理階層要做的事情不能只是管理，要能找出團隊未來的方向，雖然對台灣人來說會很反感，個人倒是覺得用"領導"才是比較洽當的詞彙。


領導(主管)認知：(個人立場)

1. 謀定而後定，避免朝令夕改：要認知主管的一舉一動、下達指令都是成員們的圭臬，要是今天主管請你研發A，後天跟你說改成研發B，再過幾天又跟你說要研發C，想必大家都會無所適從，專案進度永遠都在歸零。所以個人在下每個命令或指導棋之前，絕對不會脫口而出，都是在腦海中沙盤推演這個命令下去後會讓多少人投入資源，投入資源後會獲得哪些產出，再藉由這些產出能不能達到目的才會下這道決策。要知道主管的話語對下屬來說就是指南針，今天你自己都抓不準方向，又要如何讓事情獲得成功？
2. 必須有扛責任的覺悟：團隊成敗與否絕對是在主管身上，別想怪罪到下屬上；要是主管老是以"員工不認真"、"員工能力不足"來搪塞失敗，那上級長官又何必賦與你主管職，一個主管存在價值就是在於領導團隊的成功。
3. 不是只為上司負責，更要為成員的未來負責：設想一個情形 - "如果今天你所在這間公司突然倒閉了，你的成員都有辦法、有能力找到別的工作嗎？"主管的任務不僅是要完成上面長官交代的事情，同時間你應該要為下屬的能力培養盡到責任(除非你的下屬就是沒有心思學習，另當別論)，今天你交辦給他的任務應該是要有技能性、學習可能、有競爭力的。