大纲

• 神马是敏捷？

• SCRUM是神马？

• SCRUM的团队架构

• SCRUM的最佳实践

  • 用户故事
  • Sprint（冲刺）
  • Burn Down Chart（燃尽图）

1.神马是敏捷？

 敏捷各路诸侯：极限编程（XP）、SCRUM、MSF（微软解决方案框架）、OpenUP(RUP敏捷版)、精益开发、水晶方法、特性驱动开发

什么是敏捷？

• 美国敏捷联盟提出四大宣言和十二条准则
• 敏捷宣言：
  
  • 个体和互动更优于流程和工具
  • 工作的软件更优于详尽的文档
  • 客户合作更优于合同谈判
  • 响应变化更优于遵循计划

  靠左更敏捷，靠右更接近传统开发模式

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

2.SCRUM是神马？

• 近年最火的敏捷方法论
• SCRUM中文翻译：橄榄球
• SCRUM适用于大中小性项目
• SCRUM核心内容
  • 团队架构
  • 软件研发框架
    

3.SCRUM的团队架构

• SCRUM的团队角色
  • 产品负责人
  • SCRUM Master
  • “自组织”的开发团队
    
    
• 产品负责人（产品经理）
  • 主要职责：
    • 提供愿景
    • 提供边界
    • 提供用户故事的优先级
  • 要特别注意：
    • 需要和开发团队沟通需求
    • 需要考虑开发团队的研发能力
      
      
• SCRUM Master（相当于教练角色）≠项目经理
  • 没有行政权利
  • 训练团队用正确的方法做事，遵循SCRUM的流程和做事原则
  • 不代替团队做决定
    
    
• “自组织”的开发团队有什么角色？
  • 业务分析师
  • 程序员
  • 测试人员
  • 软件架构师
  • 数据库设计师
  • 用户体验设计师
  • ……
    
    
• 怎样才是“自组织”？——SCRUM Master领衔，其他成员听从指挥
  示例如下
  

4.SCRUM的最佳实践

SCRUM在需求方面的核心理念

• 需求是“涌现”的！
  • 不要视图初期就明细化全部需求
  • 通过“用户故事”来组织及细化需求
• 将“写需求”转变为“讨论需求”。
  • 使用“用户故事”来讨论需求
  • 所有人都参与讨论，储蓄明确需求细节

4.1用户故事

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

 标注格式：（重要）
	- 作为……角色
	- 希望系统可以……（目标）
	- 以便……（原因）
这个格式的作用：
	作为……角色--->从用户的角度来思考问题
	希望系统可以……（目标）--->思考系统要实现什么功能，达到什么效果等
	以便……（原因）--->思考这个功能对于该用户有什么实质价值

1. 用户故事的难点

• 需求有一系列大小不一的用户故事组成。
• 最开始的用户故事往往是“大故事”，需要拆分为“中故事”、“小故事”。
• 难点：
  • 发现发现和提炼用户故事
  • 由粗到细地拆分用户故事
  • 安排用户故事优先级，分派不同的Sprint中去实现

2. 如何写出第一个用户故事？
   实战：某网上售票系统，请写出第一个用户故事！
   建议：以甲方老板角度来写。
   参考答案：作为某某局长，希望建造一套网上售票系统，以便更好地为人们服务。
   
   开始分解用户故事：

   • 从第一个用户故事开始分解
     • 细分“以便……”这部分
     • 反向思考“希望系统可以……”部分
   • 进行系统涉众分析，列出关键用户
     • 思考用户在本项目上的利益所在
     • 思考“希望系统可以……”部分
     • 思考“以便……”这部分，确认“希望系统可以……”这部分的是否合适

3. 同一种用户不同场景继续拆分

• 如何拆分下面的用户故事？
  • 作为一个用户，我需要登录系统，以便只有我才能访问自己的信息。
• 提示：
  • 作为一名已注册过的用户，……
  • 作为一名新用户，……
  • 作为一名健忘的用户，……
  • 作为一名已注册的用户，……
• 参考答案-1
  • 作为一名已注册过的用户，我能用我的用户名和密码登录，让我能信任该系统。
  • 作为一名新用户，我能通过创建用户名和密码注册，让该系统能记住我的个人信息。
  • 作为一名已经注册过的用户，我能改变我的密码， 让我能保证它是安全的或容易记住他。
  • 作为一名已经注册过的用户，我想要系统在我的密码很容易被猜测时提醒我，让我的账号很难被侵入。
• 参考答案2
  • 作为一名健忘的用户，我想能够申请一个新的密码，让我忘记密码时不会被永久地锁住。
  • 作为一名一注册过的用户，我不想在我登录尝试失败后看到这是由于用户名错误、密码错误或二者信息都错误导致的信息，让其他人很难冒充我。
  • 作为一名已注册过的用户，我应能在我的账户出现连续3次失败的尝试后得到通知，让我知道是否有人在视图访问我的账户。

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

• 两大标准：

  • 能在一个Sprint中完成。
  • 加入满意条件（详细要求）

• 例如：以下用户故事可在一个Sprint中完成：

  • 作为负责市场的副总裁，我想在评估以往广告促销活动的效果时可以选择节假日季节，以便我能确认那些有利润的促销活动。
  • 如何加入满意条件（详细条件）呢？

• “满意条件”示例

  • 确保它可以工作在大部分零售节假日。
    • 圣诞节、复活节、总统节、母亲节、父亲节、劳动节和新年
  • 支持跨2个日历年的节日。
  • 节假日季节可以从某个节假日到另一个设定（比如感恩节到圣诞节）
  • 节假日季节可以设置为该节假日前面的某些天
  • 不用支持中国的春节

4.2 Sprint

1. Product Backlog 和 Sprint Backlog

• Product Backlog
  • 中文翻译：产品代办列表
  • 产品需要完成的所有用户故事的集合
  • 用户故事有大有小，既有史诗级别，也有小粒度级别
• Sprint Backlog
  • 中文翻译：冲刺代办列表
  • Sprint中需要完成的所有用户故事的集合
  • Sprint中的用户故事都可以在该Sprint中完成，并且都应该有满意条件。

2. Sprint - 1

• 一个Sprint就是一个小版本。
• 建议时长1个月。
• 一个Sprint并不是一个“小瀑布”。
  • 很难区分需求、设计、代码、测试阶段。
  • 所有工作基于对用户故事的讨论。
  • 测试先行，测试驱动，单元测试必不可少。
  • 设计也是“涌现”式的。

3. Sprint - 2

• 产品负责人和“自组织”开发团队商量并规划每个Sprint的用户故事。
• 估算用户故事。
  • 精准估算有“满意条件”
  • 精准估算规划在Sprint中的用户故事。
  • 粗略估算或暂不估损大中粒度的用户故事。
  • 估算由“自组织”开发团队负责。
  • 精准估算时，单位建议为小时；粗略估算时，单位建议为天。

4.3 Burn Down Chart

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

Sprint中的一些最佳实践

• 结对编程。
• 持续集成。
• 测试驱动、测试自动化。
• 每日会议。
• Lessons Learned（经验教训总结）