我眼中的敏捷开发

没原创_去搜索 2015-08-26

展开全文

http://blog.sina.com.cn/s/blog_5d2070030101b9m0.html

生命周期法是用于信息产品（软件、网站、互联网产品等）设计和开发的常用的设计思想。

生命周期法常用的模型有：瀑布模型（文档驱动）、迭代式模型（功能驱动）、快速原型模型等。

问题所在：随着各种技术和市场和环境的进化，设计开发的流程也面临很多问题，一些深植在我们内心的看上去很经典的流程实际上已经不能满足现在设计和开发。

所以团队才经常会在项目进行中感觉进度缓慢、没有共同的交流语言。

首先我先提出两个现在在业界对于流程的改造的主流思想。

1、UCD（用户中心的设计）嵌入传统软件设计和开发流程；

2、敏捷开发嵌入传统软件设计和开发流程。

一、UCD（以用户为中心的设计）的兴起和流程

首先，我们来看一下，传统的软件设计和开发流程是什么。

经典软件开发流程（随便找的，但是基本上大同小异）：

其他软件开发经典流程参考1

这幅图中我们看到了很多我们或许误解但是经常挂在嘴边的概念。而这些概念每个人对他的理解不同从而导致流程冲突。

这几年，大家都或多或少听说了”用户体验“这个词。

其实在行业里边，”用户体验“”交互设计“的概念也很容易混淆。我们不谈论太多的概念。因为概念本身就是抽象的，没有

太多操作层面上的指导意义。

UCD的兴起是因为行业的进步和为了解决新问题的出现。

问题1：以前，一个项目开始的时候，以开发者为主的团队习惯的考虑的视角是程序本身，而甚少关注市场需求和好不好用。

也就是说，习惯性的只关注程序本身的性能而容易忽视了这个功能到底客户需不需要；

问题2：销售项目或者产品的时候，或者跟客户交流来定义需求的时候，总是无法将双方的视角统一。客户不懂技术，急需一种

直观的东西来交流；

问题3：对于团队内部。也少了一个环节来把最重要的“需求”“好用”来重点进行设计。因为，现在的用户对于信息产品的好坏已经

不是能不能完成功能，而是好不好用。苹果因为把交互和体验等用户分析做的很好，所以才走在了前面。其实这也正是现在用户体验这个

词大热的主要原因。现在很多互联网产品失败的重要原因及时所谓”三无“：无设计、无体验、无目标。

概念不重要，只要其本质能够推动团队前进并且达成结果就行。

在传统的流程中，不是没有分析市场需求、交互设计的过程。只是这些过程被埋没在了开发者思想主导的阴影里边。我们再来看一下

UCD流程是如何尝试嵌入传统经典的开发流程的：

首先我想说明的是，这张图标实际上已经是很早之前的成果了。其创作者本身正是ajax技术的创作者。

这样的东西其实现在看来也有很多地方需要改进。

UCD流程的嵌入是对传统流程的优化，并不是推翻。

UCD流程的嵌入，是衔接商业目标和软件开发的一个中间层。

其实狭义的UCD流程也在解决软件开发中，设计和逻辑的冲突。即前台和后台分割的工作流。比如microsoft blend，adobe 催化剂等。

UCD将整个产品开始的商业计划阶段、用户体验阶段从传统的以开发视角为导向的混在在不同流程中抽离出来，并加以固化和深化。

将强迫整个团队，将风险提早暴露，而不能等到最后才发现问题。

商业价值通过满足用户需求（用户需求）或者制造需求（网站目标）体现，需求通过功能体现，功能通过用户体验和交互设计来可视化和优化，并最终通过代码实现。

其实传统的软件设计流程有一个大前提，就是商业需求已经确定，甚至不需要确定，因为早期的软件出来就有市场。所以，传统的软件设计流程开始其实

始于一个既定的目标和相对确定的需求。类似于项目的流程。

而现阶段，很多团队问题是，一开始将产品设计和项目混杂在一起。商业目的没有确立的情况下直接开始功能的设计。跨度太大导致了团队的迷茫。原因还是

没有一个对流程的透彻的理解。

下面的图表是我对于 商业开发 UCD流程和传统开发流程的整合的一些对比和思考。

商业开发系列： BRD（商业需求文档） MRD（市场需求文档） PRD（产品需求文档）。其实从这三个文档，就可以看出，不同阶段所说的需求是不一样的，混淆了阶段只能让团队迷茫，不知道该做什么而杂乱无章。
UCD流程：战略层（其实就是商业计划等大的战略层面的确定）（对应的就是BRD）——》范围层（大的商业概念下的需求细分以及整合，寻找一个边界。）（其实对应的就是MRD，旨在市场层面上分析）————》结构层（交互设计等，将前一个环节产出的经过市场研究的需求转换成的功能，在交互层面上进行设计和优化，目的是解决用户中心理念的好用）（对应PRD）——》框架层（交互做好之后，将形成信息架构和导航设计，形成界面以及原型）——》表现层

商业开发	UCD流程	经典软件开发每个环节对应	经典软件开发流程	其他开发流程
BRD（商业需求文档）	战略层	经典软件开发项目的特性决定了产品设计已经做好，所以不涉及商业需求阶段的环节。	市场调研	要件设计
MRD（市场需求文档）	范围层	1、市场调研 2、需求分析	需求分析：用户视图、数据词典和用户操作手册
PRD	结构层	需求分析中的数据词典、用户操作手册	概要设计：包含了原型设计的内容
PRD	框架层	需求分析中的用户视图；概要设计；详细设计	详细设计：详细设计说明书（包含了界面的部分）
PRD	表现层	详细设计	编码开发
无	无（UCD流程走完之后，最终产出物交给开发阶段）	编码	测试	项目设计
无	无	测试
		上面可以看出经典的流程按照UCD 的流程被拆分了。所以才会出现之前讲到的问题。就是没有足够重视一些东西。	上面可以看出，经典开发流程中设计部分也占了工作量的70%，所以，我才说， UCD只是一种优化和重构，并没有推翻经典模式。

从图中可以看出：1、不同的流程有不同的重点，所以有些流程中会出现无的状态；

2、经典软件开发流程有强烈的项目特性，其前提是商业计划阶段的确定和需求的固化；

3、可以看到，经典软件开发流程中不是没有用户分析等UCD流程，只是被打散了。所以才会导致前面讲到的问题；

4、其实概念名字的不同只是名字不同而已，看本质实际上解决的问题是一样的。

问题：专家告诉我，UCD流程之后的开发流程被这样切成了两端，而将UCD流程和开发流程衔接起来是件很难得事情。

我的理解是：

1、UCD流程中，是需要开发人员介入的；

2、这不是一个瀑布模式，不是严格的从前到后。后面我将说到基于快速原型和迭代增进的方法。其实流程之间是重叠的，不是绝对分割的。

所以这也不存在一个绝对的一分为二的说法。

二、敏捷开发嵌入传统软件设计和开发流程研究

我们讨论了几个流程的统一和不同之处。我么在讨论一下如何在现实中操作层面有真正借鉴意义的流程。

大家可以发现，前面讲了那么一大堆，无论是UCD流程还是什么，都有着从前到后，从顶层到底层的类似瀑布流的模式。

这正是问题所在。

之前讲过，瀑布流模式存在很多问题，所以无论使用任何前面讲到的流程，如果还是瀑布模型，将或多或少出现问题。

敏捷开发出现背景说明：

1、快鱼吃慢鱼

互联网产品更新换代非常之快。就不细讲了。

2、总想快速完成工作，而无论团队资源有多少。

我的观点：原型法又叫快速原型法，主要是用来解决需求问题的。而迭代则是开发过程中不断的重复一些过程，是解决开发过程中的风险控制的。而增量法基本上都是和迭代法配合使用，所以我们平时说迭代法的时候，基本是在说迭代增量法。

所以迭代其实不只是用在开发过程，每一个环节都可以经过一次迭代过程。

比如需求确定阶段。

常见开发模型比较

	概论	缺点	优点
瀑布模型	按照流程或者设定好的里程碑从顶层往下一步一步的开发。上一步的产出物（文档驱动）没有结束之前，下一步处于停滞状态。其思想是认为整个系统若干个环节后的状态可以再一开始就能加以理解。	因为是文档驱动的，所以不直观；现在的需求分析本身就是一个变数极大，并且现在的很多产品更新换代很快，所以，指望全盘理解是不可能的；
迭代式模型（敏捷开发）	迭代类似于小型的瀑布模型，旨在快速走一遍流程出现一个基本核心功能的原型或者可执行版本，然后核实。然后再进行一遍优化的迭代过程，其版本号将会增加。如果有新的功能增加，则新的的迭代过程叫做增进迭代。他是功能驱动的，产出物是为了实现功能，而非文档。在每个瀑布模型的环节里边都可以进行一次微型迭代。	因为你不基于文档驱动，所以熟悉文档并且严谨的团队个性可能会增加文档控制的难度。	及早暴露了风险所在，因为每次迭代的结果输出的是原型或者可执行文件，更加直观。
快速原型模型（敏捷开发）	原型设计是一个工具，是为了确定真实的需求，并且提供修改和讨论的直观的载体。其可以和其他流程工具结合。