談談我們的開發流程

2022-03-06 08:26:41 字數 2175 閱讀 4829

在這個公司工作五年多了,因為專案不同,角色不同,層次不同,也見識與經歷了我們在軟體開發中的各個步驟, 花些時間,總結與回顧一下我們的開發流程。

當然,先要說明一下前提:

我們做的是產品開發,一年一release,而不是專案定製開發

這是乙個產品的持續開發、重構與維護,而不是從頭搭建乙個產品 

2023年以前,我們採用的是十分嚴格的瀑布開發模型,在專案初期就能拿到非常詳細的spec,但2023年開始推行scrum,流程有所改變,但就我們的軟體規模、與使用者的互動程度,很難實現真正意義上的敏捷。所以,我覺得我們的流程可以描述為「總體瀑布,區域性迭代」,當然,這個區域性可以佔60%以上的時間。

這發生在前乙個release中後段的時候,此時公司中有些人除了做當前的專案,就要開始考慮明年做什麼了,所謂既要埋頭做事,也要抬頭看路。 一般這些人可以分為兩類:

產品設計師, 通過市場調查報告,競爭對手分析,或者純粹個人創意想出一些點子來。或是新增功能,或是細分已有功能從而細分市場等等

架構師,leaders,在**第一線發現的一些問題(原有設計、**問題),或是在開發過程中遺留下來的一些任務(如時間不夠而先用了乙個workaround),主要是一些technical debt, 也包括一些如**移植,元件更新(如vs公升級)等等。

這發生在乙個release的開始階段,一些點子已經定下來了(所謂立項) ,team也成立或者選擇好了。

那麼就需要好好想想這個東西具體做些什麼,結合scrum,這個階段我們稱之為user story grooming,就是大家一起頭腦風暴,絞盡腦汁想出所有可能需要的功能,需要完成的事。一般的做法是產品設計(po),architect,leader在一起經過多輪的討論,但我覺得把整個team都包含進來討論,或者leader與team有單獨的會議來進行一些討論,會更好一些。

初步的 story已經準備好了,接下來要做的就是team一起對所有的story進行估計,根據總的story point以及優先順序,做出release plan。為了便於控制,我們使用了的sprint長度為2個禮拜,但是因為軟體規模的關係,2個禮拜要有比較顯著的產出不太切合實際,所以我們還會定milestone,一般三個sprint乙個milestone。

此時,專案組的branch也已可以開出來了。

這是開發的主體階段,時間可以佔到60%,在計畫完成後可以立馬開始。每個sprint的成果都會被測試並小範圍demo,這個demo的範圍一般僅限於本team,所以有點review的味道。然後每3個sprint都會做一次整合到主branch上,整合的質量主要靠自動化測試保證

這裡要提一下,雖然scrum不提倡,但我還是覺得在前幾個sprint,花些時間做好設計是非常重要的,我們就遇到過幾次因為開始沒想清楚,後來返工的情況。scrum在敏捷的同時,給我的感覺是有些急功近利,區域性最優,全域性卻無法保證最優。

主體的開發完成了,不需要啥太大的改動了,接下來的工作,主要就是stabilization了 ,大家也都回到主branch上工作了。是的,敏捷到此為止,我們並不保證前面每個sprint的產出是potential shippable的。我們絕對需要接下來一段時間的穩定。

如果由於某種原因非要做乙個較大的改動,需要發乙個eco(engineering change order),為了追蹤與風險控制。

此外,因為所有team的**都在主branch上了,qa會組織一些bugbash,進行globalization測試,效能測試,系統測試,workflow測試等。

開始邀請一些客戶來試用新版本了,從beta1到beta3,參與人數會越來越多。此時除了一些日常的stabilization工作,主要精力會放在修復一些beta缺陷上。

此時會開出一些新的branch (每個beta會有乙個branch),主要模式為:

主branch - qa branch - beta branch

qa將一些重要的缺陷標為beta

開發修復後check in到主branch,並integrate到qa branch,然後將該change標為ccb(change control borad) 

通過這層層控制,保證了beta版本的穩定性。 

然後,我們通過監視beta使用者論壇,獲取使用者意見並逐步改進。 

rtm為release to manufacturing, 就是最終的發布版本。經過三個beta版本的穩定與改進後,我們會新開出乙個rtm的branch,作為最終版。所有的change都會經過嚴格的review,才能進入這個branch,此時,主branch已經開始為下乙個release服務了。

談談我們的開發流程

在這個公司工作五年多了,因為專案不同,角色不同,層次不同,也見識與經歷了我們在軟體開發中的各個步驟,花些時間,總結與回顧一下我們的開發流程。當然,先要說明一下前提 我們做的是產品開發,一年一release,而不是專案定製開發 這是乙個產品的持續開發 重構與維護,而不是從頭搭建乙個產品 2009年以前...

談談我們的合作開發

經過十幾天的努力,合作的機房收費系統終於完工了,在這裡分享一下合作開發的經驗和收穫。小崔,長海,楊元,大帥,還有我 我們一起合作開發機房收費系統,我負責系統架構設計,長海負責介面層,小崔負責業務邏輯層,楊元和大帥負責d層 有各自的分工 首先 資料庫的設計 這個階段收穫很大,先前自己設計的資料庫幾乎沒...

我們一般的前端開發流程

老闆或甲方是乙個需求的真正發起者,也是乙個基礎idea的夢想師,產品是需求專業化梳理或進行有效評估細化需求負責的,而設計是前端的上游,前端是設計的下游。設計的工作目的是把產品巨集觀的思維結果進行專業的處理,因為按一般的習慣,產品最終的結果是原型圖,而原型圖可以理解為設計的草圖,對真正的使用者來說,這...