敏捷的概念与项目监管并不是从根本上相对立的。他们都是改善产品的手段。Scrum通过紧密的协作和固定长度的Sprint中实现短周期的 “检测与调整”来达到这个目的。而项目监管则是希望通过设置所谓“检测及批准（拒绝）”的检查点来确保项目或者产品能达成一些可比较的参数目标。
然而，目的虽然相同，Scrum和项目监管却通过截然不同的途径来达到目的。混合这两种方法时问题正是出现在 这些不同的途径上。幸运的是，采取以下妥协的办法就有可能在敏捷性和全局观取得双赢。
谈判并提前设定好期望。 毋庸置疑，第一个在监管体系下采用Scrum方法的项目会面临很多挑战。一定会有一些事情是没办法做的，比如，Scrum团队无法在被允许开始编码前提供完整的设计，因此在Scrum中设计和编码是同时进行的。唯一可行的办法是团队与监管组织提前进行谈判并达成一致。团队在这一点上得到的支持越多越好，团队在公司里获得支持的层次越高越好。团队不需要去祈求监管政策的永久及根本性的变革。这些变化可以被视为一次性的或临时的妥协。
将报告方式向现有期望的方式进行适应。项目的监管机构如检查团队或者监管委员会有他们现有的关于在每个检查点想看到他们信息的期望。不要去反对这些期望。如果他们想看到一个甘特图，就给他们 一个甘特图。当然，如果可以的话，慢慢的引导他们的期望去提供更多的信息，更加面向敏捷的信息。如果燃尽图适合被提供，就提供燃尽图。或者也许你想包含一份报告，用来显示持续集成体系触发构建服务器的次数，及成百上千（甚至成千上万次）的自动测试的执行。
邀请他们参与到流程中来。 Scrum团队可以通过邀请监管委员会的成员参加日常举行的会议中来的方法，来作为那些正式但不详细的监管检查的补充。我希望把这种常用的管理方法导向到“站在边上的管理”。鼓励参与项目监管的经理们和主管们参与到每日站会中来，他们可以站在那里同时倾听项目中到底正在发生什么。通过导入用户故事的方法来产生的变化—从依赖文档到依赖交谈，应该在项目汇报中同样发生。应该鼓励人们去参访团队或者加入他们的会议，亲自看看正在构建的产品。
以成功经验为例。 没什么比成功经验更有说服力了。尽一切可能让第一个或者前两个项目 能通过放松了的或者减轻了的监管检查点。然后以他们的成功经验为证据证明将来的项目也应该被允许通过。
在试管中观察敏捷软件开发是一回事，但是在现实世界中使用它是另一回事。在试管中，敏捷方法比如Scrum很容易就被大家所接受，纷繁复杂的现实世界中的公司政治，经济等等诸如此类的东西不会来捣乱。但是在真实世界中，所有这些不愉快的东西都是存在的。很难得有这种时候，轻松的决定去使用Scrum然后就能如愿的在没有这些阻力下去做了。
由于很少的组织能一开始就彻底的修正他们当前的监管方法，团队必须得学会在他们的非敏捷式的监管下工作。采取妥协的态度，并且使用上面列出的这些折中的行动 ，能让早期的Scrum项目更容易的跨进大门并且走得更远。
作者:Mike Cohn
原文地址：http://www.mountaingoatsoftware.com/articles/42-the-art-of-compromise
