隨筆寫下的開發流程

2021-08-31 02:58:47 字數 1740 閱讀 7370

剛才突發奇想,對於開發的流程有了一點新的想法。就發出來,供大家拍磚。不知道大家對這個流程有什麼不滿呢,儘管說,希望盡快完善它,盡快應用它。好了,說正文吧。

1 了解需求

就是了解客戶,或者是市場的需求。可能要結合調研,深入體察,問卷調查之類的形式。盡可能了解市場的動向,方便把握我們的方向。

2 業務建模

了解的需求,定義的產品方向之後,就需要進行業務建模了。又可以分為三個階段:

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

這個階段引數的人員不包括開發人員,主要是業務分析人員,需求分析人員,和系統的架構師,如果需要的話,可以引入高階軟體工程師。

3 業務知識的傳播

這個傳播主要是說,需要將成型的業務知識傳播給開發人員。乙個系統,經過了分析,最終是要實現的,要用**的堆積的,所以再開發之前,需要開發者了解業務的脈絡,否則實現的東西會偏離方向,而且有可能實現的過於簡單或者過於複雜。

4 整理技術用例

這個階段有兩種做法:

1)開發人員在高階軟體工程師的輔助下,將細粒度的業務用例整理為技術用例,也就是想辦法實現每個業務用例。當然了,有可能細粒度的業務用例和技術用例是一對一的關係,也有可能不是,而是其他關係。反正,要轉化為技術用例。技術用例的內容包括:需要什麼技術手段,什麼演算法,如何實現,迴圈還是如何,修改哪些表,是否需要資料庫事務,使用sql事務還是**寫事務,等等技術細節。最好達到偽**,也就是誰拿到了,都可以實現的地步。

2)高階工程師在架構師的輔助下,完成第一種做法的內容,不讓開發人員參與。

這兩種做法的區別就是有無開發人員的參與,各有各的好處。開發人員參與,可以鍛鍊他們的分析能力,但是他們介入業務也不是一件好事。因為我們都知道,開發人員的思維方式和業務人員的思維方式是反過來的,不是一種方式,容易沒有結論。而且,開發人員專注於技術,對他們也是好事,盡量不要分散他們的精力,讓他們盡力實現軟體,盡力用更好的方式實現軟體。

5 job item

技術用例也出來了,這樣就可以劃分工作了。每個人劃分幾個技術用例,估算出實現需要的時間,列乙個**,或者是用什麼管理工具管理一下,反正方便控制進度就好了,需要知道的是每個人都在做什麼,什麼做完了,什麼還沒有完成。

每個job item有四個階段:未分配,已分配(未開始),進行中,結束。根據這些階段,對於功能的實現進度一目了然。這可能需要開發人員每天更新自己的工作內容,或者是主管每天跟蹤進度之後,修改進度表。

6 跟蹤

不要以為任務分配好了,就一切萬事大吉了。跟蹤是必要的,一定要跟蹤進度,而且要定期的檢查,否則後果不堪設想。每一層的主管負責跟蹤自己範圍內的完成進度。

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

專案經理:跟蹤的目標就是業務用例,細粒度的,粗粒度的,根據職責範圍跟蹤。還是就是整體的進度,是否需要加人,是否需要加班,人員的情緒是否正常,等等。

好的,說完了,希望大家趕緊拍磚。多提寶貴意見。

隨筆寫下的開發流程

剛才突發奇想,對於開發的流程有了一點新的想法。就發出來,供大家拍磚。不知道大家對這個流程有什麼不滿呢,儘管說,希望盡快完善它,盡快應用它。好了,說正文吧。1 了解需求 就是了解客戶,或者是市場的需求。可能要結合調研,深入體察,問卷調查之類的形式。盡可能了解市場的動向,方便把握我們的方向。2 業務建模...

軟體開發流程隨筆

工作兩個多月了,反思記錄心得體會。探索 框架,一直很被動的原因就是不了解框架,因此不知道怎麼入手,不知道從哪來到哪去,探索框架主要靠導師講解,其次自己主動探索,再其次補充框架的理論知識。我覺得應該這樣學習 理論和實踐相結合,從實踐出發,單點突破,然後再系統化吸收,巨集觀理論也要了解,不需要掌握和精通...

軟體開發流程隨筆

工作兩個多月了,反思記錄心得體會。探索 框架,一直很被動的原因就是不了解框架,因此不知道怎麼入手,不知道從哪來到哪去,探索框架主要靠導師講解,其次自己主動探索,再其次補充框架的理論知識。我覺得應該這樣學習 理論和實踐相結合,從實踐出發,單點突破,然後再系統化吸收,巨集觀理論也要了解,不需要掌握和精通...