2019-07-14 15:33:51 qq_29924227 阅读数 97
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10423 人正在学习 去看看 CSDN讲师

什么是敏捷开发?

敏捷开发=迭代开发+增量开发
迭代开发:将一个大项目分解成多个小项目,每个小项目都有类似的生命周期。开发者首先发布一个简单的版本,然后再不断的增加功能或者进行改进,这个过程就是不断迭代的过程,每次迭代都有完整的生命周期(包括需求分析、设计、编码、测试、部署评估)。
增量开发:迭代开发只是将一个大项目分成多个小项目来完成,但是没有规定如何划分项目进行迭代。这时,就要按照增量开发的方式进行迭代,迭代的每个版本都会增加一个用户可以感知的完整功能,就是按照功能进行划分迭代。

敏捷开发的优点

  1. 及时交付:敏捷开发完成第一个版本就可以先进行交付,而不需要等到完成所有功能再进行交付
  2. 反应迅速,拥抱变化:当前市场需求变化很快,当需求发生变化的时候,敏捷开发可以及时的做出相应,进行改变。
  3. 80/20原则:根据增量开发,可以先完成具有80%价值的20%的功能。

什么是瀑布模式?

一种由需求文档驱动的开发模式,开发人员严格按照文档进行开发,瀑布开发模式分为几个阶段:
在这里插入图片描述

瀑布模式的缺点

  1. 需求隔离:每个开发人员只能接触到自己负责的阶段,对用户需求理解不高,开发人员像流水线上的工人。
  2. 变更代价大:正如这个开发模式的名字:瀑布 一样,如果开发过程中需求变更,代价极大。
  3. 束缚创造力:由于强调文档驱动,限制了开发人员的创造力
  4. 周期漫长
2016-11-03 17:37:57 buding_pmp 阅读数 4087
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10423 人正在学习 去看看 CSDN讲师

[摘要]  
敏捷开发越来越火热,但在实际应用当中很多时候都是只有敏捷的“形”,却缺少敏捷的“神”,还只是在摸索中。敏捷开发对产品经理/程序员的要求都是很高的,此外还需要各个业务部门对敏捷的理解和支持,形成合力。以下分享产品项目里的九个敏捷开发实战经验。

  敏捷开发越来越火热,但在实际应用当中很多时候都是只有敏捷的“形”,却缺少敏捷的“神”,还只是在摸索中。
  在《Scrum:兼顾计划与灵活的敏捷开发》一文中,作者最后也提到过,借鉴一种新的模式的时候,最好能够批判性的吸收其精华的部分,不能全部照搬,照搬了反而会出问题。
  其实敏捷对产品经理的要求是很高的,需要安排至少两个迭代的任务,两个迭代的规划。
  对程序员的要求也很高,当所有的任务都拆散了之后,最终做出来的东西要形成一个产品,技术人员的整体意识要比较强,且一开始就得熟知产品的整个规划,否则到最后就会出现所有任务都已完结,合并出来的最终产物却是什么都不是。
  并且敏捷开发不仅仅是IT部门的事情,还需要各个业务部门对敏捷的理解和支持,形成合力,从而提升开发效率和业务满意度。
  运行一段时间的敏捷之后,发现最容易接受敏捷这种方式的是开发团队,不管是瀑布式还是敏捷,只是做工作的形式不一样了,进度更容易把握了,更能适应需求的变化了,实质其实并没有变化。
  对测试团队来讲,测试资源调配会更加的紧张,敏捷要求做完一条侧一条,与原先的整体项目排期完全不一样;对产品经理来说,敏捷能让自身更好的掌握整个产品的进度。
  但需求分析与产品设计阶段的敏捷拆分还是较为头疼的,究竟要不要写文档了,是不是有什么做什么,还是说要规划完整体设计之后才进行拆分?疑问很多,搜集了部分资料,结合敏捷实践的经验,分享如下:
  一、敏捷开发最少需要维护哪些文档?
  软件或者系统产品终归是人来维护的,业务知识和技能的传递就成为产品可持续发展的一个重要因素,这就需要有知识性的沉淀,需要有文档的产出。
  实际情况是大多数人都不喜欢编写文档、也不太喜欢研读文档,因此太多的文档只会消耗团队有限的时间,并不能带来多大的好处;敏捷开发照样重视文档的作用,也重视文档的维护。
  但文档宜少且精炼,一般情况下建议维护三份文档:
  《产品需求规格说明书》
  也即PRD:定义产品应该具有的功能、边界描述等,它作为产品团队之间共同的讨论基础,并在设计和开发过程中不断的更新维护,并记录所有的需求变更;
  《系统设计说明书》
  开发人员编写的技术设计,包含数据库E-R图,架构设计等:说明产品如何实现,内部之间是什么关系;
  《测试用例和测试报告》
  由测试人员编写:记录所有功能点的测试计划、过程和测试结果;
  二、敏捷开发是否需要系统设计?
  前面也提到过,敏捷开发对开发人员来讲实质差异不大,只是以小周期代替大周期。
  小周期包括:需求、设计、开发、测试、发布,这个过程中的设计环节是指要做产品设计和系统设计;由于做完整的设计需要有相对完整的资料和比较长的时间,与小周期是相对立的。
  因此敏捷开发不主张高度细化和完整的设计,提倡做出一个大粒度的框架性设计,一般指架构设计或者系统设计,避免在以后的重构中发生架构级别的变化,然后在逐步实现的过程中逐渐深入展开、细化。
  传统的一些设计方法比如结构化设计、快速原型法都是可以融入敏捷开发过程中加以使用的。
  三、敏捷开发是否需要项目计划?
  敏捷开发只是把整体拆分成许多个体,产品的开发实现过程对产品的功能完整性、稳定性、即时性等都有较高的要求。
  它是一种有组织有目标的行为,往往我们都将其作为一个项目来管理,这就是讨论为什么有产品经理的同时还要有项目经理,为什么要求产品经理要有项目管理的能力,因此它需要项目计划。
  但这个计划是一个短程计划,根据未实现的功能情况、前一个版本的反馈和组织目标制定开发计划;唯有这样才能不断的融入新的需求变更;
  四、敏捷开发的迭代周期大概多长?
  敏捷开发的迭代周期没有硬性的规定,结合项目里程碑、目标、功能实现情况、产品稳定性综合决定,如果产品用户活跃、功能实现难度小、维护复杂度低,建议以周为周期。
产品项目里的九个敏捷开发实战经验
  对于规模比较大、维护复杂度高的产品,考虑以2周-6周为周期发布较为合适;频繁的发布会降低用户的期望并提高用户成本,给用户心理上带来额外的负担:他会认为产品质量低,质量控制不严谨等;
  五、敏捷开发为何提倡小版本?小版本有哪些优势?
  小版本的目的就是分解复杂度、降低风险,改善团队士气等;小版本有众多优势:
  1、总体风险比较少:小版本变化小,总是在上一个版本基础上局部调整和增加,技术复杂度低;由于规划的功能较少,工作量也易于估算,所以其总体风险比较少,常常能如期发布;
  2、需求的接纳能力强:由于小版本快速实现并发布测试,然后就进入下一个版本的规划实现周期,这样新需求一旦提出就能快速进入开发视野,就能尽快实现;
  3、测试和开发高效协作:开发和测试可以并行工作,当开发实现第一个版本时,测试设计测试方案和用例;发布第一个版本后,开发就进入下一个版本轮次,测试就应用测试方案测试刚才发布的版本,提交Bug;开发在下一个版本结束时修正所有上一轮发现的Bug,然后发布新版本,如此循环往复,开发和测试实现高效协作;
  六、敏捷开发与重构的关系如何?
  敏捷开发以重构为基础,时时刻刻处于重构过程中;
  七、敏捷开发为何强调团队人员的参与、用户的参与?
  敏捷强调团队成员的高度参与就是要统一认识,把团队的目标变成每个人的工作目标,使之为每个团队成员的认同,形成高度的凝聚力,以达到群策群力、高效协作的效果。
  由于没有高度细化的文档,成员之间交换信息的唯一渠道就是面对面沟通,良好的团队氛围和协作关系促进这种沟通,并使消息有效传达。
产品项目里的九个敏捷开发实战经验
  用户由于缺乏专业训练,无法清晰、准确的表达其意图,导致需求的歧义和模糊;用户的参与使模糊、边界不确定的需求在互动的过程中得到确认和完善;在用户参与过程中,我们常常可以听到这样的话:
  “是的,就是这样的”
  “这正是我想要的……”
  “这里需要修改一下……”
  “我的想法是这样的……”
  这个过程中,用户承担了一部分测试人员的角色。我们努力做的事情就是实现用户需要的东西,并最终让用户喜欢它,唯有用户喜欢它才能用好它,那么我们怎能不认真听取用户的意见呢?一句话总结就是:用户参与帮助我们做正确的事情!
  八、怎么才能评估团队是否已经敏捷了?
  由于敏捷开发没有标准的可供参考的实践过程,所以很难通过某个过程而断定其开发过程敏捷了,那么如何来评估团队是敏捷的呢?一般采用的办法是根据团队呈现出来的氛围、项目运作状态、团队成员的感性认识等方面来评估团队和其开发过程是否敏捷,常见评估项目团队是否已经敏捷的方法如下:
  • 团队有共同的愿景,并且对这个愿景充满信心;
  • 团队有明确的阶段目标并且为每个成员所知晓;
  • 团队知晓当前计划:做什么、何时完成、预期效果等;
  • 团队任务是低耦合的,并且紧密协作;
  发布过程是轻松愉快的,构建版本并不断测试是常态行为之一。
  九、敏捷开发能缩短项目时间并提高质量吗?
  从我的实践经验来看是可以的,但目前无法提供量化的数据做参考,只能从几个方面评估和推断:
  • 用户的参与帮助团队把功能一次性完成并做正确,缩减了返工的时间;
  • 不断的重构和测试发布能把问题发现在早期,整体质量显著提高;
  • 过程目标导向,使团队高度集中于项目目标,提高了生产力;
  • 不断的发布对团队是种正向激励,荣誉感和成功欲使团队保持持续的激情;
  以上是一些敏捷开发过程当中的疑问,其实还有很多,目前我这边还只是主推让开发和测试团队敏捷,PD团队还在摸索当中。下次我会分享一下如何在需求这个层面用敏捷的方式来设计,去产出PRD文档。敏捷设计、敏捷开发、敏捷测试连在一起,这样才能最大限度的发挥敏捷的效用

2013-11-01 09:36:49 jk050802 阅读数 2125
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10423 人正在学习 去看看 CSDN讲师

敏捷开发的简单歌诀,这也概括了敏捷开发的全部内容

迭代开发,价值优先

分解任务,真实进度


站立会议,交通畅通

用户参与,调整方向


结对编程,代码质量

测试驱动,安全可靠


持续集成,尽早反馈

自动部署,一键安装


定期回顾,持续改进

不断学习,提高能力

以上这个歌诀,1,2段表明敏捷开发的开发总模式;3,4段表明敏捷开发的项目管理;5,6段表明敏捷开发的编码方式;7,8段表明敏捷开发的反馈方法;9,10段表明敏捷开发中,如何协作和提升自己能力。


敏捷宣言

敏捷开发是一种把一人为本、团队合作、快速响应变化和可工作的软件作为宗旨的开发方法。


敏捷的精神

只关注真正重要的事情,少关注那些占用大量时间而无甚裨益的不重要的事情它强调团队合作,人们专注于具体可行的目标实现真正可工作的软件)。它打破那种基于计划的瀑布式软件开发方法,将软件开发的实际重点转移到一种更加自然和可持续的开发方式上。

它要求团队中的每一个人(包括与团队合作的人)都具备职业精神,并积极地期望项目能获得成功。它并不要求所有人都是有经验的专业人员,但必须具有专业的工作态度——每个人都希望尽最大可能做好自己的工作。


敏捷的核心——持续前进

事实上,只要有人继续使用这个软件,开发就没有结束。我们进行的是持续开发、持续反馈。这种持续前进的方法根植于敏捷方法。它不但应用于软件开发的生命周期,还应用于技术技能的学习、需求采集、产品部署、用户培训等方面。


敏捷软件开发概括

敏捷开发就是在一个高度协作的环境中,不断地使用反馈进行自我调整和完善

1.它要整个团队一起努力。敏捷团队往往是一个小型团队(10个人以内),团队的所有成员在一起工作,如果可能,最好有独立在一起的工作空间,一起共享代码和必要的开发任务,而且大部分时间都能在一起工作。同时和客户或者软件的用户紧密工作在一起,尽可能早且频繁给他们演示最新的系统。

2.不断从自己写的代码中得到反馈,并且使用自动化工具不断地构建(持续集成)和测试系统。在前进过程中,你都会有意识地修改一些代码:在功能不变的情况下,重新设计部分代码,改善代码的质量。这就是重构,它是软件开发中不可或缺的部分,因为编码永远没有一天是真正意义上的“结束”。

3.以迭代的方式进行工作:确定一小块时间(一周左右)的计划,然后按时完成它们。给客户演示每个迭代的工作效果,及时得到他们的反馈(这样可以保证方向正确),并且根据实际情况尽可能频繁地发布系统版本让用户使用。


2019-12-23 14:49:30 CODING_devops 阅读数 9
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10423 人正在学习 去看看 CSDN讲师

CODING 敏捷项目管理全新版本现已上线,新版本深度结合敏捷开发理念,完美支持 Scrum 迭代式增量开发过程,可根据团队需要设计独一无二的工作流,适应不同规模团队的敏捷开发实践。

为团队打造标准的 Scrum 敏捷工作流

迭代规划: 将用户故事、分解的事项分配至不同的迭代计划,规划每一个迭代的起始时间、责任人、状态,多迭代并行,迭代计划一目了然。

在这里插入图片描述

需求分解: 从大用户故事点到具体产品需求、任务,再分解到细颗粒度的子任务,在这里,每一个成员都能保持对工作目标、业务逻辑的高度理解。

在这里插入图片描述

多样化视图管理: 自定义筛选器、便捷的看板视图,帮助团队管理者全局把控各个迭代事项进度,预测项目计划风险,提前规划资源调配。项目进程尽在掌握之中!

在这里插入图片描述

资源代码关联: 发起需求、缺陷,可能需要必要的背景说明来定位或反馈问题,这时你可以在事项里引用必要的文件、其他相关的事项、甚至代码提交记录。

在这里插入图片描述

专属工作台: 自定义筛选器、便捷的看板视图,帮助团队管理者全局把控各个迭代事项进度,预测项目计划风险,提前规划资源调配。项目进程尽在掌握之中!

在这里插入图片描述

灵活的管理特性,助力团队轻松敏捷化

  • 支持多种事项类型
    史诗、需求、任务、缺陷多种事项类型分别管理,可全部或选择性应用

  • 定制化事务属性
    为您的团队打造独有的事务属性,适配团队协同的多样化场景。

  • 自定义工作流
    无论是实践 Scrum 还是瀑布流工作方式,都可以灵活定义工作的流转状态满足不同团队个性化需求。

  • 高级事项筛选器
    可以定义团队专用或个人定义筛选器,对不同的事项进行搜索展示。

  • 准确估算故事点
    团队可用故事点或小时数的方式来估算投入的资源,更准确的做资源调配。

  • 可量化的进度展示
    每个迭代及时展示进度条,准确汇报计划的完成情况。

无限提高团队的研发效率

CODING 提供一站式软件研发协作管理,深度集成代码管理、测试管理、构建与部署、制品库以及 API 文档管理等功能,搭配敏捷开发管理,实现高度自动化的开发流水线,帮助研发团队一站式实现 DevOps 研发工作流。

点击立即体验全新 CODING 敏捷项目管理

2015-10-12 10:32:44 junli_chen 阅读数 6767
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10423 人正在学习 去看看 CSDN讲师
敏捷开发的核心思想主要是迭代式开发,将整个项目分解为数个短期的迭代周期,快速相应需求进行增量开发。
结合我们公司的开发经验来看,我个人觉得敏捷开发主要包括几个步骤:
需求制定——》需求分析——》设计编码——》测试、功能验证——》发布版本——》下一个周期

1、需求制定:需求方根据上一个版本,提出的新开发需求或调整等。
2、需求分析:开发及测试人员,与需求方讨论并分析新需求,并验证需求的可行性。
3、涉及编码:根据确认后的需求,设计实现方式并进行编码。
4、测试、功能验证:对软件稳定性进行各种测试,并由配合需求方进行功能验证。
5、发布版本:将这个版本发布给需求方。
6、下一个周期:重复1到5步骤。

实际开发中不可能情况非常顺利,一般都会有新的需求或修改在开发过程中被发现或提出,
这时候并非不能调整原有的开发计划,可以视具体情况而定决定是否加入开发计划中,
如果涉及到大规模的改动则一般需要作为下一个版本的开发任务。

由于敏捷开发是使用增量式的开发,开发周期短响应快,一般不会出现致命的缺陷,整个开发过程较为流畅。


Agile——敏捷开发,作为CMM神话崩溃后被引入的一套新的软件开发模式,这几年来被广泛引起关注,并被寄予厚望。敏捷开发在其他业界的应用是否理想不得而知,但以下总结了我所在公司的敏捷开发试验,希望可以达到管中窥豹的目的。

敏捷开发宣言——
个体和交互 胜过 过程和工具
可以工作的软件 胜过 面面俱到的文档
客户合作 胜过 合同谈判
响应变化 胜过 遵循计划
虽然右项也有价值,但是我们认为左项具有更大的价值。

以上的宣言比较抽象,基于该理念,以下是ThoughtsWork咨询公司的推崇的n个敏捷开发实践:
Iteration
迭代开发。可以工作的软件胜过面面俱到的文档。因此,敏捷开发提倡将一个完整的软件版本划分为多个迭代,每个迭代实现不同的特性。重大的、优先级高的特性优先实现,风险高的特性优先实现。在项目的早期就将软件的原型开发出来,并基于这个原型在后续的迭代不断晚上。迭代开发的好处是:尽早编码,尽早暴露项目的技术风险。尽早使客户见到可运行的软件,并提出优化意见。可以分阶段提早向不同的客户交付可用的版本。
IterationPlanningMeeting
迭代计划会议。每个迭代启动时,召集整个开发团队,召开迭代计划会议,所有的团队成员畅所欲言,明确迭代的开发任务,解答疑惑。
Story Card/Story Wall/Feature List
在每个迭代中,架构师负责将所有的特性分解成多个Story Card。每个Story可以视为一个独立的特性。每个Story应该可以在最多1个星期内完成开发,交付提前测试(Pre-Test)。当一个迭代中的所有Story开发完毕以后,测试组再进行完整的测试。在整个测试过程中(pre-test,test),基于Daily build,测试组永远都是每天从配置库上取下最新编译的版本进行测试,开发人员也随时修改测试人员提交的问题单,并合入配置库。
敏捷开发的一个特点是开放式办公,充分沟通,包括测试人员也和开发人员一起办公。基于Story Card的开发方式,团队会在开放式办公区域放置一块白板,上面粘贴着所有的Story Card,按当前的开发状态贴在4个区域中,分别是:未开发,开发中,预测试中,测试中。Story Card的开发人员和测试人员根据开发进度在Story Wall上移动Story Card,更新Story Card的状态。这种方式可以对项目开发进度有一个非常直观的了解。
在开发人员开始开发一个Story时,ta需要找来对应的测试人员讲解Story功能,以便测试人员有一致的理解,同时开始自动化系统测试脚本的开发。
Standup Meeting
站立会议。每天早上,所有的团队成员围在Story Wall周围,开一个高效率的会议,通常不超过15分钟,汇报开发进展,提出问题,但不浪费所有人的时间立刻解决问题,而是会后个别沟通解决。
Pair Programming
结对编程是指两个开发人员结对编码。结对编程的好处是:经过两个人讨论后编写的代码比一个人独立完成会更加的完善,一些大的方向不至于出现偏差,一些细节也可以被充分考虑到。一个有经验的开发人员和一个新手结对编程,可以促进新手的成长,保证软件开发的质量。
CI/Daily Build
持续集成和每日构建能力是否足够强大是迭代开发是否成功的一个重要基础。基于每日构建。开发人员每天将编写/修改的代码及时的更新到配置库中,自动化编译程序每天至少一次自动从配置库上取下代码,执行自动化代码静态检查(如PCLint),单元测试,编译版本,安装,系统测试,动态检查(如Purify)。以上这些自动化任务执行完毕后,会输出报告,自动发送邮件给团队成员。如果其中存在着任何的问题,相关责任人应该及时的修改。
可以看到,整个开发组频繁的更新代码,出现一些问题不可避免。通过测试部又在不停地基于最新的代码进行测试。新增的问题是否能够被及时发现并消灭掉,取决于自动化单元测试和系统测试能力是否足够强大,特别是自动化系统测试能力。如果自动化测试只能验证最简单的操作,则新合入代码的隐患将很难被发现,并遗留到项目后期,形成大的风险。而实际上,提升自动化测试的覆盖率是最困难的。
Retrospect
总结和反思。每个迭代结束以后,项目组成员召开总结会议,总结好的实践和教训,并落实到后续的开发中。
ShowCase
演示。每个Story开发完成以后,开发人员叫上测试人员,演示软件功能,以便测试人员充分理解软件功能。
Refactoring
重构。因为迭代开发模式在项目早期就开发出可运行的软件原型,一开始开发出来的代码和架构不可能是最优的、面面俱到的,因此在后续的Story开发中,需要对代码和架构进行持续的重构。迭代开发对架构师要求很高。因为架构师要将一个完整的版本拆分成多个迭代,每个跌倒由拆分成很多Story,从架构的角度看,这些Story必须在是有很强的继承性,是可以不断叠加的,不至于后续开发的Story完全推翻了早期开发的代码和架构,同时也不可避免的需要对代码进行不断完善,不断重构。
TDD
测试驱动开发。正如上面讲的,迭代开发的特点是频繁合入代码,频繁发布版本。测试驱动开发是保证合入代码正常运行且不会在后期被破坏的重要手段。这里的测试主要指单元测试。


敏捷方法反思:
自己参与的敏捷开发项目总的来说不是很成功,这可能也是业界遇到的通病:
1、对于全新的软件,在项目早期测试人员就参与并实现自动化测试脚本,但实际上软件的界面等非常不稳定,导致测试人员返工的工作量很大。
2、对于全新的软件,资料人员过早参与,后期返工工作量大,原因同第一点。
3、自动化系统测试工作量大,测试人员投入大量的精力在使测试自动化起来,而没有足够的精力放在真正的测试软件的功能是否正常。即便是这样,自动化系统测试脚本也多流于形式,测不出深层次的问题。
4、代码动态检查工具执行不理想,流于形式。没有人对Purify有深刻的理解和应用经验,报告中查出来很多告警,但不知如何消除。
5、由于快速搭建原型,没有在架构上进行严谨的设计,导致后期一直堆砌代码。
6、异地开发模式下无法实现快速构建、快速交付,团队普遍感觉很疲惫。
7、敏捷开发不提倡加班,但实际上不管是CMM还是Agile哪一种开发模式跟是否加班都没有必然联系。

敏捷开发

阅读数 317

敏捷开发简介

阅读数 19

没有更多推荐了,返回首页