1.前言

最近公司的一些项目迭代越来越快，从产品产生到发布的时间越来越短，因此我们开始尝试敏捷开发并取得了一点的效果。

在此记录一些敏捷开发的心得。（由于公司比较大，为了说服那些领导，介绍敏捷开发也花了很多时间，如果有相同烦恼的同学可以交流一下意见）

2.概要

敏捷开发是一种以人为核心，迭代，循序渐进的开发方法。而瀑布流强调了开发应有完整的一个周期。

用两张图比较一些瀑布流开发和敏捷开发的特

(瀑布流开发，即V字开发)

瀑布流在每一个设计开发阶段，都会对应一个测试阶段最大程度把整项目的完整行。

但是这个模式要求有完整的规划，分析，设计，测试以及文件等管理与控制。

敏捷开发主要特点体现在以人为核心的产品迭代上，在产品迭代我们还可以根据客户的要求在下一次迭代中加入适当的功能

3.主题

将敏捷开发思想引入到我们的项目中来时我们主要通过自己项目的特性考虑敏捷开发所有观点是否合适然后选择并加以改进

3.1完整的系统设计（系统架构）是否可以作为一个迭代周期内的设计

这个问题要从多个角度去考虑

1）我们的能力是否可以完成复杂的系统完整设计，同时在实施时能够只需要少量的修改

2）出现技术分歧的时候，我们是否有能力通过讨论判断出更加优化的方案

3）前期的架构设计是否会对后续的开发造成影响

完成一个复杂系统设计，或者开发基本以外包的形式进行时除了第三个问题都无法对上述的问题给出准确的答案

所以我们在前期确认了整体框架和功能标准滞后跳过了详细的设计，一边开发一遍测试的开始执行Scrum迭代开发

3.2 需要进行文档编写吗

需要，而且非常需要。

无论是技术文档还是面向用户的功能文档都是非常需要。

敏捷思想注重人与人的交流而不相信传统的文档因为中丢失了太多的信息

但是从我们公司的情况来看两个文档都需要进行文档编写。

我们公司代码的编写是以外包的形式给别的公司，所以不知道什么时候会选择下一家，而在这个过程中技术文档就是整个交流的核心

开发的项目会分配到不同的部门中去，为了减少重复劳动，软件使用文档需要详细的记录下来。

3.3 Scrum经验可以直接使用

1）客户作为团队成员直接参与项目讨论

暂时不行，无论UI设计还是编码阶段，我们最终面对的客户都是市场，少量的客户会让我们的项目不具备普遍性

2）短期的交付周期

可行，我们可以在每周交付一款可运行的软件然后进行检验是否符合客户预期并与其他部门的人进行相关讨论

3）验收测试与驱动测试

可行，我们采用的是XP和Scrum混合的敏捷开发模式，驱动测试可以让我们的项目质量更高而且我们正在这么做

同时驱动测试有利于代码的重构和解耦合，保证代码的质量减少后期代码验收时的麻烦。

4）结对编程

暂时不行，结对编程是要从整个制度上改变现有的模式，无论是外包公司还是我们公司内部都是不可行。

将来有机会我们会进行尝试。

5）开放的工作空间

可行，有利于大家情报的共有。为了实现这一块我们特别在别的地方租了一个办公室让项目相关人在里边工作

6）简单的设计

可行，按照上面所提到的我们在前期加强了架构的讨论，对于更多的细节设计会在迭代中逐步完善

7）头脑风暴

可行，给了开发人员更多的机会去优化项目的机会。会产生一些意想不到的好点子

4.将来的工作计划

1）sprint的定义

无论是一些通俗的介绍还是敏捷开发的艺术等书籍都将sprint定义为一周，其实可以根据大家自身的情况进行适当的修改

我们部门采用的是两周制。这样可有一个时间段来适应突发的变化，不会造成工作效率的下降

2）每个sprint的终结

主要是对这个阶段进行回顾然后提出一些优秀的idea并讨论如何进一步的提高，但是不会在这个上面浪费过多的时间

3）站会

这个主要提出问题，但是并不是在这里解决，而是寻求后续的帮助

5.工具的介绍

在敏捷开发中，白板和笔是最好的交流工具，但是适当的工具有助于提高工作的效率

1）redmine由于进行交流和Bug管理

2）Git做的版本控制

3）Jenkins做的发布和自动测试

4）Twiki做的wiki管理