.
實行敏捷的訣竅: 小增量、迭代和尋求回饋
.
累積專業知識
在 Feature Team 的架構下(如果你還是傳統的Component Team架構，專業知識將比較不容易串接起來，工程師做完一個功能，最大的收穫是Coding 技巧而非專業技能)，開發團隊經常能由後向前延伸，也就是團隊成員直接接觸到客戶，這是最理想的清況，當程式設計人員能夠直接取得客戶回饋的時候(面對面的溝通模式)，程式設計師成為一線的維運人員，運維的工作自然會務實，它不但提升了客戶的滿意度，工程師也會有大收穫。與傳統方式工程師躲在市場人員後面，那種缺乏實際事務經驗的作法，要實在多了。透過數個迭代之後，功能的成熟度與程式員的專業度都提升了，這對產品的未來也將打下良好的基礎，雖然成本高了些，但卻是直接提供客戶價值的最好作法。這一點跟公司的大小無關，純粹是你怎麼安排你的組織架構。
.
熟悉客戶行為
UX設計師總是揣摩客戶的各種行為模式，來提供PO藉以產出各式各樣協助客戶完成功能操作的需求。開發團隊如果能夠做到與客戶面對面的進行溝通，則許多的假設便能得到驗證，整個開發團隊也都將更熟悉客戶的行為模式，這在後續的開發作業上將成為更加明確、更為務實的依據。
.
需求切割太小，便很難作展示；切大了，又失去小增量的意義。
.
小增量是一種挑戰
將需求切割成片段的需求描述是一種自然的作法，但由於敏捷追求的增量是一種能讓客戶做成回饋的增量，這一點便挑戰著撰寫需求的人與負責開發的工程師在客戶認知上的素養。理想狀態是客戶就坐在距離開發團隊不遠的周圍，團隊能經常得到即時的回饋，然後便能夠做到即時的修正。但實質上；片段的功能程式可能無法表達得讓客戶有所感覺，自然就沒有回饋了，而切割成片段的抽象化程式可能又太難寫成可對照的需求；也就是需求難以描述出小程式想達到的邏輯。因此想要獲得小增量、又有好的回饋效果自然成為一種困難的挑戰。最普遍的參考方式是不斷的以SMART原則去檢核需求為依歸。
.
【SMART原則】
- 具體的 Specific：目標設定不要太抽象。
- 可以衡量的 Measurable：最好能以數字表現，盡量將目標量化，這將有助於規劃達成目標的行動步驟(如同OKR在制定 Key Result的關鍵指標一般)。
- 可以達成的Attainable：要合乎實際，而不是好高騖遠。
- 合理的 Reasonable：不要有互相衝突，顯得不太合理。
- 明確的截止期限 Time-based：要設定完成的期限，才有驅動的力量。
.
設計成足以試錯的小增量
先試錯，而不是一次就達標。要讓程式碼變成是一種試錯的工具。我們在開發程式之前先運用科學的精神。先要求組成一組可以達到成功動作的程式碼，再來進行包裝加工作業，再讓它變成完備的功能程式。而在開發作業時持續的求取外部的回饋，以確認自己在真的做對了的前提下逐步的完成功能的開發。我稱這種開發方式為 MVP式的開發方式(Minimum Viable Program, 最簡可行程式碼開發方式)。
善用MVP的程式撰寫方式。意思是當你只是在嘗試是否能夠做到預定功能時所撰寫的程式，所指的是沒有 Try-Catch 或是例外處理Exception等的防衛性程式碼，只有達成功能所需的最少程式碼，就稱之為MVP程式碼。這種程式碼不是最終版可以上線的程式碼，而是嘗試看看是否能達成程式目標所做的簡潔測試程式。一旦功能被確認了才有必要進行衍生成正式的功能程式。這是一種敏捷化的程式撰寫方式。他秉持以科學的精神，要求先試錯在完備開發作業的模式。
.
目的是追求創新
小增量多迭代是一種敏捷的開發方法，它只是比傳統的開發方法多了一些修正錯誤的機會。但在我們加入以「試錯」為主的理念時，犯錯所累績下來的經驗便轉換成我們擁有創新的機會所在。綜觀上圖，敏捷的小增量、迭代和尋求回饋的作業方法，讓開發作業形成一條龍式的由貫穿產品製作到客戶使用的連續作業，這也是推行DevOps時的真正目標，我們在進行 end to end的開發時成就了專業知識的累積。並在與客戶頻繁接觸，驗證需求是否實用的狀態下，對客戶行為更加熟悉了。也成就了團隊擁有創新契機的動能。.
.
(這裡省略了回饋的部份，有機會在談)
