敏捷分享快三怎麼倍投最合適的方案

敏捷式開發管理
目錄
敏捷式開發管理
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 培訓視頻
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 一次具體的需求管理br/>什麼時候開始?
什麼時候結束?
負責人是誰?
完成之後交付給誰?@
需求生命週期,全週期覆蓋,需求的狀態管理



何爲全週期?即需求全部狀態的流轉以及停止流轉。

狀態的定義添加

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 培訓視頻
培訓錄製視頻

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章