Scrum敏捷软件开发始末
2018-09-17 23:05:32 1 举报AI智能生成
登录查看完整内容
Scrum敏捷开发
作者其他创作
大纲/内容
scrum
背景
自我介绍
启蒙
2012年公司启动CMMI3-4的评估
是什么
cmmi是什么
CMMILevel 1，完成级，代表有能力完成这件事
CMMILevel 2，管理级，在1的基础上形成一套流程
CMMILevel 3，定义级，形成制度
CMMILevel 4，量化管理
CMMILevel 5，优化级，有能力改善流程，并能大概率的预防预测
启动培训
内部培训
架构
管理
格鲁夫给经理人的第一课
生产流程
管理杆杆率
招人留人
情商3部曲
每周的技术提升
外部培训
Scrum认证
scrumalliance
scrum所处位置
公司
人
事
关联人和事(处理流程)
活动流程
人事流程
财务流程
产品开发流程
瀑布
rup
历史来源
1986年，竹内弘高和 野中郁次郎在New New Product Development Game文章首次提到将Scrum应用与产品开发，他们指出：传统的“接力式”的开发模式已经不能满足快速灵活的市场需求，而整体或“橄榄球式”的方法——团队作为一个整体前进，在团队的内部传球并保持前进，这也许可以更好的满足当前激烈的市场竞争。
1993年首次在Easel公司定义了用于了软件开发行业的Scrum流程，并开始实施，敏捷思想深受日本工业界最佳实践的影响，尤其是丰田和本田公司推行的精益原则，以及竹内弘高和 野中郁次郎开发的知识管理策略。受到以上思想的影响，以及对世界范围内软件项目的研究
1995年Jeff Sutherland和Ken Schwaber规范化了Scrum框架，并在OOPSLA 95上公开发布
2001年 敏捷宣言及原则发布、敏捷联盟成立，Scrum是其中一种敏捷方法
2001年，Ken Schwaber和Mike Beedle推出第一本Scrum书籍《Scrum敏捷软件开发》
2002年Ken Schwaber 和Mike Cohn共同创办了Scrum联盟
2009年，百度淘宝引入scrum
历史分享
看板
backup
硬实力
人员
技术
基础设备
经济
软实力
氛围
员工关系
工作方式
场景
复杂度高，不确定性多，不好预测
竞争激烈需要更快的速度推出产品
核心
迭代，增量，优先级，跨职能
例如
台球
一杆下去，之后的局势无法预测
战争
C端用户产品
概念
基本概念
sprint， timebox(迭代周期)， ProductBackLog， SprintBackLog， sprint review， sprint Retrospective(回顾)， User Story， I$A，DOD，燃尽图
三个角色
Product owner(产品)
规划产品
对产品Backlog负责
产出
userStory
用户价值
谁使用了这个功能完成了什么
商业价值
成本/收益
模板
3C
关于用户故事，用3个C来描述它：1.卡片（Card） – 用户故事一般写在小的记事卡片上。卡片上可能会写上故事的简短描述，工作量估算等。2.交谈（Conversation）- 用户故事背后的细节来源于和客户或者产品负责人的交流沟通。3.确认（Confirmation）- 通过验收测试确认用户故事被正确完成
六个特性- INVEST
验收标准
一个正常流程
两个异常流程
价值成本分析排序
开发速度分析
对产品收益负责（投资回报率）
确定发布日期和内容
接受或者拒绝工作结果
Scrum Master(敏捷教练)
执行Scrum规划
推动所有会议
使团队不受外部干扰
领导团队自组织或者持续改善
指导产品负责人
为团队和产品负责人服务
team(团队)
和产品一起做计划
自组织
估算，定义实现
创建迭代，实现迭代的承诺
更新迭代
关注进度
四个会议
Sprint Planning(2个阶段)
阶段一做什么
参与人(产品，技术)
这些已经reday
已评估产品Backlog中的各项问题
已按优先级排列产品Backlog
timebox
产品陈述的产品远景
高优先级开始往下过直到大致估算出一个迭代可以完成的产品backlog list，到这停止
本次sprint 目标
估算
大致估算userStory的大小
约束产品对迭代user story的选择
阶段二怎么做，做多久
reday
阶段一的产出
分解的任务列表
考虑到这些因素
编码
测试
代码review
会议
学习新技术
解BUG
根据任务分解列表发现
sprint backlog过多
低优先级的丢回产品backlog中
过少
产品backlog中拿过来需求
再次确认的目标
根据DOD详细估算
建议
子任务不要超过一天
产品
做什么，做到什么地步
验收标准是什么
怎么做，要多久
Daily Scrum
为迭代目标服务
日例会的目标也是为迭代目标服务
三个问题
1.昨天完成了那些？
2.今天准备做那些
3.有什么阻碍了你的开发
最新燃尽图
有没有block
sprint review
输入
本次sprint迭代结果
可使用的产品
输出
更新的燃尽图
反馈
更新的产品backlog
障碍Backlog
有问题记下来，不找茬
Sprint Retrospective
回顾迭代目标完成的怎么样
3个问题
我们上个迭代有哪些事情做的好希望继续，哪些事情做得不好希望改进，有何改进计划
原则
多说I，少用You
不深究具体业务细节内部问题
本次迭代的事件
会议、决策点、里程碑、采用新技术、重大事故
本次迭代的度量数据
燃烧图、速度、bug数、完成故事点数、代码重构数
需要跟进的改进项
三个产出
产品Backlog
详细的，演进的，预估的，排序的
优先级越高，需求越详细
产品负责人维护，其他人可以提出想法
在sprint的反馈中得到改进
Sprint Backlog
团队创建
不再发生变化
任务工作量小于等于1天
燃尽图
迭代燃尽图
产品燃尽图
五个价值观
1.承诺 – 愿意对目标做出承诺 2.专注– 把你的心思和能力都用到你承诺的工作上去 3.开放– Scrum 把项目中的一切开放给每个人看 4.尊重– 每个人都有他独特的背景和经验 5.勇气– 有勇气做出承诺，履行承诺，接受别人的尊重
案例
如何判定sprint内可以完成多少功能？
没有历史数据，到底一个迭代能完成几个故事点没有概念
前几个迭代承诺驱动
按Scrum的方法去承诺
行业数据
得到量化指标
估算未来迭代的速率
未来迭代的速率随着新的迭代数据更新
量化指标之外的
接触新业务
技术架构不成熟
技术运维工作
有历史数据
如何定义最小的完成定义？
开发应该至少包含这些
达成一致的完成标准
定义完成了那些就算完成了
每个阶段都可以有DOD
产品AB
userStory->开发->测试->市场->用户->反馈数据->产品-userStory
团队的其他人对项目漠不关心，该肿么办？
确定感受到责任
责任分散
中途改变需求肿么办？
别惯他臭毛病
信任是怎么丢失？
无效的沟通
风险最后告知
需求不一致
没有buffer
过多的承诺
需求理解不充分
方案没有共识
对承诺不在意
较大的需求变化
没有充分评估，不认可变化
不能拒绝
想表现下
没意识到buffer不够了
从哪些点质疑需求？怂产品
做了这个之后使用用户会更多的使用吗，带来更大的价值？
业务规则
业务数据
界面UI
强分工
带来的学习债务
书
敏捷产品管理 打造用户喜爱的产品
敏捷教练，如何打造优秀的敏捷团队
管理3.0
团队协作的5大障碍
收藏
0 条评论
回复 删除
下一页
