最近加入新团队，尝试新的项目类型，一段时间一下也感谢颇深，目前也算是深入了解了团队和部分项目，其实平时也经常习惯性的思考团队分工协作这些方面的东西，鉴于目前团队状态和先前已经有明显区别，自然也萌生不同的思考。

之前的思考：http://www.cnblogs.com/wsky/archive/2009/07/18/1526266.html

老实说本人是带着先入为主的想法而来的，一向推崇敏捷，推崇领域驱动设计（下文称DDD），故而也无时不刻向周围的同事渗透这些思想和倾向，特别是目前是从事企业应用方面开发工作，业务导向，尤为适合。

针对目前的主要系统（下文以wf称，企业应用）和团队，且听笔者一一分析道来.

目前wf团队人员组成，与一般互联网项目相比优势之一就是需求分析师经验丰富，均可算是某一业务领域的专家，比起辛辛苦苦白手起家的web2.0创业型项目来说，我们可说有着无比清晰的系统建设方向，靠谱的需求来源。需求的方向性是明确的，这点对于开发者来说是最好不过了，我们说“靠谱”很重要，企业应用应该不至于让你被需求雷死：）。既然如此，为什么不用好这些资源呢？因为是企业内部，我们总是能和需求方以及业务专家保持直接有效的沟通，他们能够且应该比开发人员更了解业务该如何设计和系统该如何被使用，这便是实施领域驱动设计最为重要的资源和前提，业务是最具有价值的，因而我们希望并且应该做到当业务在系统中被实现时，它是可重用，可理解，可验证的，而不是用一堆晦涩的脚本或者数据库表来描述牵强的描述它。往往我们在和业务专家沟通的时候，他们已经参与或者在帮助我们设计业务，他们期望系统中业务的运行/实现方式是如他们所描述的一致，这对于业务的深入和衍进具有很大的意义，业务在专家的脑子里，若我们的设计映射了这种业务描述，那么也就等于系统/业务设计也就在他们的脑海中。

当下，企业信息化阶段已经从早期的企业网站式向企业IT系统化转变，IT系统将对企业发展提供全面支持和对业务的灵活响应，您无法难要求您的开发人员都是业务能手，但是您是否发现原来身边的业务部门人员都是天生的业务专家，如果让他们参与系统设计，让领域专家来支持您的企业信息化建设是不是能让系统更良好的支撑业务要求？

Ok，对于以上文字，笔者得出的结论就是：业务是最具有价值的，业务系统应该重视和维持价值而不是断章取义的代码设计。

接下来，笔者假设您同意了这个结论，往下看。

上文反复提到让业务专家来设计业务和系统，那么如何来具体实施？业务需要描述，同时也需要被实现为可用代码，显然业务专家不认识C#/Java，因而业界提出了所谓DSL这样的领域特定语言作为中间语言来连通业务和系统实现，DSL最近很火热的，感兴趣的具体您可以去了解一下。笔者认为目前这个还是概念，理想化的东西，业界希望定义出诸如工业标准的东西，理智对待即可，取合适而用之，“软件开发没有银弹”，DDD也是一种应对之道而已。

回归正题，如何实施。简单而言，我们需要和业务专家一起进行系统的设计，用双方均可理解的方式和语言来描述业务和设计，设计应和分析后达成一致的业务描述可一一映射，业务专家也需要能理解一定程度的传统系统设计思想（比如对象，关联，领域模型等概念），其间可进行领域建模，编写伪代码等来描述领域问题，具体设计对于开发人员有较高的要求，需要具备良好的OOA/OOD能力。

实施DDD，很重要的一点，必须尽量真实到达业务和具体设计的真实映射，如果设计和领域模型不能较直观的描述业务，那就失去意义，为保证这点，需要依靠良好的面向对象设计来保证业务映射，对最终设计需要根据确定下来的业务设计描述来验收。

从代码层面来讲，需要保证业务可重用性，必须保证领域层完整性，可测试性，以及保证领域业务不外放。往往分层架构会导致有些业务处理出现在不合适的位置，比如向UI层渗透，或领域服务暴露不当等，理想状况应该做到领域层的平台无关性，当然这是理想化，笔者认为领域可测试性，业务可验收性是最为重要的。

具体框架支持方面，谈DDD估计必谈ORM，领域层再优雅也需要持久化，一个映射能力优秀的持久化框架是必备的，目前我们使用的是NHibernate，虽然有些地方实在不那么优雅，但它还是非常优秀的。

至此算是简单的把领域驱动引入的可行性阐述了一番，看了上述的种种文绉绉的方法之谈是否觉得还是缺少些什么？具体实施层面的有了依据，从项目和团队层面来说，是否需要一个更为有效的管理方式来支撑？需求/业务永远在变化，那么敏捷开发号称拥抱变化，是不是能引入而用之？

看一些实际状况片段：

需求分析一周，一份完备的需求送入开发，评估之后4周，继而投入4周的漫漫开发中，3周半的时候开始提交测试，上线前一两天，需求方开始体验/验证系统，“这个怎么是这样的啊”，“需求变更了，这个地方要这样”，“明天发布来不及改，下一期吧”，“测试来不及啊，这不是白测了吗”“排到后面…”。4周后发布了，变更被排入开发，接着，回到下一个漫漫的周期…

“这个样式怎么乱了？”，“底层接口不稳定，没办法搞”，“这个为什么要这么做，有价值吗”

         是的，这是瀑布式开发吧，我们的迭代周期是多久，“上次是3周，有次是2周，有次是4周，哦，”。

         敏捷可以让我们变成怎么样？用Scunm试试看？

         组建2-3个Scrum团队，3-4人，每组一个Master，ok，开工，初步定义sprint周期为2周，可由一位需求分析师暂代ProductOwner角色，来全程跟进，将项目需求进行分析后，对功能进行合理拆分为backlog，进入迭代，每个sprint结束需交付可用产品/系统功能，交付需求方或测试验收验证，依据情况可让已交付功能上线。休整后进入下一个sprint。依此，磨合一段时候后，确定一个稳定的迭代周期，快速响应需求，定期准时交付可用产出。迭代期间进行每日会议，及时沟通。由于是长期的内部系统，无需对较大项目或复杂需求做详尽估时（预估的几乎不可能准确，准确的代价是拒绝了变化，这是不符合期望的），只需总是按照迭代周期向客户进行交付，稳定的周期对用户进行反馈，我们将欢迎变化，你可以在任何时候提出变更，当然变更总是有代价，提出人心知肚明，而合理评估后欣然接受相信一定是客户期望的态度，稳定的交付周期也会让客户明确感知开发成效，藉此将树立团队形象。

         当前很多时候是自己去领需求来开发，Scrum团队将由owner来接受需求，配合master来分析具体开发任务直至具体开发人，Owner精神是需要的，但是一个东西还没有分配到你的时候如何去owner？松散管理对于团队成型未必总是有效，ProductOwner必须充当需求认领人角色。

上面是一个团队改造的设想，几周前就有这个构想了，或者说遐想。接下来开始演进笔者的看法。

Scumn在具体实施层面都给出了很好的实践，大师们勾画的蓝图确实很让人向往，然而脱离实际也是举步维艰的，笔者尝试将该方法论和现状结合，但还是出了问题。

         显著问题之一，QA测试的介入，一般测试思想认为一个迭代周期后交付的部分功能测试往往会导致最后产品完整完成需要重新测试，将浪费这期间的测试工作。笔者如下反驳：

QA用于保障产品质量，参与的测试以黑盒，功能性，验收性测试为主。作为最终保障，更多的价值在于最终产品质量保障，对于产品代码状况，设计质量无法涉及，而代码作为最终产出，其质量直接关系产品质量，性能等，应该有充分的测试保障，核心代码的白盒/单元测试，系统集成测试，以及最重要的对于业务设计的测试都不可或缺，测试驱动是一个可参考的实践，业界对于TDD评价颇高，可惜笔者目前未有实践机会。若转型为敏捷团队提供测试支持，更多的测试目的在于帮助验证产品设计，监督和提高产出质量，而不仅仅是为测试而测试。

         回过头来，一个现实问题需要考量，QA部门往往独立于项目部门，编制不在一处，服务于此，现实利益相关的考核等约束使得测试人员不得不考量实际工作量和效益问题。凡事涉及利益，多半是无果…

         问题之二，当前并无明确的项目概念，通常以零散需求为单位进行开发，多半是单个开发人员独立开发，从SVN不强制加锁即可窥见协作程度并不高，零散需求工作量长短不一，暂无一致的分配者来调剂，由开发人员自行安排，缺乏统筹和资源安排合理性，且人员技能组成不够理想，强行合并人员组建团队，磨合期恐怕较长，新scrum团队内的分工较难定义。

问题之三，基础系统以及相关积累的成熟度不够高，拆分多个团队必然容易导致团队按各自风格积累，统一标准为定义前，将产生多个版本的局部标准。

         综上，论述了可用实践和相关的考虑，然而实际状态并非理想环境，一蹴而就显然不可取，循序渐进为佳，如DDD全面实施成本较高，项目主体架构已基本成型，切换不易，笔者认为可取的架构目标应该是健壮底层和基础服务，提高自动化和规范化开发，降低开发和维护成本，应用层面的编码要求可适当放宽，以较可行原则来做合理约束即可，根据当前的技术能力组成，规避应用层面开发的技术风险或繁琐程度，企业应用求稳定之后再求体验和性能，稳定的响应在可接受范围即可，重点系统和项目实施DDD，TDD等，敏捷团队还是需要有意识的磨合和组建，思想转变后相信会带来不一样的成效。

这篇博文提笔之前，笔者认为写出来的想必是XX卫道者的思维去扯方法论，写完后，发现其实是希望记录下观点的转化过程。

鲜明观点到最后被模糊了，不过文尾还是想提一些关于产品方面的东西，毕竟本文标题里也忽悠了产品的字眼，

本人虽自称已经UE疲劳，不过这玩意即使疲了也得做。

用户体验不可能只靠UED的，况且他们并非我们的直接资源，哪天没排上计划了就不做体验了？ 部门通常需要制定一系列产品标准来引导和规范其产品的质量走向，这些标准落实到实际执行者，遵循优先，而不应只从具体人员角度去度量它是否有价值（往往是由于其实现成本而导致这个思想），如品牌形象一样，任何产品或部门必然需要树立起产品/职业形象，标准就是帮助你在没有该意识的情况下达到这个树立形象目的。而标准也如双刃剑，若当前整体产品状况或阶段并不适合一个庞大而复杂的标准的时候，尽管标准很优秀，也需要考量它是否合适于在当下实施，或者它的实施成本与实际价值的比例是否足够诱人，如果在稳定性和可用性都还未完美保障的时候就大谈UE，结局惨淡笔者已见了不下少数。合适的阶段做合适的事。

关于领域驱动，您可以看这里，一点拙见，希望您能了解更多：http://www.cnblogs.com/wsky/archive/2009/10/27/1590873.html

　　最近脑子一直有很多需要记下的东西，可能是过多过乱而又忙的无暇静下思考，故而酝酿了这篇杂烩式作品，希望观点杂糅在一起也能碰出一点火花吧。