快速软件开发 学习笔记 之八
第14章 生产率工具
生产率工具代表了软件项目中Technology这一维。采用新工具可以成为提高税率的最快手段之一，但同时也是最具风险性的方式之一。
效率高的组织已经找到了既能降低风险，又能实现生产率收益最大化的良好方法。它们的策略是基于以下三个关键事实的认识：
l Productivity tools seldom produce the schedule savings their vendors promise.（生产率工具很少能够达到兜售它们的人所宣称的那种效果）
l Learning any new tool or practice initially lowers productivity.（学习任何一种新工具或新实践，在开始时都是以降低生产率为代价的）
l Productivity tools that have been discredited sometimes produce significant schedule savings anyway, just not as significant as originally promised.（先前表现并不怎样的生产率工具有时候倒也能极大地节约时间，只是这样的节约效果仍然达不到最初的承诺）
14.1 生产率工具的战略
有效地获取与使用新工具的战略应当包括下列一些基本要素：
l 尽早识别看上去有戏的新工具。
l 及时准确地评估新工具。
l 快速部署被证明确实有效的新工具。
l 避免使用被证明低效的新工具。
l 持续使用久经考验的旧工具。
| 最佳实践：Tools Group（工具组） 1. 指定一个人或一个工作组来负责软件工具信息的发布。根据组织规模的具体情况，工具组的成员可以是兼职或专职。但是，工具组的成员应该是组织中有一定地位和声望的技术人员，这样发出的建议才会被人采纳。 2. 工具组的职责在于： （1） 收集与生产率工具相关的信息。 （2） 试用生产率工具并对其进行评估。 （3） 对好的生产率工具，建议工程师们使用。 3. 工具组的定位是服务机构，而不是管理机构，因此它应该提出建议，而不是发布指令。 |
14.2 银弹综合症
银弹综合症是指天真地以为单独一项工具或技术就能够大幅度地缩减开发时间。在软件业中，患有银弹综合症的个人和组织不在少数。
怎样戒除银弹综合症？对软件从业人员来说，恐怕应该是要破除一厢情愿的幻想，要明白单独使用一种工具或实践只能对项目产生较有限的推动作用。只有同时采用多种有效实践，并把它们加以整合，假以时间的积淀，项目的生产率才能得到较大的提高。
第15章 Project Recovery（项目修复）
某些项目在项目开始很久之后才发现它们需要快速软件开发。有的项目可能已经超过了项目的早期时间节点，而有的项目可能是错过了它的最终交付日期。总之，项目是遇到了麻烦，并且需要一定的拯救措施。
本章中所提到的有的项目，它们偏离进度计划不是一点半点，它们急需帮助。这样的项目具有如下的特征：
l 没人知道项目会何时结束，而且多数人已经连猜测的欲望都没有了。
l 产品满是defect（缺陷）。
l 开发人员加班工作——自愿地或被迫地进行每周60小时以上的工作。
l 管理层无力控制项目进展，甚至无力准确地评估项目状况。
l 客户对开发人员交付承诺的软件不抱希望。
l 团队对项目进展采取守势。如果团队外的任何一个人向他们指出项目有麻烦时，开发小组就感到了威胁的压力。
l 开发人员、市场人员、管理人员、质量保证小组及客户之间的关系非常紧张。
l 项目正牌被取消的边缘，客户和管理层正在考虑这个问题。
l 开发团队的士气极度低落，开发的乐趣荡然无存，剩下的只是严肃和沉重。
对于如此一个千疮百孔的项目，小修小补根本无济于事。强有力的修复措施必不可少，本章就此作了描述。
15.1 Recovery Plan（修复计划）
本节将给出一个具体的可操作的项目修复计划，该计划是专为拯救那些深陷泥潭的项目准备的。
15.1.1 人员
1. 采取一切措施恢复开发团队的士气。恢复士气的最佳方式之一是采取一个象征性的行动以表明你把开发人员放在首位。要达到此目的的最佳方式之一就是牺牲一下你组织的某个神圣不可侵犯的规定。例如，允许开发人员比组织中其他人上班晚些，并让他们早点回家；给他们购买更好的硬件和电脑；允许他们休假。
2. 消除重大的人员问题，必须处理掉问题员工。
3. 消除重大的领导问题。在有些情况下，不力的领导是技术领导，在其他情况下，则可能是项目经理。下面是一些较有效的措施：
l 改变经理的老板。有时，经理也需要不同的领导。
l 把经理的角色改成参与型的。
l 为经理配备一名助手。根据实际情况所需，助手可以集中于技术细节，也可以处理一些行政事务。在极端情况下，助手甚至可以把经理的几乎所有职责接手过来。
4. 增加新手一定要审慎。
5. 充分利用开发人员的时间。给开发人员安排私人办公室，确保他们不要为组织的其他项目所干扰，让他们从无关紧要的工作中解脱出来。
6. 允许开发组成员各有不同。在项目后期，你应该容忍那些安静的和稳当的开发人员，他们不会站到英雄般的高度，但他们知道他们自己的角色。你所不能容忍的应当是那些英雄否定者，他们只会高声斥责英雄式开发人员想出风头。项目修复时的士气很脆弱，你不能容忍那些破坏开发团队士气的人。
7. 让开发人员自行决定开发节奏。缓和一下进度压力，给开发人员时间来考虑质量，进度其实就会自然而然地加快了。
15.1.2 过程
1. 识别并改正典型错误。观察一下你的项目，看看你是不是哪个典型错误的牺牲品。
2. 修正你的开发过程中出现的明显出错之处。出问题的项目一定是有意或无意忽略了使用软件开发的基本实践。
3. 创建详细的小型里程碑。在挽救一个挣扎中的项目时，绝对有必要建立一种追踪机制，以便你准确地知道项目的进展情况。这可以说是你剩余项目的关键。项目如果遇到麻烦了，就应当建立小型里程碑。
4. 在得出一个有把握的估算进度前，不要承诺新的进度计划。
5. 千方百计做好风险管理。
15.1.3 产品
1. 稳定需求。要想项目顺利结束，必须首先把需求稳定好。在这个阶段，通常需要撰写一份近乎完整的需求规格书。需求确定之后，就要禁止接受过多的需求变更。
2. 削减feature-set。毫不犹豫地删掉优先级低的feature。记住：在这个阶段，真正的问题是能否完成这个产品。
3. 丢掉垃圾。易出错的模块是导致项目工作量大增的重要因素。最好把它们扔掉再继续开发项目。
4. 降低缺陷数目，并要持续降低。开始使用一个“剩余缺陷图”，并每日更新。把注意力放在质量上是减少开发时间的方式之一。
15.1.4 找准时机
启动项目修复计划的最佳时机，可能不是你第一次意识到你的项目陷入麻烦之时。你必须确信你的管理者与开发团队都已准备好接受这个消息，而且做好了修复项目的准备。这是你必须一次做对的事情。
第16章 Outsourcing（外包）
Outsourcing是指把软件项目承包给一个外部组织，而不做in-house development（内部开发）。出于以下的原因，外包可能比in-house development节约时间。
l Reuse（复用）。专业的软件外包公司可以在该行业形成一定的规模经济，而一个单独的组织则做不到。软件外包公司会使用可复用的组件在短时间内为多家客户实现功能。
l 员工的灵活性。软件外包公司可能有更多的人手投入到项目中，或者有更愿意加班工作的开发人员。
l 经验。软件外包公司可能对应用领域或特定技术较有经验。
l 更好地制定需求规格书。当把项目外包时，专业的软件外包公司会要求获得高质量的需求规格书，而优质的需求分析总是能节约项目时间。
l 减少feature creep。软件外包公司对需求变更高度敏感，由此它们一般会拒绝不合理的需求变更，而减少feature creep总是能节约项目时间。
16.1 使用Outsourcing
16.1.1 软件外包项目的管理要点
有些组织有时求助于outsourcing是因为它们对管理in-house software development无计可施。它们理想化地认为干脆把项目外包出去，这样就能万事大吉。但现实却与之恰恰相反！当项目被外包到另一个城市甚至是另一个国家时，你也就失去了对项目进展状况可视性的控制，因此你也就必须加倍地敏锐和小心。一般来说，outsourcing比in-house development需要更富技巧的管理。以下是软件外包项目管理中的要点。
l 形成包括网络管理在内的管理计划。这份计划应该描述了你打算如何挑选承包方、合同谈判、开发需求、处理需求变更、跟踪承包方的进展状况、监控项目质量以及验收产品。
l 学习一点合同管理。表16-1列出了签订合同时需要考虑的一些问题。
l 把与承包方的沟通放在首位。应把与承包方保持定期（电话或碰面）沟通列入管理计划，即使看似没什么需要沟通的。
l 注意利用你自身的技术资源。应规划好多花点时间在产品规格的讨论上，还要规划好分配技术人力资源来解答承包方的问题和测试验收产品。
l 千万注意不稳定的需求。你的项目应该是需求明确且稳定的。把需求不明的项目外包，其结果往往得不偿失。
l 准备一套备用计划。软件外包项目有失败的风险，为应对外包公司不能如约交付产品，你应该提前规划，以便真出问题时可以把项目重新转回in-house development。
l 特别考虑把legacy-system reengineering性质的项目外包。一定要对遗留系统在被reengineering之后该如何处理需求变更作出规划。是由in-house developer来维护重新实现后的代码吗？由谁来负责修复缺陷和功能增强？
l 避免对外包项目采取双重标准。应该按in-house development的质量和进度标准来要求outsourcing项目。
表格 16‑1 外包合同方面的考虑
| l 除软件外，合同应说明要提供其它哪些工作成果，如architecture description、design description、source code、inline documentation、external documentation、test plan、test case、test result、quality metrics、user documentation和maintenance plan。 l 合同是否包括允许regular review和评价外包公司进展状况的条款？ l 是否已把详细的需求陈述作为合同的一部分？ l 合同是否允许需求变更？ l 谁拥有项目源代码的所有权？ l 谁拥有外包公司从其code library中提供的代码的所有权？ l 谁拥有客户方从其code library中提供的代码的所有权？ l 外包公司会从其code library中提供代码的同时也提供文档吗？ l 谁负责维护代码（包括由客户方最初提供的代码）？ l 如果外包公司负责修复缺陷，合同中是否说明了关键的修复情景和响应时间？ l 外包公司是否有权把为你公司开发的软件产品卖给其他客户？ l 如果你向外包公司提供了为加入到你的产品中的源代码（为你的产品所用），外包公司是否可以把这些代码复用到其它的一些产品中或者把这些源代码卖给其他客户？ l 如果外包公司破产了，谁拥有源代码的所有权？假如发生这种情况，可否把这些源代码由第三方暂先保存？一旦发生破产情况，客户方可以提取。 l 你是否需要为外包公司提供私有工具软件？而你对这些私有工具软件的权利受到保护了吗？ l 如果外包公司使用了工具软件来开发产品，在项目结束后这些工具软件也要交付给客户方吗？如果交付，那么谁拥有这些工具的所有权？ l 与外包公司一起工作的公司内部开发人员需要签订保密协议吗？外包公司这么做的用意是什么？这样是否会限制你公司将来开发自己产品的能力？ l 是否限制外包公司从你公司雇佣开发人员？ l 是否限制你的公司从外包公司雇佣开发人员（即使在外包公司已破产的情况下）？ l 外包公司是否要求包含他们公司名称的许可证信息在splash screen、about box，help screen或printed documentation中出现？ l 验收最终产品的标准是什么？谁负责决定验收？当验收出现分歧时，有什么机制来保护双方的权益？ l 如果产品是按许可收费的，许可收费如何处理？当产品版本升级时，外包公司是否可以提高许可证费用？如果可以，可提高多少？ |
16.1.2 外包合同种类
软件外包合同的基本种类分为：time-and-materials合同、fixed-price（固定总价）合同和no-cure-no-pay（按劳付费）合同。
l Time-and-materials合同是只要客户简单地说出需要什么东西，软件外包公司就会开始项目，直到圆满完成或客户不再出资为止。只要客户愿意出钱，软件外包公司就会根据客户的意愿对这件东西进行修改。Time-and-materials合同的好处是具有极大的灵活性，但缺点是这种项目经常超支。在很多情况下，软件外包公司会在开始工作之前要求得到大量的预付款（约50%），因此到他们开始超支时，客户会觉得自己已经无法撤销合同了。
l Fixed-price合同是软件外包公司向客户保证只用固定数额的成本开发出客户想要的东西，如果外包公司超支，那么多出的那部分由外包公司自行赔付。但是，客户为了得到这种保证，可能会比相应的time-and-materials合同多支出50%的成本。Fixed-price合同需要很详细规定客户的需求，而且当出现需求变更时，外包公司会与客户谈判以获得更多的时间和资金。Fixed-price合同需要一笔不小的预付款，因此撤销合同的代价也不菲。
l No-cure-no-pay合同是这样：客户与软件外包公司约定好项目的若干重大里程碑，当外包公司进行到约定好的重大里程碑时，客户就支付相应的款项，而如果外包公司无法到达某个重大里程碑，则客户方无需支付任何费用。与time-and-materials合同和fixed-price合同相比，no-cure-no-pay合同更便宜，所需预付款也较少（一般为20%）。其缺点是要求客户方一直处于积极跟进的状态。
16.1.3 Offshore Outsourcing（境外外包）
境外外包是指把软件项目外包给外国的软件外包公司。对于境外外包，有如下的问题需要注意。
l 沟通。应确保与外国的外包公司之间有顺畅的沟通渠道，还要注意确保语言差异并不是问题。
l 时差。时差有利有弊。如果需要实时的沟通，那么时差过大就会导致客户方或外包公司方的员工工作时间不正常。如果可以通过电子邮件来沟通的话，那么时差就反而是好处，因为外包公司方可以在客户方休息时回复邮件。
l 差旅。要为差旅规划出时间和经费。电邮和电话不能解决所有问题，面对面的会议还是需要的。
l 软件外包公司所在国的特点。你需要理解外包公司所在国的版权法、专利法和知识产权法。你还需要考虑外包公司所在国的政治经济环境和其它可能影响项目的因素。
16.1.4 外包公司评估
表16-2列出了在评估软件外包公司时应思考的问题。
表格 16‑2 外包公司评估问卷
| 管理方面的考虑 l 外包公司有什么能力兑现其进度和预算承诺？它在兑现承诺方面有何历史记录？ l 外包公司的当前客户（包括长期客户）的满意度如何？它有长期客户吗？ l 外包公司的项目管理能力怎样？它具有软件项目管理的所有方面（包括项目规模估算、成本估算、项目规划、项目跟踪和项目控制）的专业知识吗？ l 能对外包公司的保密措施完全信任吗？它是否还为你的竞争对手服务？ l 谁来提供产品支持？是你还是外包公司？你想要外包公司来提供客户支持吗？ l 是否有针对外包公司的未了结的任何法律诉讼？ |
| 技术方面的考虑 l 外包公司有什么能力来应对该项目的技术挑战？ l 外包公司的软件开发能力是否已被你公司的技术人员或第三方机构评估过？技术工作成果和开发过程是否都包括在这个评估当中？ l 外包公司在该应用领域的经验如何？ l 外包公司在该实现环境的经验如何？ l 外包公司的其它软件的质量是否可接受？外包公司是否有定量数据来支撑其质量声明？ l 外包公司的工作质量是否能够进一步提高？ |
| 一般方面的考虑 l 外包公司的财务状况是否稳定？如果外包公司遇到严重财务困难，会对你的项目产生什么影响？ l 外包公司是否有开发外包软件的记录？开发外包软件是该外包公司的主要业务吗？该外包公司对外包业务的专注程度如何？ |
16.2 管理外包的风险
表16-3表明了外包带来的风险及相应的化解措施。
表格 16‑3 外包项目的风险和化解
| 外包带来的风险 | 化解措施 |
| 项目进展状况可视性的损失 | 确保与外包公司签订的合同条款允许对项目进展状况进行及时和真实的评估。 |
| 专业知识流出客户公司 | 回答以下问题： l 对你的公司来讲，在这个领域保持开发软件的技术能力是否重要？ l 该软件当前赋予你的公司巨大的竞争优势吗？ l 如果现在公司决定放弃该领域的软件研发，今后还有机会重新进入该领域吗？ l 将来重新进入该领域的成本是多大？ l 你的软件是否包含商业机密或保密数据？ l 公司出售的产品是否基于该软件的私有特性？ l 你的公司的软件开发比起竞争对手来讲更高效吗？是否足够高效而可被认为是一种竞争优势呢？ l 你的软件产品的面市时间与竞争对手的面市时间相比是怎么样的？ l 你的软件质量水准是否高于竞争对手？ 如果对于大部分问题的答案都是“yes”，那么该软件项目应该是你公司的核心业务，把该软件项目外包并不符合你公司的长远利益。 |
| 士气的损失 | 不要将in-house developer愿意开发的软件项目外包。 |
| 失去对未来项目的控制 | 在制定合同时就要确保你对该项目下一步开发的控制权。 |
| 机密信息被泄露 | 一定要在合同中规定好哪些是机密的数据和算法，确保合同保证这些机密的知识产权受到认真的保护。 |
