应用软件开发与维护中的精益方法

    受到应用软件开发和维护高成本的困扰，很多公司将一半以上的应用软件开发业务离岸外包到低成本地区，重新谈判外包项目的费用，以及严格新项目的管理。尽管如此，开发和维护应用软件的成本目前已经占到IT平均预算的一半以上，而且所占比例继续在增加。劳动力成本占到应用软件开发成本的80%以上，因此，很多公司已经尽量减少开发维护人员的数量，或降低劳动力成本。现在它们必须重点提高开发和维护人员的工作效率。过去，很多公司尝试了很多方法，结果喜忧参半。经典的制造业精益方法从生产流程中寻找并消除浪费，运用此方法的很多公司在几个月内就取得了显著的效果。
    尽管精益原理最初运用于制造环境，但它越来越多地被运用于服务行业，特别是使用很多日常流程的服务行业。应用软件开发和维护成为精益方法的主要应用对象之一，不仅是因为它涉及到大量有优化潜力的流程，而且因为各组织之间在生产力上存在的巨大差异，这表明有些组织的效率远远低于其他组织。根据我们的经验，将精益生产的原理运用到应用软件的开发与维护能够将生产力提高20%-40%，并同时提高执行的质量和速度。
    制造环境中每种类别的浪费都能在应用软件的开发与维护中找到。应用软件的开发与维护可以被想象为按照业务要求开发新应用软件的工厂。对应用软件要求的变更是开发与维护过程中产生浪费的一种常见来源，这种变更的要求引起了精益诊断中发现的许多经典问题：设计师重新书写他们的规范、编程员等待规范稳定、由于测试环境反复重新设置，造成测验员的产能浪费，以及大量积压的未能满足的要求。就像在制造环境中一样，系统地消除这些浪费来源能够提高应用软件的开发与维护过程中最终产品的交付时间、质量和生产效率。
　　就像每种浪费因素在应用软件的开发与维护中都能找到一样，每种消除浪费的传统原理也能应用到应用软件的开发与维护中。
    流程处理通过协调产出节奏与生产流量，降低产能过剩或过多库存。软件发布计划有助于对项目进行优先排序，能够防止为满足新要求而引起的延误中固有的浪费。
　　负载平衡迫使公司充分利用多个地点的开发人员，以及外部供应商。
　  标准化在大多数应用软件开发型组织中很普遍，但它可以被更加广泛地加以应用，以减少以临时的方式定义要求时导致的浪费。
　　根据项目复杂度对项目进行细分帮助项目经理得到适合项目的资源，避免为简单的任务提供不必要的管理费用，从而消除浪费。
　　质量的负责方应该不仅局限于测试组，应该扩大到业务部门、设计师，以及编程员和测试员。不幸的是，在大多数应用软件开发团队中，端到端的质量负责制还是分散在多个缺少沟通的职能部门中，这与端到端的业绩激励措施几乎脱节。
　　所有这些原则不仅需要流程的变革，还需要行为的变化和新的管理工具。例如，为了改善项目需求的沟通方式，业务部门必须让IT部门使用商业专家资源，但是在更迫切的优先任务面前，IT部门对这些专家的使用经常要让位。与之类似，在灵活的人员配置体制下，应用软件的开发与维护经理必须共享人力资源。这是一种可能会遭到个别经理排斥的做法，因为他们习惯于在多年内依靠某些员工。因此，向精益方法的转型需要技术系统、行为体系和管理系统同时进行变革。
　　向精益技术的转型需要投入大量时间、高管层持续的努力和不断对激励措施和指标进行修改。实施精益哲学是一项长期的目标，虽然有些项目能够立竿见影，但需要多年才能让新方法成为公司文化的核心组成部分。
1、运用精益原则
向精益方法转型的第一步是诊断阶段，以评估应用软件的开发与维护流程的浪费程度。由于大多数ADM组织没有对浪费进行追踪，因此，这种评估基于访谈和询问信息和材料如何在系统中移动的问卷。按精益技术的语言，这种诊断方法被称为“材料和信息流分析”，它的一个目的是找出多少时间是有效率的，多少时间是被浪费的。然后对浪费的时间进行分析，以找到浪费的根本原因，并确定提高生产力的机遇。
一家对应用软件开发部门开展向精益方法转型的金融机构发现了应用软件维护内的两个主要的浪费致因。首先，定义项目要求的流程混乱低效，反复的次数要比高效组织多。IT部门缺乏标准的流程，不能获得维护请求中业务要求的详细描述，因此，开发人员必须反复找到业务部门来澄清业务要求，这导致了开发周期的延误，以及大量的返工。此外，还没有对项目进行优先排序的明确而有效的方法。当业务部门提出特别请求时(例如，紧急任务)，开发人员不得不将工作重点从一个应用软件转移到另一个应用软件上，并且一些项目在完工前就夭折了。应用软件的开发与维护部门衡量项目的成本和人员配置，而不检查浪费情况，并且没有提高生产力的具体目标。似乎缺乏足够的质量负责机制和激励个人投入更多精力的措施。
诊断阶段之后，该金融机构决定推出试点项目，学习实施精益精神的方法，并为在整个应用软件的开发与维护组织内推广精益方法营造动力。试点项目经理根据诊断阶段的发现开展工作，决定应用三项能够减少浪费的精益原则：为改进的路径重新设计流程、平衡各工作组的工作负荷，以及端到端的业绩管理。
2、重新设计流程改善工作路径
在试点项目中，试点小组重新设计了应用软件维护流程，通过整个系统路径，改善工作流程。首先，他们制定两月一次的软件发布时间表，根据现有的资源(设计师、编程员和测试员)制定清晰的步骤和固定的人员安排。明确规定了业务部门提交最终要求的最终期限，以及完成代码编写和交付应用软件的日期。这种可预测的时间表让业务部门更好地计划目前和未来的软件发布，并减少在最后时间提出紧急请求情况的发生。
    然后，项目小组废弃了对项目进行优先排序的临时方法，制定了正规的流程，该流程包括业务部门和IT 部门之间定期召开会议进行交流。项目小组还制定了一套处理特殊请求的正规程序，例如，可能在截止期后发出的高优先级变更。
3、平衡各工作组的工作负荷
试点方案基于更加灵活的工作小组设置。软件开发人员和测试人员接受交叉培训，以便让他们能够在全公司范围的项目上工作，而不仅局限于负责的项目小组。此举使项目经理能够更加有效地使用人力资源。例如，当一个项目小组特别忙时，它可以从其他资源充裕的小组中借调软件开发人员或测试人员。项目经理还能够利用离岸资源，以及第三方供应商的资源，满足需求高峰时的要求，而无需在较高成本的地区雇用更多人员。
4、管理整个流程的业绩
    建立在项目小组和个人层面的新业绩追踪指标侧重衡量和减少浪费。一套新的管理业绩板-特别是一份追踪业绩表现，凸显问题区域的电子表格-能够帮助项目经理在问题发生之前确定潜在的问题。在一个案例中，项目经理们发现某项任务的用时将要超过预计的时间，因此他们对软件开发人员的工作负荷进行了重新分配，将其对整个项目的破坏减少到最低程度。追踪个人的业绩表现能够鼓励软件开发人员承担更多的任务，因为现在他们所作努力的可视性更高了。
这项试点取得的成果超过大家的预期，在不到两个月内，目标应用软件维护部门的生产力提高了40%之多。而且，IT部门对口的业务部门对流程更加满意，员工的士气得到了提高。在试点成功后，公司在第二年把流程再设计、负荷平衡的工作小组以及业绩管理系统全面推广到其他应用软件维护小组。此外，试点的变革骨干将试点的成果推广到IT的其他部门，包括新应用软件的开发和基础架构的建立，进一步扩大的该变革的影响力。
流程再设项目的优先项在各种金融行业中不尽相同。
5、克服顽固的阻碍
将精益方法推广到应用软件开发组织是一项耗时两到三年的全面转型。在与不同行业内30多家公司的首席信息官和高级经理的讨论后，我们发现三种挑战最难克服：改变行为、将工作重点从具体项目扩大到普遍原则，以及制定正确的激励措施。
可能最难的挑战是改变行为和说服普通员工和经理们相信精益方法的价值。说明变革必要性的关键是在试点项目中取得积极成果，试点项目通常在愿意变革的部门中展开。在前面讲述案例中，该金融机构在一系列公司会议中宣传试点的积极成果，为进一步推广获得了支持和动力。在另一家公司中，管理层强调试点项目重要性的方法是将一位高级经理任命为向精益方法转型的项目经理，并直接向首席信息官负责。该公司同时组建特别小组，帮助在全公司内实施精益项目。
普遍容易犯的错误是注重精益实施的具体细节，而忽略了广泛应用的精益原则。在上面提及的金融机构中，两月一次的软件发布时间表就是一种具体的变革。两月一次的发布时间表在产品上市时间较短的环境中可能不是最合适的，但是，其基本原则¬—即建立一定的可预测性，消除临时需求所造成的延误——仍然适用。按照项目的复杂度和灵活性对项目进行细分，能够帮助IT部门确定合适的实施计划，以便和业务目标相一致。
如果缺乏确保变革实施的适当指标和激励体系，转型本身就不可能持续下去。在应用软件开发中，“功能点”衡量项目所获得的投入水平。一项成功的向精益方法转型的项目需要新的指标来找出浪费，并制定减少浪费的目标。