最新敏捷开发过程.docx

敏捷开发过程
Scrum敏捷开发过程实战
产品级，大团队的敏捷实战方法
需求结构化
需求描述
版本规划
迭代方案
日常活动
团队建设
与传统灌输理念的培训不同，此实战培训中不只包含“按客户价值进行优先级称ER图〕，而业务数据对应其中的实体〔图中方框〕。
实体-关系图〔教学过程中进行了简化〕中分析了实体及其依赖关系，通过适当定义，不但可以保障不会遗漏实体，甚至能直接协助进行早期估算和局部设计工作。
重要！在敏捷开发中，我们将业务数据作为史诗故事进行开发。
比方在配图中，所有实体〔5个矩形〕均包含一组“增删改查〞或类似的操作〔就是第三步中的用户故事〕，由此可知此图包含１６５人天左右的工作量／３张数据库主表和２张关系表／５组增删改查操作页面。
现场演练与指导：建立实体关系图〔30分钟〕
案例分享：ER图详细规那么与最正确实践
第三步：业务操作——利用“用例-流程图〞分析业务操作
借助精益需求建模方法〔“用例-流程图〞，一种由User Case和状态图结合演进产生的新图形，简称UCF图〕，找到一个最小的、完备的业务操作集合，作为一次交付所能发布的最新功能集合。在精益开发中，这个集合称之为MVP， Minimum Viable Product最小可用产品。
用例-流程图的“一致性〞非常好，即两个不同的分析人员针对同一需求的分析结果，无论用例的数量、名称、乃至排列顺序都惊人地相似。
重要！在敏捷开发中，我们将业务操作作为用户故事。
右图是QUML中的“增查查改删〞模板中，通过将需求分解为增加-查看所有-查看单个-修改-删除五层，并将不同角色执行的操作放在其正下方〔共有操作放在中间〕，需求分析人员可以迅速而无遗漏地获得所有用户故事。
同时，图中由业务逻辑连接的各个业务操作〔即椭圆形区域〕形成一个MVP，多一个操作那么是多余的，少一个那么不能完整交付。这对于每个迭代能持续交付至关重要。
现场演练与指导：建立用例流程图〔60分钟〕
案例分享：UCF图详细规那么与最正确实践
第四步：需求树——建立结构化的需求
传统用户故事组织方法均呈现“列表结构〞，在用户故事数量庞大时〔注：每人年大约能完成用户故事50个，外加子故事50～200个〕，很难看到整个需求的全貌。
培训中，会借助业务愿景-业务数据-业务操作的层次，对需求条目进行结构化表达，形成一棵有层次的需求树。
如图，看似是一个很普通的“增删改查表〞，但图中的第二至四级目录实际上来自于之前的业务愿景-业务数据-业务操作。这样就很容易从之前的图形化需求形成树形的需求树，其不同层次对应不同尺度的用户故事。
注：很多业界的敏捷开发工具如Jira都引入了层次化用户故事，但均没有提供层次定义和可操作的分解方法。本培训采用Word作为演示工具，也可对应到具体工具中。
×××××××××××××××××××××××××第二天××××××××××××××××××××××××××××××
第五步：用户故事——面向用户价值的需求描述方式
很多软件虽然交付了功能，却不是客户想要的。比方，微博这类的大型系统的管理员，是否会有一个“查看所有用户〞这样的功能来管理几亿个用户？如果没有，他怎么知道有哪些用户？如果有，如何防止海量用户造成的信息爆炸？
敏捷开发引入了一种面向客户价值而非产品功能的需求描述方式，将功能放在具体的使用环境中讨论，从而能为客户制作出符合其价值的产品。
现场演练与指导：编写自己的用户故事〔30分钟〕
案例分享：文字游戏还是价值挖掘挖掘
第六步：用户建模——购置决策者/主要使用者
“今年过节不收礼，收礼就收脑白金〞。尽管多数收礼者〔主要使用者〕并不知道脑白金到底包含何种成分，服用后到底有哪些好处，但是确有无数的送礼者〔购置决策者〕选择购置。
本内容介绍如何区分购置决策者和主要使用者，并面向核心用户编写用户故事。
现场演练与指导：建立自己的用户模型〔30分钟〕
案例分享：一款年收入12亿元的网络游戏对“所有用户〞的理解
第二阶段：版本规划与迭代方案
本阶段以第一阶段生成的各层次用户故事为输入，进行宏观的版本规划和微观的迭代方案。
传统敏捷开发缺少版本规划的具体实施方法，“按客户价值优先级进行排序〞听起来有道理但却难以实施。尤其是在初期无法获得全部用户故事的情况下，优先级排序非常困难。
本培训中的方法可以：
在开发的初期即可提供颗粒度可控的高层需求〔史诗故事〕进行排序；
产品经理根据业界统计数据即可进行版本规划；
在版本规划的同时自动完成工作量规划，从而准确安排迭代的数量；
在每个迭代的方案会上通过“敏捷扑克估算〞，借助集