敏捷开发过程中如何开发高质量的软件.docx

敏捷开发过程中如何开发高质量的软件.docx

《敏捷开发过程中如何开发高质量的软件.docx》由会员分享，可在线阅读，更多相关《敏捷开发过程中如何开发高质量的软件.docx（13页珍藏版）》请在冰点文库上搜索。

敏捷开发过程中如何开发高质量的软件

前言

什么是软件质量？

很多技术同仁都认为软件质量是软件是否存在Bug，是否性能高，安全性好等等。

其实软件质量的含义远多与此。

质量就是软件产品对于某个（或某些）人的价值；价值是指创造利润，又或是降低成本。

总的来说，软件质量是软件的灵魂和存在意义。

另外，我们知道现在敏捷开发日趋流行，其实敏捷开发也是顺应市场的对价值的诉求和日益复杂的业务而产生的方法论，敏捷开发是追求高质量软件的方法论和过程。

本文将和大家一起探讨软件质量的含义，以及敏捷开发中如何进行高质量软件的开发。

软件质量的理解

首先，我们先来看看什么是软件产品质量？

先有了软件质量定性的了解，才能介绍如何影响、控制和改进质量。

大师温伯格在《质量·软件·管理系统思维》说到：

“质量就是软件产品对于某个（或某些）人的价值”（某个或某些人文章中统称之为用户），这里面包含两个层次的质量含义，即“正确的软件”及“软件运行正确”：

1.“正确的软件”是说，一个软件要能够满足用户的需求，为用户创造价值。

此处的价值可以体现在两个方面，即为用户创造利润或者减少成本。

如果一个软件能够满足需求的用户群体越大、创造的利润越大或减少的成本越大，则该软件产品的质量越高。

反之，一个产品尽管运行良好，没有Bug，扩展性很强，性能很好，但如果没有服务的用户人群，没有为用户创造价值，则这样的软件尽管运行良好，也无任何质量可言。

2.“软件运行正确”是说软件没有或很少Bug，扩展性很强，性能良好，易用性高等。

这样的软件是一个运行良好的软件，但还不能称之为高质量的软件。

只有在软件符合用户的需求的基础上，运行良好的软件，才是一个高质量的软件。

当然，如果软件完全符合用户需求，但不易使用，经常出错，性能很差，这样的软件也不是一个高质量的软件。

“正确的软件”及“软件运行正确”二者相辅相成，前者关系到软件的成败，后者关系到软件的好坏。

在现实的很多开发团队中，特别是偏技术的开发团队中，往往过分注重后者（软件的Bug率，性能，可扩展性，架构等），经常陷入在软件开发过程的细节之中，而忽略了前者（软件需要符合用户的需求），开发出的软件经常能用但无用，不是最终用户期望的软件，这样的软件是能用但无用零质量软件。

在产品开发中，能用但无用的现象尤为明显。

产品和项目不一样，项目往往是为某个客户而开展，有特定的需求来源，而产品往往是一个更广泛的概念，是市场上某一类客户群体的价值代表，没有固定的需求来源，而且良好的产品往往要起到引导客户需求的作用，超越现有客户能提出的需求，所以对产品来说，“正确的软件”更加困难，但也更加重要。

当然，“软件运行正确”同样非常重要，关系到软件的好坏。

Bug，扩展性，性能，易用性等问题会造成客户想用但用不了，同样造成软件质量问题。

敏捷开发对软件质量的影响

敏捷开发对软件过程和质量控制产生了一系列的影响，主要来自两个方面的影响，用下图表示如下：

图1.敏捷过程带来的影响

图中的具体含义如下：

1.敏捷开发对“正确的软件”的影响

敏捷开发拥抱市场变化，拥抱客户需求变化，采用迭代反馈的方式管理项目。

其背后的一个核心理念是：

一个高质量的软件，首先应该是一个“正确的软件”，能够满足客户的需求。

我们知道当今的世界产品极大丰富，不管任何产品都会有的竞争对手和替代产品，大家熟知的有浏览器大战，输入法血拼，视频网站、博客满天飞，国内外ERP系统竞争激烈等。

所以，软件的质量是要在市场化的竞争激烈的环境中去进行验证，进行优胜劣汰，最终高质量的软件产品被客户接受。

所以，一个高质量的软件首先应该是一个“正确的软件”，能在激烈的市场和竞争对手中找到市场定位，有客户需求和市场销量，能提高产品的使用者客户体验的软件。

否则，软件做的再好、性能再快、界面再优美好用也不是一个高质量的产品。

敏捷开发正是符合这样市场环境而诞生并流行，其迭代反馈、拥抱变化的理念和方法，能够使得团队更能开发出符合市场和客户的高质量软件。

如上图1中所示，左图中的大半圆表示传统的开发模式中，产品不能满足客户需求的风险。

因为传统的开发模式基于中央控制的计划，没有足够的迭代和反馈理念和方法，犹如一次性的把所有的资金购买了一只股票，导致质量风险大。

上图1中右边的敏捷开发中，采取迭代反馈的原理，通过一系列的方法（下面会介绍）把市场和客户的需求和期望分散到个整个软件的生命周期中，犹如把所有资金进行资产组合，最后的软件产品质量风险小，能够较大概率的符合市场和客户的需求，并带来价值。

敏捷开发响应市场和客户价值取向，但如果没有完善的方法去收集和分析市场和客户的反馈，也会导致严重的质量问题，如软件随波逐流，随客户朝夕更改；市场定位模糊，没有核心竞争力；和竞争对手没有任何区别，陷入艰难的红海战争中等。

所以，敏捷开发方法对高质量软件也提出了挑战，需要相应的方法和流程去执行和控制。

1.敏捷开发对“软件运行正确”的影响

“软件运行正确”是说软件运行良好，没有或很少Bug，扩展性很强，性能良好，易用性高等。

软件工程中有个经典的统计，即软件生命周期的前期造成的Bug的影响比后期大的多，所以需求的变动影响是最大的。

而敏捷开发拥抱市场变化的理念，会积极响应市场需求，这会对整个软件，如软件架构、编码、测试、文档都会造成很大影响。

犹如长鞭效应，长鞭前端的抖动会逐渐放大到整条长鞭，而且波动会越来越大。

这会影响“软件运行正确”的高质量要求。

所以，我们不仅要看到敏捷开发带来的高质量客户价值的好处，如上图1右边敏捷开发的上部分波动所示，还要看到这些小波动导致的长鞭效应。

如上图1右边下半部分所示。

敏捷开发拥抱市场变化和客户反馈会对整个软件的架构、开发、测试造成很大的波动。

如果控制不好，会使得项目失控，造成严重的质量问题，如错误Bug多，架构不合理，易用性不好，性能不好等等。

总的来说，敏捷开发的理念和方法，响应市场和客户的价值，有利于发布符合客户价值的软件。

下面介绍敏捷开发过程及质量控制最佳实践，能很好的解决敏捷开发中的软件质量问题，辅助团队发布高质量的软件。

敏捷开发过程及质量控制最佳实践

敏捷开发的需要敏捷过程的支持才能快速响应市场需求，发布高质量的软件产品。

下图是作者用过的敏捷过程（可以定制适合自己项目的敏捷过程），文章不详细介绍下面敏捷开发过程，主要介绍其中的质量控制流程及最佳实践，也是围绕质量的两个方面介绍质量控制实践：

“正确的软件”及“软件运行正确”两方面。

下图2中是一个软件敏捷开发的迭代过程，每个迭代有需求，有变化，有架构，有设计，有开发，文档等。

其中深蓝色背景，白色字体的是敏捷过程中质量控制流程。

主要包括两个方面的质量控制：

“正确的软件”及“软件运行正确”两方面。

下面依次介绍：

图2.敏捷开发过程及质量控制

“正确的软件”的质量控制流程和最佳实践

这个作者认为是敏捷开发中质量控制中最重要的一点，因为这是后面所有其他软件质量的前提。

如果软件刚开始就是错误的，不能给客户带来价值的，就犹如路和方向就是错误的，那尽管在这条路上走的多好，多稳，也不会通向理想的目的地–高质量的软件。

做正确的事情，说起来简单，但做起来是最为困难和艰险的一件事情。

犹如上文说到的长鞭效应，在这里一步走错，就会导致整个软件的极大波动，导致项目失败。

因为产品定位和价值都错了，那再如何努力开发和测试也是不可能交付高质量的软件。

敏捷开发强调拥抱变化，迭代开发，客户反馈原则等也无非是使得软件在正确的方向上前进。

下面作者敏捷开发过程中经常使用的几种最佳实践，能够辅助团队正确捕获市场需求和客户反馈，并进行需求分析及过滤，设计出能给客户带来价值的高质量软件。

包括上图中的“需求”、“SWOT分析和需求审核”和“CDD&UserStory审核”。

1.需求

需求又包括需求获取和反馈，需求分析和需求创造三个方面

演示和原型

在软件敏捷开发过程中，如何获取市场的需求和客户的反馈是高质量软件的前提。

敏捷开发中，除了正式的软件开发及发布，我们还有专门的团队开发演示和原型。

演示是为了向客户和业务人员展示产品功能，并获取客户反馈；原型是为了展示对产品未来的雏形和概念，便于与客户讨论和展示，并获取市场需求。

产品、原型和演示三者的关系如图所示：

图3.敏捷开发过程中的软件、原型和演示

Persona的方法论

Persona指的是角色，也就是基于角色的方法论，强调一切从角色出发思考问题。

我们知道，每个人的思考的角度都不一样，客户的思考问题的角度和开发团队的思考角度不一样，甚至不同客户之间思考问题的角度也不一样。

团队在设计和开发软件的时候，容易陷入自己的思维角度，开发不符合客户思维角度的软件，而不符合客户的需求。

更严重的是很多团队陷入这样的惯性，而根本不知道错误在哪里。

Persona的方法论中强调，不论软件的哪些需求，哪个功能模块，甚至会议中的讨论，请首先确认出Persona。

Persona可能不止一个，所以需要分析并确认出不同的Persona，并设定所有Persona的背景，需求，期望等。

然后把讨论的需求、功能模块、会议的议题，对应到定义的Persona中。

然后根据Persona的重要与否，Persona的背景等，就可以进一步分析、确认需求。

下面是一个Persona的简单模板

Persona的简单模板：

∙Name

∙Photo

∙BriefBiography

∙Goals

∙Contextscenario

确认出Person，尤其是关键客户的Persona，然后尽量使软件符合该Persona的价值需求。

作者的经验中，Persona的方法论，非常有益于理清思路，特别是在需求分析和讨论阶段尤为重要。

需求收集和讨论时，不同的同事代表不同的Persona（有的是客户业务人员，有的是客户架构师，有的是客户技术人员）他们提出各种不同的假设、需求、改进、功能模块。

这时如果不从Persona的角度去思考和理清问题，就经常陷入混乱和口水大战。

而最终却没有满足项目或产品的最重要Persona的需求，不能创造价值。

可想而之，以此为基准的软件将是能用但无用的零质量产品。

最高境界“跟随需求，不如创造需求”

这点对软件产品来说尤为重要，前面说过产品和项目不一样，产品的需求更加模糊，而且一些新产品往往需要带有一定的新特性。

产品需求的最高境界是创造概念、规则，并由此创造需求。

不管是软件行业，还是其它商业界都是如此，如：

a.从BP机到手机，再到iPhone；

b.从胶片相机到数码相机；

c.从门户广告到搜索广告；

d.从Blog到Twitter等

商业界创造概念、规则、模式，并由此创造需求，才能创造出蓝海，并成为领头羊。

而其他跟随着只能符合创造者的提出来需求。

在这个境界上，创新是最至关重要的因素，唯有创新才能打破规则，打破需求跟随者的状态，创造出符合未来用户需求的规则和产品。

而这样的软件，也是最有价值的高质量软件。

1.SWOT分析和需求审核

敏捷开发中通过需求收集及客户反馈得到了大量的客户需求，如何进行有效的过滤并选出最有价值的需求呢？

这是敏捷开发中高质量软件的关键之一，因为没有一个很好的以客户和市场为中心分析方法，产品会随客户朝夕更改，市场定位模糊，散失稳定的核心竞争力。

开发团队常见的误差是从技术的角度来考虑哪一些需求价值大，哪一些需求紧急度高，造成的结果是有一些功能模块投入了很多资源，但却并不一定是客户最想要的。

在作者的敏捷开发中，对产品的需求和模块进行SWOT分析，分析的输入是所有的Persona客户需求、市场现状、产业现状、竞争对手现状等，输出是需求的重要度和紧急度，以及投入的成本。

然后按照性价比可以进行排序，选出最能符合市场的模块。

SWOT分析有益于以最少的投入研发出符合客户和市场价值高质量的软件。

下面是一个SWOT分析的事例：

图4.SWOT分析事例

1.CDD以及UserStoryReview

CDD（ConceptDesignDocument）指的是软件的概念设计文档，UserStory指的是用例细化的用例故事。

这二者发生在进一步细化需求并要转换成软件架构时，对这二者进行进一步的分析和审核，有益于保证从需求分析到架构设计的过度阶段的软件质量，降低客户需求理解偏差的概率。

“软件运行正确”的质量控制流程和最佳实践

敏捷开发的拥抱变化，如上面的图1中所示，会对软件架构、编码、测试、文档都会造成很大影响，犹如长鞭效应，长鞭前端的抖动会逐渐放大到整条长鞭，而且波动越来越大。

在敏捷开发中，为了快速响应变化，敏捷开发中的如下特性：

a.需求变化更频繁

b.轻详细设计，没有那么多的架构和设计的时间

c.反对冗余繁重的文档

d.反对冗长会议和电话会议

e.赞同代码就是最好设计和文档（Codeisdesignanddocument），并通过重构自然呈现架构和设计

这些特性和传统的进行大量的架构设计，然后通过文档记录并沟通的方式有很大差别。

敏捷开发中这样灵活的方式就更要求有严格的质量控制流程。

否则，最终的产品的质量很大概率出现问题。

如可扩展性、架构、可用性、测试稳定性Bug等。

下面是敏捷开发流程中控制架构、开发、测试等质量的流程：

1.架构和概要设计Review

敏捷中轻详细设计，但并非不注重设计，只是敏捷中架构的形式和内容发生了变化。

敏捷中进行的架构设计是高层次的架构设计，如：

组件的结构，软件的层次，技术选型等。

敏捷中没有进一步的详细设计。

架构设计就显得尤为重要，架构层次的错误，在后期需要大量的人力物力来弥补。

架构和概要设计审核主要围绕下面几点：

a.组件结构是否清晰。

围绕组件的特性：

“高内聚”、“松耦合”、“隔离性”、“颗粒度”、“分层”等特点，设计良好的组件结构。

组件的抽取过程，可以在公司组织结构部门设立中找到似曾相似的影子。

在公司组织结构中，任何事情重复或重要到了一定程度，就会产生一个新的部门，如做销售的人多了，就产生了销售部门，不同省的销售多了，就产生了省分部门。

在架构设计中也是一样，任何功能重复的到了一定程度，就应该抽象出新的组件，甚至一个产品。

在设计好组件结构后，就可以分工进行开发。

b.层次结构是否清晰。

关系是否混乱？

是否需要抽取单独的层次？

c.是否符合Donotrepeatyourself的规则。

好的架构设计应该是“不重复自己”，并且“不重复已有的成熟组件”。

尤其是当架构中有些功能有免费成熟开源框架或者标准可以依据，但架构设计时没有采用考虑，而重新发明轮子，导致不能重用已有的标准或开源框架的优势，这些都是不可取的。

d.技术选型是否合理。

包括数据，模型，展现，逻辑等技术选型，以及使用框架，依赖产品等。

1.代码审核，以及重构出设计

传统的架构设计，包括架构和设计两个方面、其中设计可以包含详细设计，如详细的UML图（详细的类图，顺序图等），详细的API设计以及接口描述，存储层数据库表字段设计等等。

敏捷开发中不进行详细设计然后再开发，它推崇Codeisdesign，设计是通过对代码进行重构自然产生。

所以，敏捷开发中，代码质量和可读性很重要。

是否能通过高质量的编码，以及重构，自然呈现出软件设计，关系软件可维护性，Bug出错率和修改、可扩展性、稳定性、甚至性能等质量问题。

所以，在敏捷开发中并非没有详细设计，而是详细设计的方式和时机发生了变化：

敏捷开发详细设计转移到了开发阶段，也即是：

Codeisdesign。

这样既能拥抱变化，又规避风险，又Don’tRepeatYourself。

敏捷中代码审核的质量规格应该类似与详细设计的规格，要求开发人员能够发布高质量的代码及代码结构。

团队可以设立统一的编码规范，命名规范，代码结构规范。

确保代码和代码结构的质量。

团队也可以选用一些自动化的代码扫描工具来分析代码结构及存在的不合规范的地方。

开发规范是能提高代码质量，好的代码，结构清晰，读起来毫不费力，是一种享受。

好的代码包括如下特性：

a.高质量代码结构在于开发人员不断重构，把代码按照逻辑结构分成不同的包。

b.高质量的代码格式一般可以通过工具中的编辑器的代码模板和格式器来控制。

c.高质量注释即是代码的注释，又是软件的设计文档。

d.这里强调一点是高质量的命名，不管是包命名，类命名还是变量命名，命名时应该采用能够让人看懂的名字，名字长一些往往更好，尽量少用不清晰的缩写。

如：

People对象，应该用people等能够一目了然的命名，而不是p,pe等简短不清晰的命名。

1.测试流程

在讲测试之前，我们重新回顾一下：

什么是“高质量”的软件产品？

只有统一了“高质量”的概念，测试人员才有测试的标准和最后交付软件的标准。

“高质量”的软件，可以认为是：

能为客户在最少时间内，带来最大价值的软件。

测试人员在测试软件的时候，应该在思想层次和终端用户统一“高质量”软件的认识，并且所有的测试标准也将围绕这个“高质量”的衡量标准进行，否则测试结果为高质量的产品，对客户来说可能就未必是这样。

所以测试团队在软件测试的过程中，要时刻站在客户的角度思考问题，设计测试用例，以及测试产品。

敏捷开发中的测试包括功能测试、集成测试、性能测试、安全测试、可消费性测试和无障碍测试等，这些确保能够按照设计发布高质量的软件。

这里不细讲每一个测试的环节。

需要强调的是可消费性测试。

一个高质量的软件，不仅要能够按照既定的设计良好运行，还应该是一个很好用的软件。

只有客户能够方便的使用软件，软件才能为客户创造价值，也才能称该软件为一个高质量的软件。

大家都很熟悉的Windows和Linux操作系统，从普通终端用户的角度上考虑，无疑Windows是更高质量的产品，因为它能为客户在投入最少时间的情况下，创造最大化的价值。

而Linux我称之为技术层面的高质量产品，对普通终端用户来说，其综合价值不如Windows。

可消费性测试涵盖了整个软件生命周期，将在另外的文章中详细介绍。

下面的可消费性测试中易用性测试几个常用的原则，它能够帮助测试人员测试软件的容易使用程度。

a.效率–用户要花多少时间，多少个步骤才能完成一个任务。

比如注册用户，查找一篇文档。

b.准确–在操作的执行过程中，用户犯了多少错？

测试人员要时刻记住，用户在使用产品中犯错，是设计人员的错，而不是用户的错。

c.无需记忆性–用户第一次使用是否能容易的使用产品？

或者用户多长时间不用后，还能记得如何操作产品？

好的产品设计是无需用户记忆，一切使用规则是隐含在设计中。

d.情感反映–用户完成任务后的感觉是什么？

是放松，还是紧张，该用户是否会推荐产品给用户。

用户使用产品，就犹如和设计师对话，好的设计师处处为用户考虑，用户使用完产品后会很放松甚至兴奋，会迫不及待的推荐产品给其他用户。

1.测试计划及用例Review

上面讲到，测试团队在软件测试的过程中，要时刻站在客户的角度思考问题，设计测试用例。

测试计划及用例审核Review，其目的就是为了检验测试用例的结构，计划，及每个测试用例的测试点，确保一切从客户出发。

审核过程中，应该有业务人员，架构师介入，甚至客户介入。

1.文档Review

文档是软件的一部分，而且文档能够辅助用户使用软件的，也需要严格的质量控制。

文档的目的是让人学会使用产品，所以高质量的文档，不仅是一个没有错误的文档，还需要能够快速的帮助用户学会使用软件。

下面是高质量文档书写的几点最佳实践：

a.能用视频少用图片，能用图片少用字。

现在用Flash视频教学是非常好流行的一种教学方式，尽量多用一些Flash视频的教学方式，如果没有视频，也尽量多一些图片，产品截图等。

b.多一些例子，比如Struts框架提供了showcase等一系列例子，教导用户如何开发和使用技巧，这些比纯文字的文档形象直接，效果更是不可同日而语。

c.文档中尽量少用缩写，除非是人尽皆知的缩写，如IBM,EJB等词语。

如果需要使用缩写，需要在一些地方标记出全名。

敏捷开发质量控制工具

如上面几个小节介绍的，敏捷开发中的质量控制贯穿整个软件生命周期。

包括需求，架构，设计，测试，文档等的质量控制。

工具支持上，也涵盖了整个生命周期的质量控制，从早期的需求管理工具，到各个阶段的测试工具，到代码检测及重构工具等。

由于篇幅关系，在下一篇文章系统介绍整个质量控制过程的工具支持。