在SCRUM方法中明确要求了3个文档: 1 product backlog
2sprint backlog
3 burn-down chart
Product backlog 中列举了本项目应该实现的需求,需求采用了用户故事的方式进行描述,用户故事是一句简短的采用用户熟悉的术语表达的需求,是用户讲给开发人员的故事,不是开发人员讲给用户的故事。既然是故事,就要有人讲,谁讲呢,是product owner来讲,每次讲时可能就有细节的不同,就要有变化,但是万变不离其宗,所以故事本身是有一定的弹性的。故事可以有标准的格式,我称之为三段论式故事,哪三段呢?
1 用户角色
2 需要的功能
3 目的
比如,有这样一个故事:
作为一个家庭主妇,我需要一个30平米的餐厅,以便于我可以招待10位朋友来用餐。
用户角色是家庭主妇,30平米的餐厅是功能需求,招待10位朋友用餐是为什么需要这个功能。千万不要小看这个三段论式的故事,需要仔细琢磨每一段的作用。用户角色表明了是谁使用这个功能,如果一个功能没有明确的使用者,是否可以删除呢?如果一个用户角色不重要,是否这个需求的优先级比较低呢?目的说明了为什么需要这个功能,这个功能解决了什么问题,如果一个功能没有明确的目的,那是否可以删除呢?如果目的不太关键,这个需求是否可以优先级比较低呢?
优先级?没错,我多次提到了优先级,需求一定要分优先级!谁来划分需求的优先级?Product owner!如何划分优先级?根据商业价值!根据对客户、对最终用户的商业价值来划分优先级。如何区分商业价值的大小呢?比如提问如果不实现此需求,如果晚实现此需求客户是否会不满意,是哪类人不满?不满意到什么程度?也有的专家提出了更专业的方法,其实没必要,如果product owner真的称职的话,相信他,可以凭经验划分出优先级。
是否仅仅描述了这样一句话就充分了呢?其实还有第四段,即用户故事的验收标准,或者叫用户故事的测试要点,这也是由product owner来完成的,product owner可以先完成前三段,在和team member的沟通过程中,逐步丰富完善验收标准。对于前面我们提到的那个故事,如果你实现了这样一个餐厅,比如是一个2米宽,15米长的餐厅,那位家庭主妇会如何想?哈哈,如果她心理健康的话,估计她立马让你跳楼!如果她心理不健康的话,她会跳楼的。当然在敏捷的方法中不会出现这种现象,在你开发的过程中,product owner会和你随时沟通交流的,在沟通中product owner还传达了这样的信息:
1我希望这个餐厅是5米*6米;
2我希望这个餐厅光线明亮;
3我希望这个餐厅靠近厨房;
4 ......
这就是验收标准!也可以换一种角度,从如何验收的角度的来描述:
1 我会量量这个房间是否是5米*6米的;
2 我会测测如果在这个房间里白天打扑克,不开灯的话,能否看到扑克的花色和点数;
3我会测测从厨房到餐厅需要走几步;
4 ......
如果一个故事提不出来验收标准怎么办呢?不实现它,晚实现它,直到明确了验收标准。
到目前为止我们实际讲了在product backlog中包含了5段:
Product backlog = 需求 + 优先级
= 用户故事 + 优先级 + 验收标准
= 用户角色 + 功能 + 目的 + 优先级 + 验收标准
有的专家把验收标准单列出来,我认为验收标准是需求的一部分,只不过换了一种描述方式而已,所以还是作为product backlog的一部分吧。
前面我一直在提“功能”二字,没有提非功能的需求,如果有非功能的需求怎么办?两种处理办法,一是如果能明确到某个故事,就描述在故事的验收标准中,二是写一个“技术故事”,单列出来,提醒开发人员注意这些故事,这个故事未必是product owner提出的。
对于用户故事我们希望能达到如下的理想:
1)独立性。尽可能避免故事之间存在依赖关系,故事间存在依赖关系会造成划分优先级的困难,在安排开发顺序时需要考虑故事之间的依赖关系。
2)可协商性。故事是可协商的,故事是有弹性的,故事是需要讲的,不是必须实现的书面合同或者需求。
3)对用户或者客户有价值。确保每个故事对客户或用户有价值的最好方式是让用户编写故事。
4)可预测性。开发者应该能够预测(至少大致猜测)故事的规模,以及编码实现所需要的时间。
5)短小精悍。一般一个故事在一个迭代周期内一定是可以实现的,而我们提倡短周期迭代。
6)测试性。所编写的故事必须是可测试的,能够定义出验收标准。
注意,这是理想!
Product backlog在项目进展过程中是会发生变化的,只有product owner有权来修改此文档。你可以用EXCEL文件来描述它,也可以采用一些敏捷项目管理的工具来帮助你维护,或者使用一些缺陷的跟踪工具如JIRA之类的,最直观的最朴素的办法是采用不干贴纸,直接贴在办公室的白板上,让大家都能随时看到!
分享到:
相关推荐
敏捷开发
《Scrum精髓:敏捷转型指南》的总结
人人都是Scrum Master:对于Scrum团队,PM应该从何下手.pdf人人都是Scrum Master:对于Scrum团队,PM应该从何下手.pdf人人都是Scrum Master:对于Scrum团队,PM应该从何下手.pdf人人都是Scrum Master:对于Scrum团队,PM...
scrum product backlog
Scrum方法论:小型手游团队开发游戏的5个经验.pdf
Product backlog template 敏捷 scrum
第1章 简介免责声明撰写本书的原因scrum到底是什么第2章 我们怎样编写产品backlog额外的故事字段我们如何让产品backlog停留在业务层次上第3章 我们怎样准备sprint计划第4章 我们怎样制定sprint计划为什么产品负责人...
轻松Scrum之旅:敏捷开发故事,ISBN:9787121099847,作者:贾子河 等编著
The product owner is a new role for most companies and needs this...and break those features down into small product backlog items for the team. I had already delegated my engineering responsibilities to
Scrum模板@ GitHub 用于基于Scrum创建项目的模板 标签 主题 Theme标签允许跨史诗故事的虚拟矩阵 Theme: strategic goals Theme: product modules Theme: project phases 史诗 Epic标签可以将可以细分为特定故事的...
在Scrum中,使用产品Backlog来管理产品或项目的需求,产品backlog是一个按照商业价值排序的需 求列表,列表条目的体现形式通常为用户故事。Scrum的开发团队总是先开发的是对客户具有较高价 值的需求。在每个Sprint中...
1. 一名 Product Owner 将解决复杂问题所需的工作整理成一份 Product Backlog。 2. Scrum Team 在 一个 Sprint 期间将选择的工作转化为价值的 Increment。 3. Scrum Team 和利益攸关者检视结果并为下一个 Sprint ...
1. 一名 Product Owner 将解决复杂问题所需的工作整理成一份 Product Backlog。 2. Scrum Team 在 一个 Sprint 期间将选择的工作转化为价值的 Increment。 3. Scrum Team 和利益攸关者检视结果并为下一个 Sprint ...
Introduction to Scrum 3 Roles: Product Owner : Responsible for defining the features that are needed in the product. Has the bright ideas that turn into products. ScrumMaster: Servant leader to the...
There are many concise descriptions of Scrum available online, and this primer aims to provide the next level of detail on the practices. It is not intended as the final step in a Scrum education; ...
The Product Backlog Sprints Planning Quality Part Four: The Organization Scaling Agile Distributed Teams Coexisting with Other Approaches Human Resources, Facilities and the PMO Part Five: Next ...