敏捷已死，而敏捷性长存。

在第一块看板前，邀请一些资深同学就这块看板和它背后的“风险驱动的架构设计”方法进行了一些讨论。

敏捷已死，而敏捷性长存。

这是一个架构“普通”的项目。也是第一个系统实践“风险驱动架构设计”的项目。

敏捷已死，而敏捷性长存。

何为风险驱动的架构设计？ 该方法认为：

• 架构设计的（唯一）目的是应对工程风险。
• 当且仅当有风险被识别的时候需要考虑是否进行相应的架构设计。
• 架构设计采用的技术和投入的资源要与对应风险种类和程度相适应。
• 风险本身或/和对风险的认识会发生改变，相应的架构设计活动也会改变，架构设计结果也会改变。
• 风险驱动架构设计方法适合敏捷开发过程。

敏捷已死，而敏捷性长存。

Q：敏捷开发过程貌似不需要架构设计，不需要架构师角色？
A：任何开发过程是否需要架构设计，不是由采用什么过程决定的，而是由需要完成的开发任务决定的。 如果开发的系统/软件有架构问题需要解决，不论采用何种开发过程、是否采用敏捷过程，都需要架构设计。 如果需要架构设计，而开发团队不确定有能力进行架构设计，那么团队就需要架构师介入/加入。

雪人项目进行得还算顺利。然而你发现兄弟们常常盯着雪人的肚皮部位窃窃私语。 这些人都是多啦A梦设计风格的铁根粉丝，你能感受到设计一个口袋对他们来说是非常巨大的诱惑。 你曾经反复解释口袋有多危险，明令禁止任何设计口袋的企图。然而你知道这些根本无法打消你的担忧。

你埋头迅速制造了一个口袋，不是华丽的、未知的、危险的口袋，而是一个简单、简陋、安全、甚至没有完全完成的口袋。“啪”，你把口袋拍在雪人肚子上。 你感到世界清净下来。你傻笑，认为自己理解了一个高大上的词语，叫做：“提升至架构的设计”。

看到了芝明同学的博客以及引擎octopress, 感觉漂亮又方便，于是把博客搬家了。

最近有架构师在架构师列表提问关于web/app服务器分离的架构风格。参与了讨论，摘录如下：

好的架构师说：好吧，重做是架构进化的一种形式，我们下一个架构将解决这些问题；脾气好的架构师说：好吧，你是老板，你说重做我们就重做；2b架构师说：重做？mb你是老板你了不起么？老子的架构不够nb么？老子的xxx风格yyy模式你sb懂得起么？

一只乌鸦口渴了……，可是他早上买的酸奶没拿吸管，他的勺子比瓶子口大……，这时候一只老乌鸦走过来，分享了他处理类似问题的经验，并声称已经已经被广为使用和验证。 乌鸦感到庆幸，立即找来了很多石子儿……，直到他认识到他要对付的是酸奶，而不是清水。

乌鸦看着表面上堆着石子儿的酸奶，自我感觉对“模式”的认识深了些。

“通用”是手段而不是目的，“结构”也一样，甚而“简单”也一样。感受下呢。