这篇paper的完整题目是 Management Challenges to Implementing Agile Processes in Traditional Development Organization
Motivation
传统公司的管理者在刚使用敏捷开发时，会遇到很多问题。敏捷开发主要适用于小而独立的项目，所以很难把敏捷应用于大型的、传统的、自上而下的系统开发。
两位作者给行业的相关人员发问卷，总结了“融合敏捷与传统开发”过程中的40个“困难”。其中一部分属于“可忽略”，一部分属于“只与规模有关”，一部分属于“严重”。后两部分的内容分为三个方向：开发过程冲突、商业过程冲突、人员冲突。下文对这三个方向进行展开。
1、开发过程冲突
如果把轻量的敏捷开发与重量的传统开发合并，那么一定会带来牺牲：要么牺牲敏捷性，要么牺牲多年来对传统流程的积累。
1.1 具体问题
1.1.1 Variability（变化性）
如果分别使用敏捷+传统方法，那么很可能造出来两种完全不同的软件，尤其是在 GUI 的选择、现有库的调用方面。
用 GUI 举例。面对客户需求变化，敏捷开发会更改的更快。但是传统的方法可能一开始就固定了界面，很难与敏捷开发进行协调/同步。
1.1.2 Different life cycles
敏捷开发注重立即上线功能，但是传统开发注重长时间优化以及 documentation。
另一方面，敏捷开发每次只注重一个小功能，这使得它更像是传统开发中的维护环节。
1.1.3 Legacy system
遗留的系统很难重构、分解，这影响了敏捷的使用。
1.1.4 需求
敏捷的需求更加偏向功能、不够“正式”。
1.2 作者的建议
- 认真分析所有可能的不匹配
- 定制你的过程，只选取其中最必要的部分
- 限制敏捷开发的使用范围，比如只用敏捷开发进行维护、GUI 开发
- 重新设计传统过程的“里程碑”和“检查站”
- 把敏捷开发应用在新项目上，尤其是“全新需求”的项目
- 评估风险，计算敏捷开发的收益
最后作者引用了一下自己的旧文章，说本节的问题从属于一个更大的问题，那就是“如何把软件工程的优点应用在系统工程领域”
2、商业过程冲突
敏捷与传统开发之间的一个很容易被忽视的问题是：商业模式。这里的商业包括成本评估、资源投放。敏捷开发会给商业带来更大的不确定性和模糊性，尤其是长期的敏捷项目开发。商业过程希望能获得精确的预测，不鼓励敏捷开发里那种“短期确定，长期未知”的试验。
2.1 具体问题
2.1.1 人力资源
公司的 HR 对于职位描述、时间记录更为严格，而敏捷开发人员往往模糊各种界限。同时，敏捷开发需要更综合的敏捷技能和经验，而这些条件都难以考量。
2.1.2 项目进展测度
传统的开发依赖于合约、里程碑之类的方法，而这些难以适应敏捷开发的速度和灵活度。其中主要涉及的困难是，传统项目难以分解成子任务，同时时间规划上缺乏灵活度。可以参考敏捷开发中的“需求完成记录”作为项目的测度。
2.1.3 过程标准评分
敏捷开发经常不符合传统的工业开发标准，尤其是不适用很多生命攸关的标准严格的项目。
2.2 作者的建议
- 对于 HR 方面的问题，进行一些“敏捷实验田”，并与传统开发进行对比
- 相比于衡量成本，更多的去衡量敏捷开发的产出
- 尝试新的实践，订立新的考核标准
- 根据产出的软件作为奖励依据，根据客户的满意度作为改进依据
3、人员冲突
人员是开发模式变更过程中最重要的因素。这个新开发模式的引入主要伴随着“对个体的赋能”。这个“对个体的赋能”主要包括：对合理的目标进行支持，减少反馈周期，主人翁意识，灵活度。
3.1 具体问题
3.1.1 管理模式
在传统的流水线生产模式中，项目经理把员工当做可更换的螺丝钉，并且给每个员工指定具体的任务。
而敏捷开发的项目经理扮演两个功能：保护者和教练。项目经理保护手下的员工在“冲刺”过程中，不会受到来自公司的干扰；并且在有需要的时候提供技术支持。
3.1.2 空间流动
敏捷开发经常需要结对编程，所以员工需要共享的开发空间、一面用来画进度图的墙、一个鼓励团队交流的布局、用来持续集成软件的软硬件设备。
3.2.3 对待优秀团队
很多企业一看到优秀的团队就升迁项目经理、拆散队伍。这样会破坏磨合良好的团队关系，冲散已积累的经验，让员工因畏惧职业变更而拒绝变化。
3.2.4 处理变革
组织进行变革时，组织内部经常会出现抱团的反对力量。甚至有人会通过搞破坏来阻止变革。
这种和组织对着干的“猪队友”在哪里都很讨厌，但是在对敏捷开发的影响尤其负面。敏捷开发依赖于结对编程、信息共享、责任共享。
另外，敏捷开发需要影响其他利益相关方，尤其是需要客户与团队一起工作。这就需要对客户进行相关培训。
3.2 作者的建议
- 改善团队沟通的媒介
- 教育利益相关方
- 用管理者和客户的语言来解读开发过程中的问题
- 把菜鸟提出团队，雇牛人，对成果进行奖励
- 改变绩效方式，对团队和个人分别进行奖励
validation 和 verification 的区别
- validation 是检查 specification 是否满足客户需求
- verification 是检查软件是否满足 specification
