敏捷和架构的冲突

     英文原文    <strong>：</strong>    <a href="/misc/goto?guid=4958190039075305895">Agile and Architecture Conflict</a>    <p> 实施敏捷方法和设计企业架构之间总是存在某种冲突。敏捷开发强调随着对业务领域的深入理解，逐步调整设计和计划。架构设计则要求建立起技术架构（technology stack）。它可以满足质量属性（quality attributes），也可以向感兴趣的利益关系人进行展示，作为一种沟通的途径。当使用敏捷方法来引领所需的架构设计的时候，<a href="/misc/goto?guid=4958190039805776887" target="_blank">两者强强联手将会是双赢</a>。</p>    <p> Tom Graves认为<a href="/misc/goto?guid=4958190040560177330" target="_blank">敏捷需要一个脊柱来支撑</a>。而软件架构提供了这个脊柱。</p>    <blockquote>     敏捷通常需要一个脊柱来指引方向——根据这个方向，推动一些工作的进行。这样做，相对于随意出牌，可以完成更多的工作。通常，这是个平衡问题——要在坚实的脊柱和敏捷之间有个良好的平衡。    </blockquote>    <p> Jan Van Til赞同Tom的观点，他认为<a href="/misc/goto?guid=4958190041296260958" target="_blank">没有后台的脊柱</a>，前端也很难看得出有多敏捷。</p>    <blockquote>     我们当然需要一个相对进展“缓慢”的“后台”，这样才能让我们看清我们有多敏捷（“前端”）。如果所有的东西都很时尚...我们还能从中识别出哪个是时尚吗？我们当然需要一个有点“缓慢”的“后台”，这样才能让我们看清时尚（“前端”）。换句话说，我们需要传统的东西，没有传统的东西，也就没有了时尚。    </blockquote>    <p> Simon Brown觉得，<a href="/misc/goto?guid=4958190042035906110" target="_blank">甚至“绝大部分的敏捷项目”可能都有或大或小的架构方面的问题</a>。我们需要在项目早期迭代中解决它们。Simon认为，敏捷和架构的冲突可以归结为是通过短迭代来交付商业价值，还是做一个庞大的预先设计。这里的关键点是<a href="/misc/goto?guid=4958190042767930092" target="_blank">设计要“刚刚好”（just enough）</a>。准备好一个初步的结构是很重要的，但这不意味着就要画出无数的详细类图。</p>    <p> John Bauer则提到，<a href="/misc/goto?guid=4958190043498890861" target="_blank">在对几个项目观察了一段时间以后，他发现了一个有趣的模式</a>。</p>    <blockquote>     敏捷以及那些类似敏捷的方法有个好处，对于产品来说，它能减少那些架构设计过度的软件解决方案（over architect-ed software solutions）的产生。架构设计过度的解决方案会强调软件应用项目的交付，也会使得软件开发和维护的成本上升，通常来说，是跟交付商业价值背道而驰的。    </blockquote>    <p> James Coplien和Kevlin Henney <a href="/misc/goto?guid=4958190044250105714" target="_blank">给我们介绍了一种从项目开始的时候就进行“刚刚好”的架构设计，并且确保项目成功的有效方法</a>。</p>    <p><strong> 但是，这一切在现实世界里又是怎么实现的呢？</strong></p>    <p> Simon Brown在他的博文中提出了一个有趣的挑战：他要求在4个月左右的时间内，<a href="/misc/goto?guid=4958190042035906110" target="_blank">重新开发一个程序来取代老迈的在线银行系统</a> 。他要求大家仍然使用敏捷方法，但最终还是能够交付。博文中提到了大家提出的一些方案，包括<a href="/misc/goto?guid=4958190045659733736" target="_blank">Kero</a>和<a href="/misc/goto?guid=4958190046396727708" target="_blank">John Bauer</a>的。你可以查询到更多的方案，也可以<a href="/misc/goto?guid=4958190042035906110" target="_blank">提出你自己的想法</a>。</p>    <p> 这样看来，架构设计和敏捷需要共存。不是有你没我，而且相互合作。这里的关键点就是做“刚刚好”的设计。 Simon <a href="/misc/goto?guid=4958190042767930092" target="_blank">定义了“刚刚好”</a>：</p>    <blockquote>     做一个“刚刚好”的架构，可以让你条理清晰，明确愿景。换句话说，“刚刚好”让你知道了你的目标是什么，你怎么去完成这个目标。背后的关键就是     <a href="/misc/goto?guid=4958190048477516250" target="_blank">架构是一个重大的决定</a>，而“重大”是由进行改变所需要的成本来衡量的。换而言之，这就是架构，想要修改真的会很贵，而且你真的必须尽早做出正确的决定。举个例子，质量属性，比如高性能，高扩展性，高安全性以及高可用性，通常都需要在早期就把这些考虑在基础框架内，因为想要在后期重新修改现有的基础代码库会很难。这也就是架构，你不可能在某个下午很简单地就进行重构，比如核心技术选择、架构模式、核心框架等。     <br />    </blockquote> 转自：    <a href="/misc/goto?guid=4958190049213184407" target="_blank">http://www.infoq.com/cn/news/2011/06/agile-architecture-conflict</a>