SCRUM笔记

大纲

  • 神马是敏捷？

  • SCRUM是神马？

  • SCRUM的团队架构

  • SCRUM的最佳实践

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

1.神马是敏捷？

 敏捷各路诸侯：极限编程（XP）、SCRUM、MSF（微软解决方案框架）、OpenUP(RUP敏捷版)、精益开发、水晶方法、特性驱动开发
什么是敏捷？
  • 美国敏捷联盟提出四大宣言和十二条准则
  • 敏捷宣言：
    image
    • 个体和互动更优于流程和工具
    • 工作的软件更优于详尽的文档
    • 客户合作更优于合同谈判
    • 响应变化更优于遵循计划

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

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

2.SCRUM是神马？

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

3.SCRUM的团队架构

  • SCRUM的团队角色
    • 产品负责人
    • SCRUM Master
    • “自组织”的开发团队

  • 产品负责人（产品经理）
    • 主要职责：
      • 提供愿景
      • 提供边界
      • 提供用户故事的优先级
    • 要特别注意：
      • 需要和开发团队沟通需求
      • 需要考虑开发团队的研发能力

  • SCRUM Master（相当于教练角色）≠项目经理
    • 没有行政权利
    • 训练团队用正确的方法做事，遵循SCRUM的流程和做事原则
    • 不代替团队做决定

  • “自组织”的开发团队有什么角色？
    • 业务分析师
    • 程序员
    • 测试人员
    • 软件架构师
    • 数据库设计师
    • 用户体验设计师
    • ……

  • 怎样才是“自组织”？——SCRUM Master领衔，其他成员听从指挥
    示例如下
    image

4.SCRUM的最佳实践

SCRUM在需求方面的核心理念

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

4.1用户故事

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

 标注格式：（重要）
	- 作为……角色
	- 希望系统可以……（目标）
	- 以便……（原因）
这个格式的作用：
	作为……角色--->从用户的角度来思考问题
	希望系统可以……（目标）--->思考系统要实现什么功能，达到什么效果等
	以便……（原因）--->思考这个功能对于该用户有什么实质价值
  1. 用户故事的难点
  • 需求有一系列大小不一的用户故事组成。
  • 最开始的用户故事往往是“大故事”，需要拆分为“中故事”、“小故事”。
  • 难点：
    • 发现发现和提炼用户故事
    • 由粗到细地拆分用户故事
    • 安排用户故事优先级，分派不同的Sprint中去实现

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

    开始分解用户故事：

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

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

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

  • 两大标准：

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

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

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

  • “满意条件”示例

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

4.2 Sprint

  1. Product Backlog 和 Sprint Backlog
  • Product Backlog
    • 中文翻译：产品代办列表
    • 产品需要完成的所有用户故事的集合
    • 用户故事有大有小，既有史诗级别，也有小粒度级别
  • Sprint Backlog
    • 中文翻译：冲刺代办列表
    • Sprint中需要完成的所有用户故事的集合
    • Sprint中的用户故事都可以在该Sprint中完成，并且都应该有满意条件。
  1. Sprint - 1
  • 一个Sprint就是一个小版本。
  • 建议时长1个月。
  • 一个Sprint并不是一个“小瀑布”。
    • 很难区分需求、设计、代码、测试阶段。
    • 所有工作基于对用户故事的讨论。
    • 测试先行，测试驱动，单元测试必不可少。
    • 设计也是“涌现”式的。
  1. Sprint - 2
  • 产品负责人和“自组织”开发团队商量并规划每个Sprint的用户故事。
  • 估算用户故事。
    • 精准估算有“满意条件”
    • 精准估算规划在Sprint中的用户故事。
    • 粗略估算或暂不估损大中粒度的用户故事。
    • 估算由“自组织”开发团队负责。
    • 精准估算时，单位建议为小时；粗略估算时，单位建议为天。

4.3 Burn Down Chart

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

Sprint中的一些最佳实践

  • 结对编程。
  • 持续集成。
  • 测试驱动、测试自动化。
  • 每日会议。
  • Lessons Learned（经验教训总结）
posted @ 2024-07-13 23:45  cookie..c  阅读(67)  评论(1)  编辑  收藏  举报