出家如初，成佛有余

    现代制造业为了应对大规模定制（Mass Customization）的需求，大部分公司都采用了“产品线”管理模式。所谓“产品线”是指一群相关的产品，这类产品可能功能相似，销售给同一顾客群，经过相同的销售途径，或者在同一价格范围内等，采用产品线的典型案例有丰田、福特这样的汽车制造商，华为、思科这样的电信设备制造商，Nokia、Moto这样的手机制造商等等。B·约瑟夫·派恩(B·Joseph Pine II)在《大规模定制：企业竞争的新前沿》一书中写到：“大规模定制的核心是产品品种的多样化和定制化急剧增加，而不相应增加成本；范畴足个性化定制产品的大规模生产：其最大优点是提供战略优势和经济价值。”

    借鉴制造业大规模定制（Mass Customization）的生产方式，在软件架构实现上，卡耐基梅隆大学软件工程研究所（CMU/SEI）推出了软件产品线（Software Product Lines）模型。SEI对软件产品线定义为：A software product line (SPL) is a set of software-intensive systems that share a common, managed set of features satisfying the specific needs of a particular market segment or mission and that are developed from a common set of core assets in a prescribed way。

   软件产品线具有如下如下一些重要的特征：

• 一个软件产品线应该由一系列产品成员组成，即产品家族；产品家族中的所有产品都是服务于一些特定相似的领域，例如电信、教育、航空、数字娱乐等
• 一个产品线的定义是基于市场策略的，而不是基于它的成员产品之间的技术相似性。
• 产品家族成员在构建时候都利用了相同或相似的功能，这些功能来自一些公共的、固化的、并且是受严格管理的核心软件资产
• 软件产品线每个产品都是由来自公共资产库中的组件（Component）组成，然后按预定义的变化机制，如参数化或继承，对这些组件进行必要的剪裁，添加必须的新组件，根据一个产品线范围内的公共架构来组装这些组件。因此，构建一个具体软件产品（应用系统）的主要工作是组装或繁衍而不是创造；主要的活动是集成而不是编程。

1、产品线基础知识

                     

             产品线中产品、组件、架构、商业目标关系

                               产品线核心活动                           

                  Software Product Line Practice AREAS

  软件产品线的基础知识可以参考A Framework for Software Product Line Practice, Version 5.0

 

2、互联网产品线管理策略

    对于互联网平台化产品而言，最佳的实践模式也是软件产品线的模式。平台上的各个产品一般由同一公司不同部门或不同合作伙伴来运营、维护，具体可以体现为栏目、频道、产品、地区版块等。平台化产品中各个产品运营维护团队的不同，实际上是各个公司组织机构的映射，例如按客户群划分、按产品划分、按职能划分、按地域划分等等。为区分组织架构层面的产品线管理架构和软件产品线架构，后续将软件产品线都统一成为产品平台、平台。

    这些产品依托于统一的产品平台（产品线），平台提供了各产品间能够复用的业务组件、技术架构、信息架构、运营支撑体系等。通过这些公用架构、元素的复用，可以相对快速地满足各产品公用需求，在竞争上获得较大的优势，包括：

• 降低产品维护成本
• 加快产品上市速度
• 提高产品质量
• 降低新产品开发风险
• 有利于产品需求持续积累，为产品创新提供素材

   另外一方面，产品平台上的不同产品对公用组件的个性化需求、产品上线频率、产品维护能力、需求优先级、用户体验等要求都不尽相同，无法采用统一的、相对固化的策略来满足所有需求。尤其是各产品线对平台提供的公用元素也存在定制化需求，这些需求对平台的统一性、稳定性也存在较大挑战。如何在保证统一平台的前提下，能够敏捷响应各产品线的共性需求、个性化需求，充分复用已有业务沉淀的资产（产品资产、业务资产、技术资产），保证产品能够低成本、高质量、快速上市成为互联网企业的核心竞争力之一。

   在产品平台的管理上一般可以采用如下几种模式：

  1、产品平台由专职的平台管理维护团队来维护

     有专门的产品产品平台管理团队（产品、技术、UED等）来统一对平台进行管理维护，各产品线的共性需求、个性化需求都由这个平台维护团队来完成。

      优点：平台的策略相对延续，能够保证平台相对稳定性。

      缺点：由于互联网产品需求变化快、迭代周期较短，但按照平台管理流程，需要经过繁琐的审核流程，很难满足各产品线的敏捷响应的要求；各产品线间需求（个性化、共性）优先级的排序很难满足各产品线需求，对某个产品线至关重要的需求可能在整个排序中优先级很低

  2、各产品线有自己独立的产品团队、技术支撑团队

     各产品线的需求由自己的支撑团队来开发维护，基础公用平台及共性需求由单独团队来维护

       优点：能够快速响应各产品线的个性化需求

       缺点：各产品线支撑团队只关注自身短期需求的满足，不会从全局上考虑平台的整体性，而对于架构一点一滴无关紧要的修改最终会导致整个平台的变形和混乱；对公用需求的判定放到每一个产品线团队，大家倾向于快速满足自身的需求，平台的共性需求很难持续积累下来。

3、采用软件产品线的管理模式

      采用软件产品线的管理模式并不是对上述两种管理模式的完全否定，只是希望采用业界已有的最佳实践和框架作为指导原则，从而得出适合于互联网产品线管理的最佳实践。

      关于在互联网平台化产品中怎样使用SEI的软件产品线的具体策略后续具体思考和探讨。

    对于大部分的中国互联网企业而言，对成功商业模式克隆比“自主创新”更有吸引力、成本更低。在业务模式趋同，竞争日益白热化的情况下，网络营销能力也是一种核心竞争力。

    传统的市场营销方式相对容易，市场部只需要定期出几篇软文发给平面媒体、新闻门户等合作伙伴发布即可。但面对博客、微博、SNS等新媒体的普及导致的媒体去中心化，以及用户习惯从所谓的AIDMA营销法则（Attention关注 -> Interest兴趣 –> Desire渴望 -> Memory记忆 -> Action购买）到AISAS营销法则（Attention注意 –> Interest兴趣 –> Search搜索 –> Action行动 –> Share分享)转变，要让市场部那仅有的几个人在新形势下完美搞定网络营销挑战较大。因此好的营销工具成为市场部人员的有力战斗武器。

    很奇怪，除了一些诸如“自动发帖机”这样的客户端外，市面上似乎没有一个客户端来针对网络营销来提供一揽子的解决方案。或许有开发能力的公司内部都有一套这样的工具，只不过大家都不愿意把自己的杀手锏公开化。其实像“菊子曰”这样的客户端干这事情挺有优势的，至少比针对普通大众做博客发布工具更容易找到盈利模式。

1、网络营销客户端的需求

    危机公关： 最大限度降低公司负面新闻的影响
    舆论监控： 实时监控各种媒体有关公司的正面、负面新闻
    竞争情报分析：实时监控、收集各大竞争对手的竞争情报
    整合营销：在各大新闻门户、社区、论坛、微博等新媒体一键式发布正面新闻，EDM、SDM等 

2、网络营销客户端技术方案

    在传统软件产品发布过程中（例如微软的Windows 7的发布过程中），一般都会经历Pre-Alpha、Alpha、Beta、Release candidate(RC)、RTM、General availability or General Acceptance (GA)等几个阶段（参考Software release life cycle）。可以看出传统软件的发布阶段是从公司内部->外部小范围测试>外部大范围测试->正式发布，涉及的用户数也是逐步放量的过程。

    在互联网产品的发布过程中也较多采用此种发布方式：产品的发布过程不是一蹴而就，而是逐步扩大使用用户的范围，从公司内部用户->忠诚度较高的种子用户->更大范围的活跃用户->所有用户。在此过程中，产品团队根据用户的反馈及时完善产品相关功能。此种发布方式，按照中国特色的叫法被冠以”灰度发布“、”灰度放量“、”分流发布“。

    关于“灰度发布”叫法的来源无从考察。只不过按照中国传统哲学的说法来看，很符合中国人中庸的思维模式：自然界所有的事物总是以对称、互补、和谐的形式存在，例如黑与白、阴与阳、正与负、福与祸。在二元对立的元素间存在相互过渡的阶段，所谓”祸兮福所倚，福兮祸所伏“。具体到黑与白，在非黑即白中间还有中间色——灰色。于是出现了很多关于灰色的说法：灰盒测试，灰色管理（极力推荐 任正非：管理的灰度），灰色收入，灰色地带等等。因此对于灰度发布实际上就是从不发布，然后逐渐过渡到正式发布的一个过程。

1、灰度发布的作用

• 及早获得用户的意见反馈，完善产品功能，提升产品质量
• 让用户参与产品测试，加强与用户互动
• 降低产品升级所影响的用户范围
• 。。。

2、灰度发布的步骤

  1）、定义目标

  2）、选定策略：包括用户规模、发布频率、功能覆盖度、回滚策略、运营策略、新旧系统部署策略等

  3）、筛选用户：包括用户特征、用户数量、用户常用功能、用户范围等

  4）、部署系统：部署新系统、部署用户行为分析系统（web analytics）、设定分流规则、运营数据分析、分流规则微调

  5）、发布总结：用户行为分析报告、用户问卷调查、社会化媒体意见收集、形成产品功能改进列表

  6）、产品完善

  7）、新一轮灰度发布或完整发布

3、常见问题

  3.1）、以偏概全

         1)、问题特征：

              a、选择的样本不具有代表性；

              b、样本具有代表性，但选择样本用户使用习惯并没有涵盖所有核心功能
         2）、解决方案：

              样本选择要多样化，样本的组合涵盖大部分核心功能

  3.2）、知识的诅咒

        ”知识的诅咒“的说法来自《粘住》中实验，具体可以自己搜索一下。我们自己对于自己开发的产品极为熟悉，于是乎想当然认为用户也应当能够理解产品的设计思路、产品的功能使用。

         1）、问题特征：

               a、结果没有量化手段；

               b、只依赖于用户问卷调查；

               c、没有web analytics系统；

               d、运营数据不全面，只有核心业务指标（例如交易量），没有用户体验指标

               e、对结果分析，只选择对发布有利的信息，对其他视而不见
          2）、解决方案：
               a、产品设计考虑产品量化指标
               b、结果分析依据量化指标而不是感觉

  3.3）、发布没有回头路可走

        1）、问题特征：

              a、新旧系统用户使用习惯差异太大，没有兼容原有功能

              b、新旧系统由于功能差异太大，无法并行运行，只能强制升级

              c、新系统只是实现了旧系统部分功能，用户要完整使用所有功能，要在 在新旧系统切换

              d、新旧系统数据库数据结构差异太大，无法并行运行

         2）、解决方案：

              前期产品策划重点考虑这些问题，包括：

                  回滚方案、 新旧系统兼容方案、用户体验的一致性、用户使用习惯的延续性、新旧系统数据模型兼容性

  3.4）、用户参与度不够

         1）、问题特征：

                 a、指望用户自己去挖掘所有功能。对于一个产品，大部分用户经常只使用部分功能，用户大部分也很懒惰，不会主动去挖掘产品功能
                 b、互动渠道单一
                 c、陷入“知识的诅咒”，不尊重参与用户意见
        2）、解决方案：
                a、善待吃螃蟹的样本用户，包括给予参与测试的用户小奖励（例如MS给参与Win7测试用户正版License）、给用户冠以title
                b、通过邮件、论坛、社区、Blog、Twitter等新媒体与用户形成互动
                c、提供产品功能向导。在hotmail最近的升级后的功能tip，gmail的tip都有类似的产品功能导向。在产品中会提示类似于：你知道吗，xx还提供xx功能，通过它你可以xx 。

 

4、灰度发布  VS.  A/B测试

    灰度发布于互联网公司常用A/B测试似乎比较类似，老外似乎并没有所谓的灰度发布的概念。按照wikipedia中对A/B测试的定义，A/B测试又叫：A/B/N Testing、Multivariate Testing，因此本质上灰度测试可以算作A/B测试的一种特例。只不过为了术语上不至于等同搞混淆，谈谈自己理解的两者的差异。

    灰度发布是对某一产品的发布逐步扩大使用群体范围，也叫灰度放量

    A/B测试重点是在几种方案中选择最优方案

   关于A/B测试可以参考这篇文章：A/B测试终极指南

5、灰度发布引擎

   对于一般的小系统并不需要单独的灰度发布引擎，可以参考A/B测试中做法，在页面javascript或服务器端实现分流的规则即可。但对于大型的互联网应用而言，单独的用于管理用户分流的发布引擎就很有必要了。“钱掌柜”分流发布模式 提到了原来阿里软件所使用的灰度发布引擎，设计思路具有普遍性，可以供参考

6、参考文档

  “钱掌柜”分流发布模式

   百度百科：灰度发布

   A/B testing

   A/B测试终极指南

   前两天接到了蜘蛛网客服的电话，说我年初通过他们网站订阅中国经营报时候，中国经营报赠送了几本书。这段时间中国经营报那边盘点时候发现给我的赠书一直没有送出，中国经营报那边向蜘蛛网询问情况。客服说蜘蛛网这边一直也没有收到我的投诉，因此直到中国经营报问起他们最近才发现此事。

    年初订阅杂志时候，平常也没时间去邮局，因此就直接在蜘蛛网上订了常看的几本杂志和报纸，其中就包括中国经营报。中国经营报赠送了洗衣液和几本图书。洗衣液几周以后很快就送到了，而图书过了1个月还没到，给蜘蛛网发过3次邮件投诉。第1次的回复说是已经反映到相关部门了。过了一个多月赠书还是没有送到，再发了两次邮件投诉后都没人搭理了，打了几次电话都没打通。由于对赠送的几本图书并不是很感兴趣，因此也懒得再催了。通过此事体验了一下蜘蛛网极差的服务，打算以后不再使用蜘蛛网。

    其实细想一下，也不能完全说是蜘蛛网的问题，大致的原因应该如下：

   根据中国经营报在其网站及报纸上的广告，订报送洗衣液和赠书的活动应该是中国经营报自己举办的。蜘蛛网只是类似于邮局的一个订阅渠道而已。蜘蛛网应该把我的订单传送给中国经营报了，不然中国经营报就不会每周送报，也不会安排人赠送洗衣液。预计中国经营报订报送赠品活动也是找不同的合作伙伴来弄的。例如洗衣液是开米出的，而图书又是其他合作商来弄的。因此中国经营报收到订单后，也把订单同步给了提供洗衣液的合作伙伴，但在处理过程中，把赠书的事情拉下了。

    当然并不是说蜘蛛网没有责任，其实在这过程中，蜘蛛网有很多可以改进的。而蜘蛛网与线下合作伙伴合作过程中所面临的服务品质问题也是众多电子商务提供商所面临，关于服务品质一些体会：

  1、多种客服渠道的服务体系一致性的问题：蜘蛛网的服务渠道应该主要是电话，像我通过邮件的投诉应该并没有整合到其整个呼叫中心体系中去，因此出现了我没投诉过的事情。这与电子商务企业的客户服务系统建设-再谈京东商城购物所感 中提到的类似。呼叫中心！=电话服务中心。如果不能够将同一客户通过传真、Email、IVR、电话、短信、电话、IM、社区、论坛等各种渠道的投诉申告等整合到一起，各种服务渠道的服务品质不能够保证一致性，则所谓的“以客户为中心”只能是空谈。其实并不需要呼叫中心建设时候在技术上必须支持所谓的多媒体呼叫中心、第三代、第四代呼叫中心等等。问题的关键还是在意识和管理体系上。

  2、服务边界问题：对蜘蛛网而言，其只要引导客户生成订阅订单并成功支付后，蜘蛛网将订阅订单成功发送给合伙伙伴，则在其平台的服务就结束了，后续的服务品质的保证蜘蛛网就无能为力了。这也是目前大部分电子商务网站的模式。但对于客户而言，并不关心后续服务是谁提供的，他只关心在单一的接触点，服务都能够得到保障。对于蜘蛛网这些前端提供服务的电子商务提供商而言，其服务的边界不单纯只是自己，还包括相关的合作伙伴。这正如电子商务平台之平台服务杂思 中谈到的：“在面临日益剧烈的竞争下，平台服务对于合作商户的核心价值在于：通过平台来帮助其提高竞争力。这种竞争力包括服务能力、盈利能力、营销能力、服务的持久性等。”

    这也是为何沃尔玛、麦当劳、Dell这些跨国公司其实将采购价格压得很低，但一堆合作厂商还是愿意挤破头去竞争合作伙伴的名额，除了品牌、销量因素外，还有重要的一点是：沃尔玛这些厂商会帮助合作伙伴提高标准化管理能力、服务的品质和能力。

   3、服务无小事：自己作为服务提供商服务时候，总觉得大部分客户的投诉都是鸡毛蒜皮的问题，并不影响产品使用，觉得主要是客户素质太差。当自己作为客户使用蜘蛛网这样的服务时候，才发现：我们作为客户在使用别的服务提供商的产品时候总是比我们自己作为服务提供商时候的标准更高、更没有耐心。可能只是一件鸡毛蒜皮的事情就会导致我们很不爽，从此不再使用此服务。在做产品时候，“同理心”是一种很好的手段，但“同理心”并不等于实际用户的心理，只是我们的揣测。作为客户和作为提供商时候，我们的标准体系并不一样。

    因此应当善待每一次的客户投诉及不爽，每一次的投诉都是我们改进产品最好的机会。对于客户投诉不妨想得更加严重一些。

  4、服务品质也是一种品牌：最为典型的例子要数海尔。海尔的产品可以概括为：一流的服务、二流的产品（耗电、价格高、质量一般），但并不妨碍海尔产品的口碑。个人认为海尔的品牌就是其服务品质所造就的。对于互联网服务提供商同样如此，服务也是一种核心竞争力，尤其是对于那些竞争激烈的产品。在选择产品以及合作伙伴时候，如果所提供的产品的服务品质不能保证，再赚钱的产品也会成为品牌的杀手，这时候要勇敢学会放弃。在做市场营销、网络营销时候也是如此。

 

1、为什么要进行产品重构

    旧系统人员流失，系统的业务规则、原始需求谁都不清楚，需求文档、使用文档、架构文档极其缺乏，成为一个无底洞，可维护性很差。  

    旧系统越来越复杂，潜规则太多，原本修改一个小需求，一不小心搞得上线后影响一堆用户

    旧系统的业务架构、技术架构无法满足新的业务模式需要

    旧系统性能无法满足公司业务高速发展的需要

    旧系统的产品生命周期已经到头，需要延长期生命周期

    等等

2、产品重构  VS.  重做新产品

    对现有产品进行重构还是重新做一套全新的系统并没有标准答案。技术人员们都倾向于重做新系统，并都倾向于高估自身的管理能力、架构设计能力,大家都会承诺完美的架构、完美的产品规划。但如果没解决根本性的管理问题，重构或是重做宿命都是一样的。这些管理问题包括产品规划能力、业务架构能力、项目管理能力、架构管理能力、架构设计能力等等。   

   在管理能力尚未改善的情况下，怎样保证重做新系统时候不落入旧系统“新做系统，承诺完美架构->管理失衡，系统维护陷入混乱->再重做新系统”同样的命运。好的架构是管理出来的，不是设计出来的。

  产品重构第一困难的是反向工程过程阶段，必须搞清楚现有系统的遗产状况。对于一个在线运营的系统，不管是重构还是重做都必须经历此过程

  产品重构第二困难的是旧系统迁移到重构系统的过程。怎样做到不影响现有客户使用的情况下完成灰度切换，这是最大的挑战。不管是重构或是重做都必须经历此过程

3、关于产品重构的思考

4、参考资料

  The Product Re Architecture

  利用 RUP 对遗留系统进行逆向工程 

  软件架构的艺术

 

     某一天老板或者销售人员跑过来亲切和蔼地拍拍你说：有个战略性产品需要在一个月之内开发出来，对搞定几个重点大商户至关重要，时间没有商量的余地。党组织从众多的党员同志中选择了你，这是党对你的信任，也是考验你的时候了。在生活的压力和生命的尊严之间，你只好泪流满面地接了下来。

1、不可能完成项目的典型特征

    对于互联网公司及做传统系统集成的公司的同志们而言，接到这样不可能完成的项目开发任务的情况已经司空见惯了。这些不可能完成项目的典型特征如下：

• 老板说：项目对公司具有战略意义，必须搞定
• 项目突发：销售跑过来告诉你，一个月内必须搞定这个项目
• 需求不明确
• 对现有系统架构有较大冲击，改动风险很大
• 项目给的时间很短且交付时间固定(time boxing) ，只能够倒推
• 销售过度承诺，必须实现狂复杂、狂大的需求
• 资源有限
• 设计诸多部门协调，很难短期搞定

2 、失败项目的典型症状

• 项目组所有成员及利益相关者对项目愿景及目标没有达成一致
• 为了赶进度，压缩需求分析、系统设计时间，需求理解尚未统一就投入开发
• 每个人只关心自己负责的一小块业务，对系统整体需求、架构、设计没有达成一致
• 为了赶进度，只关注功能的完成而忽视了功能实现的质量，导致大规模的返工
• 为了赶进度，不进行统一设计，由各模块负责人自己设计，设计存在较大缺陷
• 公用问题没有专人负责，工作重复
• 项目组成员沟通不畅，出问题后才沟通，导致无谓的时间浪费
• 项目组没有形成团队文化，团队成员只是为了完成项目目标而加班赶工，没有归属感

3、不可能完成项目的Scrum实践

    对于这样的不可能完成项目的管理使用Scrum这样的Time Boxing迭代开发过程很恰当，关于实践方法有兴趣的可以参考脑图。

   

原图点击下载

 

4、参考资料：

Quick-Kill Project Management

Quick-Kill 项目管理（完成“不可能的”任务）

用“看板图”实现敏捷项目的可视化

硝烟中的Scrum和XP

EssUP迭代核心——时间盒 Time boxing

 

1、敏捷软件开发不需要架构设计？

    相对于传统瀑布式开发过程及RUP这样的重量级开发过程而言，敏捷软件“重视与客户的沟通；小步快跑，尽早交付；迭代式开发，拥抱变化”等实践正好符合互联网要求快速迭代、坚持以用户为中心的设计（UCD）等特征相吻合，因此敏捷软甲开发过程成为了互联网软件开发的标准模式。

    一直以来都觉得敏捷软件是“轻架构设计”的，不管是XP、Scrum、FDD、Getting Real等敏捷软件开发过程对待设计（Design）的理念都遵循了演进式设计 (evolutionary design) 而非计划性的设计(Planned Design)。

    而且由于类似于Ruby on Rails、SSH（Struts+Spring+Hibernate）、Django、CakePHP这样快速开发架构的出现，技术架构已经成为流行的术语，一个刚毕业的小孩也能够大谈架构设计、设计模式、架构模式，传统的架构设计似乎已经没有太多的必要。

    但在实践过程中，会发现轻架构设计的一堆严重后果，诸如：陷入了"code and fix" 的恶梦；系统越来越复杂和混乱，架构完全失控；

    再读Martin Fowler的《Is Design Dead?》，才发现自己对于敏捷软件的理解是如此的教条：

  Continuous integration、testing 和 refactoring 这些有效的实作方法让 evolutionary design 看似很有道理。但是我们尚未找出其间的平衡点。我相信，不论外界对 XP 存有什么印象，XP 不仅仅是 testing、coding 和 refactoring。在 coding 之前还有 design 的必要。部份的 design 在 coding 之前准备，大部份的 design 则发生在实作每一项详列的功能之前。总之，在 up-front design 和 refactoring 之间可以找到新的平衡。

   大师不愧为大师，能够准确把握住事物的本质，能够把握住过犹不及的度。其实任何方法论都有其应用的边界，方法论没有问题，错误的根源在于使用方法论的人的教条主义。

2、形形色色的架构

    “架构”这词成为了一个技术领域时尚的话题，每一个人都在谈论架构，似乎不谈架构就没有技术品位，于是乎出现了一堆与架构有关的术语，包括：软件架构（Software Architecture）、系统架构（System Architecture）、企业架构（Enterprise Architecture ）、信息架构（Information Architecture ）、应用架构（Application Architecture ）、IT架构（IT Architecture）、产品架构（Product Architecture）、业务架构（Business Architecture）、技术架构（Technology Architecture）、解决方案架构（Solution Architecture）、基础架构（Infrastructure Architecture）、领域架构（Domain Architecture）

3、敏捷架构

    敏捷模型驱动开发(Agile Model Driven Development)中对于Agile Architecture Modeling有比较清晰的描述，也回答了为何在敏捷软件开发过程中需要进行架构设计的原因：

    1）、Improved productivity. You can think through some of the critical technical issues facing your project and potentially avoid going down fruitless technical paths.

    2）、Reduced technical risk. Your team gains the advantage of having a guiding vision without the disadvantage of having to overbuild your system – just because you’ve modeled it doesn’t mean you have to build it.   

    3）、Reduced development time.  Initial agile architecture modeling enables you to make better cost and time estimates for your project, two pieces of information which management will want.  

    4）、Improved communication.  Having a high-level architecture model helps you to communicate what you think you’re going to build and how you think that you’ll build it, two more critical pieces of information desired by management.

    5）、Scaling agile software development.  Your initial architecture model will be a key work product in any "agile at scale" efforts because it provides the technical direction required by sub-teams to define and guide their efforts within the overall project.

    6）、Improved team organization. Effective teams are organized around the architecture or line of business, not around job function.  As you scale to larger and/or distributed teams the sub-teams should each be responsible for one or more sub-systems — you don’t want to organize your sub-teams around job function (e.g. an architecture team, a development team, a testing team, …) because that requires you to increase the documentation and bureaucracy overhead which in turn increases risk, cost, and time to value.

   相对于其他的敏捷软件开发过程，在Agile Model Driven Development（AMDD）中明确包括了初始需求分析与架构建模，这个过程发生在敏捷项目开发的第0次迭代中。所谓第0次迭代，就相当于项目的热身活动，是项目得以启动的基础。

 

    Agile Enterprise Architecture 中谈到了敏捷软件架构的一些指导思想：

    1）、Focus on people, not technology or techniques

    2）、Keep it simple

    3）、Work iteratively and incrementally

    4）、Roll up your sleeves

    5）、Look at the whole picture

    6）、Make enterprise architecture attractive to your customers

4、关于架构的一些思考

4.1、架构！=技术架构

    敏捷架构并不只是指技术架构本身，正如前面提到的，还包括产品架构、业务架构、信息架构、应用架构等等。

    技术架构不单纯只是技术实现本身，还承载了业务架构、产品架构、信息架构、应用架构的具体实现，纯粹的技术框架本身没有太多的价值。纯粹的技术框架的架构可以一次性完成，但对于业务架构、产品架构的架构必须随着公司对于行业深入的了解才能逐步完善，对于业务需求的管理能力成为一个公司发展的决定性因素。

    对于一个运营型的互联网公司，核心的竞争力之一在于对所服务的行业业务及客户深刻的理解并具备将这种行业经验转化为产品及服务的能力。互联网在服务过程中积累的不单纯只是技术架构的积累，更为重要的是行业需求的积累，而这需要对应的业务架构和产品架构来作为持续积累的框架。技术架构可以较为容易获取和变迁，但行业经验却难以短期突破。

    对于中国这些互联网公司而言，基本上没有太多原创的产品，尚没有能力做到技术驱动、创新驱动的层次，大家还停留在做简单的行业应用上，公司间的竞争基本上也停留在应用开发能力及运营能力的竞争。因此对于中国互联网公司而言，合理的业务架构及产品架构比技术架构本身意义更为重要。

4.2、架构是管理出来的，而不是架构出来的

    在中国公司比较典型的情景：

    1）、公司原有架构师及开发人员因为某种原因离职，公司招聘一个新的架构师

    2）、新的架构师被公司寄予较大期望，由于维护老的架构吃力不讨好，而架构师要急于证明自己的能力，最为简单有效的办法就是重做一套系统。

    3）、新的架构师将原有的架构推倒再重新做一遍，并承诺了完美的架构：能够解决目前产品、运营、财务人员们面临的所有问题

    4）、新的架构上线后架构师及技术人员不断应付开发新的需求和迁移老的需求，疲于奔命，没有精力去整体把控架构，于是将架构的维护权限移交给每一个开发人员

    5）、销售、运营、财务发现与当初承诺的需求不符合，投诉不断；架构师认为已经完成系统架构，剩下的都是开发的问题、产品的问题

    6）、新的架构被否定掉，开发人员们或是离职或是沉沦

    7）、同样的悲剧不断上演

    一个好的架构不是一蹴而就的，没有一个架构是一次性完美地架构出来的，完美架构的诀窍就在于持续维护、持续完善。任何架构都有一个从孕育->诞生->成长->成熟->衰退的演进过程，没有经历风雨的完美架构只能是温室中的鲜花。

    对于架构的持续完善不单纯只是一个技术问题，而是一个研发管理的核心问题，架构的完善应当贯穿于市场管理流程、需求管理流程、产品研发流程各大流程中。对于架构的管理必须有专门的组织机构、流程制度来保障。

    可以说一个好的架构不是架构出来的，而是管理出来的，对于架构的管理体现了一个公司的研发管理能力。

 

5、参考文档

    Is Design Dead?

    Agile Architecture: Strategies for Scaling Agile Development

    Agile Enterprise Architecture

    The Agile Unified Process (AUP)