需求如何进行敏捷设计

标签: 产品设计 设计思想 | 发表时间:2013-01-29 06:21 | 作者:P迪
分享到:
出处:http://www.alibuybuy.com

本文作者 @朱军华Ronzhu 敏捷开发其实不光光要求开发层面和测试层面的敏捷,其实对需求设计层面也是要敏捷的,这样才能配合后续的开发和测试,使之真正的敏捷起来。

我们可以通过在实际操作过程当中在需求层面进行敏捷设计的分析来了解需求的敏捷设计。

大多数情况下需求的处理过程都可以分为需求分析和需求设计两部分,前者要将业务需求转化成产品需求,后者要将产品需求转化为产品设计,也即成品的PRD。

在做需求分析的时候,我们也是接到一部分需求之后,按钮业务优先级来做分析,每次分析肯定是将相互关联的需求放在一起分析,或者是先分析优先级较高的,后分析优先级较低,这个过程将分析的任务进行了划分。

因此其也较为接近于敏捷的模式,这里撇开不谈,主要讲需求设计部分如何与后面的开发、测试结合起来。

在真正开始谈敏捷设计之前,我觉得有必要思考一下是否所有的需求都适合用敏捷设计? 为什么有这样的疑问,在于敏捷开发其实是较为灵活的,并不是一味的为了敏捷而敏捷,其也可以分成产品敏捷和项目敏捷两种方式。

在我的理解里面,产品敏捷是真正的将敏捷设计、敏捷开发、敏捷测试结合在一起的,从产品的层面讲所有的任务都用敏捷的方式进行管理;而项目敏捷则采用的是需求设计走的是瀑布的模式,开发和测试才是敏捷的,因此两者之间还是有点差异。

有的需求不适合用敏捷的方式的来设计

 

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

  • 各功能之间较为独立的适合敏捷。一个产品有十个功能点,各个功能点之间相互依赖关系不强的,松耦合,就可以每个功能点单独抽取出来做设计。
  • 功能本身的逻辑遵循某种操作流程的适合敏捷。功能的实现是按照一个较为固定的流程一步一步往下走的,这样可以将每一个步骤单独拆分开。
  • 产品上线之后的版本维护适合敏捷。上线之后,对一些BUG、问题、小需求的缝缝补补,都适合用敏捷的方式来设计。
  • 上线后的新增需求适合敏捷。上线的的新增需求一般都针对某个功能模块来进行设计,相对来说较为独立,因此也适合敏捷设计。

反之,如果不能满足以上几个条件的,特别是耦合度较高的需求,个人建议还是走瀑布的模式,把整体的需求都梳理清楚之后做整体的需求设计,这样可以避免后面的设计过程要改动前面的设计结果的问题,减少一部分的需求变更.

敏捷虽然说很大的一个优势就在于可以较好的适应需求变化,但这个需求变化是指来自于业务层面的,而不是来自于产品设计人员或者产品经理自身的工作方式所导致产生的。

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

敏捷设计的产出如何维护

 

平常我们称一个功能点为一个CASE或者是一个Story,而在敏捷里面称之为backlog产品条目,其实只是换了个名称而已,实质没有变。

之前我也说过在学习他人长处的时候,重要的是理解和变通,而不是照抄。 产品backlog是敏捷的核心,也是整个产品敏捷过程的起源。从根本上说,它就是一个需求、或故事、或特性等组成的列表,按照重要性的级别进行了排序。

它里面包含的是用户或者业务方想要的东西,并用用户或者业务方可以理解的术语加以描述。通常有如下几个部分:

backlogexample

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

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

作者博客: IT民工

 


© 推荐 for 互联网的那点事, 2013. | Permalink | No comment | Add to del.icio.us
Post tags:

你可能也喜欢:

要边走边阅读的思想者书柜 (@toodaylab)

有使命感的设计–《设计中的设计》 (@70man)

用户体验设计思想:瞬间设计(一)

读设计看需求

隐藏在iOS5抄袭背后的设计思想
无觅

Feed enhanced by Better Feed from Ozh

相关 [需求 何进 敏捷] 推荐:

需求如何进行敏捷设计

- - 互联网的那点事
本文作者 @朱军华Ronzhu 敏捷开发其实不光光要求开发层面和测试层面的敏捷,其实对需求设计层面也是要敏捷的,这样才能配合后续的开发和测试,使之真正的敏捷起来. 我们可以通过在实际操作过程当中在需求层面进行敏捷设计的分析来了解需求的敏捷设计. 大多数情况下需求的处理过程都可以分为需求分析和需求设计两部分,前者要将业务需求转化成产品需求,后者要将产品需求转化为产品设计,也即成品的PRD.

敏捷开发者需求巨大

- - InfoQ cn
一份 Yoh的研究报告表明,在2010到2012年期间,全美国的公司总共登出过558,918份关于敏捷工作的广告,但是在此期间,只有不到121,876个有效的候选人,每100份工作中只有17个候选人. 在这些有效的求职者中,超过50%的人拥有10年以上的工作经验,但只有不到2%的人拥有1到2年的工作经验.

敏捷

- - 人月神话的BLOG
对于敏捷开发,我前面其实已经有很多文章提到了,再次强调下敏捷的核心思想个人理解为三个重要的方面. 其一是需求的条目化并以需求点进行的全程追踪和跟踪;其二是短周期迭代;其三是基于持续集成思想的进度和质量可视化. 对于敏捷开发本身,对于很多内容我仍然坚持自己的观点,具体如下:. 对于大型全新系统的开发,如果是以底层数据为核心的业务系统,则不能单纯的应用敏捷开发.

忘记敏捷

- Guan - 所有文章 - UCD大社区
瓦沙奇山下那段著名的敏捷宣言,至今已近十年. 似乎在不经意之间,敏捷已经被视为 CMM 之后又一次软件开发领域的浪潮,不论业界报道或者坊间传闻,都不约而同地将敏捷视为一个时代的开始,与之同存的是那些未尝或浅尝敏捷者的各种质疑和争论. 当敏捷在介于自发与非自发中间演变成为一种近乎“革命”的运动,围绕在它身边的躁动就不曾停歇,对于细节的争执,对于方法的固执,让我们更多地为敏捷的未来忧心忡忡.

在敏捷

- - 崔凯
这是在 www.scrum.org 网站上轮播的一张图,网站上 SCRUM GUIDES 一栏,详尽的介绍了敏捷开发的方式和方法,有兴趣的可以看一下. 这里仅谈一下 Scrum 怎么玩更舒服. 回到那张图,想玩的舒服,一起聊聊很重要. Scrum 不是定死的一种模式,每个团队有每个团队的玩法. 通过不断的磨合、反思、改进,形成最适合自己团队的模式.

敏捷个人和敏捷开发

- beralee - 博客园-首页原创精华区
    自2001初成立了敏捷联盟到现在10年的推广,敏捷开发已日渐成为当前IT行业软件开发的一种主流方法. 没有银弹,任何方法都不可能解决所有问题,反而方法应用本身还会带来新的问题. 我在今年6月份上海举办的ScrumGathering中进行了一场敏捷个人话题的分享,我说到,想要Doing敏捷并不难,只要花上几天功夫学习敏捷知识之后就可以在小范围团队中去实践了,而要做到真正的Being敏捷则并不容易,而导致并不是真正敏捷的原因中,人是一个主要问题之一,这也是为什么现在敏捷社区中对人开始越来越关注的原因.

敏捷中国2011

- Ben - 梦想风暴
果然是按照个人规律来的,我又参加了单数年的Agile China. 其实,真正仔细听的只有两个人的session,吴军和Fred George. 至于其它关于敏捷的讨论,好吧,我承认,我不是很感兴趣. 刚看完吴军的《浪潮之巅》,于是,很敢兴趣他关于工程师的说法. 在《浪潮之巅》里,他提到了五级工程师的说法,但是,书中并没有详述何为五级工程师,在敏捷中国上,他给出了答案:.

敏捷开发——Programmers(27)

- plidezus - 西乔的九卦
载于《程序员》杂志2011年第7期. 从这一期起,开始在杂志上登出整P的大幅漫画,需要看大图的同学们,讯猛点击下图. 这个系列的漫画讲述程序员——这种神秘人类的囧事,故事多来源于我身边的程序员朋友,且以互联网开发背景为主. 如果你有什么可乐的关于程序员的故事、对话、代码,愿意通过漫画的形式分享,请给我发邮件.

漫谈敏捷开发

- scotty - ITeye论坛最新讨论
软件开发是一种非零和博弈,意思是某一方的获得不是建立在另一方的损失之上,所以软件开发必须实现双赢,帮助客户成功的同时帮助自己成功. 如:通过软件帮助客户把手上的5块钱变成50块钱,然后从客户那里拿5块钱. 通过软件帮助客户节约50块钱,然后从客户那里拿5块钱. 传统的汽车制造是以计划驱动,如根据往年的经验判断今年应该生产多少汽车,但是这样带来的问题是有可能等汽车生产出来,市场已经不需要了,而这就是一种极大的浪费.