- 本文主要總結闡述目前經歷的的開發週期和項目管理，
- 閱讀大概12分鐘
- 適合新手+項目管理新手+有經驗進行自我總結
身爲前端開發，目前在三家公司做過開發
不想看之前經歷可以直接跳到總結並給出自己點方案
兩家上市公司+一家200人的小公司，這三家公司以下就簡單簡稱A/B/C吧
A公司的開發流程
一個項目的生命週期
- 1、開發組長和產品商量開發人員（需要哪些人，大概工期）
- 2、產品建羣發需求文檔
- 3、開始需求會議（此時UI基本完成，再次確定難度和事件）
- 4、根據接口時間開始開發（一般前端在後端完成60%之後纔開始）
- 5、到測試時間開始發佈測試環境開始測試
主要問題
- 改需求比較隨意，經常遇到測試好等待發布，產品要改樣式啥的
- 測試階段也比較隨意，比如要求週一測試，我可能找找藉口給你推到週二測
B時期的開發流程
一個項目的生命週期
- 0、產品經理有需求想法去找項目經理討論可行性和緊迫性
- 1、項目經理開始分任務
- 2、產品建羣發需求文檔 答疑解惑
- 3、前後端把產品叫過來答疑解惑準備開發發送答疑解惑郵件
- 4、前端或者後端選擇一位作爲項目負責人對項目工時分解，溝通開發時間和測試時間，最終開發測試產品約定統一時間
- 5、建立開發任務立項郵件附帶上一步的分解文檔，讓主管在任務平臺創建任務和分解任務，在文檔中約定時間開始開發
- 6、測試前一天確定是否延期，如果延期，需要產品測試過來重新評估工期
- 到提測最後一天時，需要產品測試和主管過來驗收項目
- 7、根據驗收，第二天中午前修復bug發測試、發佈提測郵件
- 8、bug集中在郵件中發送，典型bug需要在任務平臺建立
- 9、完成測試時會發生確認郵件
主要問題
- 開發往往在產品需求會時對項目並不清楚，導致沒有多少疑惑
- 需求會時，產品只會瞎搞，很多技術細節，開發並沒完全理解，導致後面各種問題
- 開發階段改需求導致很多問題
C的開發流程
一個項目的生命週期
- 產品在自身或者用戶反饋接到需求建立issue
- 第一週最後一天開一個需求細化會，與所有開發測試過下一步要做的需求和安排，在細化會將issue 按照等級分類，
- 第二週開始一次迭代會，將細化會沒確定的需求確定，評審每個需求需要的時間（投票決定）然後分配任務（平均每個人5-7個工作日）。兩週一次迭代（一個0.1版本）開發，按照分在不同版本issue進行開發
- 因爲開發工作日不算熟悉需求和代碼審覈+測試bug+開發的時間的，所以兩週雖然就開發5-7工作日時期很滿的
- 領取issue後，開發熟讀需求，並理解，然後找測試和產品進行
開卡讓開發描述這個項目需求 - 開發在主幹上拉去分支根據issue建立相應的分支名稱
- 完成開發後，進行桌面檢查
- 提交代碼，申請合併（先向同組申請代碼審覈=再向測試提交申請） 測試收到申請則進行測試驗收，發現bug太多，則直接駁回，否則繼續進行測試，每個bug 再申請合併頁進行消息記錄，開發改完bug則進行回覆，測試完無bug，進行合併操作。合適時機 測試將改主幹發佈線上，
- 測試正式測試之前需要看到當前代碼已被review的記錄，
- 一輪測試之後，將所有bug記在issue中，開發將所有bug改好，提交riview則可以繼續下一輪測試（一般<=3輪）
主要問題
- 沒有提測文檔環節，開發文檔在哪裏，測試注意點不夠重視，主要靠口頭
總結並給出自己點方案
總結下來最小的那個公司C公司相對完善和人性，但也有不少問題
- A公司太隨意，可能和我當時所在項目組有關（主要是輕應用）
- B公司沒有開卡環節，測試bug沒有輪次之分，開發可能在開發前兩天並不知道開發需求，郵件和工作平臺效果很好，可以記錄項目和個人工作量
- C公司如測試開發文檔都寫在issue裏面，沒有自己的文檔
總結下來大概分爲以下流程
- 每次開發分爲開發週期，一般2周，當週未做完的順延到下週
- 安排專人處理線上bug
- 一個迭代週期 10個工作日 -1個工作日會議，平均每人6-8個工作日工作量
- 每日早上站會
- 昨日自己幹了什麼
- 今日打算搞什麼
- 有什麼困難需要協助
關於細化會
功能優化｜新需求｜新項目 以下統稱爲開發任務
- 產品主持
- 講解下一期可能要做的開發任務，瞭解可行性
- 確定開發任務需求等級，
- 不確定的開發任務需求分配給開發進行調研
關於迭代會
- 對細化會的開發任務進行評審
- 投票決定每個開發任務的開發工時
- 工時最小單位是半天，超過8天則定義爲跨迭代週期的開發任務，對任務再次拆分
- 分配給每個開發開發任務，
- 保證每個人分配的所有開發任務加在一起在5-8個工作日
- 確定一個人主要負責線上項目（其分配的任務在3-5個工作日）
關於白板管理
- 最好是真實點白板+web頁面
- 分類爲本次迭代週期待開發，正在開發，正在測試，準備上線
- 每天晨會也是圍繞白板進行產出
- 建議白板方便每日擡頭就看到進度
- 建議也使用web方便任務統計和每個員工kpi覈算，方便年度和季度總結
一個開發任務的開發
1、開卡會議
- 1、開卡準備：熟悉需求並向產品詢問細節
- 2、找到UI+產品+測試 向他們闡述所有需求
- 3、提出疑問+同時測試也提出疑問
- 4、產品經解答疑問，並判斷開發和測試對需求是否理解透徹
- 完成後郵件發送參會人和抄送必要主管
- 郵件需要寫需求點+項目各方人員+開發週期等
2、測試評審
- 一般在開發開始後1-2天，測試主持向產品經理和開發闡述測試需要測到所有點
- 產品開發注意是否有遺漏或錯誤地方
- 完成後郵件發送參會人和抄送必要主管
3、桌面檢查
- 開發完畢，邀請測試和產品經理到開發處檢查程序是否符合基本功能需求
- 不符合打回
- 符合但有部分問題，半天時間改完
- 完成後郵件發送參會人和抄送必要主管
- 郵件需要寫測試建議+注意事項+host配置+需求變更+影響頁面等等
4、代碼審覈
- 通過桌面檢查後，開發申請同組進行代碼審覈，並向同時說明每一段代碼設計思路。審覈提出改進處，
- 改進完畢，對代碼進行rebase 然後提交測試
- 完成後郵件發送參會人和抄送必要主管
5、測試與debugger
- 測試完成第一輪測試指出所有bug
- 開發在第一輪完成後修復所有bug進入代碼審覈同4
- 測試開始第二輪測試
… - 測試人員反覆測試無bug則本次開發封板
- 本次開發上線前需要再次進行迴歸測試
- 完成後郵件發送參會人和抄送必要主管