目錄公司層面的迭代週期是 1 個月（跟 kpi、績效掛鉤），產研團隊將 1 個月劃分成兩個小迭代，月初由產品和技術共同制定本月的需求列表（其中產品需求主要由產品主導，技術協助評估，技術需求由技術團隊自己制定），這些計畫列表構成每個團隊和個人的月 kpi 指標，月末回顧完成率與完成質量，綜合考慮評估每個團隊和個人的 kpi 情況；
月計畫列表中的需求項根據重要性分為高、中、低級別，級別越高需要越優先完成，其佔團隊和個人 kpi 比例也越高；
乙個月分為 s1 和 s2 兩個迭代，原則上每個迭代兩周，在需求和任務分配時會明確指定其所屬的迭代以及 deadline（提測、上線）。一般 s1 需求的提測時間（如果需要測試人員參與的話）在每月的 12 - 15 號，上線在 16 - 20 號。s2 需求提測一般在 18 - 24 號，上線在月末之前；
從需求接收方式上分為迭代需求（計畫需求）和臨時需求（綠色通道需求）。迭代需求月初由產品、技術通過評審會議確定放入月迭代列表中，作為產研團隊、小組以及個人月 kpi 的重要依據。臨時需求是月中由產品或其他需求方臨時提出的、緊急的（一般是走綠色通道的）需求，產研團隊根據目前任務飽和度決定是否要調整迭代需求列表（即劃掉某些優先順序較低的需求）；
未經評審的需求放在需求池裡面（主要是產品人員關注），評審通過並決定要在本月開發的放入發布計畫裡面（設計、產品、研發、測試等都會關注）；
需求評審：小的需求評審一般是產品 + 相關技術人員參與，中大型的需要技術經理、測試人員甚至包括產品總監、技術總監的參與。需求評審大體分為產品評審和技術評審兩個環節，產品評審由產品人員內部進行，主要考察產品層面的可行性，產品評審通過後進入技術評審，至少要有一名技術人員參與，主要考察技術實現可行性；
跨迭代的需求一般需要拆分成多個子需求，分迭代實現；
需求要拆分成若干個任務分配到具體的責任人（策劃、設計、研發、測試）。其中技術任務由技術經理拆分並分配到技術人員（也可能是技術人員自己認領的）；
開發人員接收到任務後，自己根據實際情況 + 需求優先順序安排開發；
開發人員和需求處理人需及時變更相關任務和需求的狀態，確保需求能夠及時流轉；
團隊在每日站會碰頭，每個人闡述自己昨日工作、今日計畫、整體進展。站會建議控制在 15 分鐘以內；
針對每個需求，開發人員需要從 master 拉取獨立的分支開發，不可在同乙個分支上開發多個需求，因為這樣會導致多個需求相互影響，無法獨立發版；
對同乙個專案的同乙個需求，不同的開發人員建議都使用同乙個分支開發（如前後端人員），避免相互合併**的麻煩；
建立開發分支：
- git checkout master
- git pull --rebase
- git checkout -b feature-songlin-coupon-list
- git push -u origin feature-songlin-coupon-list
當某個專案發布生產並合併到 master 分支後，該項目的其他開發人員應當及時將 master 最新**合併到自己的開發分支；
某個需求的所有方面都開發完成並自測/聯調通過後，由需求主開發負責人統一寫提測郵件；
提測郵件內容：
收件人：測試組
正文：概括說明本需求內容；
對應的需求鏈結；
專案（git 和中文名稱）、分支；
開發、產品人員列表；
需測試的功能點提示列表（特別是隱藏功能點）；
其他注意事項說明；
提測後，主開發負責人需要及時變更需求狀態，改為「已提測」，相關開發人員需要及時變更自己的任務狀態；
提測後，相關開發人員可著手處理其他任務，但需要及時關注測試動態，對於測試提出的 bug，需第一時間解決，或者跟測試溝通緊急度來協商解決時間。原則上，應當在一天內解決。不可因 bug 長時間未得到解決而影響測試進度進而影響整個專案進度；
測試人員測試通過後，會回測試通過郵件，開發人員收到此郵件後，需及時準備預發布；
主開發負責人收到測試通過郵件後，需及時準備預發布事宜。
從最新的 master 分支拉取 release 分支：
- git checkout master
- git pull --rebase
- git checkout -b release-20200313.01 # 如果當天已經有其他發版了，就接著往後編號，建立的分支不可與已有分支衝突
- git merge --no-ff feature-songlin-coupon-list # 合併自己的開發分支
- git push -u origin release-20200313.01 # 推送到遠端倉庫
收件人：運維組
正文：例如：
hi，運維：測試通過，麻煩發布到預發布環境驗證。
1.財務結算系統（負責人：張三）
分支：release-20200313.01
版本：e4371a569affe13862561b7aa3d5b939c9216aa7
2.券系統（負責人：李四）
分支：release-20200313.02
版本：9aca2d369826fd294b77fc23499d43654525212f
運維發布後，由測試人員測試。
測試人員在預發布測試通過後，會回覆測試通過郵件；
主開發人員收到測試通過郵件後，需及時編寫上線申請郵件：
收件人：運維組
正文：上線申請郵件需要技術經理審批，高風險發版需要研發總監審批。技術經理需要審核分支**（如是否 master 最新**、是否有明顯的錯誤等）、發版流程、sql、發版是否衝突，並評估發版風險，給出發版時間建議。一般低風險可以在白天非高峰期發布，中、高風險需要在晚上 11 點以後發布；
上線後，開發和測試人員需及時驗證，並密切關注外部反饋，有問題及時回滾；
上線成功後，由各專案負責人將發版的 release 分支**合併到 master，並在群裡告知團隊成員；
LZCreat技術開發團隊
lzcreat技術開發團隊是乙個專注於技術研發的團隊。該團隊成立於2009年，隨著時間的推移，lzcreat技術開發團隊由最初的技術討論，到後來的技術研發，再到後來逐漸實現了技術產品化。隨著技術產品化的發展，lzcreat技術開發團隊逐漸以客戶需求為出發點，最大限度提高客戶滿意度。團隊宗旨 企業成敗...
哆唻咪發團隊 團隊開發需求分析簡介
專案名稱 校園封神榜 需求分析 1 從老師的角度考慮 每年的科技季比賽，老師都需要通過班幹部動員學生參加比賽，浪費掉了很多的時間，而且這樣通知的效果並不好，很多的學生看不到而且容易忘掉 另外，老師帶有很多的科研專案，老師希望學生可以參與到其中，從而達到教學相長的目的。2 從學生的角度考慮 對比賽感興...
敏捷團隊的規範與準則
打造乙個金誠所至的敏捷團隊，需要大家自發的來遵守以及完善相應的規範。大家在自我約束的前提下，彼此之間互相影響，由下而上推動團隊的建設。所以規矩 準則應該是越少越好，通過良好的自我約束驅動團隊的成長。在閱讀本文件之前，假設你已經了解了敏捷開發 scrum 的相關知識，若從未接觸過敏捷開發，請先查閱 敏...