More Related Content
Similar to Scrum敏捷开发模型 (20)
Scrum敏捷开发模型
- 6. ⽆无流程—反复⽆无常
• 三边
• ⼝口头需求
• 管理者随时随地的提出需求/变更
• 产品经理没有想清楚就找开发⼈人员编程
• ⽆无纪律的程序员
• 直接在⽣生产环境修改代码、编译和部署
• 源码⺫⽬目录结构混乱
• 不遵循规范/⾃自测不主动
• 混乱流程
• 测试拿到了错误的版本
• 产品经理需求变更随意
- 16. SCRUM⾓角⾊色与职责
• Scrum Master
• 负责确保⼤大家遵守Scrum的价值、实践和规则；帮助团队实施Scrum。Scrum Master并不对团
队进⾏行管理。
• Product Owner
• 管理Product Backlog、确保团队⼯工作价值的唯⼀一责任⼈人。他负责维护Product Backlog，确保每
个成员明晰列表内容、明确哪些条⺫⽬目具有最⾼高优先级，从⽽而了解下个需要开发的条⺫⽬目。
• PO是⼀一个⼈人，⽽而不是⼀一个产品委员会。可能会有⼀一些⼈人向PO提出建议或影响他的决策，但
要改变某条⺫⽬目的优先级必须先说服PO。
• Team Members
• 由开发⼈人员组成的Scrumt团队负责在每⼀一个迭代周期将⼀一定量的开发任务完成。团队同时也
是跨职能的；团队成员必须具备完成开发任务所需要的技能，5到9个⼈人被公认为是“最佳的”
团队构成⼈人数。
- 19. PRODUCT BACKLOG⽰示例
ID Name Imp（重要性） Est（初始估算）
How to
demo（如何做演
⽰示或验收）
Notes
1 存款 30 5
登录，打开存款
界⾯面，存⼊入10元
钱，转到我的账
户余额界⾯面，检
查我的余额，增
加了10元钱
需要UML时序
图。⺫⽬目前不考虑
加密的问题。
2 查看⾃自⼰己的交易
明细
10 8
登录，点击“交
易”，存⼊入⼀一笔
款项。返回交易
⻚页⾯面，看到新的
存款显⽰示再⻚页⾯面
上
使⽤用分⻚页技术避
免⼤大规模的数据
库查询。和查看
⽤用户列表的规则
相似。
- 20. PRODUCT BACKLOG中的关键
字段
• ID—统⼀一的标识符，也就是个⾃自增⻓长的数字⽽而已，以防重命名故事以后找不到它们。
• Name(名称)—简短的、描述性的故事名。⽐比如“查看你⾃自⼰己的交易明细”。它必须含义明确，这
样整个团队才能⼤大致明⽩白我们说的是什么东⻄西，跟其他故事区分开。⼀一般由2到10个字组成。
• Importance（重要性）— 产品负责⼈人评出⼀一个数值，指⽰示这个故事有多重要。例如10或150。
分数越⾼高越重要
• Initial estimate(初始估算)—团队的初步估算，表⽰示与其他故事相⽐比，完成该故事所需要的⼯工作
量。最⼩小的单位是故事点（story point），⼀一般⼤大致相当于⼀一个“理想的⼈人/天”。不需要保证绝对
的准确⽆无误，⽽而是要保证相对的正确性（即，两个点的故事说花费的时间应该是四个点的故事
说需要的⼀一半）
• How To demo（如何做演⽰示）—它⼤大概描述了这个故事应该如何在sprint review会议中如何进
⾏行演⽰示，本质就是⼀一个简单的测试规范。“先这样做，然后那样做，就应该得到……的结果”
• Notes(注解)—相关信息、解释说明和对其它资料的引⽤用等等。⼀一般都很简短。
- 26. SPRINT计划会议注意事项
• Produc Owner
• 会议前确保Product Backlog准备好
• 所有重要的backlog都已经根据重要性做过评分
• 给team讲解各个backlog，保证⼤大家都能明⽩白backlog想要做的事情
• Scrum Master
• 组织⼤大家正常的按照Scrum的⽅方式来参加会议
• Team
• 对每⼀一个backlog进⾏行故事点（story point）的估算
• 确定团队成员名单及投⼊入度（如果不能100%投⼊入的话）
• 确定本次sprint backlog（即本次sprint包含的product backlog）
• 确定sprint的⺫⽬目标
• 确定好本次sprint演⽰示⽇日期
- 33. SPRINT REVIEW
• Sprint Review是Scrum中第⼆二重要的事件（最重要的是sprint计划
会议），因为这是做改进的最佳时机
• 在Review会上，每个⼈人都可以贡献和讨论想法
• 讨论的内容主要三项：
• 爽：如果我们可以重做同⼀一个sprint，哪些做法是可以保持。
• 不爽：如果我们可以重做同⼀一个sprint，哪些做法需要改变。
• 改进：有关将来如何改进的具体想法。
