论敏捷开发中的注意点

论敏捷开发中的注意点

摘要

本文是笔者项目开发经历的经验总结。笔者所在的公司根据自身开发实力和承接项目规模选择了敏捷开发思想来开发这个项目。在开发过程中，我们感受到了敏捷思想给我们带来的成果，也看到了敏捷思想在我们所处的实际情况下的需要本地化的地方。我们对这些地方做了研究，形成了一些理论并努力使之可移植到相似的开发环境中。

背景

我所在的公司从年初开始尝试用敏捷思想来开发特种设备的监察检验软件，从某市先开始试点，我参加了这个项目，做了系统分析、代码编写、系统测试的工作。

特种设备的生产检查与定期检验是国家规定强制执行的，近年来，国家技术质量监督局鼓励各地方技监局采用信息化手段改造业务，提高工作效率；另一方面，信息化业务便于数据的收集与管理，为特种设备的管理检验标准的制定和修改提供有利依据。

我们要做的一套系统，包括了某市锅炉检验单位的全部监察检验业务的信息化及该单位的日常管理软件的开发，有一部分软件是需要分派到下层单位中收集数据，然后该单位收集整理上报给上级单位，上级单位审批后发回来，再由该单位处理，另外一部分则需要让软件使用者通过互联网填写数据以简化重要性较弱的数据收集。单位内部要对所有员工有一个统一的软件界面，而相应的业务都是从这个界面启动，我们描述为总平台。总平台是B/S结构，采用Asp.net开发，而业务使用的软件由于涉及大量的数据业务，采用Delphi+SQLServer开发。

对于为了理清头绪，我们定义了三个等级的工作，依次为：项目、模块、功能点。模块被我们看成了可以独立执行的应用程序，一个项目被分成了如干个模块，每个模块又包含若干功能点，我们的主要工作即可定义为迭代开发功能点。这么做的原因是，一方面，我们所做的项目，已在有少量实施成功的案例，它们可以作为我们功能点设计的参考；另一方面，系统的行业特性较明显

注意点一：注意发布周期的选择

敏捷软件开发的一大特点就是周期性发布可运行的软件产品，这么做的初衷是为了更明确客户的需求，背后的原理是我们常说的"客户只有看到了你给他什么，才能知道自己需要什么"。而选择周期性发布是因为一方面要及时响应客户的需求，另一方面避免开发走弯路，减少错误带来的损失。但是在具体实施的时候，我们却遇到了实际的问题。我们的开发结果是以模块发布的形式，每次发布某个模块的某个状态。起先计划是三周发布一次。结果开始阶段的三周后我们的模块只有粗糙的启动、退出功能，后台数据库初步成形，模块框架已经搭建好。发布时，我们需要客户对上述构架作出评价并反馈给我们，以便我们修改。结果客户的反馈迟迟不到，因为实际的情况是，客户只看了一眼便退出来，因为里面什么功能都没有。当我尝试向客户们解说他们可以就这个软件随意谈谈看法时，他们的反应还不如我们以需求分析为目的时的谈话，其中一个还表示了对我们的失望。我们现在就面临这么一个问题：这次发布明显是失败的，它不仅没有达到预期的效果，甚至起到了反作用。那么我们究竟失败在哪里？我们重新审视了自己发布的产品，它可评价的地方还是很多的，比方说数据库的架构，极可能存在与将来的模块数据可以合并的地方（事实上这问题在后期出现了），那么我们必须在初期定义足够兼容的实体结构和关系，这一点我们所知甚少，而客户中却有同时使用多个模块的人物，他应该看得出来，而不必等到我们对模块分析得足够彻底后跳到项目级别来分析设计项目。但是我们的客户拒绝评价之，这就是最主要的问题：客户并不知道什么敏捷开发，什么极限编程，所以更别希望他们懂得什么是迭代，他们是以自己的或者说是传统的观点看待软件，而对于他们来说，软件就是一件商品。客户对商品的概念影响着他们对我们发布的模块的看法。在他们看来，商品就是花钱买了来就能用的，没有哪家商家会给你一个厂里的半成品，过段时间再给你一个半成品，前面的那个让你扔掉，如此反复几次，才算你买到了这个商品。当我们推测到此处时，我们着手验证这个推想。我们随即给客户送过去一个我们以往实施成功的案例，请他们就软件界面提一些自己的看法，当然在选送案例时我们考虑了一些因素，既要让客户得到可靠的信息有要客户没有多少额外的负担，同时也要保证公司业务的保密。我们的想法是针对客户的心理提出来的，因为是已成熟的公司的代表作，客户会放松地使用和评价，同时可以潜移默化中接受公司的软件风格。很快地，反馈回来了，客户提出了很多零散的要求，我们从中发现了对我们的模块有可应用的变更。这时已经过完第四周了。我们注意到如果第六周再发布新板本的模块的话，会重复我们第一次发布后的尴尬，所以我们改变了发布计划，准备在模块整体功能完成后发布，整个模块的开发花去了我们五个星期的时间。之后我们的模块发布，根据我们收到的反馈和模块的完成情况，我们估计下一次发布可以定在4周之后。随后，我们的模块发布稳定在了两周。

注意点二：你的客户也要注意更改要求

敏捷开发中最平静的应该是代码开发阶段，这个阶段产生的结果依赖于团队的技术水平。但是业界公认的是不管团队水平如何，客户总是会提出更改的，这一点大家习以为常。以我们团队为例，每次迭代发布后收到的更改要求都在五个以上。理论上来讲，反馈中的更改数量应该是开始阶段较多，而后慢慢减少的。但是目前这种情况却让我们感觉到我们的开发不够敏捷。于是我们花了点时间在用户的变更需求上，方法是整理用户需求：用一张二维的表格来划分需求，横轴是需求提出的时间，竖轴是需求所属的分类。分类是我们自己定的，事先并没有具体的定义，也就是说分类的完善是和用户的更改需求归类过程同步进行。我们发现用户的更改需求可以分为以下三类：一、个人习惯类要求；二、软件正确性要求；三、软件有效性要求。个人习惯即用户的操作习惯，如一条更改要求是“在界面上输入数据时，要能够通过Enter键跳到下一个输入框内”，此类更改发生得最频繁。我们甚至发现了改了又改回去的要求。第二类的更改需求通常由用户的误操作或故意破坏性输入引发的系统报错。第三类更改需求是我们的软件流程与他们的业务流程不相符的地方。不管我们处于开发的何种状态，第一类的更改需求总是居高不下，这使我们的软件开发十分尴尬：我们期望客户能够多提出二、三类的更改需求，但是客户显然没有理解我们的这一需求。我们决定管理一下客户的更改需求。以往，我们会选定一个更改要求收集人员，定期到客户处收集客户的更改需求，收集的方法是听用户的抱怨。而更改需求是专员随手记录的，回来我们再研究这些远古咒语般的更改需求。为改善这种方法,我们做了一张更改需求的描述单,每张单子对应一个更改需求,单子上需要填写更改的原因,目标的详细描述,另外这张单子必须由我方人员和客户方负责人同时签字才能产生效用.具体实施起来如下:问题收集者每次分发给客户足够数量的问题描述单,同时回收上次的问题描述单,对单子的内容确认后请客户方负责人审核签字,随后问题收集者签字.我们在下一次迭代中应用这些更改.这么做的好处是,用户的更改需求被提升到一个让用户引起重视的地位,用户在重视更改需求的情况下提出的更改要求是经过他们挑选过的，是整个系统中较为重要的部分，而一些次要的不必要的更改，则在客户内部被过滤。另外一个好处就是客户的更改需求提出方式宽松了，可以随时提出来更改需求。以往是在我方人员的监视下使用软件，有心理压力，以为我一定要试出毛病来，就算没有也不能浪费这个做上帝的机会，结果过分地追求细枝末节

第三点：注意保持开发节奏

敏捷开发中“敏捷”的含义中，有一个我们经历了开发过程才发现的意义，即开发节奏的保持。举个例子说，敏捷开发中禁止超时工作，即使有人自愿或热衷，这并不符合我们的观念。这么做不是单为了效率，还有另外一层含义：团队行动的节奏远远要比个体行动的节奏难以把握，而团队很难在变动的节奏下创造价值。如果把握团队节奏的难度非常大，我们宁愿将团队节奏定在一个稳定的小范围内。这一点是我们亲身经历的心得。事实上，每个团队的最合适的开发节奏都不一样，要靠团队领导者有意识地调节。而一旦找到了这个开发节奏，团队的软件过程即可预测，达到已管理级，这也是我们衡量团队开发节奏的条件。

第四点：节对编程的实施

整个开发过程，我们团队共处一室，讨论着开发细节，技术问题在平时开发中讨论解决，需求性问题在每天的固定时间向客户咨询，客户如果也无法明确需求，我们自作主张地开发出来。我们鼓励团队成员讨论，互相看代码。这和敏捷开发描述的结对编程有出入，我们觉得这种编程方式对国内的程序员来说普遍过于开放了（夫妻程序员可以例外）。结对编程是一种兼顾开发效率和开发质量的方法，但不唯一，我们在侧重效率兼顾质量的原则下采取单人编程团队辅助的方法理论上要比结对编程更有效率。这么做的后果有一点就是代码质量下降，让我们在后期的迭代中有一段时间举步维艰，幸好我们因此做出的代码重构工作扭转了局面，保证了开发质量和速度。

总结

以上是我在一个敏捷开发思想指导软件开发过程的项目中的总结，这些结论的得出都经过了问题的发现，解决方法的探讨、选择、优化这些环节。对我今后的工作有不可忽视的影响。