了解敏捷开发
在真正进行敏捷开发之前我们应该对敏捷开发有个基本的认识,了解一些敏捷开发的历史缘由,知道敏捷开发从何而来,为了解决什么问题,符合什么样的应用场景等等。
其实这些基本知识通过百度谷歌搜索即可了解更多,这里也不做过多描述。我们下面简单讲一讲一些模式对比和运用场景。
4种开发模式
1、瀑布式
在很早期的项目中,我们基本都是采用瀑布式开发方式完成项目。即需求敲定,原型设计,ui设计,开发,测试,交付上线这样的流程。每个环节必需等等上一个环节完成后才能进行下一个环节。项目从开始到结束一次性完成,并交付给需求方使用。
到目前为止还是有很多项目还是基于这种模式开发,甚至某些项目必需这样开发。
比如道路修建,需要先进行各种精密的测量,地形地质勘测,材料等一系列缺点后才会进行修建工作,而且是一次性完成并交付使用。
2、迭代式
在某些项目中,存在很大的不确定性,需求方需要根据各种反馈,然后不停的修改来适应市场。
团队会在接下来一段时间重复一个或多个功能研发,那么每一次修改都是对原因功能的优化提升,这样减少对对项目的不确定性。
3、增量式
有些项目无法等待全部完成才能使用,于是进行增量开发,即先完成一个或者一部分功能,交付给需求方,需求方先使用,项目团队继续开发下一个功能。每开发完一个功能就交付一次,多次交付,直到功能全部开发完成全部交付。
增量可以让需求方快速使用上部分功能,与瀑布式一次性交付相比,需求方更早的享受到了开发成果,更快的获得项目价值。
4、敏捷式
敏捷方法融合了迭代和增量,在一个项目中,进行增量计划开发,并随时接受反馈并优化原有功能。
这种模式很好的在这些不确定性的项目中运用,计划安排持续迭代,快速交付,而且又能接受反馈,实时优化当前功能。敏捷开发目前已经运用到越来越多的项目了。
试想一下,是不是我们曾经历过的部分项目的形式已经是这样了?
敏捷宣言
敏捷宣言有利于我们了解敏捷开发最初的初衷。
敏捷开发的四个价值
- 个体和互动高于流程和工具
- 工作的软件高于详尽的文档
- 客户合作高于合同谈判
- 响应变化高于遵循计划
敏捷开发的指导原则
- 通过早期和连续型的高价值工作交付满足“客户”。
- 大工作分成可以迅速完成的较小组成部分。
- 识别最好的工作是从自我组织的团队中出现的,
- 为积极员工提供他们需要的环境和支持,并相信他们可以完成工作。
- 创建可以改善可持续工作的流程。
- 维持完整工作的不变的步调。
- 欢迎改变的需求,即使是在项目后期。
- 在项目期间每天与项目团队和业务所有者开会。
- 在定期修正期,让团队反映如何能高效,然后进行相应地行为调整。
- 通过完成的工作量计量工作进度。
- 不断地追求完善。
- 利用调整获得竞争优势。
敏捷使用
大致上一般有两种对敏捷开发的使用方式。
一种使用是基本上完全按照敏捷开发思想进行项目研发。我们完全参照敏捷开发的流程,章程,标准化进行敏捷开发。这样使用的公司也是大有人在,他们的能力和资源、市场各方面都非常符合。
另外一种使用就是根据项目实际情况对敏捷思想作部分调整,以完全符合当前项目行为。我们大部分公司还是难以完全按照敏捷开发标准来,我们受限于各种各样的条件,于是根据公司自身情况进行调整,使用敏捷思想,达到开发好项目的目的。
小结
针对敏捷开发的价值和原则以先了解为可,千万不要断章取义。我经常遇到一些同学,对敏捷开发进行误解甚至曲解,最后和其他同事争的面红耳赤。
敏捷开发不是随便看点敏捷宣言就是敏捷开发,也不是说看两本书就可以工作中正常使用敏捷开发,我们需要去理解敏捷开发的初衷,如何让一个项目做的更好。如果能让项目做得更好,不使用敏捷开发又何妨。