顾焱：大型软件产品研发团队如何向敏捷组织转型

　　作者简介：顾焱，2001年加入用友软件股份有限公司，历任NC资金开发部经理、NC供应链开发部经理、NC供应链开发总监，现任用友软件股份有限公司助理总裁、NC产品本部副总经理、NC产品线开发总监。

　　前言：敏捷(agile)这个术语出自2001年2月美国犹他州雪鸟滑雪场的一个聚会，也就是后来著名的“雪鸟会议”。在这个会议上诞生了敏捷联盟和《敏捷宣言》。敏捷宣言的内容如下：

　　我们正通过亲身实践和帮助他人实践，来揭示更好的软件开发方法。

　　通过这项工作，我们认为：

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

　　可用的软件 胜过 面面俱到的文档

　　客户合作 胜过 合同谈判

　　响应变化 胜过 遵循计划

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

　　可见，敏捷代表的是不断探索的进取精神，宣言中“正通过实践”“揭示更好的方法”，指明大家行进在探索之路。宣言中倡导的价值观既要追求过程、工具、文档，但敏捷更重要。

　　经过多年实践和探索，我们发现很多方法需要结合自身特点(人员构成情况、不同开发角色比例、公司人力资源政策，甚至中国劳动力市场情况等等)逐步尝试和推广，从而建立自己的开发组织方式。Scrum、极限编程(xp)、特征驱动开发(Feature Driven Development，FDD)等敏捷方法学都属于敏捷实践，但未涵盖敏捷全部。我们的目标：以更低的开发成本有效地组织大规模产品开发，产品开发过程更可靠，产品更准确反映用户需求，实现更稳定交付质量可靠产品。

　　一直以来，通过收集开发实践中有效的方法和经验，并在产品研发部门内部推广。这种方法逐步改善了开发过程，并推动整个开发组织向敏捷组织转型。而这些开发实践，目的都是为了克服大规模产品开发中出现的沟通和协作问题。

　　接下来，以需求、开发、测试三方面为例，来阐述研发过程中是如何持续进行转变和改进的。

　　一、 业务场景主导需求文档

　　传统文档往往重点描述产品功能，而对业务场景描述较少，在需求讨论中对业务场景的讨论也不够充分。由此导致的问题是：程序员和测试人员通过文档无法有效了解要解决的业务问题，最终都按照文档完成工作。有时需求验证通过后，还是有些很明显的应用错误却被忽略，从而滞后了问题被发现的时间。这样导致的返工和补丁都大大增加了开发成本。

　　流程与任务改进后，需求工程师更贴近实际业务，更多倾听用户的声音，这样就比较容易把用户的原始需求抽象成业务模型，在业务模型的基础上再抽象出产品功能模型。在此基础上，整理出来的详细需求文档，就能够把各功能节点如何实现描述得更加清晰。

　　我们的实践经验是：

　　探讨如何用文档描述模型，希望通过文档模板建立通用的描述方法，在文档中强调需求场景的描述，让人更容易从业务角度理解需求文档要解决的问题，从而减少对文档的误解;

　　在概要需求层面整理完整的场景清单，能更好把握产品的方向，更容易把握产品在大解决方案上的能力，降低产品的学习难度，提高顾问学习的速度，并且使产品为将来提供行业预置方案打下基础;

　　整理单独的产品功能模型，需求更容易从业务角度确认产品功能的完整性，在整理过程中也使需求工程师能够再次以一个完整的视角重新审视产品功能，发现以往忽略的盲区问题，使开发工程师和测试工程师更容易通过模型理解详细需求的业务目标;

　　在需求变更管理上我们尝试建立变更负责人制度，在每个领域内设立需求变更负责人，负责每周收集所有详细变更清单并发给相关人员，有效地避免变更后文档更新不及时导致的信息沟通不畅(比如架构师要求的产品目标被详细需求变更打乱，直到集成阶段才发现问题;详细需求已变更，但测试工程师不知情，错误填写bug导致开发工程师返工。后续计划开发的需求管理系统，会从系统上彻底解决这个问题);

　　更多需求工程师到客户现场调研，通过增加与客户交流，更好的了解客户的想法。

　　二、 “小迭代开发”模式，强化代码质量和效率

　　如何保证大版本长周期(12个月以上)编码的顺利推进是在开发中尝试解决的主要问题。

　　开发周期上推小迭代开发，周期可以是一周或两周，根据所在二级部门团队的情况自己选择不同的周期，但最长小迭代周期不能超过两周。在每个迭代周期里要明确具体开发内容，并完成对开发结果的确认。对于在小迭代周期里完成不了的任务也要分阶段确认完成情况，避免数个迭代后才发现之前未完成的任务，导致发生大规模返工。

　　在小迭代中，当完成较大的业务需求后，就可以安排由需求工程师做产品演示。这个活动需要相关各角色(开发工程师、测试工程师、应用架构师、开发经理)都参加。这里明确了演示一定要由需求而不是开发工程师来做。因为需求做演示才能把产品的业务目标完成情况充分表现出来，也更容易发现问题。开发经理通过对每个小迭代的确认，也更容易明确当前的开发进度与整体计划的偏差，对于风险的控制也更精确。可以快速解决问题，避免到联调或集成阶段再发现。让发现问题的时间尽可能靠前，这是降低开发成本最有效的手段。

　　编码过程，一直在推动开发工程师加强单元自测。但是如何加强，不同团队理解是不一样的。在一个全凭自觉的团队里，加强单元自测只是开发工程师凭自己的责任心和自己对需求的理解进行的测试，也许只是写完代码后在开发环境里简单操作一下就算做完了。但是对于一个训练有素，协作良好的团队来说，单元自测首先要知道：测什么，在哪里测，什么情况下算通过?

　　首先，测什么?不是仅凭开发工程师自己的理解进行测试，而是要与需求工程师和测试工程师充分沟通，并将结果体现在测试用例上。为了避免歧义，测试用例最好明确到具体数据。提倡在每个小迭代周期内编写当前迭代的测试用例，而不是将所有测试用例写完再评审，最好由相关的需求、开发、测试三人进行小规模评审，这样可以快速完成评审，也可以使三人对需求和产品的理解一致，提高沟通的效率。

　　之所以一直强调沟通，是因为无论文档怎么写，对于同样的一句话，不同的人会有不同的理解，这是在实际工作中会经常碰到的事情。是否需求写到足够细就可以更好的避免这个问题?对于开发来说，首先需求要把业务信息表达清楚，如果在此基础上再细致的写出所有明细，需求既要从业务方向把问题想清楚又要从逻辑上把所有细节描述清楚，这就像要求一个人文理都精通一样，难度很高。另一方面。如果需求要撰写所有业务和明细，这种工作量和时间也是目前资源承受不了的。因此，强调团队协作，用比较经济的方式来完成工作，是一种较好的模式。

　　其次，在哪里测?为什么一直强调在测试环境而不是在开发环境做单元测试?因为这其中有一个做安装盘的过程。在做安装盘的过程中，要提交代码、编译、导出脚本、打包、安装，每一个环节都有可能出问题。如果每个环节出现的错误都是从测试反馈到开发，就会增加很多交流的时间成本;如果程序员自身简单测试一下，这些问题就可以很快解决掉，这样测试工程师就将发现简单重复问题的时间节省下来，用于发现深入的逻辑问题，在有限的资源投入下，让产品质量更上一个台阶。

　　最后，什么情况下算通过?只有测试在安装盘构建的测试环境下，按照测试用例来测试未发现问题时，才算通过。这里，再次强调了安装盘构建的测试环境，因为当一个问题补丁测试通过，这个补丁相关的代码是否正确提交，以及后面一系列做盘的动作是否正确也是需要验证的。

　　代码编写上通过规范代码模板，让新人可以快速学习如何完成工作，让不同岗位的开发人员可以读懂别人的代码，在部分模块资源紧张的时候从其他团队调入的人员可以较容易的进入工作状态，也让完成的代码在一个相当长的维护周期里更容易被维护。这里所说的代码模板，是指完成某一功能需要编写的代码片段。代码片段是需要通过领域内评审认为正确的代码，但是不一定是最优的。

　　程序员需谨记：有规范代码模板的就需要按照代码模板编写，不能根据自己的理解编写自己认为更优化的代码。在一个大规模的团队中，可读性和一致性好对于降低整体的开发成本和维护成本十分重要。程序员的创造性要放到复杂业务逻辑的开发中去，不要在简单的功能代码上浪费时间。为了更好的帮助程序员完成简单的功能代码，应不断完善应用开发平台，应用集成开发环境也即将正式发布。

　　三、 基于测试用例的产品测试，提升产品质量

　　产品测试主要解决的问题是如何有效快速的回归测试，如何尽可能大的覆盖所有需要测试的路径，如何准确的判断当前产品质量。

　　为了解决这些问题，首先加强了测试用例的管理，推出了测试用例系统。测试用例的编写要求做了很大改变，要求明细到具体数据。

　　此举目的:以前更多的依靠测试人员的能力保证产品质量，但是人员能力的培养是需要周期的，新人不断加入，产品规模的快速扩大，使得这种保证质量的方式越来越吃力。需要对人员分层，让初中级测试人员能够快速具备深入发现产品问题的能力，让高级测试人员从简单工作中解放出来。通过明细到具体数据的测试用例，可以把高级测试人员的经验固化，让初中级测试人员可以通过执行测试用例快速发现问题，完成测试用例的回归，从而使原来不可复制的核心资源问题，变成增加人力可以部分解决的问题，也为将来远程测试资源的使用提供一种可行的工作方式。

　　另外，自动化测试也需要在数据明细具体的测试用例基础上进行。测试数据准备、明确的测试预期结果、数据明确的测试用例，是自动化黑盒测试的有效支撑。通过大规模的测试用例整理和测试用例系统的支撑，使回归范围的计划、统计和产品质量的评估都成为可能。

　　大型软件产品的大规模研发，是一个持续改进的过程。敏捷的研发组织需要规范的管理和管理创新。在研发实践中不断地发现问题，总结解决问题的有效方案和方法，并在组织内有效的推广，这是一个敏捷研发组织的原动力。