敏捷开发过程中总结

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哪一种开发模式跟是否加班都没有必定联系。

时间: 2024-10-05 19:05:57

敏捷开发过程中总结的相关文章

测试人员在敏捷团队中扮演的角色

对于开发模式,现在大部分互联网公司都完成了从传统瀑布开发模式到敏捷开发模式的转型,这种转型相对传统的测试人员来说,不论是在角色定位还是在技能栈方面都提出了更大的挑战,那么测试人员应该如何应对呢?下面根据我平时工作的一些总结体会来说说测试人员应该发力的方向,供大家参考: 角色 1: 培训人员 在转型初期,测试人员应该针对开发人员的薄弱环节(即业务技能)进行培训和指导.由于工作任务的差别,开发人员对负责的模块业务和具体实现细节非常了解,但是对周边模块或者业务并不是非常清楚,主要体现在配置和使用方面.

软件工程(三)--敏捷开发过程

软件工程(三)----敏捷开发过程 1.敏捷不仅仅是项目团队对变化做出快速反应的能力. 2.消除项目规划和测试的使用对应用软件过程并不是必要的. 3.通过软件增量必须在短时间内交付和软件过程必须适应增量的变化创建敏捷过程来管理不可测性. 4.在敏捷软件过程中,最高优先级是通过早期和连续交付有价值的软件来满足客户. 5.在敏捷软件开发团队中,能力.决策能力和相互信任和尊重都是需要的. 6.在敏捷开发中,更重要的是构建满足客户需求的软件,而不是担心将来可能需要的特性. 7.计划.设计.编码.测试是极

软件开发过程中的审查 (Review)

http://blog.csdn.net/horkychen/article/details/5035769 软件开发过程中的审查 (Review) 希望别人做些什么->定义出流程 希望别人做出正确的结果->定义出审查制度 软件开发项目中包括很多的审查动作,贯穿于整个开发过程.个人认为审查主要有以下目的: 1.尽早排查出潜在的问题(Potential Risk/Issue) 经过其他人的参与,以不同的视角提出不同的看法,会有类似头脑风暴的效果,集思广议来查找工程师未能注意的问题. 2.保持良好

软件开发过程中如何避免争吵?

软件开发过程中,对一个问题有不同意见是很正常的,不同思想的碰撞可以带来进步,但是如果沟通不当,引发争吵,从而延误项目开发进度,就会得不偿失了. 要做到避免争吵,首先得自我反思,自己是不是哪里做得不对,问题没考虑清楚.问题还没明白就去和别人争,就是你的不对了. 其次,要站在别人的角度先想一想问题.是不是PM有难言之隐,公司的压力过大,不能采纳我的建议? 设计师看问题的角度是不是和我不一样?我的代码编写是否规范,有没有给复审测试人员带来麻烦?项目有没有充分考虑并达到用户的需求?在和别人争论前,必须充

net开发过程中Bin目录net开发过程中Bin目录下面几种文件

.net开发过程中Bin目录下面几种文件格式的解释 在.NET开发中,我们经常会在bin目录下面看到这些类型的文件: .pdb..xsd..vshost.exe..exe..exe.config..vshost.exe.config 项目发布的时候,往往搞不清楚哪些是需要的,那些是不需要的.那么这些格式的文件到底是干什么用的呢? pdb .pdb文件,是VS生成的用于调试的符号文件(program database),保存着调试的信息.在VS的工程属性,C/C++,调试信息格式,设置/Zi,那么

软件开发过程中要主要的问题

结合软件开发生命周期,软件开发过程中应注意的问题如下(个人愚见) 1)明确项目概况,即将项目定位,要结合需求和技术实现,对项目进行准确定位,制定合理的项目开发计划. 2)面对需求变化,需求变化是软件开发过程经常碰到的问题也是致命的问题,排除客户的问题,需求分析要做的足够好,需求分析做好后,最好要客户确认签字. 3)模块划分,把软件系统按照任务需求或者数据模型进行模块划分,提高系统开发进度. 4)编码规范,项目编写代码过程中要有详细的编码规范,如合理的程序文件结构(每个程序文件应由标题.内容.附加

node.js项目开发问题集锦(不定期更新,随时把开发过程中遇到的问题加上)

1.用express开发站点时,怎么定义通用的头部和尾部 方案1:用类似asp时代的include添加,如ejs模板: <% include ../header.ejs %> <h1 class="page-header"> 这里是内容. 注:..表示header.ejs在上一级目录,ejs扩展名可以去掉,直接写:include ../header </h1> <% include ../footer %> 方案2:用类似于MVC的lay

【项目管理】敏捷组织中PMO应遵循的准则

敏捷改变了人们的工作方式,不仅仅是开发部门,而且还包括其它的部门,例如HR.财务以及PMO等.在大多数组织中,PMO是一个控制体.它指导项目团队的规范.模板以及流程.目前,大多数的IT组织都敏捷化了. Nick Oostvogels,SkyCoach公司的项目经理及敏捷教练,最近发表了敏捷组织中PMO的新角色的文章.Nick说,组织敏捷带来了一些影响,例如业务单元有偏差.项目组合规划不满足敏捷的步调,以及项目管理办公室不知道如何支持敏捷团队. 一个经典的PMO突然必须处理敏捷项目时都会表现相同的

敏捷测试中发现的一些问题及改进办法

最近产品出现了几个不大不小的问题,时间点却偏偏是在距离产品发布不到一个月!!在解决完问题后,不禁要思考一下:到底哪里出了问题? 下面是对最近出现的问题的反思和一些改进办法: 问题 1:遗漏重要需求 敏捷团队中需求的获取有很多种方式,大体的来源分为: a. 最终客户(需求和反馈) b. 行业标准 c. 竞争产品 d. 团队贡献和创新 e. 其他 我们遇到的问题是有一部分客户对域里的用户权限限制很高,不是我们常用的有域管理员权限,这是我们没有考虑到也从来没接触过的的使用方式,以至于产品根本无法在一些