持续交付对大型产品管用吗?

最近我有幸听了Martin Fowler关于“持续集成与持续交付”的演讲,Martin分享了很棒的见解–如何通过尽早交付和持续反馈来帮助团队使客户满意?

在过去5年的一大半时间里,我都在帮助大型产品公司的团队向敏捷转型。这段经历使我一直很困惑,我们给客户的建议是否真的可行?
这里列出了一些大型产品公司所拥有的特性,而这些特性给上面提到的敏捷工程实践带来了不少挑战:
• 从产品最终用户到开发团队之间的物理距离
• 产品的复杂度
• 开发团队和最终用户间的多个层级
• 产品多个模块的知识是相对独立的,比如,你必须安排业务专家来负责其中的一个或几个模块,而不是负责整个产品的业务
• 产品集成和新团队成员的学习曲线

那么,在这种情境下团队怎么办呢,是完全抛弃敏捷实践还是尽力做好实践使收益最大化?

我脑海里出现的第一个可操作的合理的解决方案就是,团队必须定义他们的内部客户。内部客户代表了最终用户的需求,他们需要和团队一起评审并反馈,并和开发团队一起改进产品。在产品的模拟环境下,他们是测试产品的最佳用户,并且这个环境的数据会一直从在线环境进行更新。

交付物(exe/dll文件)应及时地加入客户的release管理系统,这个系统由负责整个项目的产品经理来维护。该产品经理会和客户商议一个合理的产品交付节奏。这遵循了精益改善方法,方法强调团队只生产客户能消费的产品,把客户不能消费的产品交付给他们是没有任何用处的。在高可用性海量数据系统中(像银行,零售,客户服务系统等等)尤其是这样的。

大规模产品的成功有赖于PO们在各个层次上的持续合作。他们通过一系列的会议来达到该目的。我把这些会议戏称为“PO论坛”。

综上,最重要的就是遵循敏捷实践的精髓,而不是它的形式。

原文链接:http://www.scrumalliance.org/community/articles/2011/january/does-continuous-delivery-work-for-large-products