敏捷开发在项目开发和管理中的实践和应用

上一篇 / 下一篇  2022-02-28 11:10:56 / 个人分类:测试

摘要 敏捷开发已深入互联网产品的研发和团队管理过程,当前互联网+时代要求软件研发企业在面对市场需求是要能够做到快速响应,传统的瀑布开发模式已经不能满足互联网企业一系列的需求。敏捷开发提倡拥抱变化、高效沟通、持续交付、紧密协作,强调团队的自组织,本文根据实际应用情景,谈一谈在敏捷开发过程中,通过简化工作流,提升团队协作和沟通,来提高项目管理的效率,降低成本、实现产品的快速交付。

关键词 敏捷开发;信息系统;项目管理;软件开发

敏捷开发(Agile Development)是一种以人为核心、迭代、循序渐进的开发方式,目前主要有Scrum、XP和看板模式。敏捷采用的是迭代式开发,主要驱动核心是人。目前许多敏捷开发在实际应用还处于摸索阶段,只注重“形”,为不注重“神”,通过多个敏捷项目的实践,在采用一种新的模式的时候,最好结合实际进行本地化的适配。

1 敏捷项目的需求确认与任务分解

敏捷项目是欢迎用户需求变化的,项目开始阶段不需要完整的需求,但也要能准确获取客户的需求,系统原型设计是使用最普遍的方法。给客户演示原型并不断修改原型直至客户确认,可以有效地与用户针对系统的功能与可用性进行验证,节省开发前研发资源的投入,确保构建系统的正确性,开发初期原型设计的开支远低于开发实际系统的开支。常用的原型设计工具: Axure RP、Microsoft Visio、网页制作工具。

在管理用户需求时,产品负责人(Product Owner,简称PO)要将需求整理成用户故事,用户故事通过product-backlog(产品backlog)进行记录。在每个迭代开始之初,由团队负责人(Scrum Master,简称SM)召开sprint计划会议,PO负责需求的讲解,开发团队通过需求的理解,一起进行用户故事的估算。在计划会议中需要确认需求优先级、分析和评估产品Backlog,确定迭代的目标,分解工作内容,形成迭代任务(Sprint backlog),然后为本次迭代任务做估算;团队成员从产品Backlog中挑选他们承诺完成的用户故事。

2 敏捷项目的系统分析与设计

敏捷开发可以根据项目的规模对设计工作进行取舍,一般在项目开始阶段先引入一个sprint0,进行系统的分析和设计工作,敏捷开发不提倡刚开始就进行完整的系统设计,主张先做出一个大粒度的框架性设计,然后在迭代开发中逐步深入细化,当然传统的一些设计方法也可以融入敏捷开发过程。

2.1 整体架构和逻辑架构设计

对于大中型规模的项目的研发以及升级,为了让团队了解项目的整体架构,需要进行系统整体架构设计,逻辑架构设计可以放入各个迭代中进行;对于小型项目的研发,如果不涉及整体架构的调整,可以不做逻辑架构设计,设计工作尽量让有经验的人员承担,并且设计后进行评审。

2.2 开发架构设计

开发架构设计是必需的,设计由技术经理或者团队中经验丰富的工程师承担,设计完后组织团队或者专家进行评审。在每个sprint中进行开发架构设计,可以参考逻辑架构,将逻辑架构中的逻辑层映射到开发架构中的多个程序包,将逻辑架构中的一个或多个类包含在开发架构中的源码文件中。

2.3 详细设计

无论项目规模大小,对系统涉及的接口及关键功能模块要进行详细设计,详细设计加入到迭代中进行,并且设计完成后进行评审。

2.4 UI设计

对于大中型项目的研发,先进行UI设计,待UI设计完成后让客户进行评审,交付开发团队依照UI进行系统功能开发。

3 敏捷项目的迭代开发

3.1 发布周期

在进行项目研发阶段,对于规模比较大、维护复杂度高的产品,一般考虑10天为一个迭代发布周期,小型的项目可以采用7天为一个迭代发布周期。

3.2 敏捷会议

在固定的发布周期内,需要加强团队的沟通力,敏捷开发有四种会议,分别是计划会,每日站会,回顾会,评审会,在敏捷开发模式中,每种会议都有其特殊的职责和使命,不同的会议上所讨论的内容是不一致的,需要把握住会议的关键点为团队的敏捷服务。

计划会:为了提高需求讲解和任务估算的效率,发布计划会和Sprint计划会可以合在一起进行,分阶段进行发布迭代。

每日站会:把握站会时间,会议控制在15-30分钟解决问题,避免迟到,延时或坐着开会。

回顾会:回顾会不拘泥具体形式,主要是为了要解决敏捷开发过程暴露出的一些问题,问题可大可小,团队需要找到问题发生的原因,在下个sprint中至少解决1个,解决的问题最多不要超过3个。

评审会:评审不限制于会议,可以在功能开发完成后以各种方式及时和PO验证,在验证后再进行自测和交叉测试,及时纠偏;有可能的话要求最终用户参与测试流程,并得到用户对系统的认可,鼓励用户自己进行测试设计和进行破坏性测试,充分暴露系统的设计和功能问题。

3.3 质量内建与测试

敏捷开发强调产品的测试和质量是由整个敏捷团队负责的,在保证项目交付的进度和质量之前,首先团队需要定义出期望的质量标准和验收细则,以明确而且达成共识的验收测试计划。

质量内建:敏捷软件开发强调质量内建,在整个迭代开发过程中,接口以及关键功能模块要有单元测试,开发过程中团队成员进行不断做自测,功能模块开发完成后在团队内进行交叉测试和冒烟测试,其中单元测试、自测可以合到开发任务里,任务工作量包含单元测试、自测。

每个迭代測试产生的缺陷要及时记录到缺陷记录表中,并实时跟踪缺陷的状态直至缺陷关闭。团队要养成每日代码评审的习惯,每个迭代结束后由SM组织团队进行集体代码评审,评审后的问题记录到代码评审问题列表中。

集成测试:大型项目在测试阶段首先团队内至少先执行一次集成测试,然后提交放行测试组进行放行测试。

4 结束语

敏捷开发不仅仅是开发者的事情,还需要各个业务人员、售前、售后对敏捷的理解和支持,形成合力,从而提升开发效率和业务满意度。为了高质量地完成项目工作,在执行 Scrum 中的每一步的同时,需要团队通过每个迭代的执行不断地进行学习和总结,进行适合团队的调整和优化,使团队真正的敏捷起来。


TAG:

 

评分:0

我来说两句

Open Toolbar