敏捷式開發管理
目錄
敏捷式開發管理 1.背景2.敏捷開發管理的由來 2.1 文檔能省則省2.2 敏捷的初心3.敏捷的原則4.瀑布式開發與敏捷式開發異同5.敏捷的方法 5.1 DevOps 5.1.1 後臺webApi的CI/DI工作流水線5.1.2 前端CI/DI的工作流水線5.2 Scrum6 我司執行的敏捷流程 6.1 特點：迭代式開發6.2 任務管理 6.2.1 需求管理 6.2.1.1 一次具體的需求管理6.2.2 缺陷管理6.3 統一的管理工具6.4 角色6.5 流程6.6 敏捷開發最終定義6.7 目的6.8 B站培訓視頻
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由測試人員設置完成。並且所有通知信息可由teambition手機App通知。
6.4 角色
– 產品負責人（Product Owner） 主要負責確定產品的功能和達到要求的標準，同時有權力接受或拒絕開發團隊的工作成果。– 流程管理員（Scrum Master） 使得每一時刻的需求都能明確，管理每一次需求變動，變動原因，將變動落實到實處。–開發團隊（Scrum Team） 根據任務優先級編排任務–測試人員 需求明確完之後，即可針對需求編寫驗收文檔。測試過程，編寫測試案例。6.5 流程
產品需求列表，由PO負責的；召開評審會議，去除不必要需求，確定需要開發的需求；簡單需求分發任務，複雜需求畫原型圖；分配任務；測試交付能產生80%效益的20%功能；持續迭代（迭代式開發），持續交付（增量交付）；6.6 敏捷開發最終定義
敏捷開發以用戶的需求進化為核心，採用迭代、循序漸進的方法進行軟體開發。
6.7 目的
管理好需求，提高開發效率
6.8 B站培訓視頻
本人B站培訓錄製視頻
版權聲明：本文為博主原創文章，遵循 CC 4.0 BY-SA 版權協議，轉載請附上原文出處連結和本聲明。 本文連結：https://www.cnblogs.com/JerryMouseLi/p/14203881.html