Agile Software Development 9 - Agile Methods 評比

Ugly (太過極端或是因咽忘食)

1. 不做早期requirement analysis與架構設計: 先期的analysis是必要的，不要太過火就好。
2. user stories不能取代requirement spec
3. test也不能當作requirement spec: 因為test cases不夠全面，是點狀
4. 忽略或是否認系統components之間的dependency: 幾乎是不可能independent
5. Scrum Master應該要寫code
6. TDD 代替analysis - 太極端
7. manager腳色被替代 - self organizing team是個理想，完全取消manager是個幻想
8. 不考慮未來extendibility/reusability - 太短視近利

Hype (不重要的主張)

1. pair programming - 之前說過了
2. 開放辦公空間
3. self-organizing team - 理想
4. 可持續性步調 - 我認為這是重要主張，只是時常現實面達不到
5. MVP - 這也是要看客戶需求而定
6. planning poker - ?
7. cross functional team - team內還是有專家的
8. embedded customers - 通常這類人員代表性不足，也很難在開發過程中產生作用

Good (agile methods中值得採用的方法)

1. acceptance of change - 闡明"改變"是軟體開發的本質之一，接受這個本質，甚至可以變成競爭力
2.  iterative development - 應該是"short"iteration才是重點
3. code是重點 -沒錯，不要一直"討論討論討論"
4. tests是重點 - 這真的是重點!!!!!!!!!!!!!!!!!!!!!!
5. 常態性regression tests
6. velocity - 給progress一個衡量指標
7. no branch - 這邊我不確定原因為何，看來作者同意multiple branches是個危險的設定，需要找更多相關資訊。
8. product burndown chart - velocity的視覺化，這讓所有參與者知道目標快達成(落後)了沒?
9. daily meeting - 有心理學上的意義

Brilliant (軟體工程中的高明見解)

1. short iterations - 哈，看來我看法跟他一樣
2. closed-window rule - 在iteration中不能改任何requirement / spec
3. refactoring - 不斷精進
4. 所有的functionality都該有associated test - 達到quality software的基本要求
5. 伴隨第一點就是以及no branch就是Continuous Integration

Quality is Key

and is King