平衡敏捷与规范

.2.2.1 客户关系 23
2.2.2 计划和控制 25
2.2.3 项目沟通 26
2.3 技术特征 27
2.3.1 需求 27
2.3.2 开发 29
2.3.3 测试 30
2.4 人员特征 31
2.4.1 客户 32
2.4.2 开发人员 33
2.4.3 文化 35
2.5 总结 36
2.5.1 擅长领域 36
2.5.2 误解 38
2.5.3 5个关键要素 39
参考文献 41
第3章 项目开发中的一天 43
3.1 典型的一天 43
3.2 使用psp/tsp的典型的一天* 44
3.2.1 培训 44
3.2.2 工具和环境 45
3.2.3 项目计划 45
3.2.4 状态 46
3.2.5 当天的活动 47
3.3 使用极限编程的典型的一天* 50
3.3.1 培训 50
3.3.2 工具和环境 51
3.3.3 项目计划 51
3.3.4 状态 52
3.3.5 当天的活动 52
3.4 危机时期 54
3.4.1 psp/tsp对危机的处理 55
3.4.2 xp对危机的处理 56
3.5 总结 56
3.5.1 不同点 57
3.5.2 相似点 57
3.5.3 观察结果 58
参考文献 58

第4章 拓展擅长领域：两个案例分析 59
4.1 使用计划来扩大敏捷方法的应用规模：出租管理的例子 59
4.1.1 假设1：开发或修改一个素材所需的工作量不会随时间和
素材数的增加而增长 60
4.1.2 假设2：在固定时间表和规模不经济的情况下，同样可以
相信人能够按时完成一切事情 61
4.1.3 假设3：简单设计和yagni可以轻松扩展到大型项目 62
4.1.4 扩大敏捷方法的使用规模：总结 63
4.2 利用敏捷来简化计划驱动方法： usaf/trw ccpds-r 示例 63
4.2.1 个体和交互胜过过程和工具：ccpds-r 64
4.2.2 可以工作的软件胜过面面俱到的文档：ccpds-r 65
4.2.3 客户协作胜过合同谈判：ccpds-r 65
4.2.4 响应变更胜过遵循计划：ccpds-r 66
4.3 总结 67
参考文献 69
第5章 使用风险平衡敏捷和规范 70
5.1 方法概述 70
5.2 应用实例系列：基于代理的计划系统 74
5.3 中型应用：供应链管理 75
5.3.1 步骤1：supplychain.com项目风险评估 76
5.3.2 步骤2：对比敏捷和计划驱动风险 77
5.3.3 步骤4a：单独的风险解决策略 79
5.3.4 步骤4b：supplychain.com基于风险的系统开发策略 82
5.4 小型应用：活动计划 85
5.4.1 步骤1：活动计划项目风险评估 85
5.4.2 步骤2：比较敏捷风险和计划驱动风险 85
5.4.3 步骤4a、4b：event managers基于风险的系统开发策略 88
5.5 超大型应用：国家危机管理信息系统(niscm) 89
5.5.1 步骤1：niscm项目风险评估 90
5.5.2 步骤2：比较敏捷风险和计划驱动风险 92
5.5.3 步骤3和4：基于风险的niscm系统开发策略 94
5.6 结论 99
参考文献 101
第6章 结论 103
6.1 最重要的六条结论 103
6.1.1 敏捷方法和计划驱动方法都不是银弹 104
6.1.2 敏捷方法和计划驱动方法的擅长领域 105
6.1.3 未来的应用既需要敏捷又需要规范 105
6.1.4 平衡敏捷和规范的方法正在出现 106
6.1.5 逐步建立你的方法——不要自上而下裁剪 106
6.1.6 少关注方法——多关注人、价值观、沟通和期望管理 106
6.2 关于敏捷和规范的平衡，下一步怎么做 109
6.3 软件开发中平衡敏捷和规范的步骤 110
参考文献 112
后记 114
附录a 方法之间的比较 115
a.1 scrum方法 117
a.1.1 简要描述 117
a.1.2 评注 117
参考文献 118
a.2 自适应软件开发 118
a.2.1 简要描述 118
a.2.2 评注 119
参考文献 119
a.3 简约开发 119
a.3.1 简要描述 119
a.3.2 评注 120
参考文献 120
a.4 crystal 120
a.4.1 简要描述 121
a.4.2 评注 121
参考文献 121
a.5 极限编程 122
a.5.1 简要描述 122
a.5.2 评注 123
参考文献 123
a.6 动态系统开发方法 123
a.6.1 简要描述 123
a.6.2 评注 124
参考文献 124
a.7 rational统一过程 125
a.7.1 简要描述 125
a.7.2 评注 125
参考文献 126
a.8 团队软件过程(tsp) 126
a.8.1 简要描述 126
a.8.2 评注 127
参考文献 128
a.9 特征驱动开发 128
a.9.1 简要描述 128
a.9.2 评注 129
参考文献 129
a.10 能力成熟度模型集成 130
a.10.1 简要描述 130
a.10.2 评注 131
参考文献 131
a.11 软件能力成熟度模型 131
a.11.1 简要描述 131
a.11.2 评注 132
参考文献 132
a.12 个体软件过程 133
a.12.1 简要描述 133
a.12.2 评注 134
参考文献 134
a.13 净室 134
a.13.1 简要描述 134
a.13.2 评注 135
参考文献 135
a.14 方法对比表 135
附录b 敏捷软件开发宣言 137
b.1 敏捷宣言遵循的原则 137
附录c 能力成熟度模型 139
c.1 cmm发展简史 139
c.2 cmm的概念 140
c.3 使用模型改进过程 142
注释 143
附录d 平衡敏捷与规范的工具 144
d.1 螺旋模型锚点里程碑 144
d.2 利益实现分析和dmr效果链 147
d.2.1 利益实现 147
d.2.2 效果链 147
d.3 进度自变量 148
d.3.1 共同愿景和期望管理 149
d.3.2 特性优先级化 149
d.3.3 时间表范围估算 150
d.3.4 确定架构和核心功能 150
d.3.5 增量开发 150
d.3.6 变更和进度监控 151
参考文献 151
附录e 经验信息 153
e.1 变更的成本：经验结果 153
e.2 做多少架构工作才够？一次cocomoii分析 155
e.3 敏捷方法和计划驱动方法的试验与研究 158
e.3.1 项目规模的大体分布 159
e.3.2 过程改进 159
e.3.3 团队软件过程和敏捷方法 161
e.3.4 结对编程 163
e.3.5 敏捷/计划驱动混和方法 164
参考文献 164
平衡是成熟的开始 167

.　　·第3章通过描述在一天中，使用每种方法工作的典型情形以及非典型情形，对方法进行了经验式的介绍。
　　·第4章介绍了两个项目案例研究，说明了纯敏捷方法和计划驱动方法的局限以及集成这两种方法所带来的好处。
　　·第5章描述了一个基于风险的方法(该方法可以用来进行集成敏捷和计划驱动实践的方法学决策)，并用典型例子进行了说明。
　　·第6章对全书内容进行了总结并给出了一些最终的观察结果。
　　·附录A概述了主要的敏捷方法和计划驱动方法，强调了它们的主要区别，并对它们进行了总结以便进行比较。
　　·附录B至附录E提供了一些技术和背景信息，这些信息为我们针对特定技术主题的分析和讨论提供了支持。
　　致 谢
　　很难知道从哪里开始感谢本书编写过程中所涉及的许多人。首先要感谢为本书作序的三位作者：Grady Booch，Alistair Cockburn和 Arthur Pyster。他们还对本书的草稿进行了评审并提出了一些关键的改进意见。我们还非常幸运地拥有众多评审者，他们对整个草稿进行了评审，并提供了许多有见地的改进建议。他们是：Pekka Abrahamsson，Kristen Baldwin，Marguerite Brown，Scott Duncan，Peter Hantos，Denise Howard，Tony Jordano，Mikael Lindvall，Ken Schwaber和Laurie Williams。
　　我们也非常感谢敏捷社团和计划驱动社团中繁忙的领头人。在我们以不同的角度看待软件世界时，他们毫无保留地与我们分享他们的时间和专业知识。他们是Scott Ambler，Ken Auer，Vic Basili，Kent Beck，Larry Bernstein，Winsor Brown，Bob Charette，Steve Cross，Michael Crowley，Christine Davis，Noopur Davis，Tom DeMarco，Nancy Eickelmann，Amr Elssamadisy，Hakan Erdogmus，Mike Falat，Martin Fowler，James Grenning，Jim Highsmith，Tom Hilburn，George Huling，Tuomo Kahkonen，Bil Kleb，William Krebs，Philippe Kruchten，Charles Leinbach，Wei Li，John Manzo，Frank Maurer，Granville Miller，Karen Owens，Mark Paulk，Gary Pollice，Dan Port，Don Reifer，Walker Royce，Gregory Schalliol，Kurt Schneider，Sarah Sheard，Giancarlo Succi，Roland Trauter，David Webb，Christian Wege，Laurie Williams和 William Wood。他们有自己独特的见解，我们尽量做到尊重他们的观点，但在此列出并不表示他们赞同本书提出的所有看法。
　　我们要特别感谢CeBASE的同事们，他们是Mohammed Al-Said，LiGuo Huang，Apurva Jain，LaDonna Pierce，Meghna Shah，Sachin Shah，Gunjan Sharman。感谢南加利福尼亚大学软件工程中心的Paul Sitko，Patricia Costa，Atif Memon，Forrest Shull，Roseanne Tesoriero Tvedt以及马里兰大学Fraunhofer 中心的Marv Zelkowitz，他们在敏捷方法和计划驱动方法的研究方面为我们提供了支持，特别是通过电子研讨会和在USC(南加利福尼亚大学)举行的两个敏捷方法研讨会所提供的支持。感谢Peter Gordon和Addison-Wesley的工作人员，他们始终是非常优秀的合作伙伴。
　　最后，要向我们各自的妻子表达我们的爱和感谢——Sharla 和Jo——她们不但容忍了午夜传真、频繁的额外出差以及写作本书过程中常常出现的心不在焉，还提出了一些敏锐的评审和编辑建议。这些建议使本书增色不少。她们总是我们最好的动力和最诚实的批评家，因为这两点，我们爱她们。
　　

.　　如果只有强有力的规范而缺乏敏捷，将导致官僚作风，进而停滞不前。缺乏规范的敏捷则如同一个新创公司在盈利之前的不负责任的狂热。
　　也就是说，这两种类型的规范缺一不可，只是程度不同而已。计划驱动方法和敏捷方法之间的部分不同是因为强调了“规范”一词两种含义中的一种而造成的。对方法的平衡主要就是对该词的两种含义的平衡。这种平衡正是本书要描述的主题之一。
　　这是一本关于一个复杂情感主题的杰出书籍。我为作者在处理该主题时所表现出来的谨慎喝彩。
　　——Alistair Cockburn
　　敏捷开发研讨会主席，“人与技术”项目主管
　　序 言(三)
　　Arthur Pyster
　　反对敏捷很难做到，同样，证明规范不重要也很难做到。问题的关键在于找到合适的方法融合敏捷和规范。许多组织已经通过使用CMM过程改进(一种鼓励规范过程的方法)在生产力、可预见性、质量以及成本方面取得了重大进步。我曾经使用软件CMM、系统工程CMM以及最近的CMM集成帮助许多组织取得了这些进步。当CMM过程改进方法被正确应用时，可以取得良好的效果。当然，我也看到过一些组织，它们虽然使用了CMM，但产生的过程却令人窒息。任何工具都会被误用。
　　在过去的6年中，我一直在联邦航空管理局(Federal Aviation Administration，FAA)工作——在最近的4年中担任副首席信息官。为了能够安全地运送遍及美国领空的7亿名乘客，每年都要投入数十亿美元。那些管理空中交通的系统具有一些共同的特征，促使FAA不得不使用规范的开发过程。这些系统需要非常高的可靠性，而且订货到交货之间的期限很长，同时还需要政府机构、航空公司、制造商以及机场方面投入大量的资金。此外，为了确保空中交通控制系统能够在全球范围内一致地运行，系统需求还必须符合国际协定。空中交通控制系统对于所有参与方必须一视同仁，并且必须在有人在7英里高空飞行时进行安装。为了实现和部署这样的系统，精细的长期计划、稳定的需求和架构，以及详细的文档都是必不可少的。
　　尽管如此，用于构建空中交通控制系统的过程还是能够(并且已经)支持一些敏捷特征。10年前，空中交通控制系统使用的过程非常呆板。今天，螺旋式开发、增量开发以及增量部署已经司空见惯。在生命周期早期的系统原型、需求提炼以及架构演化中，会使用一些轻量级的过程。涉众尽早并且频繁地参与到项目中来以确保需求的有效性以及人机界面的可用性。我期望FAA能够在认清这些系统必需的苛刻的操作环境的同时，继续探索更多可借助于敏捷过程减少成本、加速部署的地方。
　　对于任何规模的项目，平衡敏捷和规范都是必需的。本书作者完成了一项值得称赞的工作，他们识别出了用于建立恰当的组织性和灵活性平衡的5个关键要素——人、危险程度、规模、文化以及动态性。他们透彻、全面的分析将帮助那些在敏捷和规范争论中处于困惑状态的开发者，并为他们针对自己项目恰当地平衡敏捷与规范提供了指导。
　　——Arthur Pyster
　　美国联邦航空管理局
　　信息服务副助理主管兼副首席信息官