质量是个说不完的话题，因为质量无处不在。   

    但是很多公司很多的人仍然把质量眼光仅仅是放在项目的结尾处。测试是能提高产品的质量，但是项目过程中产生的策略漏洞有时是无法补救的，会导致最终产品明知有缺陷但为了顾全某些大局而不能进行修改。

    质量是过程，而不是一个点。

    软件项目如同盖大楼，软件的需求、设计、测试过程和资源就如同建筑中的调研、设计、原料、施工和验收。土地调研失误会导致地基不坚实，设计出错、偷工减料、施工马虎都会使建筑成为危房，而验收可以尽最大努力的弥补缺漏，让其外表看起来光滑完好，但是内部的坚实性只有建设人心里明白。这样的房子你会愿意买吗？

    测试就像是进行验收的监理，提出问题、验证问题的修改程度，能够改善产品质量，但改变不了错误的需求和狭隘的设计，推到重新做总是不现实的。况且，当项目管理混乱无序时，留给测试的时间可怜的只有一点点，又能指望产品的质量如何呢？所以，提高各个阶段的工作质量是必要的。

    高质量产生高效率，工作的输出是人力的行为，人的成本占项目的一大部分，应该重视人的能力。这里不得不说一下，开发人员很大部分是年轻人，随着近年学校扩招，输出了成倍的计算机相关专业人员，但是很多的教学质量和人才质量却大不如以前。缺少良好的引导，加上人心浮躁，工作质量可想而知。有些小公司以廉价收购这样的人才，却埋下了项目失败的隐患：分配的任务无法按期完成，提交的程序bug太多；过早被推上项目经理的职位，却没有管理和计划的意识，留给开发的时间很长测试时间却很短。其实，如果开发的时间需要很长，质量无法保证时，回测和修改的时间也会很长的，项目时间一样会超额。

    如何应对这种情况？

    建议重视个人培养、重视团队合作；重视公司人员的配备，特别是年龄的组成和明确职位划分，老程序员不只经验丰富，也更是公司稳重形象的代表，能够稳定人才动向。

    要改善产品的质量，还要改善工作中过程的状况。把质量检查当做是督促提高自身的导师，而不是批判大会的狼牙棒。中国人的障碍是面子问题，每到评审会时尤其是领导在场的情况下，顾及到面子、职位、关系，总是不能把问题直接的暴露出来。中文的评审是个敏感的字眼，带着尖锐，照英文的review的含义有些许的偏离。建议要想开好评审会，先对管理层做好review意义的普及，来自上级压力消除了，才能更好的进行。

    另外，根据公司不同阶段的发展，也要调整管理形式。我们公司是个反例的典型，从小做到大，从一个项目到同时进行多个项目。前期还算顺利，人数不断增多，但是两次超过100人后都没有再发展下去，出现多人离职人心不稳的情况。人才的流失、工作衔接不畅给公司造成了很大的创伤。管理方案要适合公司某阶段的要求，才能保证稳定，保证质量。

    2010年8月27日，召开了一年一度的IBM Rational软件论坛。终于不用坐在办公室里，去看看Rational的新动向。

    开场是销售总经理Daniel Sabbah博士讲话。既然是销售总经理，看来确是一场产品宣讲会了，于是一上午出现最多的词就是Jazz（本期Rational的主打平台产品）。大致理解Rational的新动向是在“成本、质量和风险的单纯的工程度量方法”的基础上，进一步以“软件和系统计量经济学为指导”加强管理的“可持续可度量”性。

    会场外是Rational本期主打的产品展台。回来在网上搜索了一下之前的Rational系列产品名单，没有看到本期产品，看来都是新开发的。

    下午分了七个专场的讲题，并没有明显的强迫推销，讲题听着还是蛮有收获的。下面就具体说说在整个大会上的见闻。都是听来的和自己的理解，可能有些地方不正确。

•     JAZZ平台
      面向软件交付技术的协作平台。关于JAZZ平台可以通过几个词体现：B/S结构、跨地域的团队协作、可对整个软件生命周期进行管理、实现软件交付的自动化管理。

    什么样的平台可以穿引整个生命周期？其实，JAZZ平台不是一个产品，而是一组集成在一起的产品。可理解为是Rational系列下的JAZZ系列。

•     JAZZ系列产品包括：

Rational Team Concert
Rational Team Concert for System z
Rational Team Concert for Power Systems Software
Rational Change Management Express
Rational Quality Manager and Rational Test Lab Manager
Rational Requirements Composer / Rational DOORS Requirements Professional
Rational Project Conductor
Rational Insight
Rational Build Forge
Rational Asset Manager
Rational Workbench for Collaborative Lifecycle Management
Jazz Foundation

    这其中包括开发管理、测试管理、变更管理、配置管理、度量等。一直以为Rational只支持传统软件过程管理，现在上述中的Rational Team Concert也可实现敏捷开发管理。

    其中，Rational Quality Managerment（简称RQM）是自动化测试管理工具，与其他流行的测试管理工具一样，大模块包括测试需求、测试计划、测试用例、执行测试、分析及报表，差距大概在具体功能和易用性上。
    Rational Insight被归类为绩效管理，实际是度量管理，即不只包括绩效。它正符合了本次论坛开场的主题：以计量经济学进行的度量。它能够自动获取项目生命周期中的数据，进行多方面的统计并展示。对于QA和进行过程改进的公司来说这是一个很有用的工具，QA不用再到处搜集不完整的数据设计表格，公司可以通过更多更广的统计信息来发现隐藏的问题以促进过程改进。源数据怎样进入Insight？可以通过JAZZ平台提供的系列管理产品，也可以外接到Project等管理软件中，Insight可以自动获取监控。总之，要想Insight的运作良好多半要靠管理过程的自动化。
    虽然Insight的意义很好，但现在还只是1.0版本，不包括分析功能，所以拿到了各种统计后的图形企业公司仍然不知道问题出现哪里。2.0版本还在开发，据说其中就会增加分析能力。当然，光靠软件的分析是有限的，关键在人的实时分析，那就是IBM咨询的业务了。
    再有个问题是JAZZ平台集成了这么多产品，强大到可以管理整个软件生命周期，价钱一定是不菲的吧。当时没来得及问，但个人觉得这系列产品中有些是雷同和矛盾的，如传统过程管理和敏捷管理，所以应该是可以分解卖的。

•     云计算
       云计算是Google在2008年提出的，两年之内IBM就已经推出了基于云计算的产品。IBM这么迅速的响应，看来以后的生活中少不了云计算，告别主机的日子指日可待了。

    关于云计算的CDL测试管理解决方案。Rational类似测试管理的品并列摆了好几个，没来得及问清楚，网上查了也不是很明白，这个云计算到底是具体产品，还是仅是解决方案。寻思着莫非JAZZ就是基于云计算的？但是又没有明确的说明。

    仅看到的云计算给测试管理带来的好处是，使测试环境的搭建和运行更快速更稳定，未来的意义是公司中不用再建立私有机房，不用为哪台服务器突然歇菜而停工。

    当然问题也是存在的，即安全性。如果你的公司数据是国家保密性质的，云计算服务暂时还是不适用。

•     Rational Appscan
       Appscan是一款自动化安全测试工具。最深刻的印象是“白+黑”，即分别进行白盒和黑盒层面的安全性测试。该软件的使用类似于杀毒软件，执行后会自动进行代码或界面的扫描，也会实时更新升级扫描的内容。可用于开发阶段的自测、测试阶段的自动化测试、交付后的审查测试、上线后的定期监控。对于有安全性要求的公司还是很有用的，可以节省人力和时间，避免一条条的测试和技术缺陷。
•     IBM Rational 行业框架
      IBM主流的咨询业务，主要是银行、电信、医疗方面，演讲的也都是成熟稳重级的。听着很受鼓舞，也是以后打算发展的方向，可最后印象最深的只有以RUP实现CMMI。。。

    服务人员说最后会把全部的演讲稿做成pdf格式发布到网站上，也没找到。。。

•     敏捷开发scrum
       一直以为蓝色巨人是传统开发模式的捍卫者，没想到它会有专门的一个会场讲解敏捷开发，并且有Rational Team Concert对其进行支持。虽然一直说敏捷开发难度大、不适用，但看来IBM对敏捷开始蛮有信心的。再或者是IBM的实验室模式，让拥护者为敏捷争取来的一块地，卖的好不好团队来承担，演讲者也都是蛮有朝气的。只是猜想。

    Rational的敏捷开发采用scrum方法，强调迭代的增量化，2-4周既完成一次迭代。scrum的要求总结为要高度迭代、高质量代码、高度的自动化测试、全员测试，强调需求驱动、测试驱动。

    为何施行敏捷开发失败的较多，看到这些条件就知道对团队的素质、过程的控制要求有多高。

    什么样的团队能施行scrum的敏捷开发。以本公司人员为蓝本抽样分析，队员起码要有2年以上开发经验并且是代码编写非常规范，最好是top10以内学校的计算机本科生或者起码要硕士级别的，有较强自我管理能力并且能在团队中承担两种以上任务的。为什么要求这么高，看看scrum的角色、工件和时间箱的概念就知道了，高度的控制需要高度的能力。所以要施行scrum，就要精心挑选队员、工具和合作方式，否则进度、质量难以控制，只会变得混乱不堪。

    会上有人问了施行scrum后如何实现cmmi。scrum与cmmi还是存在矛盾的，既然选择scrum就不要还想着cmmi了，想过只能说是给用户看的一个牌子，那就补文档吧。

     以上是本次论坛上的见闻加个人理解，难免有误，欢迎指正与讨论。