ToB企服应用市场:ToB评测及商务社交产业平台

标题: SCRUM条记 [打印本页]

---

作者: 石小疯    时间: 2024-7-14 22:00
标题: SCRUM条记
大纲

• 神马是敏捷？
  
• SCRUM是神马？
  
• SCRUM的团队架构
  
• SCRUM的最佳实践
  
  
  
  • 用户故事
    
  • Sprint（冲刺）
    
  • Burn Down Chart（燃尽图）
    
  
  

1.神马是敏捷？

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. 示例：
2.          作为网站的所有者，我希望能统计广告的点击次数，以便我能清楚广告收益
4. 标注格式：（重要）
5.         - 作为……角色
6.         - 希望系统可以……（目标）
7.         - 以便……（原因）
8. 这个格式的作用：
9.         作为……角色--->从用户的角度来思考问题
10.         希望系统可以……（目标）--->思考系统要实现什么功能，达到什么效果等
11.         以便……（原因）--->思考这个功能对于该用户有什么实质价值

复制代码

• 用户故事的难点
  

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

• 怎样写出第一个用户故事？
  实战：某网上售票体系，请写出第一个用户故事！
  发起：以甲方老板角度来写。
  参考答案：作为某某局长，希望建造一套网上售票体系，以便更好地为人们服务。
  
  开始分解用户故事：
  
  
  
  • 从第一个用户故事开始分解
    
    
    
    • 细分“以便……”这部门
      
    • 反向思考“希望体系可以……”部门
      
    
    
  • 进行体系涉众分析，列出关键用户
    
    
    
    • 思考用户在本项目上的长地方在
      
    • 思考“希望体系可以……”部门
      
    • 思考“以便……”这部门，确认“希望体系可以……”这部门的是否合适
      
    
    
  
  
• 同一种用户差别场景继续拆分
  

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

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

• 两大标准：
  
  
  
  • 能在一个Sprint中完成。
    
  • 到场满足条件（具体要求）
    
  
  
• 比方：以下用户故事可在一个Sprint中完成：
  
  
  
  • 作为负责市场的副总裁，我想在评估以往广告促销活动的效果时可以选择节假日季节，以便我能确认那些有利润的促销活动。
    
  • 怎样到场满足条件（具体条件）呢？
    
  
  
• “满足条件”示例
  
  
  
  • 确保它可以工作在大部门零售节假日。
    
    
    
    • 圣诞节、复活节、总统节、母亲节、父亲节、劳动节和新年
      
    
    
  • 支持跨2个日历年的节日。
    
  • 节假日季节可以从某个节假日到另一个设定（比如感恩节到圣诞节）
    
  • 节假日季节可以设置为该节假日前面的某些天
    
  • 不用支持中国的春节
    
  
  

4.2 Sprint

• Product Backlog 和 Sprint Backlog
  

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

• Sprint - 1
  

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

• Sprint - 2
  

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

4.3 Burn Down Chart

• 用来跟踪Sprint未完成工作的环境
  
  
  
  

Sprint中的一些最佳实践

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

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。

---

欢迎光临 ToB企服应用市场:ToB评测及商务社交产业平台 (https://dis.qidao123.com/)

Powered by Discuz! X3.4