心智圖資源庫 PMP-敏捷複盤
PMP考前敏捷開發相關知識及考點整理,內容有專案生命週期選擇、敏捷宣言、十二原則、Scrum框架、其他敏捷的概念、依照10個知識領域來看敏捷。
編輯於2023-05-18 23:36:51Il s'agit d'une carte mentale sur les anévrismes intracrâniens, avec le contenu principal, notamment: le congé, l'évaluation d'admission, les mesures infirmières, les mesures de traitement, les examens auxiliaires, les manifestations cliniques et les définitions.
Il s'agit d'une carte mentale sur l'entretien de comptabilité des coûts, le principal contenu comprend: 5. Liste des questions d'entrevue recommandées, 4. Compétences de base pour améliorer le taux de réussite, 3. Questions professionnelles, 2. Questions et réponses de simulation de scénarios, 1. Questions et réponses de capacité professionnelle.
Il s'agit d'une carte mentale sur les méthodes de recherche de la littérature, et son contenu principal comprend: 5. Méthode complète, 4. Méthode de traçabilité, 3. Méthode de vérification des points, 2. Méthode de recherche inversée, 1. Méthode de recherche durable.
Il s'agit d'une carte mentale sur les anévrismes intracrâniens, avec le contenu principal, notamment: le congé, l'évaluation d'admission, les mesures infirmières, les mesures de traitement, les examens auxiliaires, les manifestations cliniques et les définitions.
Il s'agit d'une carte mentale sur l'entretien de comptabilité des coûts, le principal contenu comprend: 5. Liste des questions d'entrevue recommandées, 4. Compétences de base pour améliorer le taux de réussite, 3. Questions professionnelles, 2. Questions et réponses de simulation de scénarios, 1. Questions et réponses de capacité professionnelle.
Il s'agit d'une carte mentale sur les méthodes de recherche de la littérature, et son contenu principal comprend: 5. Méthode complète, 4. Méthode de traçabilité, 3. Méthode de vérification des points, 2. Méthode de recherche inversée, 1. Méthode de recherche durable.
PMP敏捷複盤
專案生命週期選擇
預測型
傳統的項目,成熟的產業:如建築,製造業,IT產業
敏捷型
迭代
增量
混合型
公司轉過渡階段,從預測到敏捷
預測轉敏捷活項目一部分是預測,一部分是敏捷
預測或敏捷,以題目的答案作為選擇的方向
以關鍵字作為區分敏捷還是預測的題目
組織變革:從預測轉敏捷
先分析評估公司的文化以及轉型對公司的影響
進行自上而下的變革,讓公司各個層級的人都參與進來,了解變更的好處和變革勢在必行
可以選一個複雜度不高的專案作為試點,快速取得成功,為其他專案帶來信心
敏捷宣言
人員
個體互動勝過過程與工具
客戶合作勝過合約談判
價值交付
可用的軟體勝過完整的檔案
應對變更勝過遵循計劃
十二原則
價值交付
我們最重要的目標,是透過及時和持續不斷地交付有價值的軟體使客戶滿意
欣然面對需求變化,即使在開發後期也一樣。為了客戶的競爭優勢,敏捷流程掌控變化
經常地交付可工作的軟體,相隔幾星期或一兩個月,傾向於採取較短的周期
可工作的軟體是進度的首要度量標準
人員
業務人員和開發人員必須相互合作,專案中的每一天都不例外
激發個體的鬥志,以他們為核心搭建專案。提供所虛的環境與支援,輔以信任,從而達成目標
不論團隊內外,傳遞訊息效果最好效率也最高的方式是面對面的交談
敏捷流程倡導永續開發。責任人、開發人員和使用者要能共同維持其步調穩定持續
最好的架構、需求和設計出自組織團隊
團隊定期反思如何能提升成效,並依此調整自身的行為表現
流程
堅持不懈地追求技術卓越和良好設計,敏捷能力由此增強
技術負債(Technical debt)和重構
以簡潔為本,它是極力減少不必要工作量的藝術
Scrum框架
總體框架
總體框架
產品願景和產品路線圖
需要多少個版本才能實現最終的產品
發布計劃
1個版本確定了發布的迭代或衝刺次數
衝刺計劃
重點
敏捷專案章程
我們為什麼要做這個項目
專案願景
誰會從中受益
這可能是專案願景和/或專案目標的一部分
對此專案而言,達到哪些條件才意味著專案完成
專案的發布標準
我們將如何合作
預期的工作流程
團隊章程(團隊社會契約)
團隊價值觀
例如可持續的開發速度和核心工作時間
工作協議
例如「就緒」如何定義,這是團隊可以接受工作的前提;
例如「完成」如何定義,這樣團隊才能一致的判斷完整性;
考慮時間盒
使用工作過程限制
基本規則
例如有關一個人在會議上發言的規定
團隊規範
例如團隊如何對待會議時間
3355
3個角色
產品負責人
開發團隊
Scrum Master
3個工件
產品待辦事項列表
Sprint待辦事項列表
產品增量
5個事件
Sprint
Sprint規劃會議
每日站會
Sprint評審會議
Sprint回顧會議
5個價值觀
承諾
專注
開放
尊重
勇氣
3個角色
產品負責人PO (客戶代表、業務專家)
維護和更新產品待辦事項列表
產品負責人是管理產品待辦事項清單的唯一責任人
維護產品待辦事項列表,排優先順序
清楚描述和表達,讓團隊能夠充分理解產品待辦事項列表
判斷並批准產品增量是否完成
確定產品增量是否完成,符合DOD完成的定義
常出考點
PO必須是全職獨立的,不能由開發團隊或SM兼任
衝突途中,有新需求變更怎麼辦?
一般常規的新需求,現在PB表上,由PO進行優先排序,通常不在本衝刺做這個需求
題目強調法令要求,優先順序極高的需求,如果不馬上完成,會導致專案失敗,這種情況,一般是需要PO和團隊進行溝通,重新調整本次衝刺的目標,以便盡快完成關係專案生死存亡的需求
開發團隊
自組織團隊
一專多能,跨職能團隊
不認可開發團隊成員的頭銜,無論承擔哪種工作,他們都是開發者
最好是100%投入,全職團隊,克服組織孤島
追蹤太陽
常見考點
題目中遇到要求,命令,強制團隊去幹事的,直接排除
開發團隊自行決定和負責使用者故事的估算,工作的分配等等
Scrum Master 又被稱為敏捷教練,團隊促進者, Scrum主管,專案經理
要確保敏捷整個團隊和相關方遵循Scrum的理論、實務和規則
對於PO
確保他能理解PO的工作職責,包括如何維護和更新PB表
對於開發團隊
確保他能遵循日常敏捷事件,例如每日站會,例如使用透明化的工具等
對於專案外部
確保能理解敏捷實踐,例如需要了解進度可以看訊息發射源,需要了解使用者故事優先順序可以和PO溝通等
僕人式領導,服務式領導,專注於團隊成長,幫助團隊消除障礙
內在障礙
開發團隊遇到技術、流程等問題,協助解決而不是親自動手解決
外在障礙
SM去協商溝通外部相關方
常見考點
在敏捷環境中,SM不負責具體的工作分配,工作安排等
一般都是SM負責掃除外部幹擾團隊的一些因素和阻礙
3個工件
產品待辦事項清單 Product backlog
使用者故事
概念
作為一個<角色>,我想要<功能>,以便於實現<價值>
INVEST原則
Idependent(獨立的)
Negotiable(可協商的)
Valuable(有價值的)
Estimatable(可評估的)
Small(小的)
Testable(可測試的)
故事點
作為一個內部參照的標準,團隊內部使用。不同團隊之間對故事點多少的比較沒意義
估算使用者故事點
計劃撲克(寬頻德爾菲)
使用敏捷估算撲克的好處
促進團隊成員間的交流,可分享、了解更多的訊息
團隊對估算結果進行討論與評判,會讓估算結果更真實、客觀,避免許多過於武斷的決定
適用於一個具體的使用者故事或一個迭代的所用使用者故事
親和估算
適用於整個PB表,粗略的整體估算
包含內容
列出所有的特性、功能、需求、增強和修復對未來要發布的產品進行的改變
依照優先順序由高到底排列的一個序列,高價值高風險>高價值低風險>低價值低風險
排序越高的產品待辦事項清單條目更清晰、更具體,符合DOR,需要立即進行開發
持續動態更新,漸進明細
產品負責人負責
衝刺待辦事項清單 Sprint backlog
把優先順序高的使用者故事從PB表移動到Sprint Backlog,在這個衝刺由團隊決定要做多少個故事,並由團隊將使用者故事精進
刺探/探針
主要是為了獲取背景知識以知道某需求在技術上可行還是不可行,通常在無法有效估計使用者故事時採用此方法
至少包括一項在先前回顧會議中確定下來的高優先級流程改進
開發團隊負責,PO進行解答疑惑
產品增量 Product Increment
打到了「完成」的定義標準DOD
產品負責人決定是否完成,不管是否發布,增量必須保證可用和持續集成
5個事件
Sprint
翻譯為“衝刺”或“迭代”
時間2-4週(固定的時間盒 time box),5-9人
注意事項
不能做出有害於 Sprint 目標的改變
不能降低品質的目標
只有產品負責人才有取消Sprint的權力,由於Sprint的時間都很短,取消意義不大
Sprint規劃會議
做計劃
接下來的Sprint交付的增量要包含什麼內容
要如何完成交付增量所需的工作
注意事項
開發團隊自己決定選擇產品待辦清單項目的數量
產品負責人能夠幫助解釋清楚所選定的使用者故事,並做出權衡
參加人員
一般是SM、開發團隊、PO 共同參與,也可以邀請重要相關人士參加
每日站會
會議內容
昨天
我為幫助開發團隊達成Sprint目標做了什麼
今天
我為幫助開發團隊達成Sprint目標準備做什麼
是否有任何障礙在阻礙我或開發團隊達成Sprint目標
會後更新資訊發射源(看板、燃盡圖、瓦斯圖等)及問題看板
注意事項
只記錄問題而非討論問題,可會後專門相關人員進行問題解決會議
SM確保同一時間,同一地點舉行,一般建議團隊成員來主持,時長一般是15分鐘
常見考點
每日站會能夠即使跟進進度和糾偏
每日站會能夠避免同樣的工作被不同的成員重複進行
能夠及時發現問題和風險,在會後及時改進能夠最大限度地降低風險對專案造成的影響
參加人員
開發團隊(SM、PO、重要相關方視情況)
SOS會議(Scrum of Scrums)
Sprint評審會議 review meeting
檢視產品增量,獲得回饋
開發團隊展示產品增量,PO邀請利害關係人參與,PO確定產品增量是否完成
調整產品待辦事項列表
闡明很可能進入下個Sprint的產品待辦清單項
Sprint評審會議的結果是一份修訂後的產品待辦列表
參加人員
客戶
重要相關方
PO
SM
開發團隊
Sprint回顧會議 Retrospective meeting
回顧哪些做得好,哪些需要改進,需要改進的內容放到下一個Sprint裡面跟進(持續改進)
參加人員
SM
開發團隊
PO(視情況)
5個價值觀
承諾
願意對目標做出承諾
專注
把你的心思和能力都用到你承諾的工作上去
開放
Scrum把專案中的一切開放給每個人看
尊重
每個人都有他獨特的背景和經驗
勇氣
有勇氣做出承諾,履行承諾,接受別人的尊重
其他敏捷的概念
看板管理
可視化的工作流程
一個白板,一些卡片就可以創建
消除瓶頸
WIP(Work In Progress)在製品的限制
常見考點
題目提到專案工作流程混亂,造成一些工序阻塞,看板管理能有效解決這個問題
題目提到其他的流程或工序進行非常順利,只有某一道工序遇到了瓶頸,造成整個流程的進度延遲,可以考慮把其他流程的跨職能團隊成員分派過來整個瓶頸的流程
MVP(Minimum Viable Product)
快速地建立出符合產品預期功能的最小功能集合,這個最小集合所包含的功能足以滿足產品部署的要求並能夠驗證有關客戶與產品互動的關鍵假設
用最少資源、最短時間做實驗,獲得早期使用者的回饋
常見考點
客戶無法明確確定需求,可以建立初步產品原型,透過後續回饋和修正,最終滿足客戶需求
在市場不確定的情況下或風險比較大的時候,透過MVP設計實驗來快速檢驗你的產品或方向是否可行
依照10大知識領域來看敏捷
整合
把對具體產品的規劃和交付授權給團隊來控制。團隊成員自行決定規劃和整合方式
專案經理的關注點在於營造一個合作型的決策氛圍,並確保團隊有能力應對變更
敏捷不存在變更控制流程的說法,敏捷是擁抱變更
範圍
敏捷方法有目的地建立和審查原型,並透過發布多個版本來明確需求。這樣一來,範圍會在整個專案期間被定義和再定義
每次衝刺開始前都定義範圍
Sprint規劃會議和Sprint的待辦事項列表
每次衝刺結束前都確認範圍
Sprint的評審會議review和產品增量的批准
進度
產品願景、發布規劃與迭代計畫之間的關係
具有未完項的迭代進度計劃
是一種基於適應性生命週期的滾動式規劃。這種方法需求記錄在使用者故事中,然後在建造之前按優先順序排序並優化使用者故事,最後在規定的時間盒內開發產品功能。此方法通常用於向客戶互動增量價值,或多個團隊並行開發大量內部關聯較小的功能
按需進度計劃
通常用於看板體系,基於限制理論和來自精實生產的拉動進度計畫概念,根據團隊的交付能力來限制團隊正在進行的工作。按需進度計劃方法不依賴先前為產品開發或產品增量指定的進度計劃,而是在資源可用時立即從未完項和工作序列中提取出來開展
控制進度工具
資訊發射源
燃盡圖
燃起圖
成本
採用輕量估算方法
詳細的估算適用於採用準時制的短期規劃
品質
規劃品質管理
DOD的定義
管理和控製品質
循環回顧,定期檢查品質過程的效果,尋找問題的根本原因,實施新的品質改進方法
專注於小批量,可以頻繁交付
測試驅動開發TDD,持續集成
資源
得益於最大限度地集中和協作的團隊結構,例如擁有通才的自組織團隊
溝通
盡量簡化團隊成員獲取資訊的管道,頻繁進行團隊檢查,並讓團隊成員集中辦公
集中工作
日常工作:每日站會
需要以透明的方式發布專案工件,並定期邀請相關方評審專案工件
日常工作:資訊發射源
報告溝通:衝刺評審會議
虛擬團隊
魚缸窗口
建立長期視訊會議鏈接
遠程結對
透過使用虛擬會議工具來共享螢幕,包括語音和視訊鏈接
風險
迭代規劃的時候,應該考慮風險
在迭代期間應該識別、分析和管理風險
應該根據對當前風險敞口的理解的加深,定期更新需求文件,並隨專案進度重新排列工作優先級
採購
可能需要與特定賣方合作擴充團隊。這種協作關係能夠營造風險共擔式採購模型,讓買方和賣方共擔專案風險和共享專案獎勵
靈活的協議
多層結構
主協議
補充協議
相關方
提倡高度透明
例如,邀請所有相關方參與專案會議和審查,或將專案工件發佈到公共空間,其目的在於讓各方之間的不一致和依賴關係,或與不斷變化的專案有關的其他問題,都盡快浮現
高度變化的項目更需要專案相關方的有效互動和參與。為了進行及時且搞笑的討論及決策,適應性團隊會直接與相關方互動,而不是透過層層的管理級別