完成對功能的了解之後，我們就要開始進入實現功能的開發階段。跟以往的開發流程不同的是，我們在敏捷開發中注重的是製作有價值的東西。也就是在計畫中，我們獲取的資訊都是對使用者有用、可以被看見以及操作和跨團隊協作的性質。
Acceptance Test Driven Development
驗收測試驅動開發（A-TDD）很容易跟 TDD（Test Driven Development，測試驅動開發）搞混，兩者是不一樣的概念。前者是關注的是溝通以及「用測試驗收更可靠」的概念，而後者則是一種開發上的技巧。
基於驗收測試開發的實踐，我們根據 PBI（Product Backlog Item）中細化（Detailing）後的關鍵案例（Key Examples）來撰寫驗收測試，這個資訊大多會包含：- Given - 背景資訊，像是「這裡有一篇文章」
- When - 定義動作，像是「點選刪除按鈕」
- Then - 描述結果，像是「文章列表中找不到『文章 A』」
我們關注的是每一個功能（Feature）以及對應的情境（Scenario）發生的事情，這也是為什麼我們要進行衝刺計畫（Sprint Planning）來細化產品需求，將它轉換為實際的功能資訊。
因為使用「測試」我們很容易誤會要進行所有的檢查，然而 A-TDD 更加接近於「確認」這件事情上，因此我們每一個測試案例都是以「確認功能正常」為前提所撰寫。
Test Driven Development
因為我們基於 A-TDD 所撰寫了端對端（End to End）的測試案例，這也表示我們能夠用 TDD 的方式進行開發，採取「小步前進」的方式進行。
從使用者的角度來看，我們在初始的階段中只需要讓「文章列表找不到特定文章」的事情發生即可，因此我們很可能會直接在畫面中隱藏這篇文章，等待通過測試後，再繼續增加更細節的實作，直到我們完整的實現符合專案需求的功能。
透過這樣小步前進的方式，我們可以維持測試經常性的保持綠燈，也更容易在發生錯誤時倒退（Revert）回到上一個正常的階段繼續進行工作。
封面圖片使用 Unsplash 上 John Schnobrich 的作品，這系列的文章只是課程的一小部分，因此並無法完整涵蓋所有概念以及精神，看關於技術的主題可以到弦而時習之找找靈感。
