敏捷式開發管理
1.背景
在現代軟體開發中，軟體專案在構建初期被切分成多個子專案，各個子專案的成果都經過測試，具備可視、可整合和可執行使用的特徵。換言之，就是把一個大專案分為多個相互聯絡，但也可獨立執行的小專案，並分別完成，在此過程中軟體一直處於可使用狀態。敏捷式開發管理概念應運而生。
2.敏捷開發管理的由來
2001年，一群大師聚集在美國猶他州，吃吃喝喝頭腦風暴，搞出了一個敏捷宣言，闡述了5條價值觀，如下圖所示。
2.1 文件能省則省
描述類屬性文件、介面說明文件（利用swagger自動生成）。而一些有價值的文件，如設計方案文件、架構體系文件等仍然是必須的。
2.2 敏捷的初心
敏捷的初心是建議我們通過一系列方法來讓我們的研發工作更加高效、靈活和有序，所以它強調團隊成員的能動性和相互之間的協作，也更重視應對變化。
3.敏捷的原則
- 我們最優先要做的是通過儘早的、持續的交付有價值的軟體來使客戶滿意。
- 即使到了開發的後期，也歡迎改變需求。敏捷過程利用變化來為客戶創造競爭優勢。
- 經常性地交付可以工作的軟體，交付的間隔可以從幾個星期到幾個月，交付的時間間隔越短越好。
- 在整個專案開發期間，業務人員和開發人員必須天天都在一起工作。
- 圍繞被激勵起來的個體來構建專案。給他們提供所需的環境和支援，並且信任他們能夠完成工作。
- 在團隊內部，最具有效果並且富有效率的傳遞資訊的方法，就是面對面的交談。
- 工作的軟體是首要的進度度量標準。
- 敏捷過程提倡可持續的開發速度。責任人、開發者和使用者應該能夠保持一個長期的、恆定的開發速度。
- 不斷地關注優秀的技能和好的設計會增強敏捷能力。
- 簡單——使未完成的工作最大化的藝術——是根本的。
- 最好的構架、需求和設計出自於自組織的團隊。
- 每隔一定時間，團隊會在如何才能更有效地工作方面進行反省，然後相應地對自己的行為進行調整。
隨著時代的變遷，裡面的內容有些會變了，如第4點社會分工越來越細，提需求的是跟客戶一起的售前通過工具更新到teambition平臺（我司採用TeamBition平臺，騰訊的TPAD也是一個很優秀的平臺工具）。
第5點還不是很理解。
第6點也是通過teambition平臺實現。我司主要在武漢與杭州兩地開發人員與測試人員進行溝通交流。因為網際網路令我們能遠端互動，感謝這最好的時代。
其他幾點應牢記於心不斷實踐。
4.瀑布式開發與敏捷式開發異同
敏捷式開發，細分需求，側重每個需求的生命週期管理。隨時提需求，隨時撤銷，隨時變更，每個需求都有，分析，設計編碼，測試，缺陷管理。產品經理，可以線上評審(結合DevOps:CI/DI)，隨時開啟新需求，結束需求。瀑布式開發只能等功能完全開發結束進行評審，例如迭代次數較少。
5.敏捷的方法
只要是符合敏捷價值觀和原則的方法論，都可以稱之為敏捷方法。
5.1 DevOps
我司採用DevOps方法，前後端的開發人員通過不斷的迭代程式碼，通過gitlab的CI/DI持續整合部署，測試人員持續測試反饋，通過teambiton對需求與缺陷的全週期管理實現了快速完成需求變更與開發以及缺陷的修復等。
5.1.1 後臺webApi的CI/DI工作流水線
5.1.2 前端CI/DI的工作流水線
綜上，通過DevOps CI/DI來持續整合,來提高敏捷開發的效率。可以說DevOps CI/DI是法家裡說的術，而敏捷思想是法家的法（規則，思想的抽象或者說是道家的道）。
5.2 Scrum
Scrum不是敏捷的全部，它只是敏捷的一個落地方法之一。
Scrum就是3355。
什麼是3355？
第一個3代表3個角色，即Product Owner（產品負責人）、Scrum Master 和 團隊；
第二個3代表3個工件，即Product Backlog（產品待辦事項列表）、Sprint Backlog（迭代待辦事項列表）和 Product Increment（產品增量）；
第三個5代表5個事件，這也是大家感受最深刻的，即Sprint Planning（迭代計劃會議）、Daily Scrum（每日站立會議）、Sprint Review（迭代評審會議）、Sprint Retrospective（迭代回顧會議）、Backlog Refinement（產品Backlog梳理會議）；
第四個5代表5個價值，即承諾、專注、開放、尊重和勇氣；
我司並不按照此方法執行。
6 我司執行的敏捷流程
6.1 特點：迭代式開發
每次迭代都必須依次完成以下五個步驟。
需求分析（requirements analysis）
設計（design）
編碼（coding）
測試（testing）
部署和評估（deployment / evaluation）
6.2 任務管理
6.2.1 需求管理
PO(Product Owner): 產品負責人，核心是產品，提需求者可以是產品經理，專案經理，測試人員(適用我司)，終端使用者，整合商，代理商；
現代化需求：需求變更快，早上提了，下午就改，敏捷是為了更方便地變更需求，我司非常適用敏捷式開發。
需求管理：關鍵是要寫下來，寫到統一的品臺teambition裡去。寫的過程，考慮問題會全面，能溯源。需求文件和開發的程式碼一樣，都要有完整的歷史記錄，能夠追溯到何時什麼人做了什麼修改，這樣可以追責到每一次需求變更。
6.2.1.1 一次具體的需求管理
- 什麼時候開始？
- 什麼時候結束？
- 負責人是誰？
- 完成之後交付給誰？@
- 需求生命週期，全週期覆蓋，需求的狀態管理
何為全週期？即需求全部狀態的流轉以及停止流轉。
狀態的定義新增
6.2.2 缺陷管理
缺陷即bug, 由測試人員經過測試案例之後，建立，指派給之前完成任務的對應開發人員，開發人員手頭工作繁忙，向組長反饋實際情況，再由軟體組長指派給其他開發人員。
- 指派流程很重要@
- 測試人員很關鍵
- 反饋很重要
- 軟體組長需要統籌規劃
- 根據優先順序安排任務
- 一次缺陷的修復成為迭代
6.3 統一的管理工具
我司採用TeamBition平臺
- 全週期
需求，開發，測試，缺陷修復，迭代全覆蓋 - 高效
任務燃盡圖，專案狀態，成員分工職責一目瞭然，減少溝通成本 - 積累
相關文件隨專案歸檔，不易丟失，適合新同事切入 - 任務看板
使公司領導層，產品，團隊對整個任務狀態及其週期全部視覺化 - DevOps
結合CI/DI，產品經理，專案經理隨時能看網頁，隨時能修改需求，提高迭代次數，減少溝通成本。給出訪問url - 程式碼
給出gitlab url
6.4 角色
-
– 產品負責人（Product Owner）
主要負責確定產品的功能和達到要求的標準，同時有權力接受或拒絕開發團隊的工作成果。 -
– 流程管理員（Scrum Master）
使得每一時刻的需求都能明確，管理每一次需求變動，變動原因，將變動落實到實處。 -
–開發團隊（Scrum Team）
根據任務優先順序編排任務 -
–測試人員
需求明確完之後，即可針對需求編寫驗收文件。測試過程，編寫測試案例。
6.5 流程
- 產品需求列表，由PO負責的；
- 召開評審會議，去除不必要需求，確定需要開發的需求；
- 簡單需求分發任務，複雜需求畫原型圖；
- 分配任務；
- 測試
- 交付能產生80%效益的20%功能；
- 持續迭代（迭代式開發），持續交付（增量交付）；
6.6 敏捷開發最終定義
敏捷開發以使用者的需求進化為核心，採用迭代、循序漸進的方法進行軟體開發。
6.7 目的
管理好需求，提高開發效率
6.8 培訓視訊
版權宣告：本文為博主原創文章，遵循 CC 4.0 BY-SA 版權協議，轉載請附上原文出處連結和本宣告。 本文連結：https://www.cnblogs.com/JerryMouseLi/p/14203881.html