从过程的连续光谱来看，我们大概处于中间位置偏左的位置，更偏向一个轻量级团队的敏捷过程，但是也包含计划驱动过程中的因素。我们的小组是自管理的，没有专门的QA和SA，我们自己去想出最好的工作方法，但是在执行中我们的计划还是相对确定的，每个季度做什么都会有一个比较明确的计划和里程碑，并且对问题领域都相对熟悉；我们的过程是迭代式，一般一个季度至少会交付一个稳定可执行的新版本，我们在文档上做的不是特别好，很多都依赖于团队成员之间的“隐性知识”；同时我们对问题的改进基本还是有一个流程和机制，会持续的跟踪问题并改进。
下面分阶段总结下我们的一些实践经验。
一、分析和设计阶段
1、在这个阶段，我们会明确准备做什么，界定问题的边界，对功能进行一个取舍。一般在一个版本完成之后会马上开始这个过程。大家都想一想接下来做什么，经过几轮PK后确定重要紧急的事情优先做，定义下一个版本的功能列表。
2、功能列表出来之后，我们会针对每个功能提出各种方案做比较，在此期间，我们会邀请更大团队范围内的专家参与方案和设计的评审，剔除不切实际以及明显有缺陷的方案，针对一些风险点提出改进建议和防范措施。
3、在设计方案出来之后，我们会分配功能的开发任务，根据每个开发人员熟悉的领域，自主领取或者被动分配任务。这个过程不是一成不变的，考虑到团队内部知识交流的必要性，也可能让不熟悉某个领域的人去做他不熟悉的事情。
二、构造阶段
1、整个系统已经有一个关键的抽象机制，针对我们的服务器有一个核心的pipeline机制，针对我们的客户端，有一个核心的发送消息流程。将所有的功能模块组织在这个关键机制周围，形成一个强有力的整体。
2、开发完成不仅仅意味着功能代码的完成，还包括测试代码：单元测试和集成测试。如果你没办法做到全面的覆盖，那就要求必须覆盖运行的关键路径和极端场景。
3、单元测试我们使用JUnit，适当使用Mock可以简化测试。但是Mock对象如果太多，也许会失去测试的价值，这里有一个权衡。
4、在整个构造过程中，我们贯彻每日构建、持续集成的原则。使用hudson做持续集成，时刻关注测试状况，有问题及时反馈给开发者。
5、有一个功能强大的集成测试框架，模拟实际环境做各种测试，它的目的是尽量在接近真实状况下去执行系统并尽早暴露问题。
6、每个功能完成之后，立即发起review，请同事和你一起复审代码。复审代码的作用不仅是发现bug，改良设计，也是一个知识交流的最佳途径。我们经常能通过代码审查发现一些设计上的缺陷，以及功能实现上的BUG。我们团队应该说是非常看重代码审查的作用。
7、使用findbugs和clover等工具，分析代码质量并改进。
8、在发布之前，做一次集中的代码review，每个人介绍下自己的功能实现代码和设计，一般我们会申请一个会议室和投影仪，并邀请团队之外的人加入review。
9、在发布之前，有一个系统的压测流程，针对每个版本更新压测方案，并预留一到两周的时间做性能压测。压测不仅能尽早暴露性能隐患，还可以发现系统在特殊情况下的一些BUG。压测除了关注系统的吞吐量、GC情况之外，还应该关注硬件的性能指标。
三、发布和总结
1、发布之前，最好让使用我们系统的用户使用新版本做一个回归测试，一方面是测试兼容性，一方面也可以及早发现BUG。
2、我们的发布流程：线下、beta、线上。每个阶段通常都持续一到两周，才会进行到下一阶段。并且是从相对不重要的系统，到关键系统的顺序进行发布。
3、发布之后，通过日志、运行时监控、用户反馈等方式收集系统运行状况，发现BUG，修正BUG，补充测试，测试通过，重新发布。
4、每个版本发布后，需要总结下本次发布过程中遇到的所有BUG以及经验教训，并提出可能的改进建议。
5、需要一个跟踪线上问题的BUG跟踪系统，可以用JIRA之类的trace软件。跟踪不仅是记录，最好列出解决的时间点，在哪个版本确定解决，甚至确定交给谁去解决，并持续跟进。
本文来源于"阿里中间件团队播客",原文发表时间" 2010-12-30"
