需求如何进行敏捷设计

标签: 产品设计 设计思想 | 发表时间: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.

谈需求和设计

- - 人月神话的BLOG
在这里再谈下需求和设计的边界问题,我们最终的业务系统实现出现的偏差,究竟是需求的问题还是设计的问题. 如果边界不清楚则很难明确的区分. 对于需求本身有原始需求,用户需求,产品需求和系统需求的各种阶段;而对于需求的过程也本身存在原始需求的收集,需求分析,需求挖掘,和需求相关的业务建模. 而对于设计同样存在总体的企业架构设计,到单个应用的总体设计和架构设计,概要设计和详细设计.

交互探讨:以用户场景和产品需求导向的设计

- - 互联网的那点事
在对设计师而言,对自己设计最重要的就是深刻理解产品需求,深入考虑用户是如何使用产品,. 作为交互设计师,我觉得有几个发展阶段:. 初入这个领域,大部份人可能更多精力放在如何使用工具、如何画线框图、如何将想法变为实际可见的Demo;. 再往下一个阶段的设计师,可能会考虑线框图怎样做得更加合理、怎样可以有更棒的交互效果、关注任务流程和信息结构的设计以及可用性原则;.

扫盲 HTTPS 和 SSL/TLS 协议[1]:背景知识、协议的需求、设计的难点

- - 细节的力量
★HTTPS 协议的需求是啥. ★设计 HTTPS 协议的主要难点.   要说清楚 HTTPS 协议的实现原理,至少需要如下几个背景知识. 大致了解几个基本术语(HTTPS、SSL、TLS)的含义. 大致了解 HTTP 和 TCP 的关系(尤其是“短连接”VS“长连接”). 大致了解加密算法的概念(尤其是“对称加密与非对称加密”的区别).

互联网架构,如何进行容量设计?

- -
互联网公司,这样的场景是否似曾相识:. 场景一:pm要做一个很大的运营活动,技术老大杀过来,问了两个问题:. (2)如果扛不住,需要加多少台机器. 场景二:系统设计阶段,技术老大杀过来,又问了两个问题:. (2)如果需要分库,需要分几个库. 技术上来说,这些都是系统容量预估的问题,容量设计是架构师必备的技能之一.

再谈需求

- - 人月神话的BLOG
谈需求工程方面的文章前面写过很多,本文仅做最近思考的一些点滴记录. 首先我们谈下业务建模层面,对于从用户提出最初的业务需求到交付一个完整的系统,在建模层面涉及到两个层面的抽象,其一就是业务建模解决现实世界本身的抽象描述,其二就是软件架构设计,解决从业务模型到IT架构模型的第二次转换. 在早些时候我们看到这两个层面的建模内容都由系统分析员承担或完成,在岗位不断细分后我们看到反而会出现忽视了业务建模的问题.

向顶级设计公司学习如何进行“头脑风暴”

- - 博客 - 伯乐在线
当今无数科学家围绕着群体智慧,研究的重点在于,群内个体之间交互的规则似乎非常简单,但整体行为上,却会产生具有“智慧”的行为. 自然界的案例比比皆是,如果你去海底世界,你可以看看一个小鱼群如何躲避鲨鱼,当鲨鱼游近的时候,鱼群会自然的在鲨鱼前方空出一个洞. 不管鲨鱼怎么游,鱼群的洞都随着鲨鱼的游动而调整.

需求变化与IoC

- - 酷壳 - CoolShell.cn
【感谢 Todd投递本文 – 微博帐号:@ weidagang 】. 程序员XX遭遇车祸成植物人,医生说活下来的希望只有万分之一,唤醒更为渺茫. 可他的Lead和亲人没有放弃,他们根据XX工作如命的作风,每天都在他身边念:“XX,需求又改了,该干活了,你快来呀. ”,奇迹终于发生了,XX醒来了,第一句话:“需求又改了.

进化而来的需求

- - 极客公园-GeekPark
[核心提示]需求是可以创造,可以进化的. 在需求的“博尔赫斯库”中,我们要做的,仅仅是模拟规则,让需求,优胜劣汰. 如果本文的标题和导语引起了坐在电脑前的你的兴趣,同时又产生了些许的疑惑,那么恭喜我自己,我的目的达到了 (真是恶趣味……). 那么,在对它们进行解释之前,还容我卖个关子,先从几个有趣的见闻讲起.

解决方案与需求

- - 扯氮集--上海魏武挥的博客 - 扯氮集--上海魏武挥的博客
曾经有一个很有名的段子,大致意思就是说在汽车尚未出现的马车时代,你去做消费者调研,只会得到这样的答案:我需要一匹更快的马,而不会得到:我需要汽车. 因为对于消费者来说,他从来没有看到过汽车,怎么可能回答你需要汽车呢. 这个段子,似乎充分说明了,创新,尤其是颠覆式创新、破坏性创新是不可能通过需求调研出来的.