Agile 敏捷建模思想2

      在团队协作类别中有四项实践－－stakeholder的积极参与，和他人一起建模，公开展示模型，和集体所有制。stakeholder的积极参与对你的成功至关重要，因为你正是为了这些project stakeholder开发系统，正是为了了解和实现他们的需求。换言之，你需要和你的甲方们密切合作，这就自然的想到了和他人一起建模－－这个“他人”也包括你的stakeholder。当你的建模工作有多人参加时（至少一个project stakeholder和一个除你之外的开发人员），你就需要和众人共同协作，相互促进，取长补短。一个擅长于业务过程建模和业务规则定义的敏捷建模者看不到的方面，一个精通结构化建模技术（例如UML类图或数据模型）的人极有可能看得到。一样的道理，系统的直接用户给你的团队提供的信息极可能是高级经理提供不了的。所以，要有这样的观点：你要在项目甲方和开发团队中营造一种积极参与的氛围，只有这样，才能够收集各种不同的观点和经验。集体所有制能够提升协作性，因为一个人单独的进行建模的工作，他很快就会遇到瓶颈，而如果每个人都能够为建模工作献计献策，那么你们就能够成为一个团队，轻易的解决问题。公开展示模型能够使得人们对模型“瞻前顾后”变得容易了，能够立刻考虑模型传达的信息，从而提高团队的协作性。当然，我们是假设模型都在众人的视线之内，或者这些模型都是大家目前正在开发或相关的。这方面的主题我在Organizing an Agile Modeling Room中有详细的讨论。

      迭代和递增类别中包括了使用合适的artifact，并行创建模型，切换到另外的artifact，小增量建模这几项实践。不论哪一个artifact，都有它的长处和短处，任何一个单独的模型都不足以充分的描述你的项目的各个主要方面（如需求、架构）。例如你会发现你为了识别系统的需求，常常需要组合使用用例、业务规则定义、和技术需求定义。单单靠用例就能令project stakeholder立马告诉你他们所有的使用需求吗？这恐怕不太可能。你可以试试换用诸如业务规则之类的artifact来捕获他们的所有业务政策，再换用诸如技术需求的artifact来捕获他们的非功能需求。否则，他们会想起点什么就告诉你什么，还会返回去讨论先前提过的细节，甚至是改变他们的原来的主意。你的需求识别工作通常是一个动态的过程，分析、架构、设计工作也是一样。 我相信物力论中指出了人们以此种方式思考的原因，我们思考的方式明显是杂乱的。敏捷建模者要认识到人们是以一种动态的方式在思考，特别是人们处于群体行为时，这样才能制定对策。敏捷建模者并行创建模型，从而能够最广泛的收集信息。这项实践又是由实践切换到另外的artifact和小增量建模来支持的－－你可能正在使用用例来捕获使用需求的相关信息，而当stakeholder开始讨论他们对编辑屏幕的要求时，你最好是使用基本用户界面原型或是传统用户界面原型来记录这些需求。你需要在不同的artifact之间来来回回，每一个artifact最好都需要编码来验证，这种方式可以由小增量建模的实践来实现－－最典型的方式就是在这个artifact上做一会儿工作，再换一个artifact，依此类推。

      简单这个类别包括了创建简单的内容，简单地建模，使用最简单的工具这几项核心实践。创建简单的内容和简单地建模这两个实践集中于模型的简单性，在建模过程中这两项实践通产是密不可分的。把精力集中在如何简单描述，建模者常常会发现一些使得你手头的模型简单化的方法。举个例子，我曾经参加了一项存储层软件的开发工作，软件的概念类似于EJB的persistence container，封装了领域对象的一些存储操作。结果我们架构和设计非常的复杂，我们试着找到一种办法：建立一张简单的图表，帮助开发人员理解如何使用存储层来工作。其间我们还发现重构能够使我们的设计易于理解。实践使用最简单的工具能够使得过程变得简单。工具越简单就越容易使用，这就降低了他人在你的模型上工作的门槛，也就增加了实际中别人去这么做的机会，这也包括了你的project stakeholder。通过使用最简单的工具，简单描述模型也变得更自然了。此外，当你使用一些简单/低精度的工具，例如索引卡片，即时贴，白板的时候，你就能亲身体验这些简单工具的效力，你在不知不觉中已经强化了一些概念：最简单的解决方法实际上也能非常有效，对你正在开发的系统采用简单的设计。

      验证类别包含了两个核心实践：测试性思维和用代码验证。有一条哲学，我常从中受益：“如果你无法测试它，你就不应该建立它，而你建立的一切都应该加以测试。”这使得我在系统建模时就考虑测试，也使得我积极的去获取我的模型的反馈－－实际上，我把该条哲学归纳为“考虑你创建的所有artifact的可测试性，以及验证所有种类的artifact。”但这并不仅仅局限于AM的范围之内。通过这种可测试性的考虑，在我建模时，我能够建立起可测试的模型，而且积极的通过编码来验证模型，这样，我就能够尽快的证实我的模型是真正可以测试的。

      辅助实践

      文档类别包括了三项辅助实践：丢弃临时模型，合同模型要正式，非到万不得已不更新。在项目的进行中，需求、对需求的理解、以及对可能的解决方案的理解，都在不断变化（回忆一下原则拥抱变化）。为了反映这种变化，你需要同步改进你大部分的项目artifact，包括模型和文档。就像在敏捷文档讨论的那样，比较好的方法是，不到万不得已不要更新你的模型和文档，这种做法才算是敏捷方法。遵循这项实践，如果你发现一个模型如果不再需要更新，那就是说这个模型对你的团队已经没什么价值了，一个没有价值的模型就可以视为临时模型，可以丢弃。不过，要注意合同模型。它定义了你的系统和其他系统之间的接口，不太可能经常改变，因为它们的重要性是勿庸置疑的。一言以蔽之，如果你有个非合同模型不再更新，那就意味着它已经没有用了。

      为沟通建模和为理解建模这两项实践属于动机类别。实际上，这两项实践并没有太多的联系，有时候你创建模型的目的是为了研究和理解问题，有时候你的目的是为了和其他人交流你的想法，有时候你的目的包括了上述两者。就像你在图1中看到的，这两项实践常常会一起引出另两类的实践，这是下文要讨论的主题。

      最后，生产率类别中包括使用建模标准，逐渐应用模式，以及重用现有的资源这几项实践。重用现有资源这个实践要求你尽量利用他人的工作成果并从中受益，这有很多种思考方向：一种是应用模式，根据经验，我认为它是所有重用方法中最有效率的一种，因为你重用的都是其它开发人员久经验证的解决方案 (Ambler, 1999)；另一种是遵循建模标准和指南，实际上，不论是标准还是指南，都能够提高你工作的一致性。是的，你可以自己写指南，有时你必须要这么做，因为你的实际环境中会有一些特别的情况。但是你只需要在Internet上稍做搜索就可以找到很多的开发指南。例如，你可javaCodingStandards找到Java的开发指南。

      类别间的联系

      让我们考虑团队协作类别。简单类别中的实践增强了实践stakeholder的积极参与的效果，因为简单性消除了参与的代沟。迭代和递增类别中的实践也使得参与成为可能，尤其是并行创建模型，因为它增大了stakeholder们参加的机会。动机类别中的实践可以提高集体所有制和和他人一起建模的效果，对问题的理解和沟通通常可以激发人们的协作精神，简单类别的实践也也坑达到激发协作效果，因为它降低了参与的门槛。公开展示模型的效果可以通过生产力类别中的实践得到提高。遵循标准，应用模式的做法可以增加一致性和可读性，而重用现有的资源（例如通用架构），则给别人开了一个好头，使别人能够在你模型的基础上继续。迭代和递增类的实践可以支持集体所有制的实行，特别是并行创建模型和切换到另外的artifact，它们使得人们在适当的模型上共同开发。

      简单类别的实践由另外几类的实践来辅助。使用建模标准和逐渐应用模式这两项实践支持同一种建模语言（使用标准和容易理解的模式），从而支持了实践简单地建模。文档类别的实践也可以支持简单类别的实践－－只有到万不得已才更新模型，这样，你才不会给模型增加不必要的信息。才有可能创建简单的内容以及简单地建模。

      现在再来看迭代和递增类别。很明显，团队协作类别的实践支持该类的实践，由于团队的参与，针对目前的情况选用正确artifact的机会就增大了，你就可以根据需要来切换使用不同的artifact。验证类实践能够赋予你使用递增方法的勇气，特别是在你用代码验证的时候。保证你想法的易测性，你就更有把握同时操作多个artifact，并在它们之间切换，因为测试问题要求你从多个方面来看待它。文档类实践同样可以促进递增方法，特别是非到万不得已不更新。但是合同模型要正式这个实践抑止了递增方法的应用，因为你总是希望能够尽早的建立和其他系统间的接口标准。切换到另外的artifact和丢弃临时模型之间也能产生正面的效果，因为一个模型完成目的之后就把工作切换到另一个模型上去。简单类实践对这个类别也很重要，通过使用最简单的工具，你在不同的artifact间来回切换就变得更容易了，你节省了熟悉工具的时间，只把精力集中在简单的内容和描述上，你也可以较容易记住模型要传达的信息。最后，动机类实践可以令你同时进行多个建模工作，因为对于复杂的系统，你需要从多个方面去沟通，去理解，因此你需要在适当的artifact间来回切换，这样才能有效的做到这一点。

      验证类实践可由简单类实践来支持－－创建简单的内容和简单地建模能使你更容易进行测试性思维。迭代和渐增类实践也能提高验证类实践。例如，在你切换到另外的Artifact时，就可能切换到源代码，这样你就可以看到模型确实可以运行。

      简单类实践可以推进生产力类实践。当你使用简单模型工作时，逐渐应用模式就更容易一些；当你简单地建模时，使用建模标准也会容易一些，而模型的简单、易懂，也会使你比较容易的重用现有的资源，例如企业需求模型或通用的架构模型。

      简单类实践以及迭代和渐增类实践可以支持文档类实践的进行。文档越简单就越容易使用－－如果你的文档容易理解，这样你就有把握万不得已才更新你的文档，因为你知道做到这一点很简单；文档如果很复杂，你的项目风险就很大，因为没有把握什么时候文档需要更新。很明显，非到万不得已不更新和丢弃临时模型的运作环境可以其它的实践来改善，例如切换到另外的artifact、小增量建模。