剛纔突發奇想，對於開發的流程有了一點新的想法。就發出來，供大家拍磚。不知道大家對這個流程有什麼不滿呢，儘管說，希望儘快完善它，儘快應用它。好了，說正文吧。
1 瞭解需求
就是了解客戶，或者是市場的需求。可能要結合調研，深入體察，問卷調查之類的形式。儘可能瞭解市場的動向，方便把握我們的方向。
2 業務建模
瞭解的需求，定義的產品方向之後，就需要進行業務建模了。又可以分爲三個階段：
業務分析：分析市場的需求，劃分業務的方向，找到業務的主體以及業務的大概內容和範圍。
整理業務粗粒度的用例：分析完業務之後，將分析的結果整理爲粗粒度的業務用例。可以用工具來輔助這個階段的工作。把握業務的脈絡和方向。
細分業務用例：有了粗粒度的業務用例之後，需要進一步的細分，整理業務的細枝末節，考慮每種業務的可能性，業務的流程，業務數據的流向。
這個階段參數的人員不包括開發人員，主要是業務分析人員，需求分析人員，和系統的架構師，如果需要的話，可以引入高級軟件工程師。
3 業務知識的傳播
這個傳播主要是說，需要將成型的業務知識傳播給開發人員。一個系統，經過了分析，最終是要實現的，要用代碼的堆積的，所以再開發之前，需要開發者瞭解業務的脈絡，否則實現的東西會偏離方向，而且有可能實現的過於簡單或者過於複雜。
4 整理技術用例
這個階段有兩種做法：
1）開發人員在高級軟件工程師的輔助下，將細粒度的業務用例整理爲技術用例，也就是想辦法實現每個業務用例。當然了，有可能細粒度的業務用例和技術用例是一對一的關係，也有可能不是，而是其他關係。反正，要轉化爲技術用例。技術用例的內容包括：需要什麼技術手段，什麼算法，如何實現，循環還是如何，修改哪些表，是否需要數據庫事務，使用sql事務還是代碼寫事務，等等技術細節。最好達到僞代碼，也就是誰拿到了，都可以實現的地步。
2）高級工程師在架構師的輔助下，完成第一種做法的內容，不讓開發人員參與。
這兩種做法的區別就是有無開發人員的參與，各有各的好處。開發人員參與，可以鍛鍊他們的分析能力，但是他們介入業務也不是一件好事。因爲我們都知道，開發人員的思維方式和業務人員的思維方式是反過來的，不是一種方式，容易沒有結論。而且，開發人員專注於技術，對他們也是好事，儘量不要分散他們的精力，讓他們盡力實現軟件，盡力用更好的方式實現軟件。
5 Job Item
技術用例也出來了，這樣就可以劃分工作了。每個人劃分幾個技術用例，估算出實現需要的時間，列一個表格，或者是用什麼管理工具管理一下，反正方便控制進度就好了，需要知道的是每個人都在做什麼，什麼做完了，什麼還沒有完成。
每個Job Item有四個階段：未分配，已分配（未開始），進行中，結束。根據這些階段，對於功能的實現進度一目瞭然。這可能需要開發人員每天更新自己的工作內容，或者是主管每天跟蹤進度之後，修改進度表。
6 跟蹤
不要以爲任務分配好了，就一切萬事大吉了。跟蹤是必要的，一定要跟蹤進度，而且要定期的檢查，否則後果不堪設想。每一層的主管負責跟蹤自己範圍內的完成進度。
技術組長：組員技術用例的完成情況，技術的實現有什麼困難，手段是否合理。跟蹤的過程中順便給予指導。
項目經理：跟蹤的目標就是業務用例，細粒度的，粗粒度的，根據職責範圍跟蹤。還是就是整體的進度，是否需要加人，是否需要加班，人員的情緒是否正常，等等。
好的，說完了，希望大家趕緊拍磚。多提寶貴意見。