领导力大挑战
在实施Scrum项目的过程中，Scrum Master的角色是相当关键的，因为他是团队的推动者。本文围绕什么是仆人式领导、仆人式领导的起源、如何将领导力传达给团队、Scrum Master作为仆人式领导者的角色展开叙述，同时重点阐述仆人式领导者应有的基本内外特征。
新闻
该内容已经被标记书签！
标记书签错误，请重试！
敏捷与架构——不共戴天，抑或和谐共处？
作者 Shane Hastie 译者 金明 发布于 2010年5月24日
很多评论人士一直在讨论：人们认为，在敏捷技巧和架构思维之间存在对立关系。
在敏捷世界中，架构通常被认为是BDUF（Big Design Up Front，大规模预先设计），因而在“YAGNI”（You ain’t gonna need it，你不会需要它）信条的指引下被忽视或者推迟。
从另一方面来看，正如IEEE Software Magazine2010年3/4月刊指出的一样：
敏捷开发已经极大地影响了软件行业的开发实践。然而，暂且不论它在全世界的流行，敏捷方法中存在这一个日趋强烈的关于软件架构师角色和重要性的困惑：很多人坚持“在大型软件密集型的系统中，架构师在达成质量目标的过程中扮演着关键性角色”这一观点，而他们质疑任何对架构不够重视的开发方法能否普遍适用。
……
IEEE推出的特别版关注在敏捷和架构之间的关系，探究由敏捷和架构之间的冲突派生而出的“错误的对立关系”。
在该特别版的介绍文字中，编辑们引用了一些敏捷思想领袖在架构方面的观点：
另外还有一个因素是从第一个sprint或者迭代一开始就“向利益干系人交付价值”。但开发人员，而不仅仅是最终用户，是否属于利益干系人的一个关键类别？Alistair Cockburn构思了一个策略，是始于“可行走的骨架”（walking skeleton），然后再迭代地演化。Mary和Tom Poppendieck提出了“可分割系统架构”的概念。最后，Kent Beck的建议是“架构在XP项目里面跟在其他软件项目中一样重要。架构的一部分是通过系统隐喻[XP实践之一]来捕捉的。”
这篇文章继续甄别出了在解决敏捷和框架之间的冲突时，需要明确的“真正问题”：
- 明确语义 —— 组织或项目使用“架构”，究竟是指什么。不是所有的设计决定都关乎架构，事实上，很少的设计决定达到了架构级别的重要性，很多项目团队在开发流程的非常早期就做出了这些决定。
- 上下文是关键 —— 该项目的环境：如组织、业务领域、现有技术、项目规模、变化率、系统寿命、重要程度、治理、市场状况和预期寿命等等方面都影响了需要做出的架构决策。
- 在生命周期中的阶段 —— 架构决策应该在生命周期中及早地作出，因为“架构包含了一组关于系统结构和行为的重大决定”。这些决定在后期将很难改变，因此架构的故事应该在早期的迭代中就融入到功能性故事之中。
- 架构师的角色 —— Martin Fowler谈及了架构师的两个方面：
- Architectus reloadus —— 重大决策的制定者和坚持者、注重对外的协调。
- Architectus oryzus —— 亲自写代码、导师、榜样和困难解决者、注重开发团队内部的协调。
- 不是所有的文档都是坏的 —— 在大多数情况下，架构需求可以表示为一个“walking skeleton”原型，仅仅针对于由少量可靠的隐喻支撑的最终目标框架。然而，也许是为了证明框架与外部规则的兼容性，或者向一个大型的、分布式团队传达，有时可能也会需要更明确的架构文件。
- 架构有方法 —— 敏捷方法在如何定义架构方面通常陷于沉默，即便是那些明确指出架构价值的方法。花一些时间和精力探索可用的架构方法（文章列出了其中一些方法）是值得的。
- 架构有价值 —— 架构成本很容易显现，特别是针对于BDUF方法，但价值可能并不总是立刻显现。用业务价值术语表达架构方面的需求，有助于揭示架构在项目中交付的价值。
（Martin）Bob大叔在他的Object Mentor博客中写道：
关于敏捷开发更阴险和流传深远的神话之一是：前期的架构和设计不好，你永远都不应该花时间在前期制定架构上的决策。相反，你应该让你的架构和设计一次一个测试用例地、从无到有地进行演化。
请原谅我，但那种说法确实是扯淡。
这个迷思根本不是敏捷的一部分。相反，它是针对“真正的敏捷取缔大规模预先设计（BDUF）”的、过于激进的言论。毫无疑问，BDUF是有害的。设计人员和架构师花费连续几个月，基于由菊花链连接起来的、未经检验的假设来设计系统，实在是毫无意义。套用John Gall的话：从头设计的复杂系统从来都工作不了。
但是，有些架构上的问题也需要在前期解决。有些设计决定必须尽早做出。埋头代码可能会把你带向肮脏的死胡同，如果提前做一些考虑，这很可能就可以避免。
请注意这里强调的大小。大小非常重要！ “大”是糟糕的，但“小”是很好的。事实上，LDUF是绝对必要的。
敏捷Architect网站也给出了一些具体的建议：
敏捷开发方法试图改善软件开发过程，使得我们可以更频繁地、更快地交付有效的解决方案。然而，尽管存在着一些成功案例，大型企业和项目在采纳敏捷上还是非常缓慢。其中一个原因是，很多敏捷方法被认为在架构方面比较弱，与复杂企业环境中交付大型系统的现实完全脱节。同时，许多架构流程被视为缓慢、笨拙和官僚。他们将从一个更敏捷的方法中受益。本网站通过把敏捷带给架构和把架构带入敏捷，来找出解决这一困境的方法。
你的团队如何克服BDUF和LDUF之间的隔阂？你是否认为敏捷与架构之间存在着冲突呢？
查看英文原文：Agile Architecture - Oxymoron or Sensible Partnership?
译者 金明 是ThoughtWorks咨询师，SCJP，系统分析师。关注敏捷方法学，特别是敏捷实施和项目管理的实践。
walking skeleton
发表人
Yao Scott
发表于
解决方案
发表人
yongji zhang
发表于
Re: 解决方案
发表人
Bai John
发表于
Re: 解决方案
发表人
李 冬
发表于
Re: 解决方案
发表人
陈 之过
发表于
说的太好了!
发表人
陈 之过
发表于
我不懂什么叫“菊花链”
发表人
Ma Karl
发表于
行业解决方案
发表人
Ge Xiangping
发表于
-
walking skeleton很贴切～
-
如果把敏捷比作是从上海到北京的一段旅程，边走边解决是没问题的。
但是如果一开始方向就走错了，走到广东去了，那就不对了，所以这里的大方向就是架构。
或者认为是初步解决方案。
敏捷的自适应，也是在对整个业务上下文，目标，有个了解的基础上进行的。 -
很久以来一直困扰的问题,今天终于有所突破...
-
我感觉你的这个说法更像是用户需求，而不是所谓的架构。
换句话说用户实际需要个CRM系统，你最终给用户的是一个ERP系统。 -
有道理 项目是无法分解的错综复杂的任务 一段旅程那可简单了很多 呵呵
-
RT
-
敏捷的特点就灵活,一开始走错方面没关系啊,敏捷不会假想一开始就是正确的,恰恰相反,敏捷总是假想一开始是错的,然后去修正它
-
就国内行业解决方案的项目来说，我认为敏捷主要应该是针对业务细节上的敏捷，避免在业务理解、业务流程上走错的太远。
所谓架构，无非是针对业务结构，交互接口等做技术选型，这步应该是在架构验证阶段首先敲定的框，而不是在迭代开发过程中再来验证。
8 条回复
关注此讨论 回复