《术以载道》读书笔记4：Scrum敏捷项目管理

01 前言

这一章节主要讲以Scrum为代表的敏捷实施办法的相关知识，Scrum敏捷实践应该来说是比较常用的，这一章也算是温故知新，查缺补漏吧~

02 CMMI与敏捷对比

相同点：

1-目的相同，都是为了按时、按质的实现需求，交付客户

2-都认为每个人都会犯错

不同点：

1-实现方法不同

以CMMI为代表的规范方法是这样的设想：通过遵循规范的过程可以降低犯错的概率。

如何保证过程按规范执行了？  ———— QA检查

怎么检查？ ———— 通过检查过程执行时留下的证据

过程完好等于结果完好吗？  ———— 不等于。因为过程中的证据客户可能并不关注，是否对客户有直接作用也未必，无用功也说不准

那以Scrum为代表的敏捷实践方法呢？

相信胜任工作与互相协同的人是敏捷方法的核心基础。

即使过程中出了错，也可以及时纠正，强调好的结果更胜好的过程

2-侧重点不一样

CMMI强调了通过过程保证来确保结果的达成，在过程监督与执行上要求更严格

Scrum强调在产品本身上投入更大的质量成本

但是目前市场对对这两种方法存在误解的人太多了，比如

都敏捷了不需要管理，不需要文档

CMMI就是要文档

这些不全面认识导致的言论确实有点玷污了敏捷或是CMMI的名声

CMMI之前我们叙述过，那以Scrum为代表的敏捷是咋样的呢

03 Scrum敏捷项目管理是怎样的

# 3个角色

Scrum Master（敏捷教练）

注意，Scrum Master不是项目经理，他/她不会对团队成员分配任务或者考核，他的主要职责可以概括如下：

会议主持人：主持Scrum的4大会议（迭代计划会、每日站会、迭代评审会、迭代回顾会）

牧羊犬/清道夫：屏蔽项目组外部的干扰，清楚项目组内部的各种障碍

外交官：负责对外发布项目组的信息

教练：最重要的一点，将敏捷文化与思想传播至每一个项目成员

Scrum Master从过程上保证如何实现项目

Product Owner（PO、产品负责人、需求负责人）

PO（此处是简称）是产品需求的负责人，他/她主要承担以下职责

需求决策人：需求的重要性、优先级、发布内容等

需求讲师：对项目组成员讲解需求的含义，答疑

Product Owner 定义项目做什么

Team Member (团队成员）

从技术上保证如何实现项目

# 3个文档

Product Backlog（产品代办事项列表）

Product Backlog列举了本项目需实现的需求，采用用户故事的形式进行描述，即：

作为一个用户角色

我需要XX功能

达到XX目的

此外，我觉得验收标准和优先级也应在此处明确

Sprint Backlog（任务列表）

某一个迭代的任务列表，可以类比为活动级别的WBS

例如，在PB里有这么一个列表

作为系统的合法登录用户，可以通过输入账号密码登录系统，以便进行操作

那对应的任务列表可能会有：

### 单元测试程序编写

### 界面设计

### 密码校对算法设计

### 程序调试

简而言之，Sprint Backlog就是定义实现某个用户故事必须要做的事，有TeamMember一起头脑风暴确定。

Burn Down Chart（燃尽图）

这个我觉得是敏捷的神器。

以一个图展示，横坐标是日期，纵坐标是生育的工作量，还有一条控制线。

如果趋势线在控制线之上，项目做偏了....十有八九要延期

如果趋势线在控制线之下，项目进度良好，可能会提前完工

# 4个会议

Sprint Planning （迭代计划会）

迭代开始前召开

项目组全员参与

需求讲解，估算，开发任务分配等

输出规模与工作量，Sprint Backlog

Daily Meeting （每日站会）

每天早上定时召开

项目组全员参与

进展汇报与信息同步

输出燃尽图

Sprint Review （迭代评审会）

迭代结束后召开

项目组全员参与、客户及相关利益方代表参加

演示可工作的软件、评审完成的功能

输出修改后的Product Backlog，可工作的软件

Sprint Retrospective（迭代回顾会）

迭代结束后召开

项目组全员参与

经验教育总结

输出经验教育总结，更新团队协议