[原创] 帮助项目成功——日构建

帮助项目成功——日构建

关键字：

       日构建、持续集成、项目管理

摘要：

       日构建本质上是一种管理实践，即通过持续集成、快速反馈来保证软件工作产品渐进的、可预期的朝着目标推进。以日构建为基础管理措施，有利于保证项目成功和提高软件产品质量。

什么是日构建（Daily Build）

所谓日构建，通俗来讲就是每天把所有的工作产品集成起来，并尽可能让其处于可测试状态。日构建是持续构建概念在以日计的较小发生频度下的特殊称谓。

XP方法中把日构建列为软件开发管理中的最佳实践；敏捷软件开发中也把持续集成当作是保证软件项目成功的一个原则。无独有偶，2003中国软件技术大会，上海微创软件公司技术总监蔡培讲述微软公司的软件开发管理时，演讲中提到微软软件开发管理中的一个重要实践，也就是日构建。

为什么需要日构建

软件开发管理中有很多问题往往让管理者非常烦恼，比如：

1.         项目周期一共只有半年，两个月后才看到原始的界面和一些初步的功能。需求人员一操作，发现设计师对业务需求的理解不正确。而设计师一操作，发现开发人员并未真正理解自己的设计意图。无奈，只好部分地方重新设计、重新编码，进度被拖延了。要是早些验证该多好呀！

2.         原本商量好的两个接口，没想到半月后一集成，居然并非当初想象的样子。理解有误，但是当时又没有暴露出来，结果只能返工。

3.         每次集成发现都需要三天的时间才能把所有的编译问题搞定。而错误往往源于接口变更未及时通知，或者通知后开发人员又忘记调整代码了。

4.         尽管项目中已经明确规定遵守《编码规范》，可是每次代码走查就发现还是存在很多违例现象。真希望有个自动工具，每天对开发人员的代码进行自动判断，发现问题立即自动通知项目经理。

5.         开发人员承偌本周完成，但是总是发现因为这个原因哪个原因导致最后没有完成。如何知道开发人员每天的工作效率呢？他每天写了多少行代码？真正实现了哪些规定的功能？实现的质量如何呢？

6.         软件的质量如何保证真是个难题。项目时间本来就紧，而测试人员往往需要等到产品基本成型了才能投入进行测试，测试时间不可能很长，这样就很容易导致产品中存在很多潜在bug. 要是能把测试提前到与开发一同进行多好啊。但是产品未出来，测试人员如何测试，看起来好像不可能实现。

7.         每次项目的里程碑展示和评审，总会导致各个项目经理和部门经理疲于为使自己的工作产品可以正常工作起来，并与兄弟部门集成而加班很晚。难道不能让我们的工作产品每天都是保持在可运行的状态，一步一步推向成功吗？

 

软件项目开发中的问题不一而足，远非上面所列。但是，仔细考虑上面这些问题，是否可以寻找到妥善的管理方法或者技术方法来解决呢？我所知道的一个答案就是在软件项目管理中引入日构建，并且不断把日构建利用到极致。

帮助项目成功

       软件开发的主体是人，需要通过人与人之间沟通、交流才能对工作目标和过程达成共同认识和理解。但是，常常见到的问题是沟通和交流缺失、不到位、失效，由此而导致重复工作、无效工作、甚至错误工作。仔细分析软件开发的沟通和交流问题，我觉得有如下几个关键影响因素：

1.         团队之间的沟通和交流依赖团队成员的性格和做事方法，如何在项目中引入机制保证团队成员自发坚持并做到必要、有效的沟通、交流？

2.         交流中存在对目标的理解错误不可避免，但是需要通过某种措施尽快取得反馈，从而却修正误解。如何建立机制来出促进这种反馈？

日构建的引入明显在在上面描述的影响因素中发挥了作用。为什么这么说呢？解释如下：

1.         日构建对每个开发人员的日常开发行为和目标作了许多规范，这些规范本身就减少了沟通的代价，协调了团队成员的工作。

2.         日构建的各种输出其实就是软件项目各个方面和层次的一个真实而且及时地反馈。例如，编译结果及时反馈了接口的协调；代码审查反馈了对编码规范的真实遵循情况；代码行统计反馈了实际工作量；构建后的可执行工作产品反馈了当前产品的状态。

软件的质量保证一直是个难题，一个方面的原因是软件的质量缺乏完善的度量指标体系和度量方法，另一个方面的原因是因为影响软件的质量因素绝大多数都与人相关，人的知识、智商、心理素质，甚至某个时段的心态和心情都足以影响软件的质量，所以软件的质量控制是典型的TQC(Total Quality Control)控制。

我们一惯采用测试来保证软件质量保证，但是测试对质量的保证存在一些不理想的方面：

1.         软件的质量是在软件开发过程中逐渐形成的，而目前的测试通常发生在我们的产品模块基本可以工作起来，或者可以集成起来之后。测试似乎是一种事后的质量保证手段，发现问题的修复代价较高。

2.         软件的质量控制周期非常长，影响因素多，需要在开发过程中及时取得质量的反馈，而测试只是一种后期的反馈。

3.         软件的质量除了运行时为用户提供稳定、可用、够用的功能外，还体现在软件的可维护性上。目前的白盒测试只能从功能上反馈软件的外部质量，而无法反馈软件的内部质量（代码质量，具体体现在软件本身的可维护性和bug分布）

4.         软件的质量严重依赖于人，所以从管理上应该防微杜渐、敏捷监控、规范管理。而测试发生在后期，bug的发现不仅修复代价较高而且容易对团队成员造成心理上的影响，影响个人的工作状态。

日构建的原则是从每个人的工作产品出发，一开始就强调集成，反馈，并且致力于提供可供测试的系统，从而把质量的控制提前到编码的开始（编码前的工作成果是否也可以纳入日构建呢，这是后面讨论的问题）阶段。日构建在反馈的频度上至少高于每日一次，这种高频度的反馈很容易解决出现的问题，久而久之会有助于提高团队对问题处理的规范性和一致性，这是保证软件质量的根本。日构建直接处理每个人的工作产品，我们可以在这之中加入很多对工作产品的审计和监控，实际上这就给予了我们控制内部质量的手段。这种手段与白盒测试结合起来，就可以对更全面控制软件质量。

软件项目管理的一项重要内容是如何公平、公正度量每个成员的工作成果以及对成员作出评价和激励。每个人的工作可能存在很多差异，比如工作难度、工作量、工作态度等。我们原来对每个成员的工作评价可能更多带有主观色彩，这不是成熟的项目管理方法。真正的公平、公正应当是建立在量化的基础上。日构建直接处理每个人的工作产品，在处理中加入统计、审计可以非常可观的度量每个人的工作量和一定程度的工作态度。比如，通过行代码统计、元数据统计我们可以分析出某项目组的绝对工作量，某个人的绝对工作量。通过代码规范审计，我们可以客观反馈出个人对于规范的遵守和执行情况，这完全可以作为工作的一个客观评价指标。

 

日构建对于项目管理所带来的帮助可能还远不止这些，因为日构建在本质上把工作产品和开发过程在某种范围和某种程度上紧密结合起来了，从而赋予我们挖掘更多更好的管理控制能力。

结束语

软件的开发过程是一种经验型过程(Empirical Process)，而非确定性过程(Defined Process)，也即，软件的开发并非明确可描述、可预测的。所以在SCRUM软件方法论中，认为可以把工业过程控制中的概念应用到软件开发中来，把软件开发当作一个黑箱（Black box）来处理，通过对黑箱的输入输出不断进行度量，在此基础上，结合经验判断对黑箱进行调控，使其不越出设定的边界，从而产生满意的输出。那么如何来做到这种度量和反馈呢？我想，日构建给了我们一个答案！

cloudward 

2004-8-16