敏捷式開發管理
目錄- 敏捷式開發管理
- 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 Scrum
- 5.1 DevOps
- 6 我司執行的敏捷流程
- 6.1 特點：迭代式開發
- 6.2 任務管理
- 6.2.1 需求管理
- 6.2.1.1 一次具體的需求管理
- 6.2.2 缺陷管理
- 6.2.1 需求管理
- 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
轉載請註明出處，本文鏈接：https://www.uj5u.com/gongcheng/241814.html
標籤：其他
上一篇：專案中的Git使用規范
下一篇：專案中的Git使用規范