敏捷式開發管理——基於Teambiton平臺落地

敏捷式開發管理

目錄

• 敏捷式開發管理
  • 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
  • 6 我司執行的敏捷流程
    • 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.敏捷的原則

1. 咱們最優先要作的是經過儘早的、持續的交付有價值的軟件來使客戶滿意。
2. 即便到了開發的後期，也歡迎改變需求。敏捷過程利用變化來爲客戶創造競爭優點。
3. 常常性地交付能夠工做的軟件，交付的間隔能夠從幾個星期到幾個月，交付的時間間隔越短越好。
4. 在整個項目開發期間，業務人員和開發人員必須每天都在一塊兒工做。
5. 圍繞被激勵起來的個體來構建項目。給他們提供所需的環境和支持，而且信任他們可以完成工做。
6. 在團隊內部，最具備效果而且富有效率的傳遞信息的方法，就是面對面的交談。
7. 工做的軟件是首要的進度度量標準。
8. 敏捷過程提倡可持續的開發速度。責任人、開發者和用戶應該可以保持一個長期的、恆定的開發速度。
9. 不斷地關注優秀的技能和好的設計會加強敏捷能力。
10. 簡單——使未完成的工做最大化的藝術——是根本的。
11. 最好的構架、需求和設計出自於自組織的團隊。
12. 每隔必定時間，團隊會在如何才能更有效地工做方面進行檢討，而後相應地對本身的行爲進行調整。
    隨着時代的變遷，裏面的內容有些會變了，如第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