Agile(敏捷)开发介绍

开始本篇之前先来大致看看敏捷开发的内容：
首先敏捷开发的宣言：

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

再来看一下，敏捷开发需要遵循的一些原则：

• 我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。
• 即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。
• 经常性地交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。
• 在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。
• 围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。
• 在团队内部，最具有效果并富有效率的传递信息的方法，就是面对面的交谈。
• 工作的软件是首要的进度度量标准。
• 敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。
• 不断地关注优秀的技能和好的设计会增强敏捷能力。
  简单是最根本的。
• 最好的构架、需求和设计出于自组织团队。
• 每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。

以上那么多内容，简言一下， 相对于标准化的CMMI开发， 敏捷开发的优势是快速和变化。至于质量、客户满意度等这个本身就是软件开发不可少的要求。

实际的项目状况

虽然Agile 开发方法有以上的一些优点，但是不同的软件开发方法适用于不同的项目实际的状况 。连Agile 的创始人之一 Martin Fowler也认为：
新方法不是到处可适用的。在以下情况下，适合采用Agile方法：

• 需求不确定和易挥发（Volatile,意指今天的要求明天就不需要了）的场合。
• 有责任感和积极向上的开发人员 。
• 用户容易沟通并能参与。
  而且在实际的项目软件开发过程中， 很难完完全全严格按照某种软件开发方法来进行，明言很早就告诉过我们： 不要“本本主义”， 要“理论联系实际”。 大多数的项目开发过程， 都很根据实际的项目情况，人员情况，结合了多种开发方法， 针对实际的状况做一些方法上的调整，只是有可能某种方法处于主要的地位。
  本篇介绍的项目的大致情况如下：

1. 项目是一个大型的企业级应用系统基于某个平台的二次开发(系统主要是用来做生产、研发、等填单、流程以及对相关的智力资料进行管控)
2. 项目的是给公司的全球用户来使用(用户超过6000)
3. 虽然之前也有类似的系统在做管控， 但是基本上参考意义不大。 因为环境在变化、需求的变化也很快。用户需要快速的就用到系统。
4. 开发团队有2位需求分析人员、4位经验丰富的开发人员和2-3位测试人员
5. 团队的组建大概有6年时间，虽然大家能力和合作都还不错， 但是缺乏激情和主动改进的动力。团队之前的开发基本上是标准化流程开发居多。
6. 用户都很忙。
7. 开发使用 JIRA 来进行任务分派。
8. 系统分模组、分阶段上线。

实战的项目开发过程

基于以上的描述状况， 项目交付需要快速、变化比较多，看上去比较适合Agile 的开发。其实，实际中也是自然而然的就使用了这种开发方法，因为如果再标准化的开发流程，就会面临着很多的问题。慢慢的就形成了这样的开发流程（针对某个模组）：

1. SA 与用户进行需求的收集， 与用户进行确认和沟通(PPT)
2. SA 拆分User Case , 并撰写规格(Excel)
3. SA向AP解说规格并进行任务分派、时程规划和需要Demo Prototype的安排。
4. AP 根据规划，分阶段进行开发，交付。
5. SA 对开发的功能进行测试。
6. SA 与 User 进行Demo , 收集意见，分发AP 进行修改
7. 4和 5 的步骤会重复多次
8. 全部开发完成， QA 进入测试
9. 测试完成， 进行模组的上线

遇到的问题

以上流程仔细看， 很容易发现两个问题：

1. 没有SD 的工作
2. 测试看上去做的有欠缺

针对第一个问题： 没有SD的工作
首先， 时间比较紧， 再有， AP都比较资深， 所以大部分SD的工作都被省略了。但也因为这， 导致了一些后续的问题：

1. 开发时间估计不足
   SA 对代码的估计Always 总是乐观，一个页面上栏位联动的功能， 对于SA 来说，从功能层面上来说或许很简单， 但是从开发层面来说， 需要考虑的部分却更多，或者是有跨浏览器兼容的考虑；或者是对既有组件进行扩充修改； 这个时间上的消耗远远超过了SA的预估。
   另外， 代码层面上的一些相互影响也是AP 人员最为清楚， 所以SD 的工作， 有些部分是必不可少的。而且对于这部分工作不能单单是开个Task 给某个SD进行完成， 应该有这样一个快速的会议， 让相关的SD一起来风暴一下。对于估时以及时程的部分， SD也是要负一半的责任的。
2. 代码重用度不高， 堆砌严重。结构混乱
   SA 与AP 单线联系， AP 开发的功能 SA 来验证， 时程上有很敢， 导致AP 以最快的速度来完成功能的开发， 什么代码风格、代码质量、代码重用性、代码维护性通通先放一边， 先完成SA对于Demo 的要求。 另外一方面， 这里说了是Demo 的要求， 所有的这些功能，有可能在Demo 之后会被推掉重来， 所以花过多的时间去考虑功能之外的部分在AP 的角度看来，的确有一些得不偿失， 慢慢的也就形成了堆砌严重甚至结构混乱。
   追求速度不能丢掉质量， 针对特定的情况， 可以使用不同的方式来保证质量， 可以在系统稍微稳定一些的时候做一些代码重用和代码重构的工作， 但是必不可少。

针对第二个问题： 测试看上去做的有欠缺
从上面的流程可以看出：
SA 有在做类似的单元测试， QA 最后阶段会做SIT和UAT合二为一的测试。
这样的话，问题又来了

1. SA 的测试不充分
   SA 为什么要测试？ 原因是功能的变化很快， 每次的Demo 总有一些变化， 大的可能要推到重来， 如果QA 过早进来测的来， 第一个是Bug 数量会很多， 再一个是针对同样的功能， QA可能会测试到一些不成熟的版本，浪费时间。由此， 稳定之前 SA 先进行测试。
   但是SA 的测试是粗粒度的， 因为功能是SA 开出来的， 所以SA不需要参考规格来做测试。 SA 测试觉得有一些改动也会随时找AP 来进行修改， AP 发现一些改进的部分也与SA 确认来进行一些修改。在这个过程中， 系统的功能总是在逐步的变化着的， 而SA 关注的只是某个点的功能， 而且SA 基本上不会做回归测试。 改动后影响的部分怎么样了， 没有人知道， 只能扔给最后一轮的QA 了。

2. QA 的测试总是紧急。
   QA总是在最后阶段才进入测试， 多的话， 可能预留1个月时间， 少的话也就半个月。 而QA 因为进入的时间晚，对系统的功能了解不多，光熟悉就要花费一段时间。熟悉之后的测试也是磕磕绊绊。时间上很难保证完成。
   QA可以在晚点介入测试， 但是介入系统的时间应该要早些， 参与SA 与AP 的会议，参与User demo 的会议。

3. 测试的质量不高， bug 漫天飞舞(真的？ 假的？)
   以上也提到了，功能的改动会很多， 但是规格基本山很难与之同步改动, 这样的话， QA进入测试的话，依据规格来测， 势必出现很多问题。 有的是Bug , 有的是规格未修改的部分。总之， 结果就是bug 漫天飞，平均的话一个小功能产生两个 bug。
   AP 需要花时间看， 还要与SA check , 然后再与QA 说明，节省的一些时间终于被耗费掉了。
   另外， 频繁的改动后， 有时间甚至SA 自己对规格都不甚清楚了。 甚至出现要确认规格的时候，会出现SA 要AP 来说明的状况。

汲取的教训

1. 后期需规格和补充规格及资料
   清晰而正确的规格必不可少， 不然所有的都没有依据了。 但是规格的完善可以放晚一些， 比如：放在QA 开始测试之前进行。
2. SD 某些工作必不可少(时间的Double Confirm 一级大体的设计)
   所谓“先谋而后动”， 没有设计的行动， 往往盲目或是在做一些重复功和无用功。SD可以简化， 但是有些工作是不能剔除的，像时间和时程确认以及总体设计。
3. regular 收集需改进部分及定期的重构
   系统需要持续改进，任何角色，SA, SD, AP,QA 只要发现系统有需要改进的部分都可以提出来， 统一安排进行改进。
4. 定期Code Review
   自律是一个范畴的词汇， 在不同的状况下， 自律的程度不同，需求层次论可以很好的说明这个。所以， 定义的Code Review 对与提升代码质量的用处不仅仅是在Code Review 本身meeting 所发现的问题上。
5. 需增加开发人员的测试和单元测试
   黑盒测试的同时， 适当的补充一些白盒测试， 最好的就是AP 自己编写的单元测试。准确、高效。
6. 增加自动测试的部分， 规范QA测试的标准和流程。
   加速测试的速度、提示测试的质量在Agile 开发中应该起着该有的作用。
   提升QA 测试的能力， 区分bug的能力， 归类bug, 完善测试流程与AP 交互， 对于加速开发不无益处。
   除此， 导入自动化测试来做一些重复的测试部分， 减轻QA 负担， 加快测试。