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

 

第十一章 激励机制（motivation）

1、激励是决定工作表现最重要的影响因素，研究表明， 激励对生产率的影响比其他任何因素都大！

 

2、开发人员的典型动机！

 

3、激励研发人员最重要的5个因素

    （1）成就感

        a、拥有对自己的自主权——完成自己设定的目标会更积极；

        b、为研发人员设定目标——加快开发速度的简单有效方法；

    （2）发展机遇

        a、可以提供进修的机会；

        b、为员工提供参加培训的机会；

        c、为员工购买专业的书籍；

        d、参加其他项目扩展其技能；

        e、为其指定导师，关注其职业发展；

    （3）工作乐趣

    （4）个人生活

    （5）成为技术主管的机会

 

4、研发人员士气杀手

    （1）保健因素——工作环境不利于研发人员身心健康；

    （2）被管理者操控——开发者倾向于处理明白无误的事务，并希望管理者以直截了当和实事求是的方式处理；

    （3）执行计划的压力——执行不可能完成的任务；

    （4）缺乏对付出努力的肯定——要及时肯定为开发而付出的努力；

    （5）因技术措施不当被牵连——非技术管理者命令开发人员离开开发主题而进行其他开发工作；

    （6）开发人员没有参加与自己有关的决策行为——使开发人员得不到足够的重视；

    （7）生产率障碍——开发人员不能发挥自己的最佳效率；

    （8）低质量——开发人员的成就感是从自己所从事的开发工作中获得的，低质量的产品会直接影响开发人员士气；

    （9）过分夸张的激励形式——开发人员会觉得自己收到了侮辱；

 

第十二章 团队合作（team work）

1、对“团队”含义的认识——并不是恰巧在一起工作就可以称为一个团队，团队是指能够相互负责、拥有共同的目标以及技能能够相互补充的一些人。

 

2、研究发现：个人生产力可以分为10个等级，而 最好的团队的生产力是最差团队生产力的4倍！

 

3、最好的团队有什么样的特点？

    （1）共同的目标和愿景；——提高凝聚力，为共同的目标努力奋斗；

    （2）团队成员之间的认同感；——从团队成就中获得满足；

    （3）结果驱动的结构；——构造最大产出的团队；

    （4）能够胜任职位的团队成员；——胜任自己的职位，扮演好自己的角色；

    （5）对团队的承诺；——团队的成功来源于成员的承诺；

    （6）相互信任；——四个核心内容：诚实、开放、一致、尊敬；

    （7）团队之间的相互依赖；——各自发挥各自的优势，做有利于团队的事情；

    （8）有效的沟通；——增加理解，减少沟通成本；

    （9）自主意识；——团队成员自由地去做能够使项目成功的事情；

    （10）授权意识；——被授权后可以采取任何为获得成功所采取的行动；

    （11）小的团队规模；——8到10人是团队最佳规模；

    （12）高层次的享受。——打造自己团队的专属幽默感。

 

4、团队需要进行长期建设，原因如下：

    （1）持久的团队会有更高的生产率；

    （2）长期的团队避免高额的启动费用；

    （3）长期的团队降低了个人问题风险；

    （4）长期的团队降低了人事变动。

    （5）时间空闲问题——保留团队比重新组织团队更划算。

 

第十三章 团队结构（team structure）

1、即使你拥有了技术、好的努力工作的员工，错误的团队结构依然会削弱他们的努力而不是将他们推向成功！

 

2、组建团队时首先要考虑的因素是决定团队的主要目标：为了 解决问题？为了 创新？还是为了 战术执行？

 

3、团队的种类

    （1） 解决问题型团队——主要从事一个或多个特定问题的解决，团队成员要求 可信赖的、聪明的、活跃的。

    （2） 创新型团队——探索创新性和可能性，团队成员需要 自我激励、独立、富于创新和百折不挠。

    （3） 战术执行型团队——重点在于执行一个良好定义的计划，以高度集中的任务和清楚定义的角色为特点，团队成员要求有 使命紧迫感、行动敏捷性以及忠诚于团队。

 

4、团队模式汇总——为实现团队目标而组建团队的方式

    （1） 业务型团队（business team）——有一个技术领导带领的团队

        a、技术领导负责制定困难技术问题的最终决策；

        b、可适用于问题解决型、创新型和战术执行型；

    （2） 首席程序员团队（chief-programmer team）——基于首席程序员是普通程序员效率的10倍这一事实

        a、突出首席程序员的作用——一般团队把首席程序员与一般程序员放在同等位置；

        b、由 首席程序员负责起草整个说明书、完成所有的设计以及大多数代码的实现，并最终负责几乎所有的项目决策；

        c、 一般程序员扮演对首席程序员支持的角色，对首席程序员的设计和代码实现进行专门的研究；

        d、该种团队类型目前使用较少，但是还是推荐使用，尤其是针对 创新型目标和战术执行型目标。

    （3） 臭鼬项目团队（skunkworks team）——典型的黑箱管理方式

        a、一批有才华、有创新能力的开发者，放在一个不受组织官僚限制的机构中，使它们能够放手开发和进行创新；

        b、不利方面：对项目进展没有足够的可视度；

        c、尤其适合于创新型目标。

    （4） 功能负责团队（feature team）——开发、质量保证、文档管理、程序管理和市场人员都采用传统的等级报告结构

        a、 团队位于传统组织的最上方，从每一个部门中抽取对产品功能负有责任的一个或者多个成员；    

        b、尤其适合问题解决型目标，也适用于创新型目标，但是不适于战术执行型目标。

    （5） 搜索救援团队（search-and-rescue team）——重点在于解决特定问题

        a、团队成员要求有能力立即解决问题，有过硬的专业知识；

        b、专门针对于问题解决型目标，太过基础不适于创新型目标，太过短期不能支持战术执行；

    （6） SWAT团队（SWAT team）——每个人都是某一方面专家，高度默契使得他们像一个整体

        a、SWAT——special weapons and tactics，在软件领域，SWAT——skilled with advanced tools；

        b、持久型的团队，习惯在一起工作；尤其适合于战术执行型目标，也可用于问题解决型目标。

    （7） 专业运动员团队（professional athletic team）——强调高度细化的个人角色

        a、特别适用于战术执行型目标，强调高度细化的角色。

    （8） 戏剧团队（theater team）——强烈的方向性和与众多项目角色协调为特点

        a、在共同的目标愿景下，强调个性突出。

        b、尤其适合创新型目标。

    （9） 大型团队（large teams）——沟通和协调是团队中的关键问题

        a、可以划分多个小组，每个小组是不同的团队模式。

 

5、项目经理与技术领导

    a、项目经理与技术领导两个角色之间的职责有重叠也有区分；

 

第十四章 对功能集的控制（feature-set control）

1、功能蔓延是阻碍项目快速开发的重要问题。

    

2、对项目功能集的控制主要分为三个阶段

    （1） 项目前期：重点在于对功能的简化

    （2） 项目中期：重点在于控制功能蔓延

    （3） 项目晚期：重点在于剪切多余功能

 

第十五章 高生产率工具（productivity tools）——好工具才能够事半功倍！

 

第十六章 项目修复（project recovery）

1、一般的修复方案

    （1）缩减项目规模——以便于在计划时间内完成规定任务量；

    （2）关注短期改善，提高生产效率；

    （3）面对不能按时交付的软件，放弃原计划，着手准备危害控制。

    （4）放弃部分功能，提高生产率。

 

2、在进行项目修复时， 最根本的问题是如何完成这个项目！

 

3、修复计划安排

    （1）了解现状

        a、评估项目处境；

        b、应用W-理论分析；

        c、做好修复项目的心理准备；

        d、询问开发人员需要做什么；

        e、面对现实，贴近现实；

    （2）人员方面

        a、采取一切措施鼓舞开发人员士气；——士气决定一切；

        b、确保为开发小组创造了良好的环境；——良好的环境是保证；

        c、消除重大的人员隐患问题；——保持组内成员没有搅局者；

        d、消除重大的领导问题；——替换不适合的领导；

        e、增加新手一定要慎重；——新手会浪费更多的时间；

        f、充分利用开发组时间；——集中精力，高速运转；

        g、允许开发组成员各有不同；——不能强求千篇一律；

        h、观察开发人员节奏；——调整好节奏，提高开发速度。

    （3）过程

        a、修正支离破碎的过程；——找出偏离开发主线的原因；

        b、创建详细的小型里程碑；——小型里程碑既可以追踪进度，又可以鼓舞士气；

        c、依据里程碑的完成情况安排进度；——根据实际情况安排进度计划；

        d、细致地追踪进度情况；——追踪进度，保证不偏离主线；

        e、记录里程碑未完成的原因；——一定要找出原因所在才能避免再犯；

        f、短期后再继续调整；——实时校准，才能使计划更准确；

        g、在得出有意义的里程碑进度前不要提交新计划；——新计划的提交要有根据；

        h、进行风险管理要不辞辛劳；——进行风险管理，防范于未然。

     （4）产品——产品性能没有管理好的话，不可能修复好一个项目。

        a、稳定需求；——需求的稳定是其他一切的基础；

        b、修正功能集；——分出优先级；

        c、评估自己政治地位；——寻找项目停止的原因中是否涉及组织政治问题；

        d、去除无用垃圾；——果断丢弃垃圾；

        e、降低缺陷数量，并持续降低；——保证软件质量是减少时间浪费的关键；

        f、找到一个良好的状态，并在此基础上继续。——找到好的基础，再往上进行。

 

4、找准项目修复的时机——可能并不是第一次项目陷入麻烦的时候。

    a、 当你的管理者和开发组都准备接受这一现实，并同意进行修复，且做好的项目准备时。