今天有幸参加了一个沙龙,其中一个主题是《从愿景到用户故事》-量化建模语言在敏捷开发中的应用
一说到这个,我兴致就来了,首先感觉这是作为PO应该了解的知识
量化, 建模语言, 敏捷开发,这些关键词都是我的兴趣点
好吧, 兴致勃勃的来到了会场,哇塞, 只有一个缝隙的空档, 塞着坐了进去, 闷热的气流(好像没有气流),有点喘不上气的感觉 , 开始吧,希望我不要睡着 ~~
还是要特别感谢 火星人 -陈勇老师 ,听后感---非常棒的课程!
量化什么?怎么个量化? 带着这些疑问开始了~~~~
我的理解就是什么人做了什么事情,偶是程序员的思维,一想就又跑到用例图上了,赶快拽回来 ,看,角色业务图是这个样子的 ,这张图的核心就是列出核心业务,侧重价值分析,老师已经点的很清楚了
这个在我理解,就是谁对什么对象做了什么动作,谁和这个对象,都可以抽出是实际存在的,理解为实体, 做了什么动作,理解为操作或动作,也是他们之间的关系
刚才的角色业务图,是谁做了什么,理解为只有两层关系
而实体关系图, 是谁对什么对象做了什么,拆分出三层关系,个人觉得这套业务转化为实体的思路非常值得学习, 详细可见PPT
随着角色和对象转化为实体, 动作转化为关系,一个简单的实体关系图就呈现了
3.根据ER实体图,画出UCF图(理解为带甬道的用例图),这个时候关键的概念引入了: 1×角色-业务图=1× 实体-状态图, 1×实体=1×用例-流程图=4~9个用例
看,没错吧,带甬道的用例图,他有啥作用呢?往下看,就知道了,量化的概念马上就出来了
对一个实体的操作,体现到系统上, 一般有增、删、查、改, 这是基本的四个操作,如果再加上批处理,申请,审核等等, 就是这句话: 1×实体=1×用例-流程图=4~9个用例
看下图,便知:
好吧,上面的图,已经非常清清晰了, 老师这个时候说出了一组数字,应该是有科学评估过吧
一个实体模块是35人日(4-5个用例 例如增,删,改,查)
一个用例是4.3人日
这样,量化的数据就出来了
如果用实体量化来估算, 实体模块: 2×35人日= 70 人日
如果用用例量化来估算, 用例: 4.3(个实例)×7+ 4.3(个实例)×7= 60.2 人日
可以看出,使用一种简单的建模语言,在项目初期可以快速将业务需求转化为技术需求
在立项,预算与招标时, 仅用极少量的分析工作, 即可获得工作量,工期及价格等全方位的信息
一个小时的分享,量化什么,怎么量化,尽收眼底
量化什么? 量化的是实体,量化的是用例
怎么量化? 从用户-业务图转化为ER实体关系图, 对实体的量化就已经出来了,ER实体关系图,转化为用例-流程图, OK, 对用例的量化也就出来了
需要记住的数字:
7×功能点(单独计算):一个功能点仅从开发工时来说,一般是7人日
35×功能点(含所有操作):一个功能点从业务需求分析,到立项,设计,开发,测试,上线,平均35人日
4.3×用例:等同于一个用户故事,对一个用例从需求到上线,平均4.3人日
偶觉得受益匪浅,也希望这篇能给大家带真的带来些分享~~
最后其实我还有两个疑问,大家一起探讨吧