昨天分享了在不同的 Sprint 之間，我們會要用怎麼樣的心態去面對第一個以及每個 Sprint 的持續迭代改善。相信這也是過去對於 Scrum 的認識中，常常被提到的觀念。

今天我們要來聊聊開發團隊在一個 Sprint 內，也就是這固定的 TimeBox 之中，能夠如何進行迭代。

逐步縮小迭代的範疇

在完成 Planning Part 2，亦即完成每一個 Story 下的 Task 細分後，有一個頗為重要的問題浮現於腦海：各位的團隊在確實開始開發程序時，具體的實踐方法又是如何？是否先對第一個 Task 進行深入的討論，抑或是直接開始撰寫 Production code？又或者，是選擇從 TDD 的角度出發，先行定義測試？

此問題背後的意圖，實際上是要強調，無論在何時、何地，我們都可以將迭代的概念無縫地融入開發之中。

舉一個簡單的例子來說，假設需求如此描述：
建立一個使用者登入的頁面，並在其中加入帳號和密碼的輸入欄位，然後...(略)

從此需求出發，每一開發步驟應該被視為是一次小型的迭代，每一次的努力都使我們更進一步接近終極目標。想辦法從需求來發動去引出實際的程式碼。切記，要把腳步放小，試著讓每次的步伐越小越好。

實際上可能就會開始以下的幾個步驟：

1. 首先會是先有個測試，會描述有個頁面，位置會是在 localhost/login 的地方。此時才開始去生成這個頁面的 html 檔案。
2. 頁面上將會看到輸入帳號的輸入框，再藉由這個測試，去引出要有這個帳號輸入框的存在。
3. 頁面上將會看到輸入密碼的輸入框，再藉由這個測試，去引出要有這個密碼輸入框的存在。
4. 接下來會是預期有登入按鈕的的測試，然後才會實作登入按鈕。
5. 因為上一部有了登入的按鈕，接下來將會是預期後端伺服器存在 login 的 api，藉由這個失敗的測試去引出要實作 api的事實。

依此類推，將這幾個小小的循環，持續迭代出這個功能，從需求開始，到頁面上可見的輸入框，再到後端的驗證以及資料庫的更新，利用這個概念持續去把每個步驟拆小，讓裡面的每一步都是個小小的迭代。

實際上，這種開發方式與 Test Driven Development (TDD) 和 Acceptance Test Driven Development (ATDD) 的策略有許多相似之處，尤其是其中的「紅綠燈」測試循環。

然而，我想進一步強調的是，我們是否能在每一天、每一小時、甚至每一行代碼中都真實地呈現迭代的哲學？更進一步地說，無論是日常的工作節奏，抑或是短時間內的工作成果，甚至是每一行代碼、每一個函數、每一個字符，都應該體現迭代的真諦。

在這裡，我想強調的是，相對於名稱或技術術語的差異，真正關鍵的是，我們是否能確保每天的工作成果不斷地迭代，從而使整體的產出更加貼近 Sprint Goal。

預告：[Page 4] Scrum 中的角色 — 產品負責人 Product Owner

接下來筆者將會分享一些這些年對於 Scrum 中每個角色除了 Scrum Guide 介紹之外，在實際運作上所遭遇到的經驗。
會在明天首先登場的會是產品負責人 Product Owner