项目管理者联盟 | 中国工程管理网 | 中国研发管理网   会员中心 资料库 项目管理者联盟博客 项目管理者联盟圈子

PMI-ACP®认证

适合敏捷开发项目
敏捷项目管理最佳实践

6月开课 | 实战课

PMI-PBA®认证

重视项目商业分析
商业价值与需求分析能力

4月开课 | 新闻

软考项目管理

信息系统项目管理师
系统集成项目管理工程师

计划 | 报名 | 经验

PMP®认证

单项目管理经典指南
年轻项目经理首选

北京 | 杭州 | 网络

PgMP®认证

大型复杂项目全球标准
定位高级项目管理层

北京 | 上海 | 深圳

NPDP®认证

产品管理国际认证
全球产品管理最佳实践

北京 | 上海 | 感受

PfMP®认证

链接战略与项目
实现组织资源投资回报

17计划 | 北京 | 上海

项目管理者联盟论坛
价值源于交流与分享
PgMG认证
会员区:
登陆ID 密  码
功能区: 公告建议 | 帖子搜索 | 管理团队 | 荣誉版主 | 帮助手册






 项目型组织  项目管理  工程项目  科技项目  项目化管理  管理软件  资格认证  职业休闲
EPM体系与流程 综合集成管理 总承包管理 IT软件开发 项目型制造 P3E/P6 PMP | PgMP 职业发展探讨
组织与人力资源 进度,范围,成本 国际工程 生物制药 专业服务 微软PROJECT IPMP | PRINCE2 管理学堂
项目管理信息化 团队建设与沟通 房地产 汽车设计开发 生活项目 PowerOn专版 软考项目管理 英语角|读书版
多项目与大项目 质量与风险 监理与咨询 手机数码 文体娱乐 注册建造师 房车吃游
PMO建设与管理 采购与合同 工程设计 项目管理硕士 闲聊版|商务版
俱乐部北京 | 大连 | 福州 | 广州 | 杭州 | 南京 | 山东 | 上海 | 深圳 | 四川 | 天津 | 武汉 | 西安 | 郑州 | 申请成立 TOP榜精华 | 最新 | 最热 | 会员

版面信息

说明:项目经理学习管理的地方

本版版主

aceld1981
登录:2011-8-5
次数:10
注册:2011-6-23
发帖:11

俱乐部导航

北京大连福州广州杭州
南京山东上海深圳四川
天津武汉西安郑州 

联盟·近期活动

2018年PMI(中国)项目管理大会
主办单位:PMI中国
时    间:2018-10-20
地    点:北京·北京国家会议中心
电    话:010-82273401-11
邮    件:pmp3@mypm.net

社区热点

PMP是全球共享的知识体系
2019年项目管理认证考试时间安排
PMP培训班(杭州)-2019年度计划
PMP培训班(北京)-2019年度计划
项目集管理PgMP认证培训-12月北京
项目集管理PgMP认证培训-12月上海
项目集管理PgMP认证培训-9月上海
项目组合管理PfMP高端课程-9月上海
NPDP国际产品经理认证培训-9月上海
PMP培训班(北京)-针对12月考试

精彩专题

更多:

推荐信息

·项目经理沙龙俱乐部
·推荐项目管理公开课程
·联盟VIP会员服务
·联盟99元大课堂
·建造师课程辅导免费试听

社区圈子

项目经理职业生.
圈主:zhenjm
行业:综合应用

软件项目经理水.
圈主:camer
行业:IT软件

深圳市东方大唐.
圈主:东方大唐
行业:IT软件

企业项目管理体.
圈主:zhenjm
行业:综合应用

项目管理小茶馆
圈主:heroxmt
行业:能源煤电油

联系社区管理员

咨询电话 010-82273401/11
斑竹申请 admin@mypm.net

项目管理者联盟
版权所有 © 2003-2004
京ICP证070584号 
BBS业务许可2007第353号 
最佳显示模式:1024*768像素
项目管理与PMP认证
需求设计层面如何实施敏捷 [发表于 2016-11-25]
状态 开放帖 精华贴 浏览量 2140   
该帖子同步发自圈子:项目管理小茶馆 (访问该圈子)

  敏捷开发其实不光要求开发层面和测试层面的敏捷,其实对需求设计层面也是要敏捷的,这样才能配合后续的开发和测试,使之真正的敏捷起来,前面介绍过敏捷开发的大体模式了,这次主要分享一下实际操作过程当中需求层面如何进行敏捷设计。

  大多数情况下需求的处理过程都可以分为需求分析和需求设计两部分,前者要将业务需求转化成产品需求,后者要将产品需求转化为产品设计,也即成品的PRD。在做需求分析的时候,我们也是接到一部分需求之后,按钮业务优先级来做分析,每次分析肯定是将相互关联的需求放在一起分析,或者是先分析优先级较高的,后分析优先级较低,这个过程将分析的任务进行了划分,因此其也较为接近于敏捷的模式,这里撇开不谈,主要讲需求设计部分如何与后面的开发、测试结合起来。

  在真正开始谈敏捷设计之前,我觉得有必要思考一下是否所有的需求都适合用敏捷设计?为什么有这样的疑问,在于敏捷开发其实是较为灵活的,并不是一味的为了敏捷而敏捷,其也可以分成产品敏捷和项目敏捷两种方式,在我的理解里面,产品敏捷是真正的将敏捷设计、敏捷开发、敏捷测试结合在一起的,从产品的层面讲所有的任务都用敏捷的方式进行管理;而项目敏捷则采用的是需求设计走的是瀑布的模式,开发和测试才是敏捷的,因此两者之间还是有点差异,为什么有的需求不适合用敏捷的方式的来设计呢?

  敏捷的模式总的来讲就是将整体拆为多个个体,然后再单独的完成各个个体以达到这些个体合成之后就是整体的效果,所以这里就有一个问题存在,产品的整体需求是否适合拆分?个人在操作经验中总结如下:

  1、各功能之间较为独立的适合敏捷。一个产品有十个功能点,各个功能点之间相互依赖关系不强的,松耦合,就可以每个功能点单独抽取出来做设计;

  2、功能本身的逻辑遵循某种操作流程的适合敏捷。功能的实现是按照一个较为固定的流程一步一步往下走的,这样可以将每一个步骤单独拆分开;

  3、产品上线之后的版本维护适合敏捷。上线之后,对一些BUG、问题、小需求的缝缝补补,都适合用敏捷的方式来设计;

  4、上线后的新增需求适合敏捷。上线的的新增需求一般都针对某个功能模块来进行设计,相对来说较为独立,因此也适合敏捷设计;

  反之,如果不能满足以上几个条件的,特别是耦合度较高的需求,个人建议还是走瀑布的模式,把整体的需求都梳理清楚之后做整体的需求设计,这样可以避免后面的设计过程要改动前面的设计结果的问题,减少一部分的需求变更,敏捷虽然说很大的一个优势就在于可以较好的适应需求变化,但这个需求变化是指来自于业务层面的,而不是来自于产品设计人员或者产品经理自身的工作方式所导致产生的。当然肯定也有人是全部都走敏捷的,这样的话对其产品规划能力要求较高,整体思维逻辑要很清晰,才能避免出错,这里只是个人建议,仅供参考。

  说完是否需要采用敏捷设计之后,下面讲一下敏捷设计的产出如何维护。平常我们称一个功能点为一个CASE或者是一个Story,而在敏捷里面称之为backlog产品条目,其实只是换了个名称而已,实质没有变。之前我也说过在学习他人长处的时候,重要的是理解和变通,而不是照抄。

  产品backlog是敏捷的核心,也是整个产品敏捷过程的起源。从根本上说,它就是一个需求、或故事、或特性等组成的列表,按照重要性的级别进行了排序。它里面包含的是用户或者业务方想要的东西,并用用户或者业务方可以理解的术语加以描述。通常有如下几个部分:

  backlog示例

  序号ID:统一标识符,就是个自增长的数字而已,用以唯一标示每个backlog,主要用来做标示用,以及在PRD当中标注每个backlog所对应的需求设计描述;

  名称Name:简短的、描述性的backlog标题,比如“查看你自己的交易明细”。它必须要含义明确,这样开发人员、测试人员才能大致明白我们说的是什么东西,其实也方便产品经理自身做checklist检查,可以跟其他backlog区分开,它一般由2到10个字组成;拆分backlog是有要求的,一般要求每条backlog都能在规定的单个迭代周期里面完成;

  重要性Importance:产品经理评出一个数值,指示这个backlog有多重要,一般为1到10之间的整数值,分数越高越重要。其实就是优先级,只不过有的人所理解的优先级是1最优先,所以这里用重要性来表述。优先级的评定主要参考两个维度,一是业务价值,二是紧迫性,其他的都可以暂不考虑;

  工作量估算Initial estimate:团队的初步工作量估算,表示完成该backlog所需的工作量,最小的单位是0.5人/天。为尽量提高估算的准确性,目前个人采用的是整个团队每人都写一个估算工作量,去掉一个最高的,去掉一个最低的,剩下做平均,呵呵,然后再安排各自讲解一下为什么,最终要在团队内部达成一致;

  演示How to demo:大略描述了这个backlog应该如何进行示范,本质就是一个简单的测试规范。一般为“先这样做,然后那样做,就应该得到……的结果”,敏捷对每个backlog的要求就是可演示可单独上线的;

  备注Notes:相关信息、解释说明和对其它资料的引用等等,一般都非常简短;

  通常都把backlog存放在共享的Excel文档里面,以便团队成员都可以随时查看编辑。一般来说这个文档归产品经理维护,但也并不把其他团队成员排斥在外。开发人员和测试人员常常要打开这个文档,弄清一些事情,或者修改估算值。

  这里又会产生一个问题,那就是如何让产品backlog停留在业务层面上?举例来说,如果产品经理有技术相关的背景,那他就可能添加这样一个backlog:“给Events表添加索引”。真正目的也许是“要提高在后台系统中搜索事件表单的响应速度”。到后面可能会发现索引并不是带来表单速度变慢的瓶颈,也许原因与索引完全不相干。

  所以指出如何解决问题的应该是开发团队,产品经理只需要关注业务目标即可。这种面向技术的backlog,可以一直问下去“为什么”,直到发现内在的目的为止,然后再用真正的目的来改写这个backlog(“提高在后台系统中搜索并生成表单的响应速度”)。最开始的技术描述只会作为一个注解存在(“为事件表添加索引可能会解决这个问题”)。

  维护backlog表就是一个对产品需求进行拆分的过程,拆分完成后再根据迭代计划来设计具体的实现,前面所讲的项目敏捷则是将所有需求都设计完成之后才进行拆分,这时主要就是为了把开发任务和测试任务拆分出来了。

  相对来说,敏捷还是一种较为新颖的模式,目前在互联网行业用的较多,每个公司在用的时候实际情况可能都不大一样,其实没有关系的,适合自己的就是最好的,只要能提高产品迭代发布的效率,就可以了,先用起来,然后在用的过程当中慢慢优化,发挥敏捷的最大的效用。

--------------------------------------------------------------------------------------------------------
项目管理者联盟资深会员
>>> 由论坛统一发布的广告:
楼主 帅哥约,不在线,有人找我吗?子墨


职务 无
军衔 主帅
来自 贵州省
发帖 846篇
注册 2013-6-2
PM币 28931
经验 11973点

Re:需求设计层面如何实施敏捷 [回复于 2016-11-28]
必须点赞 有木有 写的太好了
1楼 美女约,不在线,有人找我吗?bolechuanmei


职务 无
军衔 无军衔
来自 河北省
发帖 2篇
注册 2016-11-28
PM币 34
经验 10点

Re:需求设计层面如何实施敏捷 [回复于 2016-11-28]
赞赞
2楼 美女约,不在线,有人找我吗?首信软件


职务 无
军衔 中尉
来自 上海市
发帖 207篇
注册 2016-11-28
PM币 1539
经验 828点

Re:需求设计层面如何实施敏捷 [回复于 2017-1-3]
受教
3楼 帅哥约,不在线,有人找我吗?zchyxy


职务 无
军衔 无军衔
来自 河南省
发帖 1篇
注册 2017-1-3
PM币 24
经验 8点

Re:需求设计层面如何实施敏捷 [回复于 2017-2-28]
完成任务
4楼 帅哥约,不在线,有人找我吗?mawei1983


职务 无
军衔 无军衔
来自 上海市
发帖 1篇
注册 2017-2-28
PM币 10
经验 8点

Re:需求设计层面如何实施敏捷 [回复于 2017-3-1]
收藏
5楼 帅哥约,不在线,有人找我吗?13072523216


职务 无
军衔 无军衔
来自 江苏省
发帖 1篇
注册 2017-3-1
PM币 14
经验 6点

共1页  97 [ 第1页 ] 8:
  
!  您尚未登录,不能回复主题。    现在 登录  注册
关于联盟 | VIP会员 | 培训服务 | PMP认证 | PgMP认证 | 刊物出版 | 沙龙会议 | 人才服务 | 广告投放 | 联系我们 | 友情链接
建设运营:共创时网络
版权所有 京ICP证070584号 BBS业务许可2007第353号