（本文写于2004年，因 DONEWS丢失再转贴这里。）

日构建在XXX部门的应用经历
日构建未来构想
“没有最好，只有更好”，这是对日构建系统的要求。未来的日构建一方面要解决目前日构建实施中已经显现出来的问题，另一方面，则要挖掘出更深的内涵。
1. 流程全自动化
流程全自动化的意义是节省维护的人力成本，同时加快构建的反馈。日构建的理想状态是按需构建，即任何时候有构建需要，日构建则启动，并以最短时间产生输出。当然实际情况是构建需求可能并不统一，同时输出与构建启动存在一定的时间差。平衡一下，我们希望以更短的构建周期来达到构建反馈的作用。
设想中构建流程的发起可以是时刻触发，也可以是命令触发，还可以是自动侦测触发，即当发现有任何新的提交，则触发构建。一旦触发，全自动的流程应该在无人监管的情况下正常产生目标输出。
2. 构建流程可定制
构建存在多个流程，这是实践中发现的需求。有时候可能只需要对个别项目进行全部构建既可，有时候只需对项目的部分工件进行局部构建既可，有时候可能只需要对最终输出替换某个元数据，等等。日构建的构建应该可以定制为不同种类的流程任务，并辅以不同的项目，部件作为构建参数，当有特定要求时，只需要选择某种流程任务，并指定参数既可完成。
3. 更高易用性
目前的日构建为各种构建需求提供了一系列的构建命令，这种基于命令的构建方式虽然灵活性非常高，但是不易记，难使用。目前的构建只能针对某个项目进行处理，无法提供批命令作用一组项目或者一组工件。未来改进措施是提供类似PT的菜单命令，并扩展支持复合命令，提高灵活性和易用性，争取让每个人都可以较容易学会使用，以便进一步推行“替死鬼”制度。
4. 可插拔的审计和统计处理框架
审计和统计属于附属在日构建上的“扩展”功能，正是这种“扩展”功能是日构建走出了普通构建的定义，成为产品和过程的一个有效控制手段，并为基于敏捷理论的项目管理提供是实践方案。审计和统计的功能必定随着项目需要而存在较多的变化，因而日构建应该需要支持可插拔的审计和统计处理模块，以便提供足够的适应性和可扩展性。
5. 数据和报表分离，提供更多管理决策信息
目前的日构建虽然也采用了数据和视图分离的设计原则，但是构建输出数据还是以文件形式存放，不便于数据共享。未来的日构建输出需要部分改造为输入到数据库，并且形成历史信息库，比如每日构建各个项目的构建信息，单元测试，甚至性能测试的数据信息等。这样基于每日开发进度信息和状态形成的数据库，可以直接提供管理层最真实、最有价值的信息，为项目管理、技术决策提供直接依据。这个功能对XXX的敏捷化管理应该非常充满吸引力。进一步，这个数据库还可以与DMP结合起来，发挥更大的价值。
6. 与统一环境的结合
日构建的输出已经成为不同工作人员的工作输入。目前的日构建输出需要人手工同步到标准服务器，并且手工控制版本。未来设想日构建的系统可以作为一个外挂模块直接集成到统一环境中去（关于统一环境的未来设想请参看本人的另一篇文章），这样管理人员可以通过统一环境直接搭建各种测试环境，开发人员可以借助统一环境直接更新自己想要的版本组件。
7. 补丁管理
一旦XXX面世，即将面临各种补丁管理。日构建应该能够很好支持补丁的打包和发放。

 （这是本人2004年 关于 敏捷软件项目管理的一个创作系列，（一）这篇因为donews丢失，再补贴这里，其他三篇可以在前面看到）

1       让人的资源多起来

       软件项目开发的核心资源就是人，在一定的项目规模和资本规模下，人的资源是受限的。项目中考虑人的资源常常以人数来计，但是实际中我们都清楚，工作量是以任务来分解和总和的。这就说明人和任务之间存在一个关系，这个关系就是角色。

1.1    角色（Role）

角色是对工作任务的职责抽象，与具体的职位有着区别。一般情况下，角色和职位是多对一的关系。敏捷风格的项目管理认为在产品（软件）开发过程中，成员所承担的角色虽然有其固定的一面，但是可以赋予它更多变化来改变工作的分配模式。举例来说，A的职位是项目经理，但是同时也是优秀的设计师，那么，可以认为A承担了项目经理和设计师两个角色。

在软件开发管理中，角色其实非常丰富。常见的角色如：项目经理、需求分析师、系统设计师、开发工程师、测试工程师。对于大型项目，比如基于J2EE的项目，根据实际项目中的技能需求，需要各种类似专家的角色，比如人机界面工程师，部署工程师，配置管理员，DBA等。

敏捷的项目管理中要求角色不是固定的，一人可以担任多个角色，这样才可以充分利用已有的资源。如同电网的电力资源一样，资源的存在和分布有时是难以改变的，但是其是否充分利用依赖如何调度。

角色是项目中任务的具体承担对象，从角色角度而不是职位角度考虑资源的分配，有利于合理分工，保持资源的平衡。对于存在多个项目并行工作的情况，这一点非常有意义。我们知道，一个公司的DBA不会太多，多个项目并行工作的时候，可能各个项目都需要DBA的协助，但是从人员编制上，DBA可能仅隶属于某个具体的项目组。这个时候如何解决资源的分配呢？同样，优秀的架构师对于整个公司来说也会是稀缺资源，我们如何让这些稀缺资源发挥更大的作用呢？当然，可以考虑从人力资源编制上解决这个问题，比如成立独立于跨项目组的专门的架构师组，总体设计组等。但是，实际情况往往是人力资源制度的改革步伐永远会远远落后于实际需要。况且，从资源模型本身来看，资源本质上是与角色捆绑的而不是与职位捆绑的。

<图〉

从管理的角度，我们希望资源可以最佳利用。绕过人力资源编制，实际上可以采取特殊的运作模式来达到这一目的。方法就是，赋于比职位多得多的角色，让人具备多个可分配的单位。在这一点可以用CPU的多线程来比喻。

案例：

2001年的时候，公司有Milkyway和Apollo两个项目在同时运行，两个项目都是电子政务项目，采用J2EE技术实现。当时公司是首次接手电子政务项目，对于Web页面所需要的大量美工虽有考虑，但是最终只招聘到一个合适人选。在Milkyway项目组中，大家都知道开发人员Alen喜好摄影，其实是一个图形制作爱好者，Photoshop高手。当美工资源已经成为事实上的开发瓶颈时，我给领导提出了一个建议：是否可以让Alen也充当美工角色呢？可以在开发任务上为Alen消减一半，让他有另一半的时间去让我们的工作产品漂亮起来。后来跟Alen商量让他兼美工这一角色，他愉快地答应了。我想，对于一个图形制作爱好者来说，还有什么工作比干自己喜欢的事情更愉快呢！

1.2 虚拟团队(Virtual Team)

虚拟是相对现实而言。虚拟团队一经发明，已经在互联网上广泛流传。所谓虚拟团队，是指没有实际的组织形态，但是有具体的任务目标；团队成员虽然来自各方，但是为着共同的任务目标而进行工作。

虚拟团队和实际团队比较，优势在于：组建灵活，反应快捷。

实际的团队往往根据长远的任务目标而设立，一经设立，成员即往往有了固定的身份。比如，项目组往往根据产品模块的任务目标而设立，一般来说在项目的生命周期中会一直存在下去。但是实际的项目工作开展过程中，一方面存在很多跨项目组的工作要做，另一方面存在很多短期的任务需要调度资源完成，这个时候固定的团队就难以胜任工作任务的分配。

虚拟团队本质上是根据任务对资源的临时性组建。前面我们已经通过角色把资源独立化了，现在通过虚拟团队，我们可以把独立的资源再通过任务目标而集中起来。

案例：

在上面谈到的Milkyway和Apollo两个项目案例中，当Milkyway项目推进到开发完成60%的时候，系统的基础框架已经基本可以在浏览器中看到。这个时候，架构师发现系统的响应很不理想，这个发现其实并不出乎意外。尽管公司是首次接手基于Web的项目，根据多年的经验还是预测到了可能存在的性能瓶颈。目前的任务就是需要立即组织部分专家来诊断性能瓶颈的准确所在，并敦促项目组成员调整代码。可是面临的问题是公司的测试工程师并不熟悉基于Web项目的性能测试，如何寻着额外的资源呢？另外，还有一个问题，性能问题来源于架构和代码，需要对系统结构和代码最熟悉的系统设计师和开发人员参与才行。这个时候Apollo项目正进入详细编码开始阶段，根据任务分配情况，管理层觉得部分设计师可以抽调部分时间来参与Milkyway项目的性能优化。为此，成立了Milkyway项目性能优化虚拟团队。

Milkyway性能优化虚拟团队

组成成员：

1.          所有Milkyway项目的开发成员和设计师

2.          Apollo项目组的Wiki和Polo（两位经验丰富的设计师）

负责人：

Wiki担任负责人和组织者。

目标：

         全方位优化Milkyway的性能，达到客户认可的各项系统响应时间指标

任务：

1.          一周内给出Milkyway项目的性能测试报告和性能优化具体指标

2.          三周内给出一期优化分析报告

3.          持续跟踪性能，从第四周起，每两周给出性能测试报告

执行：

1.          Milkyway的所有成员需要配合Wiki的组织工作，并接受安排的合理任务

2.          Milkyway项目经理Cobo协助Wiki安排工作

测试部经理Anny，配合Wiki安排测试设备和数据准备。

    摘要：写下孩子成长过程的点点滴滴，这是一份责任，也将是每个父母都可以完成的“著作”！    （全文共1245字）——点击此处阅读全文