快速软件开发——项目修复(笔记)

陷入麻烦的项目的一些特征

• 没有人对项目何时结束有一点点概念，而且绝大多数人连猜测的欲望都没了。
• 产品满目疮痍。
• 开发组人员工作超时，每周多余60多个小时——或者是在非自愿的情况下，或者是同事间引发的压力下。
• 管理者已经无法控制进度，甚至无法准确评估项目的状态。
• 客户对开发组能否交付承诺过的软件不再抱有信心。
• 开发组对项目进度采取了守势。如果组外的任何一个人向他们指出项目有麻烦时，开发组就感到了威胁的压力。
• 开发人员、市场人员、管理人员、质量保证小组及客户之间的关系非常紧张。
• 项目正处于被取消的边缘，客户和管理层正在考虑这个问题。
• 开发组的士气极度低落，开发的乐趣荡然无存，剩下的只是严肃和沉重。

理念

想修复项目，必须在获取项目的“控制权”的前提下，同时着手于人员、过程和产品。根据项目情况，果断采取措施，小修小补只会影响团队士气。

人员

• 采取一切措施恢复开发者士气，采取一些象征性的行动以表明你把开发人员放在首位。
• 消除重大的人员问题，处理影响员工士气的人员。
• 消除重大的领导问题，处理好行政方面的事情，可以给经理配备助手。
• 尽量不要添加新手。
• 充分利用开发人员的时间，帮他们排除环境干扰，避免无关紧要的工作，并减少私人的停工时间。
• 允许开发人员的不同处事、工作风格，但不容忍高声斥责英雄式开发人员想出风头的英雄否定者，不允许破坏团队士气的人。
• 观察开发人员的开发节奏，给开发人员时间来考虑质量，进度其实会自然而然地加快。

过程

• 识别并改正典型错误。
• 修正明显支离破碎的开发过程，找到出问题的“根本”原因，并解决。
• 创建详细的小型里程碑。里程碑必须具有小型性：必须在1~2天内完成；二元性：要么完成，要么没完成，不存在完成90%的情况；彻底性：最后一个里程碑完成，意味着项目也就结束。
• 依据里程碑的完成来安排进度，当前的里程碑当天完成，没完成可适当加班完成，已完成可提早下班回家。在安排里程碑的进度时，不要把开发人员的加班时间计算在内，那样只会自食恶果。
• 细致地跟踪进度进展状况，确保已完成的里程碑是确实“100%”完成。保证小型里程碑在进度上偏离正轨。
• 记录里程碑未完成的原因，可以发现一些潜在的原因。
• 在一个短的时间以后再调整——1周或2周。如果开发人员总是比计划的里程碑慢半天，那便需要校正开发人员的开发进度。如果开发人员需要7天完成计划4天的工作，那就把余下的工作量乘以7/4。不要想以后把时间补回来，你肯定补不回来！
• 在你得出一个有把握的进度前不要对一个新的进度计划做承诺！
• 进行风险管理要不辞辛苦。每天进行风险例会，发现的问题要做出及时的决策。

产品

• 稳定需求。确认可接受需求集，并禁止接受过高的变更。
• 修正特征集。删除掉优先级较低的性能，定义一个最小的功能集。可以把优先级低的功能放在以后的版本中。
• 评估你的政治地位。设法排查政治上对项目造成的干扰。
• 去除没用的垃圾。找出产品中资料极低的那些部分，不要可惜，立刻删除重新设计。不然项目会被这些东西一点一点磨死。
• 降低缺陷数据，并要持续降低。
• 达到一个可知的良好状态，并在此基础上继续。使产品始终处于可构建和可测试的状态。

找准时机

启动项目修复计划的最佳时机，可能不是你第一次意识到你的项目陷入麻烦之时。你必须确信你的管理者与开发组都已准备好接受这个消息，而且做好了修复项目的准备。你要抓住展示出修复计划的时机，避免“狼来了”情况的发生。

总结

接手修复一个支离破碎的软件开发项目的确是一个挑战。

• 修复工作不是靠加班加点来实现的，而是通过鼓舞士气来加速的；
• 把需求搞稳定是修复的先决条件，如果需求还在变化，修复是不可能实现的；
• 根据需求进行详细规划，得出一个现实的进度计划，任何冒险的计划都会导致修复的失败；
• 采用小型里程碑技术有效跟踪计划，使其不偏离轨道，是修复实现的保证。