作者 Ben Linders ，译者 姜信宝 发布于 2014年9月30日 | 讨论

在敏捷项目中，产品负责人往往被看做是业务和IT联系首要保障的人。但对于有效的IT业务整合，仅有产品负责人是不够的。来自业务、需求和组织的供应方的人们，做些什么可以提高IT和业务整合的效果呢？

在敏捷和软件架构研讨会2014上，来自Ordina的Klasien Postma介绍了“敏捷项目不能产生有效的IT业务整合”。在她的演讲中，Klasien说明人们如何采用精益思想去决定哪个架构文档是必须的，以及当文档是必须的时候，讨论为什么在许多项目中往往是IT团队采用敏捷实践，并且在关于如何提高敏捷项目中业务、需求和供应方的参与方面给出了一些建议。

Klasien介绍了她的工作经验，她在司法委员会和荷兰税务机关这两个政府部门当中担任过不同的架构师角色。她观察到这些组织中的一些趋势，包括向更少的部门集中化，通过共享服务中心实现专业化，以及更加注重IT管理。

司法委员会采用两种团队：产品开发团队——面向供应链，专注于业务价值和项目范围；服务开发团队——面向组件，专注于质量和跨项目范围的重用性。团队使用多个backlogs以管理他们的工作并与其他团队协作。

Klasien给出一套基于精益思想的问题，可以用来决定哪些架构文档是必须的，以及何时需要它们：

• 谁需要这个文档？
• 为什么他/她需要这个文档？
• 对他/她来说这个文档的价值是什么？
• 文档丢了会怎么样？

不同类型的架构文档有不同的用处。领域架构用来做长期规划，项目开始的时候架构文档支撑项目初始化。在迭代期间使用解决方案架构以及控制架构和变更管理。

根据Klasien所说，这些就是为什么需求、供应和业务作为合作伙伴不配合的原因：

• 用户被称作客户，而不是同事
• 没有把供应方当做业务伙伴
• 有许多偏见，且没有足够的自信

Klasien在她的的演讲中提供了一些建议，不同的利益相关人可以参考相应建议提高业务IT整合的效果。她建议业务要意识到他们应该关注自动化，并且业务人员应该钻研自动化流程以及尽量不要反对IT。对来自需求方的利益相关人，她建议当现实和理论不符时应该去拜访执行单位，亲眼查看现状，因为现状与理论总是有偏差的，需求方还应该在制作产品规格时让真正的用户参与，不要认为IT是很困难的事情。对于供应方的利益相关人，她建议邀请产品负责人之外的用户参加演示会以及产品规格会议，并专注于简单的说明。

Klasien说，对于业务IT整合，建立在平等上的合作是最重要的。要把业务现实有效地融入到IT解决方案中，需要让思路脱离固有的模型和预定义的模式。

查看英文原文：How Agile Can Yield Effective IT Business Alignment

感谢杨赛对本文的审校。

给InfoQ中文站投稿或者参与内容翻译工作，请邮件至[email protected]。也欢迎大家通过新浪微博（@InfoQ）或者腾讯微博（@InfoQ）关注我们，并与我们的编辑和其他读者朋友交流。