管理非常好的实践：透明度

　　牵涉到完成时的完整性，尽可能详细地了解正在做的事情就变得很更要。在应用敏捷管理实践过程中，如果没有项目管理实践，那么获得的将是提交质量上的提升而不是IT响应性的提升。要获得更好的响应性，就需要使所进行的工作透明化。

　　敏捷方法可以通过以下途径实现透明化：需求的表达方式、团队的组织方式、协作方式和过程追踪方式。当然支持这些的主要敏捷实践，如用需求卡片表示需求、协作方式、迭代交付等，并不是全部的解决方案，其本身也需要适当的调整以适应特定的环境。

　　例如，一个地理位置上分散的、几百人组成的团队，通常会把项目分解到几个团队由其独立完成，而不是所有人都去研究同一类需求。这些独立的团队将影响到需求的实现方式：高层次的需求可能需要多个团队各自完成一些子部分，而各子部分之间则通过消息来传递信息。而这并不会减少需求卡片所带来的价值，这种“准需求”能使各团队完成各自独立的（至少是分离的）、可测试的需求，从而很好地实现业务价值。

　　此外，还要考虑到项目管理方式的模式化程度。分布集中的团队可能会体验到“需求卡片墙”生动地将需求分阶段展示出来的好处，它将包括已完成的、待定的、正在实现中的和准备解决的。然而，地理位置分散的团队无法使用真正的需求卡片“墙”。在此情况下，可以使用项目追踪报告（比如借用Mingle等工具）使团队掌握项目状态。团队的分布形式也会影响到业务的协调程度。虽然业务应该与开发团队分布于同一地理位置，但对于分散的团队来说这不可能。但这并不意味着对本地业务的了解没有用处，因此可以在本地设置一个业务代理——如请一位业务方面的分析专家，可以取得同样的效果。

　　版本发布计划的实践会根据环境不同而有相当大的变化。在一个高度动态的领域里，版本发布计划基本就是一种“一厢情愿”的想法。在这种情况下发布计划很可能会误导项目的利益相关人并损害团队的利益。这时，XP方法中的“昨日气象”法应该是管理发布过程最安全的方式。在一个较稳定的领域里，版本发布计划就能在很大程度上改善项目档案管理。

　　另一个需要根据情况考虑的是某种环境下的紧张程度。Scrum方法可能会对经常在生产中遇到故障或者发现缺陷从而急需危机管理的项目很有效，我们可以一个中等长度的时间（比如一个月）划分工作段，在各阶段每天举行站立会议。但对于无法规律地得到发布版本的客户，可能更喜欢敏捷方法中常见的、一致性更好、时间更长的迭代和发布周期。

　　总之，透明度并不是在做任务的时候顺便获得的，而是通过诸多在特定情况下可以最大化透明度的实践来实现的。