领导力大挑战
在实施Scrum项目的过程中，Scrum Master的角色是相当关键的，因为他是团队的推动者。本文围绕什么是仆人式领导、仆人式领导的起源、如何将领导力传达给团队、Scrum Master作为仆人式领导者的角色展开叙述，同时重点阐述仆人式领导者应有的基本内外特征。
新闻
该内容已经被标记书签！
标记书签错误，请重试！
敏捷和架构的冲突
作者 Vikas Hazrati 译者 金毅 发布于 2011年6月18日
实施敏捷方法和设计企业架构之间总是存在某种冲突。敏捷开发强调随着对业务领域的深入理解，逐步调整设计和计划。架构设计则要求建立起技术架构（technology stack）。它可以满足质量属性（quality attributes），也可以向感兴趣的利益关系人进行展示，作为一种沟通的途径。当使用敏捷方法来引领所需的架构设计的时候，两者强强联手将会是双赢。
Tom Graves认为敏捷需要一个脊柱来支撑。而软件架构提供了这个脊柱。
敏捷通常需要一个脊柱来指引方向——根据这个方向，推动一些工作的进行。这样做，相对于随意出牌，可以完成更多的工作。通常，这是个平衡问题——要在坚实的脊柱和敏捷之间有个良好的平衡。
Jan Van Til赞同Tom的观点，他认为没有后台的脊柱，前端也很难看得出有多敏捷。
我们当然需要一个相对进展“缓慢”的“后台”，这样才能让我们看清我们有多敏捷（“前端”）。如果所有的东西都很时尚...我们还能从中识别出哪个是时尚吗？我们当然需要一个有点“缓慢”的“后台”，这样才能让我们看清时尚（“前端”）。换句话说，我们需要传统的东西，没有传统的东西，也就没有了时尚。
Simon Brown觉得，甚至“绝大部分的敏捷项目”可能都有或大或小的架构方面的问题。我们需要在项目早期迭代中解决它们。Simon认为，敏捷和架构的冲突可以归结为是通过短迭代来交付商业价值，还是做一个庞大的预先设计。这里的关键点是设计要“刚刚好”（just enough）。准备好一个初步的结构是很重要的，但这不意味着就要画出无数的详细类图。
John Bauer则提到，在对几个项目观察了一段时间以后，他发现了一个有趣的模式。
敏捷以及那些类似敏捷的方法有个好处，对于产品来说，它能减少那些架构设计过度的软件解决方案（over architect-ed software solutions）的产生。架构设计过度的解决方案会强调软件应用项目的交付，也会使得软件开发和维护的成本上升，通常来说，是跟交付商业价值背道而驰的。
James Coplien和Kevlin Henney 给我们介绍了一种从项目开始的时候就进行“刚刚好”的架构设计，并且确保项目成功的有效方法。
但是，这一切在现实世界里又是怎么实现的呢？
Simon Brown在他的博文中提出了一个有趣的挑战：他要求在4个月左右的时间内，重新开发一个程序来取代老迈的在线银行系统 。他要求大家仍然使用敏捷方法，但最终还是能够交付。博文中提到了大家提出的一些方案，包括Kero和John Bauer的。你可以查询到更多的方案，也可以提出你自己的想法。
这样看来，架构设计和敏捷需要共存。不是有你没我，而且相互合作。这里的关键点就是做“刚刚好”的设计。 Simon 定义了“刚刚好”：
做一个“刚刚好”的架构，可以让你条理清晰，明确愿景。换句话说，“刚刚好”让你知道了你的目标是什么，你怎么去完成这个目标。背后的关键就是架构是一个重大的决定，而“重大”是由进行改变所需要的成本来衡量的。换而言之，这就是架构，想要修改真的会很贵，而且你真的必须尽早做出正确的决定。举个例子，质量属性，比如高性能，高扩展性，高安全性以及高可用性，通常都需要在早期就把这些考虑在基础框架内，因为想要在后期重新修改现有的基础代码库会很难。这也就是架构，你不可能在某个下午很简单地就进行重构，比如核心技术选择、架构模式、核心框架等。
查看英文原文：Agile and Architecture Conflict
译者 金毅 多年来服务于欧美软件外包行业从事管理工作，对软件工程、方法学等在外包业的运用和CMMI实施略有感悟。
敏捷是架构的脊柱
发表人
Chen Yongfu
发表于
Re: 敏捷是架构的脊柱
发表人
zhang mt
发表于
Re: 敏捷是架构的脊柱
发表人
Chen Yongfu
发表于
Re: 敏捷是架构的脊柱
发表人
ding simon
发表于
Re: 敏捷是架构的脊柱
发表人
. 西瓜肚圆圆
发表于
很搞
发表人
Zeng Abrams
发表于
先想明白
发表人
anchuan qian
发表于
-
“敏捷是架构的脊柱”，这句话十分贴切。敏捷应该在架构的基础上，如果没有架构为依托，不会有真正的敏捷，混乱倒是会多一些。
-
在哪本敏捷的书里面讲到不要架构，或是降低了架构的重要性啊？从一开始就敏捷就没有把自己放到与架构对立的位置上，而是那些对其没有深入研究而只是一知半解的人才如此认为。把敏捷宣言看完就开始对敏捷大肆评价甚至批判的人确实太多。要评价之前也要先多做些功课吧
-
你正好说反
-
说白了就是要想清楚了才才开始编程
-
反了么？
赞同敏捷是架构的脊柱，首先就认为敏捷和架构并不冲突。
其次，认为架构是个框，或者是条基线，敏捷并不能脱离或偏离于此。
其实，我人为两者并不是同一性质的概念，因此并不存在非此即彼的问题吗，也不存在对立的问题。
敏捷是一种开发模式，所以我认为架构是基础。 -
敏捷是架构的脊柱? 不赞同，两个没有完全必然的联系，敏捷是一种开发方式而已.
-
Design is not dead, 在前几个Sprint下做适当的up-front design是必要的。
-
他说的是架构师敏捷的脊柱，不是敏捷是架构的脊柱。
敏捷只是一种实现方式，总要建立在稳定的架构基础上才行。要不真是会越来越混乱，这也是我们正在面临的。每个人看了几本书都说自己动了敏捷的思想，都可以开个分享会将敏捷，但是真正懂得的有多少呢
8 条回复
关注此讨论 回复