《Rapid Development：Taming Wild Software Schedules》阅读（三）

第二部分 快速开发

第六章 快速开发中的关键问题

1、进行快速开发地前提是“避免经典错误”、“掌握软件开发的基本原则”和“风险管理”。

 

2、没有放置四海而皆准的方法——根据具体项目找到合适的快速开发方法。

 

3、当选择快速开发时，判断好 是为了加快开发速度，还是为了减小风险，因为两个不能兼得。

 

4、期望与现实：学会识别用户不切实际的期望——预计计划完成时间与实际完成时间之间的差距造成了开发速度慢的感觉。

 

5、如何去除开发速度慢的感觉——对项目的计划进行重新定位，修正计划完成时间。

 

6、时间花费在哪里？

    （1）在开发过程中，只有35%的时间是被有效利用的，剩余的65%的时间基本上都是在放在了无效的工作中，比如修复错误。

    （2）常见的几个浪费时间的地方：

        a、返工——前期工作不足造成后期花费大量的时间去修复！

        b、功能蔓延——在项目中25%的需求会发生变化，但是对本质的需求不进行控制会造成需求的大量蔓延，直接影响开发进度！

        c、无限期的需求定义——需求定义没有往往会占用很长时间，避免这一问题的比较好的方法有联合应用开发、阶段交付、渐进原型和不同的风险管理！

        d、模糊的项目前期——对前提的时间点没有准确的规定！

7、开发速度的权衡——进度、产品和费用之间的权衡！

 

第七章 生命周期计划（lifecycle planning）

1、瀑布模型（pure waterfall）是所有生命周期模型的始祖，尽管它存在着各种问题。

    （1）主要问题是 缺乏灵活性。

 

2、瀑布模型是文档驱动型模型，即由文档驱动从一个阶段到下一个阶段。

 

3、 编码修正模型（code-and-fix）不是很有用，但是却是用得最多的，因为当你没有采用特定模型时，你采用的就是“编码修正模型”。

 

4、编码修正模型的两个优点：

    （1）不需要什么成本：除了编码工作之外的成本，没有其他成本；

    （2）只需要极少的专业知识。

 

5、螺旋模型（Spiral）：以风险为导向的模型，把一个项目分解成若干个小项目，然后定位小项目中的风险。    

    （1）唯一的缺点就是太过复杂。

    （2）最大的优势就是随着时间的增加，风险逐渐减小。时间和资金花的越多，风险越小，这正是快速开发所需要的。

6、经过修改的瀑布模型

    （1）生鱼片模型（sashimi：waterfall with overlapping phases）

        a、传统的瀑布模型允许在阶段结束进行检查时存在最低限度的重叠，而生鱼片模型建议的是一种大幅度的重叠。

        b、存在的问题——因为阶段重叠造成里程碑不明确，很难进行精确的过程追踪，并行地执行活动可能导致无法有效沟通，以及效率低下。

    （2）具有子项目的瀑布模型（waterfall with subprojects）

        a、 传统的瀑布模型的另一个缺点：必须完成所有的架构设计后才能开始进行详细设计，在详细设计全部完成后才能进行编码和调试！

        b、拆分子项目的模型的缺点：相关性无法预料。可以在架构设计时，或者详细设计完成后进行子项目拆分，排除依赖性。

    （3）降低风险的瀑布模型（waterfall with risk reduction）

        a、瀑布模型的 另一个弱点是必须在架构设计之前，完成地定义需求。看似很有道理，但是现实中很难实现！

        b、解决办法：在瀑布模型顶端引入能够降低风险的螺旋（spiral）

   

7、渐进原型交付（evolutionary prototyping）

    a、从开发系统概念开始项目，逐渐地向客户展示设计的原型，根据客户反馈继续进行改进，再次交付原型，直到双方满意为止！——做的是 原型交付！

    b、 缺点：不能确定开发一个令人满意的原型需要多少时间！！

8、阶段式交付模型（Stage delivery）

    a、 持续地、在在确定的阶段向用户展示软件！而不是在项目结束的时候一下交付全部软件！

     b、缺点：如果管理层面和技术层面没有细致的规划，工作就无法进行！

    c、建议：管理层面上——规划交付的阶段对用户有意义，工作安排上包成开发人员能够按时完成开发；

            技术层面上——确保各个组件之间的关联性，确保顺利完成阶段交付。

9、面向进度设计模型（design-to-schedule）

    a、与阶段交付模型（stage delivery）类似，都是连续地阶段规划开发产品。

    b、差异是：面向计划的模型在开始阶段不必知道究竟要达到什么目标。—— 保证能够在某一时间点进行产品发布！

    c、模型的 关键点： 区分好系统特性的优先级，然后根据优先级进行规划各个开发阶段！

    d、缺点：因为不知道目标，会造成浪费时间架构、设计不必要的特性！

10、渐进式交付（evolution delivery）

    a、渐进原型交付和阶段交付的结合体！综合了两者的优点！

    b、渐进原型和渐进交付的区别：前者关注点在原型交付，后者在核心功能！

11、面向开发工具设计（design-to-tools）

    a、只有在现有软件工具支持下才开发某些功能，否则就放弃这些功能。软件工具特指代码库、类库等。

    b、 优点：可以和其他模型一起使用！

    c、 缺点：失去对产品的控制，不一定能够实现全部的功能！

12、直接购买商业软件（commercial off-the-shelf software）

    a、当想要开发软件时，可以选择直接购买！

    b、优点：可以直接使用！

 

第八章 估算（estimation）

1、软件开发者面对着 估算准确性和项目控制的权衡及选择。

 

2、准确的估算时项目快速开发的基础！

 

3、不能提供人们想要的准确估算的原因？？

    软件开发是一个不断改进的过程，开发过程中产品的不确定性导致了估算的不准备！

 

4、与客户之间的合作：给客户提供尽量准确的估算信息。

 

5、项目估算时困难的，可以按照以下三个步骤进行：

    （1）第一步：项目规模估算（代码行数或功能点 ）——是下一步工作量估算的基础

        a、进行项目规模估算时的建议

            ·避免没有准备的估算——不打无准备之仗；

            ·给估算留出时间，并做好计划——估算也是要花费时间的；

            ·使用以前项目的数据——站在前人肩膀上才能走的更远；

            ·使用基于开发人员的估算——没有参与就没有发言权；

            ·走查估算——进行走查会议，统一个人估算差异；

            ·分类估算——把项目分成不同类型模块，然后进行估算；

            ·进行低层次的估算——检查越仔细，估算越准确；

            ·不要忽略普通任务——普通任务也是任务；

            ·使用估算软件——事半功倍，更准确；

            ·使用不同估算方法，然后比较差异——比较才能改进；

            ·随着项目推展改变估算准则——变化的才是永恒的。

    （2）第二步：项目工作量（人月）

    （3）第三步：项目计划（多长时间）

    （4）提供某一范围内的估算，并随着项目推进，实时改进项目估算。

 

第九章 进度计划（scheduling）

1、如何定制计划才能有利于快速开发？

    营造良好的开发氛围，摒弃草率和易错的决策机制，倡导计划有效性、设计合理性、质量保证的省时性。

 

2、产生过分乐观的进度计划的根源？

    （1）为了赶在某一特定时间发布产品；

    （2）故意缩短进度计划；

    （3）后期新功能的加入使进度计划变得过分乐观；

    （4）进度估算本身不够充分。

3、过分乐观的进度计划产生的危害？

    （1）丧失了计划的精确性——无法精确地进行跟踪；

    （2）导致其他计划的质量下降——由进度计划的不准确导致其他项目规划不准确；

    （3）增大偏离规划的风险——不能按时的执行进度计划造成偏离；

    （4）减少软件功能点数量——过分乐观的计划造成没有足够时间完成计划的功能；

    （5）项目推进苦难重重——耗费项目经理不必要的时间和精力；

    （6）客户关系紧张——客户失去对开发者的信任；

    （7）项目仓促结束——影响开发人员士气。

 

4、过分乐观计划对 开发人员产生超负荷的进度压力！

    部分原因是因为开发人员缺乏谈判技巧，不能够有效地说服别人。

 

5、开发人员谈判能力差的三个原因？

    （1）开发人员通常比较内向；

    （2）进度计划的制定应该在开发方面和管理方面以及管理方面和市场方面的谈判和交涉的基础上进行——这些都是开发人员的弱项！

    （3）开发人员的性格使得他们反对所谓的谈判技巧！

 

6、学习有原则谈判的策略——一个提高谈判能力的好的学习起点！

    （1） 将人从困境中解脱——一切谈判都首先与人有关，其次才是利益与立场！

        a、以合作的态度改善与对方的关系；

        b、不要坚持双方想法达到的绝对平衡。

    （2） 关注共同利益，而不要过分坚持立场——要避免对立的立场，找出利益共同点！

    （3） 提出对双方都有利的备选方案——不要把谈判看做是你死我活的角斗游戏，从解决问题的角度出发进行协商，从而达到双赢！

    （4） 坚持客观的标准——因为客户没有专业的知识，所以要坚持客观的标准！

 

第十章 面向客户开发（customer-oriented development）——重视客户关系能够提高

1、客户对于快速开发的重要性

    （1） 提高效率——提高开发效率；

    （2） 减少返工——避免无谓返工；

    （3） 降低风险——避免偏离计划；

    （4） 消除矛盾——项目更好推进。

 

2、面向客户开发方法对开发过程的影响

    （1）计划——面向客户的开发方法有助于增加客户对项目的满意度；

    （2）需求分析——面向客户的开发方法能帮助开发人员了解客户的真正需求，从而避免返工；

    （3）设计——面向客户的开发方法有助于对客户的需求变更做出快速反应。

    （4）实现——面向客户的开发方法使得开发过程充满信心。

 

3、 合理控制客户的期望值

    （1）弄清客户的期望值可以减少大量的矛盾和额外的工作量。

    （2）培训客户使其更好地了解软件开发过程，以便于能够达到客户的期望值。

    （3）以任何理由使客户对项目进度、费用和功能产生不切实际的期望都会给项目带来不能克服的风险！