【《敏捷软件开发方法概述》2800字】

敏捷软件开发方法概述1.1敏捷开发说起敏捷，就必须要说起一本经典，那就是《人月神话》，它在二十世纪七十年代发表，提出了“NoSilverBullet”的观点[18]。竹内弘高等人提出使用Scrum的暗喻来软件开发过程[19]；几年后萨瑟兰和Schwaber发布文章向世人隆重介绍了敏捷方法下的最优实践Scrum方法[20]。紧接着，MartinFowler，KentBeck，WardCunmingham[21]成功的把极限编程方法应用于他们当时的项目，这也是极限编程第一次成功应用。1997年，阿里斯达·科克伯恩提出水晶方法[22]；一年后，杰夫·德卢卡发表特性驱动开发方法[23]，把特性作为最小的开发单元，实现早期的敏捷开发。2000年马丁·福勒提出了ContinuousIntegration[24]，这就是后来耳熟能详的持续集成方法。2001年敏捷联盟成立，自此“敏捷”一词正式频繁出现在项目管理领域。并被越来越多的学着关注到，他们对敏捷进行的深入的研究。譬如这期间出现的精益帆布模型（LeanCanvasModel）[25]，适用于敏捷团队的办公模型[26]，以及适合小微团队使用的轻量级软件过程改进策略[27]。为应对竞争而诞生的敏捷[28]，充分发挥化整为零的策略，它专注于在开发过程中，如何将一个项目的工作，划分拆解为更多的小模块，把每个模块分解到不能在分解，以便估算成本和工期，同时，对模块进行分析，根据相关性，把那些集成到一起可以运行的若干模块，集中到一个版本进行迭代。这样，就可以把一个大项目，划分成若干小系统，每个系统之间有彼此独立，完全可以同步开发。鉴于此，有人发表了敏捷项目管理的方法[29]，进一步丰富了项目管理理论。2001年，一组软件和项目专家聚集在一起讨论他们项目的成功之处。该小组创建敏捷宣言，一份对成功的软件开发所需价值的声明[30]。同年“敏捷宣言”形成规范[31]，大力的促进了敏捷的统一性。NomiBaruah(2015)认为运用敏捷方法论可以有效的支持和管理客户的变更需求，并且在项目的任何时间点都能够倾听客户的需求，同时保证这些需求信息的完整性，最终完成有效的变更[32]。因此与传统方法相比，敏捷具有明显的的优势，灵活且较少的非生产性工作、便于快速交付的策略、有利于提高团队绩效的模型、更严格的项目管理和控制以及更快的检测[33]。1.2敏捷实践敏捷是一种理念，具体如何去实践，就需要借鉴前人的智慧，根据众多学者们的研究和实践家们的实践，普遍认为Scrum和极限编程是敏捷较为成功的两种最佳实践。本文选择Scrum作研究对象之一，接下来就介绍Scrum是如何进行敏捷开发的。Scrum，顾名思义，橄榄球，同时也代表橄榄球运动的意义，团队成员之间相互追赶，一起提升。在实际的操作中，Scrum构建下的团队通常包括产品所有者，敏捷教练和开发成员们。产品所有者也是产品负责人，对产品的端到端进行全面负责。敏捷教练，在最初的意思是充当流程管理员的角色，通常是为了拉通各成员的交流，推动项目进展的角色。开发成员们就是开发团队，开发团队通常很少。他们具体的职责如表1-1所示：表1-1Scrum角色责任角色责任产品责任人明确产品功能和产品标准，确认产品的最终交付时间，和交付的状态，同时也可以评判团队成员最后提交的产品是否符合要求敏捷教练负责敏捷流程的执行，拉通各角色沟通开发团队负责产品的开发工作，人数控制在7人左右，每个成员各司其职，负责不同方向Scrum的团队相当于是一个特种作战队，里面的每个成员都需要有不同的能力和技能，组合在一起，形成一个有战斗力的团队。快速响应需求，快速行动，快速变更及出结果。同时团队有充分的自组织能力，团队自行决定以怎样的方式完成工作，具备其他组织不具备的灵活性和自主性，同时又能充分发挥每个人的主管能动性。产品负责人，作为项目的第一负责人，他决定这产品的最终的样子。他对待开发的需求事项，进行分析和设定优先级，每个开发周期，根据迭代要求，选择适合的需求，转交给开发团队进行开发。从市场角度来看，产品负责人需要对产品的商业价值负责。ScrumMaster负责确保团队中的所有人都能正确的理解并执行Scrum方法，他是团队中的服务型领导。相对于传统的项目经理角色，ScrumMaster的首要任务并不是对项目和团队进行管理，并确保达成商业目标，而是一个教练和引导者。由于ProductOwner对商业利益负责，ScrumMaster只是协助ProductOwner辅导团队，确保项目遵循Scrum的流程和规范，使Scrum方法能发挥出最大效力。Scrum团队是自组织的，即在如何实现产品待开发列表的功能这个问题上，除了团队自身没有人能质疑已有的决定。因为Scrum认为每个人的分工不同，且在自己的领域都是经验丰富的人员，所以一旦成员作出某种决定，默认该决定是正确决定，即使是敏捷教练，甚至是产品经理，都无法左右开发团队的选择何种方式进行开发。而产品经理只要最后确认收到的交付物是符合满足他要求的即可。Scrum之所以能成功，并如此受欢迎，还在于它的循环迭代的方式，因为任何人都无法在项目开始之前，就知道最后的产品是什么样子的。所以没有办法在最开始做出详细的需求说明，只有按照Scrum的思路，不断迭代、不断优化、持续交付、增量交付的方式进行，才能不断修正，以达到最初的目的。Scrum的开发流程如图1-3所示：图1-3Scrum开发流程图从上图可知，源于市场、客户和高层的需求，通常是从创意、缺陷或者功能上提出的。由产品负责人进行统一汇总，形成产品功能列表，别通过分析设定优先级。在计划会议上，开发团队确定迭代周期，每次迭代通常在2周左右，最多不超过1个月。然后从产品功能列表中，按优先级顺序，提取需求到本次的迭代中进行开发。开发过程中，开发团队通过每日站会进行自我管理和进度推进，并在迭代周期结束时，提交可工作的软件到评审会议进行评审。每次评审结束，开发团队需要召开一次反思会议，用于复盘和团队的自我成长。1.3敏捷特性敏捷开发的特点，和其他开发方式不太一样，总的来说有以下几点：第一，轻量型。敏捷的轻量型，源于它的团队架构，和简单的迭代循环。只要设定好优先级，开发团队选择迭代版本的开发任务后，就可以按照自己的性格习惯进行开发工作，只需要提交可用的交付版本即可。产品负责人只需要把需求分解设定优先级后放入待开发列表，以及最后接受开发团队的交付成果即可。第二，拥抱变化。变化是传统开发模式下开发人员最不愿意面对的。敏捷由于是迭代开发，由若干循环组成，每次的变更，都可以通过需求池和设定的优先级，而归入不同的迭代周期，将变更是为需求，即可解决心理上的抗拒问题。同时，又倡导沟通，每次沟通后的变更，其实从某种意义上也是对产品的优化。这也能说明敏捷交付物的质量为什么好的原因了。第三，持续迭代，增量交付。敏捷并不按照一下子开发所有的功能，测试后交付完整的产品。反而，是乐于循序渐进式的提供交付物，且每次的交付物都是可用的，可解决客户实际需求的产品。每次迭代都是基于上次迭代后的改进或者优化后者升级，是产品趋向于越来越完善的方向努力。