Scrum理论
Scrum是以经验过程控制理论为依据,简单,但高度的纪律性;采用迭代、增量的方法来提高产品开发的可预见性并控制风险。Scrum的三大支柱支撑起每个经验过程控制的实现。
Scrum 是一种工作管理的方法,不仅仅限于软件开发, 可以用来管理其它活动。 Scrum 不包含技术方法或实践。
第一大支柱是高透明度
第二大支柱是检验
第三大支柱是适应
Scrum的backlog
在XP(极限编程)中叫用户故事(user story),在
Scrum中叫backlog(条目)。
Sprint中的backlog每一项都是一个用户故事。
需求本身需要分类
史诗Epic
故事Story
增强Enhancement
缺陷Defect
技术债务TechDebts
重构Refactor
不同时期的客户提出需求关注点不一样
“史诗”只是我们对大的用户故事的标签而已
其实各种“用户故事”中,大致可以分为史诗Epic、故事Story、增强Enhancement、缺陷Defect、技术债务TechDebts、重构Refactor等几种。
其中史诗和故事大致形成树状结构,很容易勾勒出产品或项目的结构,是最需要展示给用户的;
增强和缺陷在一定程度上需要展示给用户,但除了评审中或交付后客户提出来的之外,都可以不展示给用户,而且即使展示,“展示”的层次也应该不同于史诗和故事;
而技术债务和重构由于太技术化,不适合直接展示给用户,而更适合展示给Product Owner及开发团队。
用户故事的组成
Card –卡片一般来说用户故事是写在记事卡片上,卡片上可能包括了一些说明和估算的信息
Conversation –对话有关的具体信息是通过和产品拥有者的交谈沟通得出的
Confirmation –验证用验收测试来确认实现的正确性
我们 为什么 要使用用户故事?
促进沟通 持续交付 开发敏捷
客户最终需要的并不是文档
而是通过软件帮助其完成业务价值
短小精悍的故事可以帮助我们推进沟通,挖据客户的真实需求
关注商业价值而不是功能实现,更敏捷的交付产品
如何编写故事清单
步骤:
建立用户故事树
确定业务边界
初步划分业务板块
绘制用户故事树
绘制用户故事树:
故事分解是自上而下的
故事树的完善是自下而上的
跟客户沟通的是整个故事树
开发的永远是最底层的故事
界定业务边界
如何编写故事清单
- 建立用户角色
明确使用对象
确定各场景角色职责
建立用户角色职责
编写用户故事
三段论
用户沟通
可接受条件
编写用户故事
如何编写用户故事
用户故事应该很清晰地体现对用户或客户的价值,最好的做法是让客户团队来编写故事。为了构造好的用户故事,我们关注六个特征。一个优秀的故事应该具备以下特点:
更新用户角色
更新故事树
故事树的完善是自下而上的,根据对业务的理解深入需要改变上级故事。
总结:
敏捷是什么?
SCRUM 开发流程
产品backlog
用户故事的组成
用户故事的规范