最近我有幸听了Martin Fowler关于“持续集成与持续交付”的演讲，Martin分享了很棒的见解–如何通过尽早交付和持续反馈来帮助团队使客户满意？
在过去5年的一大半时间里，我都在帮助大型产品公司的团队向敏捷转型。这段经历使我一直很困惑，我们给客户的建议是否真的可行？
这里列出了一些大型产品公司所拥有的特性，而这些特性给上面提到的敏捷工程实践带来了不少挑战：
• 从产品最终用户到开发团队之间的物理距离
• 产品的复杂度
• 开发团队和最终用户间的多个层级
• 产品多个模块的知识是相对独立的，比如，你必须安排业务专家来负责其中的一个或几个模块，而不是负责整个产品的业务
• 产品集成和新团队成员的学习曲线
那么，在这种情境下团队怎么办呢，是完全抛弃敏捷实践还是尽力做好实践使收益最大化？
我脑海里出现的第一个可操作的合理的解决方案就是，团队必须定义他们的内部客户。内部客户代表了最终用户的需求，他们需要和团队一起评审并反馈，并和开发团队一起改进产品。在产品的模拟环境下，他们是测试产品的最佳用户，并且这个环境的数据会一直从在线环境进行更新。
交付物（exe/dll文件）应及时地加入客户的release管理系统，这个系统由负责整个项目的产品经理来维护。该产品经理会和客户商议一个合理的产品交付节奏。这遵循了精益改善方法，方法强调团队只生产客户能消费的产品，把客户不能消费的产品交付给他们是没有任何用处的。在高可用性海量数据系统中（像银行，零售，客户服务系统等等）尤其是这样的。
大规模产品的成功有赖于PO们在各个层次上的持续合作。他们通过一系列的会议来达到该目的。我把这些会议戏称为“PO论坛”。
综上，最重要的就是遵循敏捷实践的精髓，而不是它的形式。
