第二部分 快速开发 1516章 完结

第二部分有效开发

第15章生产率工具

生产率工具对于开发者而言，诱惑力是相当大的，它也确实在快速软件开发当中扮演了重要角色。采用新工具可以成为提供效率最有效的手段之一，但同时也是最具风险的方法之一。

关于生产率工具，有三个关键事实：

l 生产率工具很少达到它的卖家宣称的效果。

l 学习任何一种生产率工具，在开始时都是以降低生产率为代价的。

l 之前表现不怎么样的工具，有时候也能极大的节约时间。不过第一条仍然成立。

1.快速开发中生产率工具的作用

没有银弹，软件开发中的次要复杂度和必要复杂度。

次要复杂度，是指在软件活动中，由人引起的问题。比如需求采集中的问题，语言和框架选择的问题，编程语言本身的问题等。这些问题是可以解决的。必须一些项目管理方法论，比如高级编程语言的出现等。

必要复杂度，是指软件本身要解决的问题而衍生出来的。比如软件包含三十个必要的功能，这三十个功能就是必要复杂度。

软件功能面临的问题，在于我们能够清除大部分次要复杂度，而剩下的必要复杂度无法改变。

良好的组织与管理，比起技术来，似乎是更加关键的因素。

2.生产率工具的战略

与常理相悖的是，工具的采用是一个长期的战略问题，而不是一次性的选择。生产率工具的战略包含以下一些基本因素：

l尽早识别有希望的新工具。

l及时与准确的评价新工具。

l快速部署被证明有效的新工具。

l避免使用被证明低效的新工具。

l继续使用久经考验的旧工具。

3.生产率工具的获取

以随机的方式获取软件工具的组织，大致将使投资被浪费一半。获取工具时常常碰到的问题如下：

l软件工具市场总是言过其实。

l获取到不好的工具后，往往会阻碍更多有效工具的获取。

l一些工具获取后，被放弃了。

l一些工具由于缺少培训，而没有得到充分利用。

l一些工具与现有的工具严重不兼容。

1.获取计划

等到需要的时候，才开始调研的组织，其等待时间太长了。对新工具的调研，评价与交付应该是一项常抓不懈的事情。

1.工具组

一个有效的方式就是指定一个人或一个工作组来负责软件工具信息的发布。他们的职责范围包括：

信息收集。

评价。

协调。一个公司的不同项目组可以试用不同的新工具，但如果不加协调的话，不同的组很可能就会试用同一个新工具。对于组织而言，这是非常低效的做法。

传播。

2.建立工具组的风险

建立一个集中的工具组会产生一些风险，其中最坏的就是工具组控制过多。工具组应当只是收集发布有效的工具信息，然而在面对快速开发项目时，工具组需要警惕僵化成一个官僚化的标准组织。

建立工具组的初衷是服务机构，而不是标准组织。处于项目一线的人才清楚什么是他们最想要的。工具组可以推荐工具，给出意见，提供帮助，但他们绝不能替项目组做出决定。

另外，工具组的成员，他们说话必须非常有分量。如果工具组都是不被重视的人，那么他们的建议也得不到重视。

2.选择标准

预计收益。对于快速开发项目，预计收益的度量是苦难的，而且必须是保守的。

供货商稳定性。

质量。

成熟度。

培训时间。

适用性。

兼容性。

发展规划。

定制选择标准。

3.承诺

一旦工具选定之后，你就需要坚持使用。不要东张西望。因为你每一个项目，每一个工具都会遇到一次大障碍。当你碰到障碍时，你必须意识到，在项目进行中更换工具，将预示着很有可能你将再次碰到大障碍。

4.生产率工具的使用

如何实现生产率工具与项目间的结合，对提高快速开发能力同样有着重大的影响。

1.何时使用

软件项目通常存在着熟悉新工具的学习曲线，和因新工具而带来生产率收益之间的平衡。

从单一项目的角度去看，如同上图所示，如果你计划在项目A的时间长度内完成项目，就最好不要使用新工具。如果你计划在项目B的时间长度内完成项目，就可以尝试新工具了。

从组织的角度去看，考虑的问题就有所不同了。如果你拥有较多的类似项目A的短期项目，你在每一个项目中都不必引入新工具，但是为了组织的长期发展，你有时就不得不引入新工具了，尽管这个工具对某一单个项目并非最合适，但这个新工具是对组织来说，是存在长期生产率的提高的。

因此，你可以为快速开发得出两条结论了：

l从长期考虑，你必须经常性的引入能提高生产率的工具。这种引入并不能单纯的从某一个项目的基础来看待。

l从短期考虑，快速开发项目并不适合引入新工具。所以你要尽量在对时间要求不太高的项目中引入新工具，以吸纳新工具的学习曲线。

2.培训的重要性

3.进度缩减的期望值

软件项目通常存在着熟悉新工具的学习曲线，和因新工具而带来生产率

5.银弹综合症

第16章项目修复

往往有些项目在进行了很久之后，才发现需要快速开发，而且通常都是在延误了里程碑之后。这些项目通常有以下一些特征：

l没人对项目何时结束有概念。

l产品满目疮痍。

l开发组人员工作超时，加班严重。

l管理层已经无法控制进度。

l客户对开发组不再抱有信心。

l开发人员，质量保证，市场人员，客户与管理层之间的关系非常紧张。

l开发组士气低落。

对于一个如此千疮百孔的项目，小修小补已经无济于事了，强有力的措施必不可少。本章中将对这些措施进行讨论。

1.一般修复方案

对于想挽救项目的人来说，一般有三个基本方式可以选择：

l缩减项目规模。

l把注意力放在短期改善上，以提高生产率。

l面对软件不可能按时完成的现实，放弃原计划，着手准备危害控制。

通过将三个方式结合，我们得到了第四种方式：

l扔掉一些功能，尽量提高生产率，抛弃原计划。

本章将主要讨论第四种方案。

1.修复理念

在项目修复模式中，注意力很容易可能放在错误的问题之上，比如一些具体项目的具体问题，而忽略了本质问题。

项目陷入困难的首要原因就是控制不力。而想要收回一度放弃的控制权是很困难的。

2.修复计划

本章中讨论的计划，是专门为那些深陷泥潭中的项目准备的。假如你的项目还不至于那么惨，你也就可以用一个不那么彻底的方法。

本章中讨论的计划，与支撑起项目快速开发的四维相当一致：避免典型错误，采用最基本的开发实践，风险管理，寻求面向进度的实践方式。

第一步，准备工作。

l评估你的处境。

确定截至日期到底有多关键，找出到底什么才能满足它。你或许会发现真正的硬性期限根本不存在。

l应用W理论分析。

为了获取成功，你的开发组需要什么，客户需要什么，为了维护良好的客户关系需要什么。过去的已经过去了，你要着眼于现在，如果无法找到每个人根据自己的价值标准，都能觉得成功的方式的话，就干脆结束这个项目。

l自己做好修复项目的准备。

你需要让开发组和管理层都知道，项目如果按照以前的做法，显然是于事无补的。想挽救项目就必须有大举措。如果人们不愿意采取重大举动，就表明你已经输了，不如结束项目。

l问问你的开发组需要什么。

向你的开发组每一个成员询问至少五种拯救项目的观点。然后对这些观点进行讨论。

l变得现实一些。

如果你处于项目修复模式，你的开发组极为需要的是清醒的，现实的项目领导。在你没有一个很好的理由来确认一个日期之前，千万不要承诺。

第二步，人员。

人员是快速开发中最重要的杠杆支点。在进入过程和产品这两个维度之前，一定要把人员基础打的牢固一些。

l采取一切措施恢复开发组的士气。

士气对于开发有着至关重要的作用，而在项目修复期间，恢复士气才是正确的问题。

恢复士气最佳的办法之一，就是采取一个象征性的行动，来表明你把开发人员放在了首位。要实现此目的，最好就是牺牲一个组织上神圣不可侵犯的事物或观点，想公司表明公司是位于员工之后的。

l确保你已经为开发组创造了保健类因素。

比如去掉过多的进度压力，改善恶劣环境，剔除管理上的行政臃肿，或其他不利因素。

l消除重大人员问题。

开发组对领导最常见的抱怨就是，他们很少过问组织内有问题的员工带来的麻烦。如果你觉得你的组里有这样的人，你就要勇敢的面对并且处理好。

l消除重大领导问题。

一个将项目带到灾难边缘的领导人，不可能做出任何重大举措，将项目引向成功。当你发现项目领导人有问题时，撤换是一个方式，但并不是唯一的方式，你可以尝试一下方案：

改变领导的领导。

把领导的角色改成参与型。

为领导配备一名助理。根据情况，让助理来处理具体业务，领导只需要关注全局问题。

l增加新手一定要谨慎。

牢记brooks法则，向一个已经延误的项目中增加新手，无异于火上浇油。不要盲目的增加人手。

其实这个问题，关键点在于项目剩余的任务，还能不能继续分解。如果能分解到新人的加入不影响其他人，你就可以放心的加人。

l充分利用开发人员的时间。

有很多方式可以集中开发人员的力量：给他们单独的办公室，确保他们不被行政事务打扰，

l允许开发组成员有所不同。

总有人会起来应对项目修复的挑战而成为英雄，也总有人觉得英雄太累而不愿意全身心投入，那都没有关系。在项目后期，你应该容忍那些安静而稳定的员工，他们不可能达到英雄的高度，但他们知道自己的角色。但是不能容忍那些斥责想成为英雄的人，他们对于士气的破坏力是巨大的，而项目修复时期的士气是宝贵的。

l观察开发人员的节奏。

第三步，过程。

识别，并改正典型错误。以下是一些需要问的最重要的问题：

产品定义是否改变？

项目是否存在设计不足而导致的隐患？

目前是否有准确最终项目状态的管理控制？

是否有为了进度而牺牲质量的行为？

截至时间是否现实？

人们工作是否努力？

是否有采用了全新的技术而浪费的时间？

是否存在有问题的员工，拖累了开发组和其他人？

l修正明显支离破碎的开发过程。

l创建详细的小型里程碑。

在项目修复期中，绝对有必要建立一个追踪机制，以便你准确地知道项目进展情况。

里程碑必须具有小型性，二元性和彻底性。小型性是指里程碑可以在一两天之内完成。二元性是指里程碑要么完成，要么未完成，不存在中间情况。彻底性是指你完成最后一个里程碑时，项目也就完成了。

l根据里程碑的完成来安排进度。

为每一个里程碑设置完成日期，千万不要打加班的主意。最好这样安排进度：开发人员如果在一个小型里程碑上落后了，那么他们最多当天加一下班就可以完成。这样就能保证项目按照计划逐日进展。

l细致地追踪进度进展情况。

如果设置了里程碑而不跟踪的话，相当于没有。绝对要保证开发人员在小型里程碑上的二元性，只有完成和未完成，99%也不叫做完成。绝不能让开发人员在小型里程碑上偏离正轨。

l记录里程碑未完成的原因。

记录每一个里程碑未完成的理由，这样就能从中间发现一些潜在问题。

l短期之后再调整，1周或2周。

如果开发人员总是比里程碑慢半天的话，1周或2周之后就可以开始调整了。如果开发人员需要7天来完成4天的工作，就把以后的工作量乘以7/4。不要幻想在以后把时间补回来。

l在得出一个有意义的进度前，不要固守一个进度。

不要把新的进度给到领导，因为你需要时间才能掌握和校正进度，这个进度需要计划，校正，再修改，再校正的过程。

l不辞辛劳的进行风险管理。

要根据第五章的风险管理来集中进行风险管理。创建出十大风险清单，并坚持持续监控。

第四步，产品。

l稳定需求。

如果在整个产品生命期中需求一直不停变化的话，你就没有必要再去找其他原因了。项目顺利结束，必须先把需求稳定好。

l修正特性集。

要毫不犹豫的删掉优先级低的功能和特性。

l评估你的政治地位。

如果你更多地陷入了政治漩涡而不是产品开发，本章中讨论的修复计划的作用就极为有限了。

l去除没有用的垃圾。

找出产品中每个人都知道的，质量极其低劣的部分，仍掉它们。

l降低缺陷数目，并持续降低。

当我们遇上进度麻烦的项目，通常对进度和范围非常感兴趣，而自然就忽略了质量。

l达到一个可知的，良好的状态，并在此基础上继续。