当前位置:网站首页>【項目管理/PMP/PMBOK第六版/新考綱】純幹貨!敏捷型/Stacey矩陣/vuca/敏捷宣言/沖刺/產品負責人/敏捷團隊/敏捷教練/待辦事項列錶/迭代任務列錶/可交付產品增量

【項目管理/PMP/PMBOK第六版/新考綱】純幹貨!敏捷型/Stacey矩陣/vuca/敏捷宣言/沖刺/產品負責人/敏捷團隊/敏捷教練/待辦事項列錶/迭代任務列錶/可交付產品增量

2021-09-15 05:04:09 程序員大本營

系列文章目錄

  1. 一篇文章看懂PMP的2021新考綱重點(建議收藏)
  2. 項目發展史/項目定義/項目集/項目組合/十五至尊圖
  3. 商業論證/效益管理計劃/項目運行環境/組織過程資產/環境事業因素/組織系統

項目生命周期-敏捷型

  • 產品目標、範圍、需求都是不明確的,只有通過持續不斷的迭代開發和確認,才能完成最終產品
  • 敏捷需求變化大,是受變更驅動的,含有增量和迭代的成本,需要用戶持續參與
  • 敏捷開發中後面的迭代有可能是對前面迭代產品的修正、完善甚至顛覆

在這裏插入圖片描述

Stacey矩陣

通過對需求和技術的兩個緯度的明確程度,幫助開發者選擇不同的開發方法。

最常見的示意圖是下面的這種

在這裏插入圖片描述
英文原版的示意圖是這樣的

接近確定性: 當因果關系確定時,問題或决策也接近確定性。當過去一個相似問題或决策發生時,通常是這樣的。人們可以非常確定地從過去推斷和預測行動的結果。

遠離確定性: 確定性連續的另一端是遠離確定性的决策。對决策制定者而言,這些情况常常是獨特和新穎的。因果關系不是很明朗。從過去的經驗推斷,在遠離確定性的範圍預測不是一個良好的方法。

項目生命周期-混合型

混合型 = 預測型(瀑布型) + 適應型(敏捷型)

vuca時代

VUCA是指組織將處於"不穩定"(Volatile)、“不確定”(Uncertain)、“複雜”(Complex)、和"模糊"(Ambiguous)狀態之中。

在這裏插入圖片描述

不穩定

  • V=Volatility(易變性)是變化的本質和動力,也是由變化驅使和催化產生的。
  • 特點:挑戰本身與維持的時長是未知並且不穩定的,但是並非難以理解。相關信息通常是現成的。
  • 舉例:一場自然灾害使得供應鏈脫節,繼而導致產品價格波動。
  • 做法:勤於閑時,將資源投入到預備力上,例如,保持庫存和儲備人才。這些措施通常意味著大額的花銷,但是投資應與風險程度匹配。

不確定性

  • U=Uncertainty(不確定性)缺少預見性,缺乏對意外的預期和對事情的理解和意識
  • 特點:盡管缺乏額外信息,事件的基本因果關系已知。具備變革的可能性,但不一定成功。
  • 舉例:競爭者的新產品發布懸而未决,業務與市場的未來不够明朗。
  • 做法:將資金投入信息的搜集、分析,並分享你的所得。這一做法與組織結構變革相結合時效果最佳,例如用信息擴大分析網絡,降低不確定性。

複雜性

  • C=Complexity(複雜性)企業為各種力量,各種因素,各種事情所困擾。
  • 特點:這種情况包括許多相互連通的變量,有些信息是現成的,或能預測到。但想清晰地梳理其複雜程度與本質並非易事。
  • 舉例:生意遍布多個國家,每個國家的監管環境千差萬別,關稅體系以及文化價值觀也各不相同。
  • 做法:重組、聘用或培養專業人士,積累重組資源,應對複雜性。

模糊性

  • A=Ambiguity(模糊性)對現實的模糊,是誤解的根源,各種條件和因果關系的混雜。
  • 特點:因果關系往往是不清晰的。沒有先例可供參考,你面對的是“不確定中的不確定”
  • 舉例:决定將業務拓展到未成熟的市場或新興市場,或在主營業務範圍之外開發新產品。
  • 做法:試驗。理解因果關系需要不斷提出假設,確保你能够從中得到教訓,並將成果廣泛應用到實際中。

敏捷宣言

原版官網 http://agilemanifesto.org/iso/zhchs/manifesto.html

敏捷宣言强調的敏捷軟件開發的四個核心價值是:

  • 個體和互動高於流程和工具
  • 工作的軟件高於詳盡的文檔
  • 客戶合作高於合同談判
  • 響應變化高於遵循計劃

也就是說,盡管右項有其價值,我們更重視左項的價值。

沖刺

在這裏插入圖片描述

Product Owner 產品負責人

  • PO是有授權的產品領導力核心,是Scrum團隊的三大角色之一。

日常工作內容

  1. PO參與組合規劃
  2. PO參與產品規劃,與利益幹系人一起構思新產品。
  3. Sprint前,PO負責制定Sprint計劃。
  4. Sprint內,PO要參加Daily Meeting。例會上聽取情况,了解進展,提供協助。
  5. PO必須每天能够解答問題,並進行驗收測試。
  6. Sprint內,PO還要確定下個Sprint的計劃及優先級順序
  7. PO參與Sprint Plan,對產品列錶進行梳理。
  8. Sprint結束時,PO要參與show case 和 Sprint RetroSpect

Scrum Team 敏捷團隊

  • 敏捷團隊對交付成功負責
  • 高度自治
  • 人少,够開發功能
  • 跨職能部門

Scrum Master 敏捷教練

不是團隊領導者,也不是項目經理,更不是經理。

Scrum Master 是反饋環中重要的角色(另外一個反饋環是 Scrum 中的事件),他是一個支持角色,更像是團隊的一面鏡子,幫助團隊識別出現在的問題,從而能够走向“完美”的目標。

在這裏插入圖片描述
對以下方面負責

  1. 團隊
  2. 產品負責人
  3. 組織
  4. 開發實踐

Product Backlog 待辦事項列錶

根據路線圖及其需求為開發團隊列出的工作的優先級列錶

  1. 產品負責人在項目開始時對backlog進行優先級排序,但是當來自開發人員和涉眾的反饋不斷湧來時,他不會對backlog進行調整。
  2. 團隊將backlog上的條目限制為那些面向客戶的條目。
  3. 待辦事項列錶以文檔的形式保存在本地,並且不經常共享,防止相關方獲得更新。

在這裏插入圖片描述

Sprint Backlog 迭代任務列錶

  • 每個 Sprint 的需求庫,在每個迭代規劃時會選擇當前迭代需要完成的需求或者大的缺陷。

  • 一種做法是 PO 可以先規劃好 Sprint Backlog,然後和 Scrum Members 一起討論本次 Backlog 規劃。也可以整個敏捷團隊在做 Sprint Plan 時一起規劃這次迭代的 Backlog。

  • 大概原則:Sprint Backlog 應該是可完成的,Backlog 的工作量應該是可度量的,包含每個需求的工作量評估。對 Member 來說有的 Story 是有挑戰性的。

  • 狀態:基於 Scrum 團隊自身的特點進行定義即可,常規做法如:ToDo-Doing-Done-Testing-Finish 等等,格式不局限。目的讓整個團隊很直接的看到當前迭代 Sprint 的整體狀態即可。

Increment 可交付產品增量

沖刺結束,團隊可以交付的產品增量
這應該是潜在可發布的,指的是產品質量達到發布的標准
是否發布由產品負責人做最後的决定

總結

作為新考綱的新增內容,敏捷開發的內容和細節實際上非常多,對於沒有IT項目研發經驗的同學來說有些難,推薦參考其他知識體系中的敏捷多學習相關內容。

可以關注我下,這樣就不會丟掉之後的重點~

版权声明
本文为[程序員大本營]所创,转载请带上原文链接,感谢
https://chowdera.com/2021/09/20210915050047036S.html

随机推荐