设想一下这个：负责的副总裁看到的报表显示一切正常，可是等到发布时的吃惊发现却令他不快，因为事情被搞得一团糟。不幸的是，这种情形实在是太过司空见惯了，除非你的组织采取的是敏捷应用生命周期管理（Agile ALM）流程，这种流程可以促进整个生命周期之内的透明性。我们来看看为什么Scrum等敏捷过程能够帮助实现透明度的。

　　迅速评估项目状态

　　敏捷需求教练兼顾问Derek Wade今年1月21日在Twitter上是这样评价Scrum内在的透明性的：“Scrum鼓励可视性，也需要可视性，从交付团队到组合管理皆如此。组织之内任何等级都不能免除。”

　　在采用敏捷开发的公司中，资深经理任何时候都可以查看任务板（或者如果团队使用的是虚拟任务板的话在网上）了解进度，流程的障碍在何处，已完工的工作量以及剩余工作量等。

　　Thycotic Software的CEO Jonathan Cogley发现，信息辐射体可以帮助他跟踪项目状态。“团队在一个高度可见的位置（大的可视化图表）维护着一个燃尽图（burn-down and burn-up chart）。我们也可以每天早上召开邀请我参加的站立会议，每周还会进行当前的进度演示。”

　　我问在线房屋搜索网站UDR的副总裁兼CIO Scott Wesson，是什么让他可以迅速评估项目状态。他回答道，“查看实际的应用。你可以用燃尽图来估算所有你想要的东西，但是如果你不能亲自看到解决方案或者并未参与到解决方案的制定过程的话，那么你就只能在一边瞎想，‘他们有没有做对？’”

　　敏捷开发还可以把沟通问题和依赖性迅速揭露出来。如果A团队由于B团队破坏了开发过程的某样东西而受阻，持续集成过程将会让所有人都了解这一点。每一次迭代都要交付生产就绪代码的迫切需求意味着障碍要呈现在大的可视化图表上，无论它是实体的还是虚拟的，同时必须有人负责清除这些障碍。

　　是什么让敏捷变得透明？

　　经理依赖于里程碑和基准指标。像故事图这类的技术能够将功能分割进一个个用户故事当中，然后软件按照平均速度发布，这些有助于我们设立里程碑。我们都知道自己的估计只是猜测而已，因此我们会随着了解的增多而重新查看它们。项目状态会以燃尽图和已完工作及剩余工作的可视化方式进行呈现。

　　敏捷原则推动我们经常要根据哪些事情有效和哪些无效来做出反应。我们根据小规模试验来协力改进。我自己的团队每天都使用一项工具来捕捉有关当前迭代情况的反馈信息。我们回顾反思结果的点点滴滴都会发布到公司内部的维基上面。经理可以看到我们正在做什么事情，不断改进我们的能力，从而屡屡实现业务价值。

　　当我问Scott Wesson怎样才能让开发对主管透明时，他回答道：“大多数主管并不关心开发的过程，而是关注项目的成果。”他的企业会定期召开更新和状态会议，主管能够从可信任的顾问那里获得反馈。他说，“主管必须创造一个透明化是常态的环境。这种环境应该可以容忍错误，能够让人吸取教训。如果没有这样的气氛，那么无论你的方法论如何，主管都无法从开发或交付团队那里了解到真相。”

　　频繁交付与可持续节奏

　　频繁交付高质量软件的关键是管理技术债务，这样团队的速度就能保持稳定。我们的经理知道每一次冲刺平均能完成多少个故事点，然后做出相应计划。采取好的测试和编码实践的时间也被考虑到速度里面。一旦代码设计得好并且有好的自动化回归测试的支持，我们就能迅速安心地做出修改。

　　对敏捷陌生的团队往往背负着庞大的技术债务。ALM工具可以采用持续集成流程集成进来，从而衡量代码完整性和测试覆盖率之类的因素，为这笔技术债带来经济价值。管理人员能够理解以前在开发上走捷径会给业务带来什么代价。提前进行一笔大投资使得团队可以控制它。

　　每一个软件项目都会遭遇挫折。在传统的瀑布式流程中，问题往往被隐藏起来，直到很后面的测试阶段才被发现。在敏捷流程中，我们也还是会有问题，但是我们能够很快吸取教训，在它有可能延误项目之前就把问题给处理掉。资深经理可以迅速跟踪日常流程，让软件开发跟业务需求一致。