敏捷开发过程Word文档下载推荐.docx
- 文档编号:14280282
- 上传时间:2022-10-21
- 格式:DOCX
- 页数:20
- 大小:556.22KB
敏捷开发过程Word文档下载推荐.docx
《敏捷开发过程Word文档下载推荐.docx》由会员分享,可在线阅读,更多相关《敏捷开发过程Word文档下载推荐.docx(20页珍藏版)》请在冰豆网上搜索。
如何利用用户故事来产生、管理测试用例
如何利用用户故事来管理变更、缺陷和客户反馈
课程将围绕每个小组实际工作中各自产品或项目的自身需求展开,通过对其进行结构化、用户故事化、
用户建模、模拟计划会估算、设定验收标准等,从而演练Scrum各个环节所需的技能。
知识及案例讲解约占
70%,实际练习约占30%。
注:
本大纲中以一个易于理解的电子商务系统的研发为例,实际应用时可应用于银行、电信、政府、电
子商务、互联网社区娱乐、仪器仪表等各种主流行业。
XXXXXXXXXXXXXXXXXXXXXXXXX第一天xxxxxxxxxxxxxxxxxxxxxxxxxxx>
0概述
本阶段培训通过简短介绍,让学员大致了解敏捷开发的历史及其尝试解决的问题。
敏捷开发尝试解决的问题
Scrum及其历史
产品负责人ProductOwner
产品负责人团队
产品负责人的职责
现场演练:
分组并推选ProductOwner
1第一阶段:
需求结构化与需求描述
本阶段培训旨在从头到尾打通需求,即从感性的产品愿景分解到可供开发的具体需求条目。
传统敏捷开发使用“条目化”的方法来表达需求。
但具体分解和描述需求的方法停留在“每个故事交付一个客户价值”“从客户价值角度描述需求”等非常含糊、难以落地的层面上。
这导致分析所得的需求个体差别很大,难以作为大型、长期产品研发的正式工程文档。
本课程引入了QUML作为分界用户故事的基础,通过三层需求完成从产品愿景到可开发任务的分解:
三层需求分别为业务愿景(左上图),业务操作(左下图中的方框,即史诗故事),业务数据(右侧三
张图中的椭圆,即用户故事)
这就解决了传统敏捷开发中存在的以下问题:
1.最初的产品愿景与割裂的用户故事之间缺少必然联系
2.大量用户故事之间缺少清晰的结构
3.用户故事颗粒度大小不一此外,这种体系下建立起来的“用户故事树”(需求树)还能:
1.直接分配到开发任务中
2.直接生成代码结构
3.直接用于结构化管理变更、增强、重构、缺陷等
4.直接与测试用例匹配而为一人年的工作量进行这种需求分析,只需要1小时左右
1.1第一步:
业务愿景一一利用“角色-业务图”来支撑产品愿景
愿景(Vision)是用户对产品的核心期望。
培训中使用“角色-业务图”(简称RB图)来表达和落实愿景。
比如在配图中:
“购物子系统”核心愿景是“建立一种有保障的网上购物方式”;
图中使用“确认收货-转账”的第三方监管业务实现。
这样软件开发人员就能得到确切的技术方案,而不是面对描述非常虚的愿景;
而技术方案实现后,又能支撑愿景。
有了愿景,产品就不会简单停留在“能用”的状态,而是要积极增加可以实现愿景的功能。
现场演练与指导:
建立角色业务图(20分钟)案例分享:
RB图详细规则与最佳实践
1.2第二步:
业务数据一一利用“实体-关系图”发掘业务数据
此内容将客户愿景转化为“对某些的业务数据的操作”,从而逐渐进入开发人员可理解的范畴;
同时业务数据还是早期功能点估算的核心元素。
具体分析工具是实体-关系图(简称ER图),而业务数据对应其中的实体(图中方框)。
实体-关系图(教学过程中进行了简化)中分析了实体及其依赖关系,通过适当定义,不但可以保障不会遗漏实体,甚至能直接协助进行早期估算和部分设计工作。
重要!
在敏捷开发中,我们将业务数据作为史诗故事进行开发。
比如在配图中,所有实体(5个矩形)均包含一组“增删改查”或类似的操作(就是第三步中的用户故
事),由此可知此图包含165人天左右的工作量/3张数据库主表和2张关系表/5组增删改查操作页面。
建立实体关系图(30分钟)
案例分享:
ER图详细规则与最佳实践
借助精益需求建模方法(“用例-流程图”,一种由UserCase和状态图结合演进产生的新图形,简称UCF图),找到一个最小的、完备的业务操作集合,作为一次交付所能发布的最新功能集合。
在精益开发中,这个集合称之为MVP,MinimumViableProduct最小可用产品。
用例-流程图的“一致性”非常好,即两个不同的分析人员针对同一需求的分析结果,无论用例的数量、名称、乃至排列顺序都惊人地相似。
在敏捷开发中,我们将业务操作作为用户故事。
右图是QUML中的“增查查改删”模板中,通过将需求分解为增加-查看所有-查看单个-修改-删除五层,
并将不同角色执行的操作放在其正下方(共有操作放在中间),需求分析人员可以迅速而无遗漏地获得所有用户故事。
同时,图中由业务逻辑连接的各个业务操作(即椭圆形区域)形成一个MVP,多一个操作则是多余的,少
一个则不能完整交付。
这对于每个迭代能持续交付至关重要。
建立用例流程图(60分钟)
UCF图详细规则与最佳实践
1.4第四步:
需求树一一建立结构化的需求
形化需求形成树形的需求树,其不同层次对应不同尺度的用户故事。
很多业界的敏捷开发工具如Jira都引入了层次化用户故事,但均没有提供层次定义和可操作的分解方法。
本培训采用Word作为演示工具,也可对应到具体工具中。
XXXXXXXXXXXXXXXXXXXXXXXXX第二天xxxxxxxxxxxxxxxxxxxxxxxxxxx>
1.5第五步:
用户故事一一面向用户价值的需求描述方式
电孑苍目单
作为一个SMt,可以査看电子节目单■以了解一周以内所有电频迺的节目日程.
约束:
1+千佃站存储空间;
1^2M
很多软件虽然交付了功能,却不是客户想要的。
比如,微博这类的大型系统的管理员,是否会有一个“查看所有用户”这样的功能来管理几亿个用户?
如果没有,他怎么知道有哪些用户?
如果有,如何避免海量用户造成的信息爆炸?
敏捷开发引入了一种面向客户价值而非产品功能的需求描述方式,将功能放在具体的使用环境中讨论,从而能为客户制作出符合其价值的产品。
编写自己的用户故事(30分钟)
文字游戏还是价值挖掘挖掘
1.6第六步:
用户建模一一购买决策者/主要使用者
“今年过节不收礼,收礼就收脑白金”。
尽管多数收礼者(主要使用者)并不知道脑白金到底包含何种成分,服用后到底有哪些好处,但是确有无数的送礼者
(购买决策者)选择购买。
本内容介绍如何区分购买决策者和主要使用者,并面向核心用户编写用户故事。
建立自己的用户模型(30分钟)
一款年收入12亿元的网络游戏对“所有用户”的理解
2第二阶段:
版本规划与迭代计划
本阶段以第一阶段生成的各层次用户故事为输入,进行宏观的版本规划和微观的迭代计划。
传统敏捷开发缺少版本规划的具体实施方法,“按客户价值优先级进行排序”听起来有道理但却难以实施。
尤其是在初期无法获得全部用户故事的情况下,优先级排序非常困难。
本培训中的方法可以:
1.在开发的初期即可提供颗粒度可控的高层需求(史诗故事)进行排序;
2.产品经理根据业界统计数据即可进行版本规划;
3.在版本规划的同时自动完成工作量规划,从而准确安排迭代的数量;
在每个迭代的计划会上通过“敏捷扑克估算”,借助集体智慧解决个体问题:
1.迅速找到最快的解决办法;
2.发现高手与新手的差距,并通过讨论弥补差距;
3.以10分钟代价提前发现上千行代码的浪费;
2.1第一步:
版本规划一一项目早期的量化分层规划方法
掘赢1,0
版本规划涉及到立项时的战略性规划、迭代间的发布
规划、随时可能发生的产品升级规划等不同层次。
培训中会建立三级规划方法与之对应,分别是业务愿景规划、业务数据规划和业务操作规划。
由于业务数据的定义兼容FPA(功能点分析)中ILF(内部逻辑文件)的定义,因此每个业务数据无需知道细节即可按业界数据2人月计算(精确数值为35人天)。
配图中展示了一个电商网站不同阶段规划的情况。
左
侧业务愿景每个对应4〜20人月规模的需求;
中间业务数
据级别每个对应2人月规模的需求;
右上角黑体字则是业务操作,每个对应4〜5人天规模。
2.2第二步:
迭代规划
若一个版本需要在三个迭代后才能完成,那么每个迭代应该完成哪些功能?
本培训中引入了精益创业(LeanStart-up)中MVP(最小可用产品)的概念,介绍如何聚焦于最少的工作量完成一个可以供用户使用并提交反馈的产品。
在完成迭代规划后,产品经理就得到了一个意向性的迭代列表,以及每个迭代中的需求分布情况。
接下来在每个迭代开始第一天,需要召开计划会议对详细需求进行讲解和估算。
2.3第三步:
迭代计划会
本阶段通过讲解计划会的完整过程及背后的思想,并通过实际练习,对之前需求分析阶段获得的用户故事进行估算。
详细内容包括:
猪与鸡的故事一一敏捷计划会背后的分权思想
如何通过放权提升开发人员个体的积极性。
产品经理如何讲解故事
如何从大到小、从整体到局部、从背景到功能地分层讲解用户故事;
如何在客户环境中理解需求。
开发人员扑克估算
如何让团队成员说出真实的估算值;
如何让高手在估算时就能帮助新手;
如何通过估算来澄清需求。
讲师在从事开发时,曾将已经完成的、多达4000行代码
压缩为55行代码。
在实施敏捷估算后,在计划会即可避免这种浪费,而无需等待编码实际结束后才发现。
小游戏:
世界□□口□(保密内容)有多高?
(演示估算扑克的使用方法,10分钟)
我的故事要多少工作量?
(使用客户内部开发需求,15分钟)
XXXXXXXXXXXXXXXXXXXXXXXXX第三天xxxxxxxxxxxxxxxxxxxxxxxxxxx>
3第三阶段:
敏捷日常工作
本阶段的核心内容是如何在顺利在迭代期内跟踪项目进展。
此阶段培训将涉及到传统的每日立会燃尽图、故事板等工具,但同时也会介绍多家公司根据自身情
况对敏捷开发活动的改良;
3.1日常活动第一步:
每日立会与敏捷生
态系统
无数敏捷团队因为每日立会简单易行而将其作为第一个推广的敏捷活动;
无数敏捷团队也在无奈中亲自见证了这个
简单易行的会议最后如何变得死气沉沉,不得不依靠“迟到罚款箱”来维持。
敏捷生态系统。
看似无关的敏捷
培训中将介绍每日立会一一乃至所有敏捷开发活动一一背后的运行原理:
实践与团队模型之间其实存在着隐形的联系。
3.2日常活动第二步:
看板
看板是一个
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 敏捷 开发 过程