今天鐵人賽來點輕鬆的，有鑑於網路上多數文章都用PM的視角，來推銷敏捷工作法有多好，今天我想用工程師的角度談談敏捷式開發，以及怎麼在Mendix平台上用Scrum工作法工作。

什麼是Agile工作法

你敏捷，我敏捷，大家都在用敏捷! 敏捷工作法在這一兩年突然在台灣盛行起來，跟市場變化速度脫不了關係，尤其是軟體業，產品生命週期短，在強調彈性與靈活應對方面，傳統Waterfall的工作方式根本看不到車尾燈。

敏捷工作法最棒的地方在於能快速推到市場，看到有什麼問題馬上改，反正R&D平常加班慣了，不怕多加一天班，阿不是! 敏捷工作法能讓設計師與工程師合作更緊密，並能由PM反覆確認，到這裡就要來了解一下大家共有的疑惑，工程師在敏捷開發過程中可以做些什麼?

敏捷工作法是於2001年由一群工程師所提出來的(嘿嘿!想不到吧)，強調工程師間的互動以及良好溝通。敏捷開發(Agile)又細分為不同實際做法，包括Scrum/Design Sprint/看板，這些框架的共通點為團隊只需適度的計畫，過程中要相信團隊成員的能力，由人來創造價值，所以說敏捷開發首重的就是我們要有信仰!

這信仰不是隨便說說的，因為跟瀑布式開發的最大差別在，敏捷式開發只有里程碑但看不到最終的樣貌，一切的改善都是循序漸進的，這可以用網路上的圖來解釋

敏捷工作法，工程師可以注意的點有:

1. 了解ticket有哪些緊急的棘手的優先處裡
2. 與領域專家密切合作，要記得溝通，不要悶著頭寫自己的扣
3. 要有心理準備，敏捷開發不代表開發會變快
4. 找到一個可以跟你結隊編程的夥伴，互相激勵

什麼是Scrum工作法

Scrum是Agile工作法中的一個流派，概念類似金庸小說裡的門派，每一種敏捷工作法的方法都有自己的長處，所以要依自身團隊目前的情形決定要用哪一種。

Scrum工作法主要成員約為5~9人，主要成員為

流程包含
列出工作清單 -> 衝刺規劃會議 -> 每日站立會議 -> 衝刺檢視會議 -> 衝刺自省會議-> 完成並重複

請看引用的圖表

Scrum工作術與其中會產生的問題在這次鐵人賽中有相關的系列文可以參考。
而工程師在這過程中可以注意的點為:

1. 記得打破界線跟其他專家溝通
2. 主動了解目前的相關情形，而不是聽其他人說了算
3. 要相信自己的價值

在Mendix上使用不同工作法的時機

雖然說靠北工程師上最常見的主題就是在黑PM，但如果要了解怎麼讓工作更有效率，我們應該試試怎麼從PM的觀點來看產品開發週期。在網路上有個很棒的PM面試分享文，其中講到了PM這個職位在意的一些重點，根據文章所描述的方針，整個流程為下圖

而這些重點在Mendix上工作時我們也必須留意，Mendix官方有給出Scrum工作法的指引。

團隊大小
工程師人數大約3人左右。

善用Sprint 0的時間
了解需解決的問題以及認識stakeholder與SMEs，這個時候是最容易問關鍵問題的時候，要好好把握，除此之外，讓團隊成員在開始工作前達成共識也是相當重要。

會議時間建議
Mendix官方推薦的會議時間如下

總結，如果老闆要做敏捷式開發，照做就對了!