敏捷開發框架下的軟體工程/第一階段
經過近兩年的具體指導下的作業，學生們來到軟體工程的二年級課程，期望得到詳細的簡報。當他們沒有從我們這裡得到簡報時，他們轉向客戶，希望在那裡找到簡報。通常他們也不會在那裡得到簡報。
在 2008 年，我們的軟體工程課程正在努力開發“活生生的校園資訊基礎設施”。這意味著什麼？這是一個好問題，也是學生一直在向我們和他們的客戶 Paula 提問的問題。
在這個專案中，我們並不是故意含糊其辭，我們真的不知道這個專案將走向何方。這使得教授這門課程變得有趣，在採用敏捷概念擁抱變化的同時，我們也體驗著勇氣、簡單性、反饋和尊重的價值觀。這同樣適用於學生和學者，從而形成了一種共同的學習體驗。
我們也遵循宣言，更重視左邊的那些，而不是右邊的那些
- 個人和迭代勝過流程和任務
- 可工作的軟體勝過全面文件
- 客戶合作勝過合同談判
- 響應變化勝過遵循計劃。
我們將這種敏捷方法與一個框架相結合——三個迭代。每個迭代都有里程碑交付成果，第一個是理解和溝通，第二個是功能交付，第三個是健壯交付。
因此，第一次迭代的目標都是關於建立理解——而不是專案將要產生的結果，甚至它必須做什麼。相反，重點在於為什麼——為什麼這是一個需要他們幫助的專案。換句話說——什麼是商業機會。
第一次迭代也是關於建立信心和溝通（在團隊內部和與利益相關者之間）。
在第一次迭代中，目標是建立對商業機會的理解，以及團隊如何利用他們在資訊科技方面的技能來努力實現這一機會。
他們做的第一件事之一就是與客戶會面。這次會議的目的是與客戶建立聯絡。現在還不是期待詳細的功能需求的時候。
在第一次迭代結束時，我們將擁有
- 建立一個開發團隊
- 與客戶建立牢固的溝通渠道
- 確認我們與客戶在專案的高階需求方面達成共識
- 建立一種方法和工作實踐。
第一次迭代很快。對於為期一年的頂點專案，這應該最多需要兩週時間。兩週，這太短了！沒錯。在每章中描述的每個任務中，一個資訊框指示每個任務應該花費多長時間。如果花費的時間比這更長，那麼你做錯了什麼。