Ｊａｚｚ，驾御研发的力量_华为2018年研发投入

　　按时按量地研发对于软件研发人员而言，简直是“难于上青天。”的确，对于需求变更不断的软件研发来说，成功的“作品”少之又少。 　　据美国一份评估报告显示，17个主要的国防部软件合同中，平均28个月的进度计划推迟了20个月才完成，一个4年应该完成的任务，7年还未提交，其中没有一个项目按时完成；由于存在软件问题，b1轰炸机的部署被推迟了，同样的原因，580亿美元的a12飞机计划也被部分取消了。
　　究竟是什么阻碍了软件研发的进程?软件研发人员又将怎样做才能减少不满意项目的产生?
　　“了解研发团队中每个人的进度，且实时按需协调团队整体步伐，使之协作有序进行将提升项目的成功率!”IBM大中华区软件集团Rational总经理夏然这样认为。
　　
　　协作，难亦不难
　　
　　李璐，IBM中国研发中心新兴技术研究院开发经理。十几年前，李璐在长城集团软件研发中心工作，由于缺乏被定义好的开发流程，李璐每天的工作就是接到任务，然后拼命地埋头苦干，由于在软件开发过程中，并不了解整体研发流程中存在怎样的问题，团队之间的协作也就无从谈起，“当时我们甚至说不清楚自己身上究竟背负了多少工作，而这些工作的重要性究竟是什么，根本没人能说清楚。”李璐回忆道。
　　由于缺乏管理流程，团队之间没有标准，根本谈不上所谓的协作，从而也就导致各部门及各人员间工作的整体性极差，项目进度及软件质量也就可想而知。多年后，当李璐进入IBM中国研发中心新兴技术研究院后，她才知道其实软件研发可以不那样痛苦。
　　“IBM自身有一整套的自定义流程，我们利用Rational Unified Process来实现。我们甚至实时地了解项目中每个人的进展状况，并针对出现的问题进行及时调整。”李璐深有体会地说。
　　据她介绍，Rational UnifiedProcess是一个面向对象和网络化的程序开发方法，它像一个提供程序开发所有方面和进程的指导方针，同时也是模板和例子的在线顾问。软件研发人员可以通过它把开发的程序因素和开发的其他方面在一个统一的框架内结合起来。RUP定义了开发的四个阶段，每个阶段被组织进入许多单独的反复，这些反复在下一个阶段进行之前必须满足定义的标准。
　　在初始阶段，开发者定义工程的范围和它的商业案例；在细节阶段，开发者十分详细分析工程的需要，定义工程的结构基础；在建设阶段，开发者创建应用设计和源代码；在转换阶段，开发者把系统地送给用户。
　　“RUP在每个反复完成时提供一个原型。这个产品还包括对J2EE和BEA法开发的支持，提供了一个基于HTML的对同一程序的描述，这样一个组织可以为自己的使用进行定制。”
　　
　　自动，简亦不简
　　
　　孙振芳，北京天宇朗通有限公司配置管理主管，多年前其曾任职的一家公司。公司构建时间为8个小时左右，要求在早上9点之前必须拿出一个可发布的版本供测试使用。这时就要求在9点以前的8个小时或更多的时间内必须保证能够成功地构建。
　　当时公司有两名构建人员，一个是下午两点半上班，工作到10点半，另外一个是晚上6点上班，工作到第二天上午。他们的生物钟基本被打乱。而且他们每天在重复同样的事情。“如果我们能够实现这种自动化，就能够把构建人员释放出来。”孙振芳说到。
　　为了实现自动化，解放构建人员，IBM Jazz平台做了许多优化。通过Jazz，团队成员在工作时可以看见登录成员，并自动获得影响其自身工作内容的变更、输入和里程碑通知。同时，定制的项目过程将指导团队工作流，并自动化过程步骤，以及设定基于多种程度级别优先级的检查点。预设和执行软件构建过程。加速多服务器、跨平台环境的构建过程。创建详细的记录材料以保证构建的可重复能力。这样一来，通过自动化构建过程和减少构建错误的可能性，节省时间、开销和返工。协助保证构建可重复性以满足所需的循规需求。
　　“通过Jazz，我们可以让开发人员直接去机器里申请，构建资源自动领取工作，而不需人为的去等。还有是多机协同构建的问题。如果我们能够实现N台机器一起去构建一个产品的话，我们的时间就会缩短到1/3。”
　　
　　透明，繁亦不繁
　　
　　“软件研发就如同生产汽车，当我们将生产变成自动流水线，软件研发就与繁复的轿车生产一样都不再是难题，关键是化繁为简。”北京恒讯时代信息技术有限公司高级咨询顾问肖勇对软件研发颇有体会。
　　“目前我所看到的，以及我咨询服务的公司，我看到了大量软件项目的失败或延期，一个根本的原因就是在沟通体制和机制方面有很大障碍。一方面是缺乏一套沟通的机制，另一方面，在支撑体系上，缺乏一套能够支撑工程往前推进的软件平台、信息平台。因为只有拥有这个软件平台(信息平台)以及配套的机制以后，利益相关者才能切实知道他在软件生产过程中所肩负的责任，有时候他不清楚自己要做什么，该如何跟别人去协调呢?但当我看到Jazz后，我相信我的后顾之忧没有了。”多年经验使肖勇对软件研发失败有着深刻体会。
　　例如我们假设一个跟踪并修复错误的情况。修复错误的工作在团队中流动，从发现并报告问题的小明，到复核传入的错误报告并将该工作分配给小红的小马，到修复该错误的小红，并最终返回到小明以进行验证。错误修复本身在团队中流动，从修复代码流中的该问题的小红，到验证包含该修复的构建版本中的修复的小马。
　　这些流可能非常脆弱。如果签入某个修复而没有更新错误报告，或如果不存在将修复与特定代码流和构建版本联系起来的纽带，则团队中的流就会中断。这些中断会在团队中导致混淆并妨碍进度。更有甚者，中断也许不会立即在团队中的任何人面前表现。而与领域相关的工作和主要与维持团队协作相关的工作之间的交织将对整个项目造成更大的威胁。
　　尽管IDE集成了若干工具，但开发人员仍然要手工做大量的重复性簿记工作。如果小红只需告诉IDE她现在正在设法修复某个特定的错误，这就要好得多。然后，当她完成修复和测试用例时，可以指出她已经完成该工作，而无需执行进一步的操作，系统将提交已更改的文件，并将这些文件与错误报告相关联，更新构建说明，并将错误报告标记为“已结束”。
　　如果工具以这种方式自动化簿记工作，则能通过确保错误报告与代码签入之间的重要联系是可靠的，从而帮助提高团队的工作效率。同时，还可以提高单独的团队成员的工作效率。
　　相信，Jazz通过其协作、流程识别和自动化、透明度三大特点将给予更多软件研发人员以可驾御的力量。