ACP敏捷專案管理微課-敏捷管理流程及框架(丁仿)
上次分享的課程內容是:敏捷專案管理中的幾個及職責
本次分享SM 框架及流程
各位群友大家好,本群ACP敏捷專案管理微課今日主題:敏捷專案管理框架及流程
傳統的專案管理,有自己的管理過程,比如我們的5大過程組
那麼在敏捷裡面,也有自己的流程,簡單來說如下圖:
ACP|PMP顧問-布丁 14:32:01
詳細如下圖:
ACP|PMP顧問-布丁 14:32:47
首先,來自我們的客戶、市場或者高階管理層提供給我們這個專案或者產品的介紹
ACP|PMP顧問-布丁 14:33:36
接著PO(產品負責人)建立產品的願景,通過梳理活動分解為一組特性,並收集到按優先順序排序的列表中,也就是我們的PBI
ACP|PMP顧問-布丁 14:34:04
PBI(Product Backlog Items)中的條目,都是經過產品的功能價值或者優先順序初步排序的內容
ACP|PMP顧問-布丁 14:35:36
首先,PO要建立和維護Product Backlog
那麼隨著細化,在後續的每個sprint開始的時候,還可能會重新排定優先順序。
ACP|PMP顧問-布丁 14:36:56
需求必須進行條目化管理,才能進行分配、開發、跟蹤,才能描述什麼做完了什麼沒做完。“客戶價值角度”就是描述使用者如何使用,而不是描述技術層面如何實現。所以,我們可以看到敏捷的出發點,一直都是從業務價值的角度出發。
ACP|PMP顧問-布丁 14:37:37
至於user story如何分解,後續會安排專題。這就是第一個模組
ACP|PMP顧問-布丁 14:38:30
接下來進入到我們的Sprint meeting
ACP|PMP顧問-布丁 14:39:00
PO先向團隊介紹產品的背景和功能概述,並確定本次Sprint的目標
這個過程,一般我們會用一個白板牆,方便及時設計和溝通
ACP|PMP顧問-布丁 14:40:31
Sprint計劃會議,一般分兩部分,上半部分主要討論:做什麼,下半部分主要討論:怎麼做
ACP|PMP顧問-布丁 14:41:02
Sprint計劃會議1: 做什麼
1. 分析和評估 product backlog
2. 確定sprint目標
3. 排定優先順序
ACP|PMP顧問-布丁 14:41:50
Sprint計劃會議2: 怎麼做
1.決定怎樣實現sprint目標 (設計)
2.從產品backlog中建立sprint backlog
3.估計sprint backlog 故事點
ACP|PMP顧問-布丁 14:43:10
這裡面其實就設計到敏捷裡面非常重要的部分,比如如何去做分解,估算使用者故事的規模
ACP|PMP顧問-布丁 14:44:55
使用者故事:可以更好的交流,避免冗長的文件,從業務價值角度出發。一般用一些便籤卡片,使用者故事有自己的模版
ACP|PMP顧問-布丁 14:46:07
在排序中,我們可能會使用一些XP裡面的一些方法,比如MoSCoW方法等,User Stroy這個也是來自於XP中的一些實踐。
ACP|PMP顧問-布丁 14:46:34
方法和工具,大家先了解這個名次,後續會介紹如何使用,本次只介紹框架。
ACP|PMP顧問-布丁 14:47:20
Tasks的估算,一般會使用”計劃撲克“,跟我們PMP裡面的Delphi技術原理是一樣的
上海-諮詢-奧雷風骨 14:47:21
能舉一些使用者故事的簡單例子嗎,謝謝
ACP|PMP顧問-布丁 14:48:10
使用者故事的語法“作為一個……,可以……,以(以便)……”
ACP|PMP顧問-布丁 14:49:37
比如:
作為 一個【QQ群管理員】
我想要 【一鍵修改群成員名片】
以便 【群友能夠更好的認識】
ACP|PMP顧問-布丁 14:50:09
採用比較直觀的方式,關注業務價值。寫在故事卡上,⽅便交流和討論。
廣州 - IT – Steven 14:50:16
我想要檢視成員最後發言日期, 以便清理成員
ACP|PMP顧問-布丁 14:50:41
而且,我們後續做估算的時候,也是直接拿出這些小卡片,然後來估算,將估算的故事點大小,寫到卡片的一角
ACP|PMP顧問-布丁 14:51:00
@廣州 - IT - Steven 是的,這個是一個使用者故事,但是這裡有個不是很好的描述是“我”,這個使用者角色,沒有列出來。你是群成員,還是管理員,還是群主等
廣州 - IT – Steven 14:51:16
哦, 對 是 群管理員
ACP|PMP顧問-布丁 14:51:31
所以,user story我們有個叫INVEST原則.下次講這個,本次先介紹框架,不能太展開,要不然時間不夠呀
ACP|PMP顧問-布丁 14:52:41
SP meeting的階段,產出物主要有SBI,也就是:sprint backlog items
ACP|PMP顧問-布丁 14:53:55
接下來,Dev Team,按照這個SBI,開始進入我們的sprint(衝刺)過程
ACP|PMP顧問-布丁 14:54:35
這裡面,為什麼要做故事點的估算,就是因為我們一個sprint一般2-4周,我們的dev team要估計這個srpint我們能承諾完成多少事情
ACP|PMP顧問-布丁 14:55:22
假設我們2周,有2*4*5=40小時的工作時間(假設:每天有效工作時間4小時)
ACP|PMP顧問-布丁 14:56:00
那麼我們在挑選SPI的時候,我們就按照這個優先順序,挑出來40個小時的tasks就行,超出的部分,我們下個迭代再做。
ACP|PMP顧問-布丁 14:56:46
接下來進入到我們的sprint過程:
ACP|PMP顧問-布丁 14:57:21
看這裡圖,這個srpint是一個閉環,意思是這個是一個完整的衝刺,而且,不能被外界打擾
ACP|PMP顧問-布丁 14:57:44
這也就要求我們的SM、PO要保護好我們的DEV team
ACP|PMP顧問-布丁 14:58:17
在迭代週期裡,我們不能變更,要變更,放到PBI裡,我們dev team再評估他的優先順序及價值
深圳-IT-DT 14:58:17
每日站會真的有必要開嗎
ACP|PMP顧問-布丁 14:58:33
等下講daily meeting
ACP|PMP顧問-布丁 15:00:03
先介紹每日站會的內容及形式:
1、昨天完成了什麼?
2、今天打算完成什麼?
3、遇到什麼阻礙或者困難?
ACP|PMP顧問-布丁 15:00:24
這裡參與人員是Dev Team,PO最好也可以參加,SM看情況
ACP|PMP顧問-布丁 15:00:37
很多企業把這個daily meeting開成了彙報會.
敏捷團隊是自組織的,所以,不需要向誰彙報,團隊成員直接相互承諾
ACP|PMP顧問-布丁 15:01:02
而且,最好是固定時間、地點,dev team養成良好的習慣
ACP|PMP顧問-布丁 15:02:23
至於為什麼說建議每天開的原因:
1、彼此瞭解每個人做了什麼,團隊之間的承諾,比如我昨天承諾說今天完成什麼事情,結果第二天還是在承諾完成這個事情…臉面上也掛不過去
2、在遇到的問題時候,可以及時的提出來,你不會的,說不定其他人有解決方案
3、讓團隊保持一個固有是節奏,節奏很重要。
ACP|PMP顧問-布丁 15:03:05
當然,還有其他很多原因。
ACP|PMP顧問-布丁 15:04:07
如果是線下的團隊,最好用物理白板,這樣大家可以只管的看到,現在團隊當前的進度情況,也便於瞭解風險,而且,我們會每天更新這個burndown chart,看下團隊當前的速率如何
至於daily meeting如何開,如何高效,現實中又有哪些衝突,我們後續也會單獨介紹
ACP|PMP顧問-布丁 15:06:42
daily meeting,也是一個團隊不斷審視自我的過程
ACP|PMP顧問-布丁 15:07:56
目前已經到了實施階段了
ACP|PMP顧問-布丁 15:09:43
在這個sprint中,產出了可交付的產品增量。這裡是可以工作的軟體,並不是說在程式設計師的電腦上是可以執行的…
ACP|PMP顧問-布丁 15:09:57
我們經常聽到程式設計師的10大謊言
ACP|PMP顧問-布丁 15:10:18
①我以後給程式碼加註釋。
②這是臨時辦法釋出時不會這樣寫。
③已經開發完只剩幾個小問題。
④開發:需要10天。老闆:5天能完嗎?開發:可以!
⑤TODO。
⑥在我機器上是好的。
⑦這不需要測試肯定是好的!
⑧以前就有這問題。
⑨只需改一行程式碼不會影響其它程式。
⑩這是硬體問題跟軟體無關。
深圳-IT-DT 15:11:12
11.以上每一條都是真的
廣州-IT-大白 15:11:20
+1
ACP|PMP顧問-布丁 15:12:07
所以,我們這裡說的是:可以工作的軟體
敏捷不提倡冗長的文件,這在第一次的分享中我們也介紹了。
有時候我們演示,寫了一大堆的文件或者漂亮的PPT,敏捷裡面,不提倡。
ACP|PMP顧問-布丁 15:13:03
直接演示你可以工作的軟體,或者直接讓關鍵干係人來體驗一下
ACP|PMP顧問-布丁 15:13:31
接下來進入到我們的review meeting
ACP|PMP顧問-布丁 15:15:06
目標:根據團隊這次 Sprint 所釋出的版本,評審相關的 Backlog 中的問題,檢查是否已達到Sprint 的目標。這個是檢視團隊的過程,也是對當前做的是否是客戶最關心的,最優價值的事情的一個判斷。
ACP|PMP顧問-布丁 15:17:11
而且,2-4周,出一個迭代版本,團隊也能看到自己的成果,客戶也能看到自己要的東西。拿到手的,才是最有感覺的,再多的文件,都抵不過一個可以直接執行的軟體,客戶才會為你的可交付成果買單,也可以快速的達到自己的迴圈
ACP|PMP顧問-布丁 15:18:28
Scrum團隊在衝刺結束時要執行兩個“檢視與調整”活動。
第一個就是我們剛說的Review meeting,利益干係人和Scrum團隊檢視正在構建的產品
第二個活動稱為回顧會議,Retrospective Meeting
ACP|PMP顧問-布丁 15:19:01
在每個迭代後召開簡短的反思會。
總結哪些事情做的好,哪些事情做的不好。制定改進計劃。
ACP|PMP顧問-布丁 15:19:14
也是我們常說的PDCA的過程,不斷優化團隊的過程
在完成衝刺回顧之後,再次重複整個過程,開始下一個衝刺規劃會議。
ACP|PMP顧問-布丁 15:21:19
這就是敏捷的全部流程