這幾個問題在《敏捷下的需求和**分支管理》一文中其實已經給出了答案，時隔兩個月，管理方式又有了些調整和改進。我覺得還是有必要單獨寫一寫。
總體的流程沒有大的變化，還是使用tapd來管理需求和缺陷，使用gitlab來管理**的分支，但有幾個小的調整：
之前是以一周做為乙個迭代週期，實踐中發現，以週為單位，粒度還是太大，有時候緊急上線乙個功能或是修復bug，連續幾天都會有發布，甚至一天內還有多次發布。目前迭代遵循著以下幾點：
像這樣調整，產品的迭代會更加敏捷，同時也對整個團隊提出了更高的要求，怎樣在這樣高速迭代的過程中，還保證產品的穩定性？
自從以任務為導向調整成需求為導向時，就已經意識到需求的重要性，同時也面臨乙個問題：需求文件誰來寫？
一些大公司的研發團隊，配置齊全，有專職的需求分析師，而像我們這種小的創業型產品團隊，我希望每個人都能是需求分析師。
在調整為需求導向的開始階段，是我乙個人在寫需求的詳細描述，一旦精力分散，就會導致有疏漏，效果不是很好。現在我要求團隊成員每個人都參與寫需求，在接到任務時，必須先思考，把自己到理解寫出來，然後才開始開發。
我會對需求做review，也會讓經驗豐富的程式設計師來做review，找出遺漏的點和錯誤的點進行補充和改正。
讓每個人都參與需求的編寫有兩個好處：
之所以要做調整肯定是遇到了問題，所以，先說問題：
需要更小迭代的發布，常常a功能已經在測試中，這時b功能並入主分支進行測試，a功能測試完，b功能還在測試中，這是如果發布，會導致沒有完成測試的b也發布了，而我只想發布a
客戶a使用的是v6.7.5版本，而現在最新的版本已經迭代到了v6.8.0，在v6.7.5上發現的bug應該怎麼辦？
引入release分支可以雖然在操作步驟上帶來了一些複雜度，但是可以確保能夠以最小粒度發布。
在release分支發布上線後，以發布的版本號為名稱在gitlab中打乙個tag，這樣就可以解決上面的問題2，分為兩種情況：
以v6.7.5的tag建立分支來修復bug，修復後直接在該分支進行測試，驗證通過後發布，最新版本如果該bug已經修復，則直接更新tag
以v6.7.5的tag建立分支來修復bug，修復後直接在該分支進行測試，驗證通過後發布，最新版本如果沒有修復該bug，將修復bug的提交合併到主分支，然後更新tag
同樣，當程式發布到docker容器中後，在容器的私有倉庫中也打上以版本號命名的tag，可以便於公升級後的回滾。
工具和流程都只是輔助手段，目的是為了團隊能夠更好的溝通協助，能夠持續地有高質量的產出，千萬不能本末倒置。
最後，祝大家端午節快樂！
需求，總是不斷的需求
我作經營分析專案。專案施工中最難的就是需求的界定。以前我作營帳系統的時候，什麼叫做需求，就是要你作的事情。需求的滿足有時能提高客戶的滿意度，但是也不是絕對的。2003年開始施工的專案，做到現在已經累計了600多張報表。局方改制，使用統一的報表接入口 說實話，除了及其個別的省份，經營分析系統就tm乙個...
需求收集和管理
需求收集和管理是軟體產品賴以發展的關鍵 需求一般源自 1 來自於服務部門的需求，服務部門的需求來自終端使用者。3 商反饋的使用者需求 4 研發及測試人員反映的需求 如何將所有的需求蒐集到乙個中心需求庫，對需求進行分類 判斷 審查 存檔 跟蹤實現情況 有的需求並不一定是真正需求，有的需求實現需要的工作...
Git的版本和分支管理
1 2 3 本地的分支管理 建立分支，你可以使用 git branch dev 這就建立了乙個dev development之意 更好的，選擇使用下面的方法建立兩個分支 dev，建立後會自動切換到新建立的分支，git checkout b dev 要切回master分支怎麼辦？使用 git chec...