软件开发的爵士乐

软件开发的爵士乐

软件开发是一种高度协作的过程，就像是一支乐队在集体演奏，每一个音乐家不但要集中精力演奏自己的部分，同时还要与乐队全体成员保持合拍与同步。 根据一项调查显示，只有37的用户对软件开发的速度感到满意，42左右的用户对开发出来的软件应用感到满意。大部分用户对开发的质量、项目的执行和开发速度的需求一直在改变。所以软件开发能够达到满意的不到一半，这是软件开发行业里面临的一个严重的挑战。 英国17世纪玄学派诗人约翰·堂恩有这样一首诗：“谁都不是一座岛屿，自成一体，每个人都是广袤大陆的一部分。”在软件开发的环境中，每个人也不是单独作战，开发的质量和周期取决于团队中的每一个人。 软件开发是一种高度协作的过程，每个人不但要完成自己这部分的代码，更重要的是需要和项目中的各个模块完美的结合在一起。就像是一支乐队在集体演奏，每一个音乐家不但要集中精力演奏自己的部分，同时还要与乐队全体成员保持合拍与同步，否则表演就会失败。 过去，每个人都在寻找适合自己的工具，导入导出着各种信息数据，用来提高软件开发过程中的协作、效率和透明度。 在全球整合的浪潮下，未来的软件开发一定是团队的开发和分布式的开发。开发团队很可能分布在全球各地，互未谋面，远隔千山万水，这对开发者们的团队意识提出了更高的要求。同时他们也需要一个畅通的沟通平台，它能够将整个软件开发生命周期中的各个环节都无缝的管理起来。 正是基于这样的洞察，IBM去年便提出Jazz平台和其带来的协作新理念。Jazz是一种开源的软件开发技术平台，它的设计宗旨是：凭借为分散在世界各地的团队提供独特的协作方式，改变人们相互合作构建软件的方式，促使软件交付工作变得更加连贯、高效和透明。 值得一提的是，Jazz在开发的过程中借鉴了Eclipse过去的经验，Eclipse是一个可扩展的平台，是一个开放标准，可以免费下载。“我们在Eclipse上已经有很好的经验，借助过去的成功经验，我们将其应用到Jazz和RTC（基于Jazz技术的软件开发平台产品）的开发中，Jazz的开放和可扩展的架构不仅来自IBM，还有合作伙伴和开源社区的工具生态系统。Jazz会沿袭Eclipse的经验，沿着可以开放的、可拓展的架构继续走下去。” IBM大中华区软件集团Rationl总经理夏然说。 Jazz倡导了一种全新开发模式，无论是开发者、架构师、需求分析师或者项目领导者，都能够与团队其他成员实时沟通，并随时找到所需要的东西。 Jazz有三个重要的目标：一是沟通协作，二是可控的流程，三是增加透明度。 下面，我们来听听分析师、开发经理、配置主管，这三个软件开发中的主角， 遭遇这些问题时，怎么去解决。 分析师：我们需要一个平台 北京恒讯时代信息技术有限公司高级咨询顾问肖勇，是2008年奥运会IT特聘专家。 多年来，肖勇一直从事软件工程咨询方面的工作，同时他也在公司内部扮演着另外一个角色，就是做系统分析。从分析师的角度来看软件开发过程中遇到的问题，肖勇有他独特的视角和观点。 在制造业，要生产什么产品大家想到的第一件事情就是要建立一条生产线，然后通过生产线的完整体系来控制产品的交付。同样，在软件行业里也面临这样的问题。软件工业发展到目前的程度，缺乏一套能让软件生产的利益相关者协调工作的工作平台。 一方面，大家可以通过这个平台让软件需求方、设计人员、测试人员和其他相应的业务人员等方方面面的利益相关者在上面就自己关心的工作层面进行工作的协调。 “到目前为止我所看到的大量软件项目的失败或者延期，一个根本的原因就是在沟通体制方面有很大障碍，缺乏一套有效的沟通机制。” 肖勇说。 另外一方面，在支撑体系上也缺乏一套能够支撑工程往前推进的软件平台。因为只有在这个信息平台以及配套的机制建立后，利益相关者才能切实知道他在软件生产过程中所肩负的责任。 工作成果的复用也是一个问题。大量的软件企业积累了很多这种相关的资产，有些是隐形的、有些是显形的。由于这些利益相关者没有办法统一、协同地创建并管理软件分析设计的工作层面，同时架构的一致性难以维护，因此这些经验和成果很难复用和传承。 另外一个层面是架构层面，软件架构相当于软件的骨架，或者说是软件设计层面的灵魂部分，相当于音乐的主旋律。在软件的生产过程中，维系这个架构就像指挥能够控制音乐的主旋律一样。 映射到软件的设计过程中，大量的软件分析和设计人员在设计的过程中，往往不知道背后的商业理由是什么。架构发生变化时，这个变化如何很好地贯彻到后面的代码和实施、部署等一系列的阶段，就成为一个问题。 同时，在做迭代控制的时候，很难把握的是迭代的节奏，或者说是软件生命周期过程中的节拍。这个节拍的脉搏把握得不好，迭代构成就没有依据。在迭代的过程中，就很难去告诉利益相关者项目当前的情况是怎么样的，将走向何方？过程是否可控？ 肖勇做了八年的产品服务，从分析师的角度，他希望在目前的软件生产体系中有一套统一协同的工作平台，就像汽车生产线一样。 同时，他还希望软件开发的一些经验能够复用，就像麦当劳、肯德基能够在全球快速克隆，不变形地复制。在这样一套统一的平台下，知识、架构、经验能够贯彻，在不同的项目中传承。他说：“在我看到了Jazz之后，我认为Jazz在很大的程度上解决了这部分问题。” 肖勇：“希望软件生产体系中有一套统一协同的工作平台，就像汽车生产线一样。” 开发经理：流程就是生命 李璐：“开发经理最重要的一部分职责就是要清楚团队中的每一个人在做什么。” 作为IBM中国开发中心新兴技术研究院开发经理，李璐负责在软件测试领域的技术创新和产品开发。 一个曾经在开发领域、测试领域里工作的人，李璐在自己的职业生涯里有一些很头疼的问题。 她说：“一个开发经理最重要的一部分职责就是每天要清楚我的团队中的每一个人在做什么，每一件事情以怎样的顺序发生？我的客户是谁？我的需求是什么？需求以何种形式交付到系统里？根据这样的需求产生哪些文档？开发进程如何满足这些需求？每日构建的状况到底如何？有多少成功的构建？有多少失败的构建？基于这些构建，测试的曲线在哪儿？如何通过各种各样的报表汇总出这个结果，能迅速地传达给整个产品管理的团队，并且对这样的进展做出及时的反馈。” 李璐以前在长城集团的软件开发中心工作，那时候她遇到最多的开发问题和流程有关。那时候没有软件开发流程的概念，也没有一套被定义好的开发流程，大家只知道有工作就做。在没有流程的情况下，大家不知道在过程中存在什么样的问题，甚至说不清楚自己身上背负多少件需要解决的工作，这个工作在整个开发团队里的重要性是什么。 既然没有定义的标准，每个人认知别人工作的重要性和自己工作的关系没有一个统一的标准，作为团队就不能很好地解决各自之间的依赖性，使产品顺利交付，自然更谈不上标准化的问题。 还有资源配置不合理的问题，一个工作效率高的人可能很忙，他编的代码质量也很高，所以所有的事情都依赖于他做。可能有些效率慢的人做的工作比较少，但管理者没有办法挖掘在整个项目里有多少项目资源被发挥到极致，这都是资源配置不合理的典型现象。 对于大规模的软件开发，动辄上千人的规模，沟通成了首要问题。全球分布式的企业，大家不在同一个时区，语言也具有多样性。 只有保持大家互通信息，知道每个人在项目里从事什么角色，每个人在什么时候完成什么工作，和别人通过什么方式进行协作，才能保证在一个人完成了自己该完成的工作以后别人开始完成下一部分工作。大家叠加在一起，才可以顺利地完成项目。 从项目管理角度来讲，通常可以用MS（解决方案框架，具有一种分布的、能够提高责任性的项目管理小组方法）框架把所有的内容都列到表里，这样可以知道重要的开发任务分成几大部分，每个大部分有多少任务。但是最终还是要回到人的视角，人和人互相依赖的工作关系，这样的工具难以提供协作功能，让管理者得到及时的信息，每个人的工作状态发生了什么改变。 捕捉一种静态的人在开发工作中的信息是很容易的，但是要捕捉在一个动态的开发过程中人的变化很难。“能解决这个问题，是我们在基于Jazz平台进行开发工作的过程中得到的最大的益处。”李璐说。 配置主管：构建管理透明化 天宇朗通通信有限公司配置主管孙振芳具有四年的软件设计研发经验，三年软件配置管理经验，作为配置主管，他认为在软件开发中如何进行构建管理是一个难题。 软件构建的管理属于软件配置管理的一个重要部分，孙振芳根据自己的工作经验认为构建管理的重要性至少要占到配置管理的1/3。 传统的工作流程，有构建申请者，也就是真正需要构建的人，或者是开发人员，或者是集成人员，或者是软件经理。一般的公司，都有专人来受理构建申请者提出的构建。可以是通过电子邮件的方式，提出构建版本的要求。然后由构建工作人员构建到服务器上 去执行构建。 这时就产生了一个自动化的需求，希望能够由构建申请者直接去填写构建条件，然后去构建系统里申请构建，构建系统直接触发构建服务器，就减少了构建工作人员的工作量，把他们解放出来，去做更有意义的事情。 同时，构建申请者的构建申请处于一个等待构建负责人去构建的状态，构建的结果或是成功、或是失败、或是取消，构建状态的变化需要有一个平台给相关人员看到构建的进展。比如说，构建之后，需要把构建的结果交给测试人员。 也就是说，当构建成功的时候要告诉测试，接下来的工作由测试人员来执行。如果没有一个很好的信息反馈和协作平台，造成这个信息滞后，整体的开发时间可能会被耽误。 规模大的公司构建日志是非常复杂的，构建的机器也非常多。每个构建机器上存了很多构建日志，如果其他人员想很方便地查看，需要统一地把所有机器上的构建日志统一起来，提供一个平台让开发人员去看，甚至提供一些历史的构建日志。如果构建日志不能很好地保存，一些详细信息丢失，开发人员只知道构建失败了，但不知道为什么失败。 还有构建机器的管理，尤其是构建的排队问题很令人头疼。比如有10个构建，只有四五台机器，传统的做法是由开发人员直接在构建机器上执行构建，敲一些命令，启动构建。 资源不够的情况下，大家需要排队，需要员工加班去等能用的机器。“我们需要的是，让开发人员直接去机器里申请，构建资源自动领取工作，而不需要人为去等。如果我们能够实现多台机器一起去构建一个产品的话，我们的时间就会缩短到原来的1/3。” 孙振芳说。 “我们构建的终极目标有两点：一是要实现构建的自动化，尽可能减少人员介入；二是不同的角色要能够完美协作；三是信息通畅，没有停滞。这也正是Jazz平台的三大特性——协作、流程显示和自动控制、透明度。我想，Jazz平台肯定能解决构建方面的管理问题。” 孙振芳最后补充道。 孙振芳：“如果我们能够实现多台机器一起去构建一个产品的话，我们的时间就会缩短到原来的1/3。”