关闭

ACP敏捷项目管理微课-敏捷管理流程及框架(丁仿)

标签: ACP培训PMI-ACPACP考试敏捷流程丁仿
309人阅读 评论(0) 收藏 举报


上次分享的课程内容是:敏捷项目管理中的几个及职责


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

这就是敏捷的全部流程



0
0

查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    个人资料
    • 访问:10783次
    • 积分:207
    • 等级:
    • 排名:千里之外
    • 原创:10篇
    • 转载:4篇
    • 译文:0篇
    • 评论:0条
    文章分类