Waterfall (1970, Royce) :
就是五十年後我們仍然最常用的model。
這是很理想性的，甚至只能是教育性的，主要問題:
(a) coding phase來的太晚，software只關乎coding成果，結果真的實作卻是放在如此後面的流程
(b) requirements一旦決定之後，基本上進入program design之後就不能改變
(c) 現實中的維護maintenance phase沒考慮到，但實際上佔了軟體工程成本的70% (?)
Agile view on Requirements
對requirement的agile 方面的批評是
1. requirement實務上是常改變(changing)的，太早固定只是自以為是
2. requirement文件基本上是個浪費(waste)
XP: 蒐集requirements是一個經常性的動態活動，而非產出一個靜態固定的文件
Scrum: 沒有前期的analysis / design phase，而是一直處於不斷的sprints cycle來蒐集requirements
Lean: 看不懂!
總之，agilist 認為requirement gathering phase不該太長，也不該是靜態性的結束。(不過要注意很多自認apply agile methods的人，過分低估前期的requirements gathering，造成工程上的大災難)。
Common Agile Principles (只是參考，不該形成教條）
1. 顧客為主：XP希望引入顧客成為team member （embedded customer)，但實務上很難找到這樣的顧客，而且顧客有可能代表性不足。Scrum: 定義product owner來取代傳統manager，這是體制內的角色，比起embedded customer來說較為權責相符。
2. Accept Change: 這對應到OOP中的extendibility，但是實務上不一定能簡單做到。
3. self-organized team: 這仍是對manager角色的弱化，manager主要功能在agilist眼中：
- 鼓勵進度
- 幫忙找出問題
- 移除障礙
- 對困境提供協助
- 鼓舞成員，抵消負面批評
- 授權team member能直接面對客戶
4. 可持續步伐：不要壓榨才能長久
5. 只做出使用者要的feature，不要做自己想像的: 降低複雜度，也省非常多錢 (
亂做一堆features會使得cost非線性成長)
Toyota的車廠管理衍生出Lean management，以下是幾種可能的"software waste":
(a) 就是產能過剩，做出沒人要的東西
(b) 庫存太多，做了不賣浪費時間浪費錢，打擊士氣
(c) 做一堆對產出產品無用的步驟
(d) 技能或經驗不足所以花一堆時間在蒐集資訊
(e) 沒被找出的bug costs money!
(f) 等待相關人士給予意見
(g) 不同framework之間的協調時間
極簡者 / 短視者 觀點: minimum viable product / 不需要中間產物 (文件 圖片等)。但這也招致了不少software engineering從業者的批評，本課程認為這些觀點過於極端，不是好的software engineering。
6. iteration時間縮短但是更多，
iteration過程中要freeze requirement
傳統的development iteration的模式是先建立infrastructure，然後一層層往上疊起，但
這就讓usable product/code 能出現的時間往後延長了不少:
agilists preferred的方式是快速但partial functional的release:
不過這門課老師覺得可以採用dual development，首先對risk最高的底層infrastructure花全力去完成 (比一般agile iteration更長)，之後才進入agile iteration。
7. 所有tests未通過前，不要implement new features
這個被列為最重要的agile教條之一，但是實務上我覺得要怎麼推動是一個問題，如果tests都是類似unit tests，那應該是比較容易推動。
8. use cases / scenarios 來描述requirements
好處是這讓測試的規格確定，同樣老師批評:
Lean specific principles
Lean的waste觀點:
這是一個不錯的negative impact checklist，可以實際用來檢視專案是否有浪費的情況。
Lean的learning觀點 (這是積極採取行動，透過資訊蒐集):
1. test給我們關於code的更多資訊
2. 嘗試各種solution會比寫文件或是花時間規畫能得到更多的資訊
以上五點其實就是讓我們盡量在開發時獲得資訊最大化的方法，agilist也希望能delay decision making，直到更明確information獲得之後，所以他們不喜歡大量的事前planning，
但是要小心可能造成拖延症! 這個拿捏可能跟經驗有關。
Crystal specific principles
Crystal方法主要focus在"focus" XD
1. 不要讓developer multitasking，避免分心
2. 不要中斷developer的開發連續流程，至少保持兩小時不打擾
3. team需要明確知道goal是什麼，只focus在goal
4. 人本尊重 (鼓勵發表意見的安全感，不受嘲弄)
XP specific principles
1. 人本尊重
Lean / Scrum specific principles
天下武功，為快不破。
要對要建立在快速information gathering。
每個iteration中，盡快給出end product，獲得feedback，進入下一個iteration。
Scrum specific principles
user stories (requirements)認為是可以獨立存在的，不依賴其他的user stories。
這就是所謂的feature independence。
不過這還是case by case。
