开发项流程（Development Item Process）
当时的这个Scrum试点项目身负重任，其中之一就是要探索出在新型的敏捷模式下该使用何种的开 发流程，负责人就是当时的Linux部门经理，而我则捞到了负责测试部分流程的机会。整个试点项目的人员扩张速度不错，4个人的团队维持了好几个迭代，陆续有人加入，新的测试人员在大概是第四个迭代的时候才补充进来，而后逐渐扩张到两三个团队。这样的扩张速度对测试流程的确定来说非常好，一开始我可以只考虑自己的想法，不断地尝试摸索，可以很快地得到反馈然后改进；等到想法大致成形的时候，又可以专注于帮助其他成员理解流程和使用，验证流程的易用性；等到人员更多的时候，就可以着重验证流程的推广复用性。
试点项目并非是全权负责新产品的开发，它其实是归属一个更大的项目、产品的，产品经理在芬兰，芬兰也还有一些团队，两地之间的团队必须要合作，虽然杭州的项目享有流程等各方面的自由，但也必须考虑和芬兰团队现有模式流程协作的问题。流程中也要把这些细节都考虑进去。
我讨厌浪费，讨厌重复的信息，也不喜欢把不同特点的信息混淆在一起，而且流程要为人服务，它需要根据人在工作中的行为、活动特点来制定，而不是凭空想象，这是我在流程总结中所秉持的重要原则。因此，在流程中测试活动开展所需要的信息，每一份信息只应该存在于一个位置，其他地方全部应该通过链接或者引用使用这些信息，而且测试和开发都会用到的信息也适用此原则。信息应该分为长期存在和短期存在两种，可以看做是从读、写的角度进行区分：同一份信息和被测对象相关，且在可预见的未来还会继续被读写的话，看做是长期的类型；同一份信息主要是阶段性的，和特定的版本、时间点相关的，且在可预见的未来只会被读取但不会被更新（写）的，看做是短期的类型。两类信息或者以不同的文档进行维护，或者以不同的方式进行维护。
如下简单表述一下当时所设计出来的流程，这个流程因为种种原因在试点项目结束后没有被延续使用，但是大概是三四年后我已经成为敏捷教练的时候，意外得知它居然一直在别的产品线沿用至今（当时），其生命力可见一斑。我将侧重描述其变化、改进之处，和以往流程相同的地方则不做介绍。
● 新流程的目标包括：推动开发和测试专家们的密切合作以提高软件的质量；合理化以及简化相关文档；减少文档数量，加强维护，以提高文档的质量；促进开发和测试人员之间的互相学习，以增加项目资源的灵活性；等等。
● 开发项是新提出的概念，将软件的规格说明书撰写、设计、实现和测试封装在一起，作为最小的原子化产品组件（Component）。原子化的意思是保持开发项之间的互相依赖在可以做到的最低水平；移除或重排任何开发项的时候，对其他开发项不产生（或产生最小的）影响。
● 在迭代开始前，先有技术报告或者需求文档，由此而产生出开发项；然后是和以往的项目过程一样的入口阶段，确定项目日程并且生成相关的高阶（High Level）文档。包括集成计划文档、项目计划文档、模块（Module）测试策略以及开发项测试计划文档都在此时创建。
● 所有和开发项相关的测试活动都在Sprint内完成，这些测试被称之为DIT（开发项测试），测试用例本身还是属于以往的功能测试级别。但是开发项的测试计划、测试执行、报告等一系列过程全部都要在一个Sprint中完成，测试用例的自动化比例并未做硬性规定，但当时我们的成果是100%自动化。
● 项目成员主要分为开发和测试两类工程师，但是角色的定义并不是拿来当做不可逾越的红线使用，必要的情况下，开发工程师也会承担部分测试任务甚至整个人投入测试，或者测试工程师也会和开发工程师一起，结对开发代码。
● 开发人员的工作安排会受到测试工作的影响，每日站会或者平时工作中，可能会发现软件不容易测试，就需要开发人员协助检查以及修改代码提高软件的可测性。或者是在开始写测试脚本之前，就去跟开发人员约定程序输出的内容和格式。
● 测试文档根据信息的长期性、短期性进行了区分。
1、测试计划与报告：将这两个单独的文档合并到一起，在单独的章节里展示各自的信息，每个软件发布使用一份测试计划和报告。总共四个章节：被测功能描述以及模块列表（持续更新）、持续集成测试状态（每个迭代的测试报告）、总结（质量评估、经验反馈、推荐和建议）、现存问题（尚未解决或仍不明晰的问题）。目的是在单个软件发布周期内持续记录测试的状态，缩减不必要的文档量。
2、测试用例与缺陷：每一个模块或技术领域使用一份测试用例及缺陷文档。文档内容包括：该模块或技术领域的整体描述，测试用例列表及状态，缺陷列表，测试辅助程序，操作命令。目的是提供一份可以全面了解被测模块或技术领域的文档，包括当前的所有功能、曾有的和现存的缺陷，以及如何使用操作命令和测试辅助程序进行测试。
3、测试用例清单：用Excel记录所有的测试用例即可，信息来自于现有的测试管理系统，包括测试用例的编号、已测过的最新软件发布、已测过的最新版本信息、测试用例的版本、测试用例名称、自动化的状态。
4、缺陷清单：用Excel记录所有的缺陷即可，信息来自于现有的缺陷追踪系统，包括缺陷的编号、标题、严重程度、缺陷单状态、相关的测试用例以及版本。目的是提供一目了然的缺陷清单，可以知晓其历史及现状。
5、Sprint缺陷清单：记录在Sprint开发过程中发现的软件缺陷，相当于轻量级的缺陷追踪系统，无法当天修复的问题才会被记录下来，而无法在当前Sprint中解决的问题则会被录入缺陷追踪系统，并且录入前一个缺陷清单。
Linux编程培训
为了帮助新人快速地融入项目，我们还承担着开发一套培训课程的任务。在Linux环境下进行开发的同时，我们需要总结经验，有针对性地记录所需要掌握的各方面知识，并且做成培训材料，提供给加入团队、项目的新手。我也参与其中有少量的贡献。
相关链接：
我的软件测试之旅：（1）起点——作为软件开发人员
我的软件测试之旅：（2）转变——作为专职测试人员
我的软件测试之旅：（3）同期——加入测试自动化小组
我的软件测试之旅：（4）并行——自动化回归测试
我的软件测试之旅：（5）难点——功能改进的测试
我的软件测试之旅：（6）跳转——追逐新鲜事物的探险者
我的软件测试之旅：（7）启程——Scrum中的测试工作者
我的软件测试之旅：（8）困难——没有现成的测试工具
我的软件测试之旅：（9）行动——简化测试文档和流程