一期内容回顾,如果希望了解可以点击页首的目录。
之一:用户故事有些比较主要(直接体现用户价值),有些相对次要,应区别对待;其中“业务操作”最适合写成。
之二:利用功能点中业务数据(文件)+业务操作形成最主要的用户故事框架,非常方便产品经理和用户理解产品功能
之三:利用快速功能点可以迅速估算这些用户故事的完成工作量,即功能点 = 业务数据 × 7 + 业务操作 × 4 。
之四:功能点数 / 生产率 = 估算工作量,其中引用了国际和中国OA的参数。
之五:总结。
“为什么一期说了半天,不像是谈用户故事,更像是功能点?”因为用户故事和功能点都是对需求进行条目化、描述的方法,而后者更利于在前期进行估算,估算的精度也非常好,所以建议大家在写主要的用户故事的时候,遵从功能点的定义。
而二期,则主要是说进入开发阶段后,那些微小的开发任务如何描述和管理,以及众多大小各异的用户故事该如何组织。
二期内容:
1. 回顾一期
2. 有哪些种类的用户故事?哪些决定了产品架构?哪些是细枝末节?不方便写成“作为一个……可以……以便……”的故事该如何描述?
3. 用户故事组织结构:如何“摆放”用户故事才能不失大局?如何才能“一眼看到”10人年开发的成果?
4. 用户故事跟进开发:用户故事后来哪里去了?用例、MVC这些设计实现元素与用户故事这个需求管理元素有什么对应关系?
鉴于内容很多,而且多数不是传统的敏捷开发考虑的问题,而是首次被实践和提出来的解决方案,因此视现场的进度和互动,可能要分3期才能讲完。
本话题中所涉及的产品需求管理理念,在火星人敏捷开发免费工具中已经实现,欢迎同时关注本博客中未来关于火星人的文章。
位置:
直播现场 QQ群:190375042 PMBar项目实践群,需要提交简历,欢迎项目经理以上人员加入,加入报名: http://www.pmbar.net/read.php?tid=1406
转播现场:博客左侧四个QQ群均进行图文转播,所问问题也会被反向转播到直播现场,请根据自己所处地区加入相应的QQ群。