张传波老师的Scrum学习心得

一.什么是敏捷？敏捷是神马？

1.敏捷各路诸侯：

OpenUP、精益开发、极限编程（UP）、SCRUM、MSF（微软解决方案框架）、水晶方法、特性驱动开发

2.敏捷的四大宣言：

个体和互动更加优于流程和工具

工作的软件更加由于详尽的文档

客户合作更加优于合同谈判

相应变化更加优于遵循计划

3.十二准则
1.我们的最高目标是，通过尽早和持续地交付有价值的软件来满足客户
2.登建对霸苦需竞争程是在项目开发后期，要善于利用霸求
3.要不断交付可用的软件，周期从几周到几个月不等，且越短越好。
4.项目过程中，业务人员与开发人员必须在一起工作
5.龍无程目人员，给他们以所需要的环境和支持，井相信他们
6.无论是团队内还是团队间，最有效的沟通方法是面对面的交谈。
7.可用的软件是衡量进度的主要指标8敏捷过程提倡可持续的开发。
8.项目方、开发人员和用户应该能够保持恒久糖定的进展速度           
9.对技术的精益求精以及对设计的不断完善将提升敏捷性
10.要做到简洁，即尽最大可能减少不必要的工作。这是一门艺术。
11最佳的架构、需求和设计出自于自组织的团队。
12团队要定期反省如何能够做到更有效，并相应地调整团队的行为

4.SCRUM是神马？

SCRUM是近年来最火的敏捷方法论

SCRUM中文翻译为：橄榄球；

SCRUM适用于大中小型项目

SCRUM核心内容：团队架构和软件研发框架

二.SCRUM的团队架构

1.传统的团队架构

项目经理带领下有：系统分析员、软件设计师、程序员、测试工程师、实施工程师、配置管理员、QA

2.实际的团队架构（分等级层次）

项目经理（团队的头）下带领的：

两种决策——系统分析员、软件设计师

以程序员为核心

测试工程师和实施工程师次之

配置管理员和QA为末端

3.SCRUM的团队角色：产品负责人、SCRUM Master、“自组织”的开发团队

4.产品负责人=产品经理？

产品负责人的主要职责：

提供愿景

提供边界

提供用户故事的优先级

结果为产品负责人≠产品经理

5.团队协作示例

团队协作有产品负责人、业务分析师、测试人员和程序员构成

其中共需完成10项任务，各自任务如下

产品负责人：讨论用户需求、给FedEx指定测试

业务分析师：讨论用户需求、给FedEx指定测试、调查DHL、给DHL指定测试

测试人员：讨论用户需求、给FedEx指定测试、FedEX测试自动化、给DHL指定测试、DHL测试自动化、加入构建

程序员：讨论用户需求、支持FedEX设计、编码和单元测试、加入构建、支持DHL设计、编码和单元测试

三.SCRUM佳实践

1.用户故事：

   示例：-作为网络的所有者，我希望能统计广告的点击次数，以便我能清楚广告收益

   标准格式：-作为……角色——从用户的角度来思考问题

                     -希望系统可以......(目标)——思考系统要实现什么功能，达到什么效果等

                     -以便......（原因）——思考这个功能对于用户有什么价值

   非常方便讨论！

2.用户故事的难点：

需求由一系列大小不一定的用户故事组成
最开始的用户故事往往是大故事，需要拆分为中故事，小故事。
难点:

发现和提炼用户故事，由粗到细的拆分用户故事，实现用户故事的优先级分派到不同的sprint中去实现

3.开始分解用户故事：

从第一个用户故事开始分解。

-细分“以便......”这部分

-反向思考“希望系统可以......”部分

进行系统涉众分析，列出关键用户

-思考个用户在本项目上的利益所在

-思考“希望系统可以”这部分

-思考“以便......”这部分，确认“希望系统可以......”这部分的是否合适

4.用户故事到底要拆分到多细？

两大标准：

-能在一个Springt中完成

-加入满意条件（详细要求）

例如：

-以下用户故事可在一个Sprint中完成：

作为负责市场的副总裁，我想在评估以往广告促销活动的效果时可以选择节假日季节，以便我能确认那些有利润的促销活动。

“满意条件”示例：

确保它可以工作在大部分零售节假日

支持跨2个日历年的节日

节假日季节可以从某个节假日到另一个设定

节假日季节可以设置为改节假日前面的某些天

不用支持中国的春节

四.Product Backlog和Sprint Backlog

1.Product Backlog：

-中文翻译：产品代办列表

-产品需要完成的所有用户故事的集合

-用户故事有大有小，既有史诗级别，也有小颗粒级别。

2.Sprint Backlog：

-中文翻译：冲刺代办列表

-Sprint中需要完成的所有用户故事的集合

-Sprint中的用户故事都可以在该Sprint中完成，并且都应该有满意条件

3.Sprint-1

一个Sprint就是一个小版本

建议时长是一个月

一个Sprint并不是一个“小瀑布”

-很难区分需求、设计、编码、测试阶段

-所有工作基于对用户故事的讨论

-测试先行，测试驱动，单元测试必不可少

-设计也是“涌现”式的

4.Sprint-2

产品负责人和“自组织”开发团队商量并规划每个Sprint的用户故事

估算用户故事：

精准估算有“满意条件”的用户故事

精准估算规划在Sprint中的用户故事

粗略估算或暂不估算大中粒度的用户故事

估算由“自组织”开发团队负责

精准估算时，单位建议为小时；粗略估算时，单位建议为天

5.Burn Down Chart（燃尽图）

用来追踪Sprint未完成工作的情况

以未完成工作为纵轴，第1天到第30天为横轴，用户故事、故事点和工作量为计量单位

理想曲线为未完成的工作由第一天到第30天称直线y=-x降低，到第30天为0

实际曲线在第一天到第十五天小幅度降低，第十六天到第三十天大幅度降低，并在第三十天为零

6.Sprint中的一些最佳实践

结对编程

持续集成

测试驱动、测试自动化

每日会议

Lessons Learned（经验教训总结）