隨筆寫下的開發流程

剛纔突發奇想，對於開發的流程有了一點新的想法。就發出來，供你們拍磚。不知道你們對這個流程有什麼不滿呢，儘管說，但願儘快完善它，儘快應用它。好了，說正文吧。

1 瞭解需求

就是了解客戶，或者是市場的需求。可能要結合調研，深刻體察，問卷調查之類的形式。儘量瞭解市場的動向，方便把握咱們的方向。

2 業務建模

瞭解的需求，定義的產品方向以後，就須要進行業務建模了。又能夠分爲三個階段：

業務分析：分析市場的需求，劃分業務的方向，找到業務的主體以及業務的大概內容和範圍。

整理業務粗粒度的用例：分析完業務以後，將分析的結果整理爲粗粒度的業務用例。能夠用工具來輔助這個階段的工做。把握業務的脈絡和方向。

細分業務用例：有了粗粒度的業務用例以後，須要進一步的細分，整理業務的細枝末節，考慮每種業務的可能性，業務的流程，業務數據的流向。

 

這個階段參數的人員不包括開發人員，主要是業務分析人員，需求分析人員，和系統的架構師，若是須要的話，能夠引入高級軟件工程師。

3 業務知識的傳播

這個傳播主要是說，須要將成型的業務知識傳播給開發人員。一個系統，通過了分析，最終是要實現的，要用代碼的堆積的，因此再開發以前，須要開發者瞭解業務的脈絡，不然實現的東西會偏離方向，並且有可能實現的過於簡單或者過於複雜。

4 整理技術用例

這個階段有兩種作法：

1）開發人員在高級軟件工程師的輔助下，將細粒度的業務用例整理爲技術用例，也就是想辦法實現每一個業務用例。固然了，有可能細粒度的業務用例和技術用例是一對一的關係，也有可能不是，而是其餘關係。反正，要轉化爲技術用例。技術用例的內容包括：須要什麼技術手段，什麼算法，如何實現，循環仍是如何，修改哪些表，是否須要數據庫事務，使用sql事務仍是代碼寫事務，等等技術細節。最好達到僞代碼，也就是誰拿到了，均可以實現的地步。

2）高級工程師在架構師的輔助下，完成第一種作法的內容，不讓開發人員參與。

這兩種作法的區別就是有無開發人員的參與，各有各的好處。開發人員參與，能夠鍛鍊他們的分析能力，可是他們介入業務也不是一件好事。由於咱們都知道，開發人員的思惟方式和業務人員的思惟方式是反過來的，不是一種方式，容易沒有結論。並且，開發人員專一於技術，對他們也是好事，儘可能不要分散他們的精力，讓他們盡力實現軟件，盡力用更好的方式實現軟件。

5 Job Item

技術用例也出來了，這樣就能夠劃分工做了。每一個人劃分幾個技術用例，估算出實現須要的時間，列一個表格，或者是用什麼管理工具管理一下，反正方便控制進度就行了，須要知道的是每一個人都在作什麼，什麼作完了，什麼尚未完成。

每一個Job Item有四個階段：未分配，已分配（未開始），進行中，結束。根據這些階段，對於功能的實現進度一目瞭然。這可能須要開發人員天天更新本身的工做內容，或者是主管天天跟蹤進度以後，修改進度表。

6 跟蹤

不要覺得任務分配好了，就一切萬事大吉了。跟蹤是必要的，必定要跟蹤進度，並且要按期的檢查，不然後果不堪設想。每一層的主管負責跟蹤本身範圍內的完成進度。

技術組長：組員技術用例的完成狀況，技術的實現有什麼困難，手段是否合理。跟蹤的過程當中順便給予指導。

項目經理：跟蹤的目標就是業務用例，細粒度的，粗粒度的，根據職責範圍跟蹤。仍是就是總體的進度，是否須要加人，是否須要加班，人員的情緒是否正常，等等。

 

好的，說完了，但願你們趕忙拍磚。多提寶貴意見。