当前位置:首页 > 经验学习 > 设计思想

需求如何进行敏捷设计

所属栏目:设计思想 时间:2013-12-26 来源: 作者:admin 点击:

本文作者@朱军华Ronzhu 敏捷开发其实不光光要求开发层面和测试层面的敏捷,其实对需求设计层面也是要敏捷的,这样才能配合后续的开发和测试,使之真正的敏捷起来。
我们可以通过在实际操作过程当中在需求层面进行敏捷设计的分析来了解需求的敏捷设计。
大多数情况下需求的处理过程都可以分为需求分析和需求设计两部分,前者要将业务需求转化成产品需求,后者要将产品需求转化为产品设计,也即成品的PRD。
在做需求分析的时候,我们也是接到一部分需求之后,按钮业务优先级来做分析,每次分析肯定是将相互关联的需求放在一起分析,或者是先分析优先级较高的,后分析优先级较低,这个过程将分析的任务进行了划分。
因此其也较为接近于敏捷的模式,这里撇开不谈,主要讲需求设计部分如何与后面的开发、测试结合起来。
在真正开始谈敏捷设计之前,我觉得有必要思考一下是否所有的需求都适合用敏捷设计? 为什么有这样的疑问,在于敏捷开发其实是较为灵活的,并不是一味的为了敏捷而敏捷,其也可以分成产品敏捷和项目敏捷两种方式。
在我的理解里面,产品敏捷是真正的将敏捷设计、敏捷开发、敏捷测试结合在一起的,从产品的层面讲所有的任务都用敏捷的方式进行管理;而项目敏捷则采用的是需求设计走的是瀑布的模式,开发和测试才是敏捷的,因此两者之间还是有点差异。
有的需求不适合用敏捷的方式的来设计

敏捷的模式总的来讲就是将整体拆为多个个体,然后再单独的完成各个个体以达到这些个体合成之后就是整体的效果,所以这里就有一个问题存在,产品的整体需求是否适合拆分?个人在操作经验中总结如下:
各功能之间较为独立的适合敏捷。一个产品有十个功能点,各个功能点之间相互依赖关系不强的,松耦合,就可以每个功能点单独抽取出来做设计。
功能本身的逻辑遵循某种操作流程的适合敏捷。功能的实现是按照一个较为固定的流程一步一步往下走的,这样可以将每一个步骤单独拆分开。
产品上线之后的版本维护适合敏捷。上线之后,对一些BUG、问题、小需求的缝缝补补,都适合用敏捷的方式来设计。
上线后的新增需求适合敏捷。上线的的新增需求一般都针对某个功能模块来进行设计,相对来说较为独立,因此也适合敏捷设计。
反之,如果不能满足以上几个条件的,特别是耦合度较高的需求,个人建议还是走瀑布的模式,把整体的需求都梳理清楚之后做整体的需求设计,这样可以避免后面的设计过程要改动前面的设计结果的问题,减少一部分的需求变更.
敏捷虽然说很大的一个优势就在于可以较好的适应需求变化,但这个需求变化是指来自于业务层面的,而不是来自于产品设计人员或者产品经理自身的工作方式所导致产生的。



当然肯定也有人是全部都走敏捷的,这样的话对其产品规划能力要求较高,整体思维逻辑要很清晰,才能避免出错,这里只是个人建议,仅供参考。
敏捷设计的产出如何维护

平常我们称一个功能点为一个CASE或者是一个Story,而在敏捷里面称之为backlog产品条目,其实只是换了个名称而已,实质没有变。
之前我也说过在学习他人长处的时候,重要的是理解和变通,而不是照抄。 产品backlog是敏捷的核心,也是整个产品敏捷过程的起源。从根本上说,它就是一个需求、或故事、或特性等组成的列表,按照重要性的级别进行了排序。
它里面包含的是用户或者业务方想要的东西,并用用户或者业务方可以理解的术语加以描述。通常有如下几个部分:



序号ID
统一标识符,就是个自增长的数字而已,用以唯一标示每个backlog,主要用来做标示用,以及在PRD当中标注每个backlog所对应的需求设计描述;
名称Name
简短的、描述性的backlog标题,比如“查看你自己的交易明细”。它必须要含义明确,这样开发人员、测试人员才能大致明白我们说的是什么东西,其实也方便产品经理自身做checklist检查,可以跟其他backlog区分开。 它一般由2到10个字组成;拆分backlog是有要求的,一般要求每条backlog都能在规定的单个迭代周期里面完成;

请站长喝杯咖啡?

站长一直坚持白天工作、晚上熬夜更新素材,付出了巨大的精力和时间,其中的辛酸难以言述。

坚持免积分、免登录、无任何限制下载!如果本站素材对你有用,不妨考虑请站长喝杯咖啡鼓励一下!

标签:

你应该也喜欢这些吧

共有 0 条评论

给个评价吧

验证码: