SCRUM条记
大纲[*]神马是敏捷？
[*]SCRUM是神马？
[*]SCRUM的团队架构
[*]SCRUM的最佳实践
[*]用户故事
[*]Sprint（冲刺）
[*]Burn Down Chart（燃尽图）
1.神马是敏捷？
敏捷各路诸侯：极限编程（XP）、SCRUM、MSF（微软解决方案框架）、OpenUP(RUP敏捷版)、精益开发、水晶方法、特性驱动开发什么是敏捷？
[*]美国敏捷同盟提出四大宣言和十二条准则
[*]敏捷宣言：
https://img2024.cnblogs.com/blog/3414406/202407/3414406-20240712000030913-849197882.png
[*]个体和互动更优于流程和工具
[*]工作的软件更优于详尽的文档
[*]客户合作更优于合同谈判
[*]响应厘革更优于遵照筹划
靠左更敏捷，靠右更接近传统开发模式
[*]敏捷准则
1、 我们的最高目的是，通过尽早和连续地交付有价值的软件来满足客户
2、 欢迎对需求提出变动——即使是在项目开发后期。要善于利用需求变动，资助客户得到竞争优势
3、要不停交付可用的软件，周期从几周到几个月不等，且越短越好
4、项目过程中，业务人员与开发人员必须在一起工作
5、 要善于鼓励项目人员，给他们以所必要的环境与支持，并相信他们能够完成任务
6、 无论是团队内还是团队间，最有效的沟通方法是面临面交谈
7、 可用的软件是衡量进度的主要指标
8、敏捷过程提倡可连续的开发。项目方、开发人员和用户应该能够保持恒久稳定的进展速率
9、对技能的精益求精以及对设计的不停完善将提升敏捷性
10、要做到简洁，即尽最大可能淘汰不必要的工作。这是一门艺术
11、最佳的架构、需求和设计出自于自组织的团队
12、团队要定期反省怎样能够做到更有效，并相应地调整团队的行为
2.SCRUM是神马？
[*]近年最火的敏捷方法论
[*]SCRUM中文翻译：橄榄球
[*]SCRUM适用于大中小性项目
[*]SCRUM焦点内容
[*]团队架构
[*]软件研发框架
https://img2024.cnblogs.com/blog/3414406/202407/3414406-20240712003105078-1208011368.png
3.SCRUM的团队架构
[*]SCRUM的团队角色
[*]产品负责人
[*]SCRUM Master
[*]“自组织”的开发团队
[*]产品负责人（产品经理）
[*]主要职责：
[*]提供愿景
[*]提供边界
[*]提供用户故事的优先级
[*]要特殊留意：
[*]必要和开发团队沟通需求
[*]必要考虑开发团队的研发本领
[*]SCRUM Master（相当于教练角色）≠项目经理
[*]没有行政权利
[*]训练团队用正确的方法办事，遵照SCRUM的流程和办事原则
[*]不代替团队做决定
[*]“自组织”的开发团队有什么角色？
[*]业务分析师
[*]程序员
[*]测试人员
[*]软件架构师
[*]数据库设计师
[*]用户体验设计师
[*]……
[*]怎样才是“自组织”？——SCRUM Master领衔，其他成员听从指挥
示比方下
https://img2024.cnblogs.com/blog/3414406/202407/3414406-20240713183552060-1665225760.png
4.SCRUM的最佳实践
SCRUM在需求方面的焦点理念
[*]需求是“涌现”的！
[*]不要视图初期就明细化全部需求
[*]通过“用户故事”来组织及细化需求
[*]将“写需求”转变为“讨论需求”。
[*]使用“用户故事”来讨论需求
[*]所有人都到场讨论，储蓄明白需求细节
4.1用户故事
示例：
作为网站的所有者，我希望能统计广告的点击次数，以便我能清楚广告收益
标注格式：（重要）
- 作为……角色
- 希望系统可以……（目标）
- 以便……（原因）
这个格式的作用：
作为……角色--->从用户的角度来思考问题
希望系统可以……（目标）--->思考系统要实现什么功能，达到什么效果等
以便……（原因）--->思考这个功能对于该用户有什么实质价值
[*]用户故事的难点
[*]需求有一系列大小不一的用户故事组成。
[*]最开始的用户故事往往是“大故事”，必要拆分为“中故事”、“小故事”。
[*]难点：
[*]发现发现和提炼用户故事
[*]由粗到细地拆分用户故事
[*]安排用户故事优先级，分派差别的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未完成工作的环境
https://img2024.cnblogs.com/blog/3414406/202407/3414406-20240713220658559-1476117111.png
Sprint中的一些最佳实践
[*]结对编程。
[*]连续集成。
[*]测试驱动、测试自动化。
[*]每日会议。
[*]Lessons Learned（经验教训总结）
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。
页:
[1]