依然是一樣的話題，依然是我自己的點滴心得，我希望能通過這種方式不斷的去認識以及總結。
上次Flow VS Agile中我們談到了過程和敏捷的初體驗，主要針對一開始如何做需求的研發。
轉眼3個月過去，我的項目經歷立項、市場分析、總計劃、需求研發、需求澄清、工作量評估、架構設計這幾個階段。如果按照Process過程來講，可以說我們到了概要設計這一步。（標準瀑布過程：問題定義、可行性研究、需求分析、總體設計、詳細設計、編碼、測試、運行維護）
從目前來看那我們豈不是沒有敏捷嗎？可是上次不是談到我們是用的敏捷來管理項目嗎？對了，到目前爲止，我們確實還沒有用到敏捷，這都是標準的瀑布模型，標準的開發流程。但對於前面的步驟的原則不太一樣，我們不是讓每件事情100%完成才啓動下一個步驟，這纔是關鍵。比如說我們的需求開發可能只是定一個大的框架，如feature有了，可能就到下一個步驟進行設計了，進行GUI了。這樣看來我們有點像是快速開發的模式。
那麼真正的Iteration迭代是什麼時候開始呢？就是在所有開發環境基本準備完畢的時候，如，架構設計完成了，概要設計也有點眉目了，基本開發IDE統一了，code rule有了，一個簡單的實作有了，那麼我們就可以開始Iteration了。或者說可以開始做release plan meeting了。那麼前面所有我姑且稱之爲Iteration之前的準備吧。
用一句話總結上面所說，就是，我們用快速開發的模式來做Iteration迭代之前的準備工作。可能這個時候很多“觀衆”會問了，爲什麼不用純快速開發或者純Agile呢？呵呵，我覺得這或許就是我們常說的凡事都有利有弊，關鍵是我們要找到適合我們自己的平衡點。這或許就是我們的平衡點吧。
這裏引入一個我也不知道是誰說的思想，過去的這麼多年來，我們的軟件開發方法可以分爲三大類：第一大類，也就是最初的時候，我們開發基本上只有Coding，沒有太多的設計，甚至沒有任何市場分析及需求開發，測試和後期維護也很少。因爲那個時期編程纔剛剛起步，可能編程完全就是爲了體現計算機的計算能力，或者使用計算機作爲輔助工具。我們姑且叫他Coding類吧。第二大類，軟件的興起，軟件給我們帶來了全新的生活方式，我們越來越注重用軟件來解決問題，軟件設計也越來越複雜，編程不再可能是個人英雄了。我們需要團隊的力量，這個開發人員越來越看中設計，完美的設計帶來的好處不用我說，提高效率，減少返工，擴展方便。我們可以把這個階段叫做Architecture&Design類；可能很多公司目前都屬於這一類。還有一類，也是我們公司現在所推行的，Full類，是什麼意思呢，就是我們會適當減少對設計的投入比例，而增加需求、以及後期推廣維護的投入比例。讓這個研發生命週期是一個比較平均的一個投入比例，既不完全倒向Coding，也不完全倒向Architecture&Design。
回到我們上上一段所說的，這就是我們的平衡點，也正是我們Process & Scrum的藝術之處。
