189 8069 5689

AUP2敏捷统一过程之一:序言及降低过程的总体拥有成本

这是敏捷统一过程系列的第一篇。(前篇,之一序言,栏目总目录)

涉县ssl适用于网站、小程序/APP、API接口等需要进行数据传输应用场景,ssl证书未来市场广阔!成为创新互联建站的ssl证书销售渠道,可以享受市场价格4-6折优惠!如果有意向欢迎电话联系或者加微信:13518219792(备注:SSL证书合作)期待与您的合作!

敏捷统一过程的全称是AUP(Agile Unified Process),不过为了能区别已经被提过一次的AUP(就是RUP),这里称之为AUP2。

这个系列会探讨如何在一家企业完整实施敏捷开发过程。在以往业界的讨论中,多数时候将话题集中在如何在一个小范围的团队中实施敏捷,比如Scrum本身的框架仅限于4~7人的团队如何做需求管理+计划管理+任务管理的;即使引入了Scrum of Scrums,其范围虽然扩大到几十人乃至上百人,但管理内容仍仅限于这三个环节。

而实际上一个企业实际要管理的内容很多,以一个产品研发企业为例,最早期的产品规划、用户群定义、团队招聘、绩效考核、产品运营、技术架构这些都是企业要考虑的问题,如果这些内容没有被照顾到,开发人员就可能会同时受到CMMI、Scrum、编程规范、团队模型……等不同的、互不相关的过程或技术的约束,写完这个文档再写那个文档,导致无所适从。

有些企业在实施敏捷开发后,由于很难和别的过程接口,很容易遇到下面这些问题:

1. 为什么我们使用了敏捷开发,但产品并没有成功?(与产品定位的接口,Nokiaer应该经常问这个问题)

2. 我们的队员有些不喜欢敏捷开发怎么办?(与团队模型的接口,比如不喜欢帮助别人,或者不喜欢让别人看代码)

3. 用户故事和用例我们应该写哪个?(与设计方法的接口,若已经实施了UML、面向对象、MVC、用户建模……等等一系列技术方法,问题会很尖锐)

4. 我们想同时使用Scrum和持续集成、自动化测试,他们之间有何关系?

5. 公司负责过程的质量部门在敏捷开发中扮演什么角色?

……

很多企业可能连问这些问题的机会都没有,因为他们发现“敏捷开发并没有想象中那么容易推广”,于是中途就放弃了。

AUP2敏捷统一过程尝试提供一个框架来思考这些问题,从而让软件开发人员不会感觉自己在很多管理方法、技术中分别工作,而是流畅地在一个统一的过程框架下工作。

AUP2的实践环节不是普适的,随着时间的变化也不是一成不变的。它只是提供了一个思路:在任何情况下,我们都应该统一地看待企业所采纳的过程、技术、组织架构……等内容,以期达到最低的拥有价值。

Process过程

Process这个词比较难解,在CMMI传入之前,国内基本上不知道这个词,国外也很少提到。对比下面这几个词汇,可以大致理解Process的含义。

Practice实践

大致指小规模的单一实践,比如需求跟踪矩阵、用例、序列图、用户故事、每日立会、自动化测试等。实践的规模大小不一,有些实践又是若干子实践的集合,比如持续集成。

Process过程

指若干实践的集合,这一集合能解决某些领域的某些范围的问题。

注意:以下的各种模型、方法论并不完全等同于过程,但这里抽取其呈现出来的过程侧面。

CMMI

CMMI中列出的内容大致相当于一家外包领域企业(尤其是为DOD提供外包开发的企业)所需的过程;它所涵盖的范围则是CMMI2级(需求管理、计划、跟踪……)、CMMI3级(需求开发,设计,测试……)等。

CMMI是迄今为止描述过程最完整的体系,它采用级别Level~过程域Process Area~实践Practice的方式来完整描述自己的体系;还有一种不太为人熟知的方法,就是先分为工程/管理/支持/组织级改进四个域(具体名字忘了),然后再过程域~实践三级。

从实用性的价值看,这种分类方法能让我们理解其他过程能管理多大的范围。

UML

UML本身不是一种过程,但在使用UML的时候会使用到CMMI中提到的需求开发、设计、编码三个过程域,还会用到用户建模、部署这两个CMMI没怎么提的内容。

UML对于理解何为“Unified”非常有好处:UML把需求、设计、编码三个环节联合起来思考,一个环节的输出,会变成下一个环节的输入,环环相扣,从而大大节省了开发工作量。

这个特点在后面的AUP2描述中还会提到。

RUP(Rational Unified Process)

RUP的范围包括(含英文缩写的是与CMMI重合的部分,虽然不完全重合):

商业建模,需求(RD需求开发),分析与设计(TS设计与现实),实现(TS设计与实现,学名叫“technical solution技术解决方案”),测试(VER验证测试/VAL验收),部署(VAL验收),配置与变更管理(CM配置管理/ReqM需求管理),项目管理(PP项目计划/PMC项目跟踪),环境。

商业建模之所以在CMMI中不太重要,应该是因为CMMI应用与外包领域中的乙方,而这个过程则属于甲方的职责。

环境是RUP的一个重点内容之一,目的是向软件组织提供过程与工具的支撑。这正是Rational的业务所在。

RUP还潜移默化地定义了众多角色,虽然从敏捷开发的角度看,这略微有点不“跨职能”,但从实践的角度看,能让团队意识到存在某些复杂的工作需要有人承担。

Scrum/XP

Scrum的主体内容也可以称之为一个过程,应用于需求快速变化但又需要整体计划的企业(这个定义适应面很大,因此才大受欢迎)。按CMMI的名词定义,Scrum涵盖了ReqM需求管理、PP项目计划、PMC项目跟踪与监控这三个过程域。

XP较少提到过程的内容,更像是互相关联的一些实践的松散集合,而XP发展的趋势也是化整为零。按CMMI的名词定义,极限编程覆盖了RD需求开发、TS设计与实现、VER验证与测试。

敏捷开发过程的局限性

与其他过程相比,显然Scrum/XP的覆盖面相对少。

“这正是我们选择敏捷开发的原因,因为它比较轻量级。”或许有人会说。但这个回答的理解有问题:轻量级和覆盖面是两个概念。无论采用什么开发过程,商业建模、绩效考核、团队发展这些内容都是企业必然会考虑的,一个覆盖面过小且无法为自己不覆盖的部分提供支持的过程,尽管降低了局部的管理难度,却有可能反而会使公司的研发管理的总体成本变高。

典型的就是绩效管理,由于敏捷开发未提供绩效管理的模型,导致很多企业仍然采用传统的绩效管理方法(比如面向个人的绩效考核,数代码行,数缺陷数……),而这种管理方法又会反过来导致敏捷开发进行不下去。

在本人参与或了解的企业中,实施敏捷开发的主要阻力不是敏捷开发本身的实践有多难,而是如何将敏捷开发与现有的组织结构和制度相适应,或如何改造现有的结构和制度以适合敏捷开发。

因此应该在敏捷开发的语境下扩展那些周边的过程,以便为实施敏捷开发的大环境提供指导,以降低研发管理的总体成本。

其中一个有效的方法,就是建立以敏捷为指导思想的统一过程,以涵盖敏捷之外的组织结构与制度,并使之与敏捷开发相匹配。


 

下一篇文章,将会大致提出一个框架,对UP进行分析,并对AUP2潜在的要覆盖的范围进行描述。


文章名称:AUP2敏捷统一过程之一:序言及降低过程的总体拥有成本
分享网址:http://cdxtjz.cn/article/jippdp.html

其他资讯