敏捷软件开发学习笔记(一)之敏捷开发基础概念

敏捷开发

敏捷联盟

一批业界专家(拥有大量的实践经验)聚集在一起概括出了一些可以让软件开发团队具有快速工作、响应变化能力的价值观和原则,称为敏捷联盟。他们创造出了一份说明,也就是敏捷联盟宣言。

敏捷联盟宣言

我们正在通过亲身实践以及帮助他人实践,揭示更好的软件开发方法。通过这项工作我们认为:

  • 个体和交互 胜过 过程和工具
  • 可以工作的软件 胜过 面面俱到的文档
  • 客户合作 胜过 合同谈判
  • 相应变化 胜过 遵循计划

虽然右边也有价值,但是我们认为左项具有更大的价值。

个体和交互胜过过程和工具

团队的构建比环境的构建更重要。

可以工作的软件胜过面面俱到的文档

直到迫切需要并且意义重大的时候,才来编写文档。

极限编程

极限编程(XP)是敏捷方法中最重要的一个,他有一系列简单却相互依赖的实践组成。

客户作为团队成员

这样可以更好地了解彼此所面临的问题,并共同去解决这些问题。

用户素材

必须要对用户的需求很了解,这样才能更好的设计与估算项目。

短周期交付

XP项目每两周交付一次可以工作的软件。

  • 每次迭代通常耗时两周
  • 可以创建一次计划来规划随后的6次迭代,也就是所谓的发布计划。

验收测试

可以以客户指定的验收测试的形式来了解需求的细节。

结对编程

两个人一起编程。(说实话,这种形式还没有见过)

测试驱动开发

单元测试试一种验证行为,更是一种设计行为。同样,他也是一种编写文档的行为。编写单元测试避免了相当数量的反馈循环,尤其是功能验证方面的反馈循环。

测试驱动的开发方法(TDD)
  1. 单元测试(单元是用来验证系统中个别机制的白盒测试)

    单元测试的流程如下:

    • 新建测试
    • 运行所有的测试,发现新增的测试无法通过
    • 做一下小小的改动使测试通过,甚至可以采用一些不合理的代码。
    • 运行所有的测试并通过
    • 重构代码

    单元测试的好处:

    • 测试使得模块之间隔离。在编写代码之前先编写测试会暴露出程序中应该被解耦的区域
    • 单元测试相当于可执行的文档
  2. 验收测试(验收测试时用来验证系统满足客户需求的黑盒测试)

    正如单元测试作为可编译、运行的有关系统内部结构的文档那样,验收测试时有关系统特性的可编译、执行的文档。

集体所有权

不是按照模块来划分的,每个人都有权利去改进任何模块。每个成员都肯定有自己擅长和不擅长的地方,可以做自己擅长的事情,可以去请教其他擅长的成员他们擅长的项目。

持续集成

程序员每天会多次对代码进行修改。

可持续开发速度

不加班(O(∩_∩)O哈哈~)

开放的工作空间

这样可以更好的讨论交流问题

计划游戏

计划的本质是划分业务人员和开发人员之间的职责。

初始探索

在项目开始的时候,开发费人员和客户会尽量确定出所有真正重要的用户素材。随着项目的进展,客户会不断编写新的用户素材,素材的编写会一直持续到项目完成。
开发人员共同对这些素材进行估算。估算是相对的不是绝对的,可以将大的素材进行分解,小的素材进行合并。可以定义一个计量标准,如半天实现一个素材,然后将每个素材进行标点。随着项目的进行,估算会越来越准确。

发布计划

知道了素材的速度以后,客户就可以定义素材的优先级别,然后选择那些会带来最大收益的素材。开发与客户对项目的首次发布时间达成一致,通常为2~4周。

迭代计划

可发和客户选定迭代规模,通常为两周。迭代期间用户素材的实现顺序取决于开发人员。一旦开始迭代,客户就不能改变该迭代期间需要实现的素材。就算没有完成所有的素材,迭代也要在指定的日期结束。然后结合已开发完素材的速度来重新规划开发速度。这样的反馈有助于保持计划于团队事假状况相同步。

任务计划

在新的迭代开始时,客户和开发人员共同指定计划。开发人员将素材分解成开发任务,一个任务就是一个开发人员能够在4~16小时之内实现的一些功能。然后开发人员认领开发任务,并估算任务所需要的点数。

不断迭代即可

每次迭代完成,给客户演示当前的程序,客户对程序进行评价并提出反馈

结论

通过一次次的迭代,项目进入了一种可预测的,舒适的开发环境。每个人都知道将要做什么,以及何时去做。当然并不是所有的项目都适合用XP进行开发。

简单的设计

XP团队的设计尽可能的简单而且富有变现力。即一开始不会设计的很复杂,知道迫切而且必须使用复杂方案的时候再使用复杂的解决方案。以下有三条XP指导原则可以对开发人员进行指导

  • 考虑能够工作最简单的事情。如能用文件就不用数据库
  • 只有在有十分明显的迹象表明使用复杂方案更加划算的时候再使用
  • 消除重复的代码

重构

要经常性的对代码进行重构。
每个软件模块都具有三项职责:

  • 运行起来所完成的功能
  • 要应对变化
  • 要和阅读他的人进行沟通

怎么样才能让软件模块易于阅读,易于修改呢?使用软件开发的原则和模式可以帮助我们创建更加灵活和具有适应性的软件模块。然而,要使得软件模块易于阅读和修改,所需哟啊的不仅仅是一些原则和模块,还需要你的注意力,需要纪律约束,需要创造美的激情。(代码的编写要自己满意才行,当然这一切的前提都是在能完成任务的情况下)

隐喻

隐喻通常可以归结为一个名字系统。这些名字提供了一个系统组成元素的词汇表,并且有助于定义他们之间的关系

结论

极限编程是一组简单的具体的实践,这些实践组合在一起形成了一个敏捷软件开发过程

猜你喜欢

转载自www.cnblogs.com/qiye5757/p/9613816.html