在這個公司工作五年多了，因為專案不同，角色不同，層次不同，也見識與經歷了我們在軟體開發中的各個步驟， 花些時間，總結與回顧一下我們的開發流程。
當然，先要說明一下前提：
我們做的是產品開發，一年一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的夢想師，產品是需求專業化梳理或進行有效評估細化需求負責的，而設計是前端的上游，前端是設計的下游。設計的工作目的是把產品巨集觀的思維結果進行專業的處理，因為按一般的習慣，產品最終的結果是原型圖，而原型圖可以理解為設計的草圖，對真正的使用者來說，這...