上次分享的課程內容是：敏捷專案管理中的幾個及職責

本次分享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

這就是敏捷的全部流程

​