敏捷开发方法在SaaS系统开发中的适用性研究

　　【摘要】敏捷开发方法为软件开发指处了一条快速适应需求的路。本文在介绍敏捷开发方法及其实现方式的基础上，对敏捷开发方法在SaaS系统开发中的适用性进行了分析。

　　【关键字】敏捷开发;SaaS

　　0引言

　　SaaS(SoftwareasaService，软件即服务)是云计算技术飞速发展的重要产物之一。相较于传统软件，SaaS产品一般是面向ToC市场。因此在开发初期，产品的最终用户很少参与到产品决策当中，开发团队只能通过预期分析明确用户需求，而这极大可能造成产品功能与实际需求之间存在偏差。此外用户还会不断地对产品提出新的期望，因此需要团队根据使用反馈，对产品功能进行持续的优化调整。由此可见SaaS产品需要具备高适应性，能够根据用户的反应快速调整产品功能架构。这也决定SaaS系统的开发，不会是单向的，而是一个需要不断经历从开发到使用再到调整的重复性过程。

　　传统软件开发模式虽简单易懂，但实操时其过程却较为繁杂。而且传统开发模式对过程中的各种文档都有着极其严格的要求，因此很大程度上降低了开发效率。2001年，由MartinFowler，JimHighsmith等17位软件开发专家起草的敏捷宣言发表，其核心是希望通过轻量型开发、测试驱动、快速迭代来提高系统适应性和灵活性。同时经过人们多年的实践总结，目前已发展出了多种敏捷实现方式。

　　本文将在介绍敏捷开发及各种实现敏捷开发方式的基础上，从SaaS项目的目标、团队和开发过程3个方面，讨论其适用性。

　　1.敏捷开发的特点

　　敏捷开发的核心包括4句开发宣言和12条开发原则。与传统开发方法相比，敏捷开发有以下主要特点：

　　(1)敏捷开发强调的是适应变化而不是一成不变。软件开发除了要应对诸多不可预见因素外，还要满足不断变化的期望，因此高适应性才更符合软件开发的实际。敏捷开发通过缩短交付周期、多次提交中间成果、增加各方交流来提高开发适应性。

　　(2)敏捷开发更注重人的作用。从激励团队成员到重视开发团队的自主性，敏捷开发希望团队中的每个个体都可以将其自身特点和创造力充分发挥，让项目更具有生命力

　　(3)敏捷开发更重视可用的产品而不是详尽的文档。传统开发模式极度依赖文档记录，并认为只有在文档中详细地记录、分析客户需求，才能降低后续开发工作可能遇到的风险，避免大范围的修改和重构。而敏捷开发认为保持轻量化迭代才更为重要，通过持续的集成、测试、调整，在保证软件可用的前提下，不断为现有系统增加新的功能，持续收集用户反馈意见，逐步对系统进行优化调整，才能成功完成项目、交付满意产品。

　　2敏捷开发的实现方式

　　从本质上看，敏捷开发只是一种简明扼要的概要准则，其并未明确在进行软件开发时需要具体应用何种方法、实施哪些步骤。但是经过多年的实践总结，人们已经提出了多种敏捷开发的实现方式。其中，最广为人知的当属Scrum框架、看板(Kanban)框架、极限编程(ExtremeProgramming)框架

　　2.1Scrum框架

　　在Scrum框架中，用户需求首先被收集、汇总，用以生成各种功能描述。然后各功能描述被分类、组合进而生成关联任务。非关联任务包括系统维护、技术升级等工作。各种任务汇聚在一起组成的列表构成产品待办清单。Scrum中的迭代周期称为冲刺(Sprint)，通常为2周到4周。每个Sprint周期会从产品待办清单中选取部分任务组成Sprint待办清单。Scrum团队通过每日例会、评审会议来对Sprint开发进度和产品质量进行把控。

　　Scrum建议每个项目都至少配有一个敏捷专家(Scrummaster)和一个产品负责人(Projectowner)。敏捷专家负责遵循敏捷框架，为项目团队提供指导和培训，消除阻碍团队进行工作的障碍和干扰。产品负责人负责明确项目利益相关者的期望，确定项目开发工具和技术，对迭代周期内的各种事项进行优先级排序。

　　2.2看板框架

　　看板框架的核心是将工作流程可视化。在看板框架中，复杂工作会被分解为一个个界限明确、难易适度的任务“卡片”，然后分配给相应团队或个人。通过可视化管理能够有效帮助人们识别项目的运转情况、降低沟通成本，也有助于整个团队发现任务“过剩”或“不足”的问题，及时调整任务计划。

　　2.3极限开发

　　总地来说，极限开发与Scrum框架非常类似，都是通过短周期迭代完成系统开发任务。不同的是，在极限开发中，迭代开发周期更短，通常为1到2周;极限开发允许对迭代周期内的待办事项进行调整，只要该事项还未开始;极限开发团队严格按照待办任务的优先级来完成开发工作，而不是随机挑选[1]。

　　此外，极限开发还提供诸如结对编程(pairprogramming)、测试驱动开发(test-drivendevelopment)、精简设计(simpledesign)等实操方法用以指导团队的开发工作。

　　3.敏捷开发在SaaS项目中的适用性分析

　　3.1从项目目标来看敏捷开发的适用性

　　如前文所述，SaaS产品在开发初期，最终客户很少会参与到项目决策当中，因此开发团队对客户的使用目标是通过预期分析得到的，这很可能造成产品功能与实际需要之间存在偏差。为减少偏差，开发团队会持续跟踪用户反馈，在推进开发工作的同时，不断对系统进行调整，完善整体功能架构。可以说，在SaaS系统开发过程中会面临诸多的不确定因素，因此系统是否具备高适应性便显得尤为重要。

　　适应变化是敏捷开发的重要特点之一。通过一次次的迭代开发，不断缩小产品与客户预期之间的差距。即便既定的目标发生重大改变，采用敏捷开发的产品也能很好的适应。

　　此外，敏捷开发规定每次迭代结束后，都需向用户提交最小可行产品(Minimumviableproduct,MVP)。MVP的关键在于，它不仅能向客户展示各种可行的解决方案、让客户直观体会到产品价值，而且通过不断完善的功能，在增强客户信心和期待的同时，能够让开发团队对客户需求有进一步的认识，为下一次的迭代开发做好准备。

　　3.2从项目团队看敏捷开发的适用性

　　在传统开发模式中，每个开发阶段都对应不同部门。从需求分析、架构设计到研发、测试、项目实施，每个步骤都需要部门之间相互配合、分工协作，由此便产生了纷繁复杂的项目文件、对接文档。一旦项目目标或者客户需求发生改变，项目进行变更、调整的成本极高，因此涉及的各方人员都会产生抵触情绪。

　　而敏捷开发团队结构是趋向扁平化的，职能的划分由此变得模糊。在项目中，产品经理要理解系统，研发要懂得设计，测试要熟悉客户，而全部成员都要理解产品的设计理念。通过及时的、面对面的交流，降低了沟通成本，使得整个团队可以更加专注于产品本身。通过激励团队成员，团队中的每个个体都可以将其自身特点和创造力充分发挥，从而让项目更具有生命力。

　　3.3从项目开发过程来看敏捷开发的适用性

　　3.3.1需求

　　在传统开发模式中，需求明确的过程由需求分析师(Businessanalyst，BA)负责进行。其他人员只能被动等待。

　　而在敏捷开发中，团队不必一次性明晰所有问题，以核心流程和核心业务为重点制定出迭代计划后，团队就可以启动首轮的开发工作。其他细节可以留待随后的开发过程中逐步填充进来。

　　3.3.2计划

　　在传统开发模式中，项目计划是以里程碑模式形成的，即在需求、开发、测试、上线、初验、终验等过程提交相应成果。任何一个过程的延迟，都会对后续阶段的工作产生重大影响。

　　而敏捷开发以增量迭代为目标，每个迭代周期结束时，提供对应的增量成果即可，这大大提高了项目的可执行性。

　　3.3.3测试

　　测试在传统开发模式中往往是最后一环，也是最为困难的一环。由于测试后置，一些异常处理、极限处理的问题在开发时极易被忽略。而这些隐患会对系统集成测试产生重大影响，进而导致部分功能进行重构。

　　而敏捷开发提倡测试先行。以极限编程为例，其要求团队开发人员，在系统需求分析阶段就开始编写代码级的测试用例，这样可以让开发人员积极参与到需求讨论和分析中来，从而深刻理解需求本质。

　　软件开发论文范例：关于计算机软件开发技术的相关探讨

　　4结束语

　　敏捷开发是一种全新的软件开发模式，其初衷是为了让开发过程能够适应快速变化的需求，使开发的系统具备更多的灵活性。这些都满足SaaS系统的开发需求。因此敏捷开发适用于SaaS系统开发。

　　参考文献

　　[1]Cohn,Mike.DifferencesBetweenScrumandExtremeProgramming.2007-4-6.

　　作者：顾超