400-998-6158
敏捷建模指的是团队在实施前对过程或产品的工作流进行评审。模型可以是短暂的，自发的或一个原型。
敏捷建模促进：
提升干系人之间的沟通；
通过投入少时间、降低成本去建立模型；
在开发实际产品前管理期望。
模型需要刚刚好就可以，它可以只是一个白板上的图形描绘、纸模型、投影展示或流程图。
这些模型的重点不是完美，而是提供一个整体解决方案
敏捷建模是（不是）什么？
当在描述事物的范围时，你需要说明它是什么，它不是什么。不管你谈论的是系统还是案例中的AM都一样。以下就是我对AM的范围的观点：
AM是一种态度，而不是一个说明性的过程。AM是敏捷建模者们坚持的价值观、敏捷建模者们相信的原则、敏捷建模者们应用的实践组成的集合。 AM描述了一种建模的风格。当它应用于敏捷的环境中时，能够提高开发的质量和速度，同时能够避免过度简化和不切实际的期望。 AM可不是开发的“食谱”，如果你寻觅的是一些细节的指导，如建立UML顺序图或是画出用户界面流图，可以看看在建模Artifacts中列出的许多建模书籍
AM是对已有方法的补充，而不是一个完整的方法论。 AM的主要焦点是在建模上，其次是文档。也就是说，AM技术在你的团队采用敏捷方法（例如eXtreme Programming，Dynamic Systems Development Method （DSDM），Crystal Clear）的基础上能够提高建模的效果 。AM同样也可以用于那些传统过程（例如Unified Process），尽管这种过程较低的敏捷性会使得AM不会那么成功。
组织建模的有效实践
借助团队拓扑，我们明确了“技术架构地图”上的标的物（团队）的分类和之间的关系，是时候讨论一下地图的坐标系了。本着敏捷价值驱动的一贯原则，坐标系的一轴应该是“价值”；而这个数字化时代组织的基石就是“以客户为中心”，必然要求我们从客户视角来审视价值。
地图上的物体——团队——除了分类和关联关系外，还需要考虑在一个企业里的定位。比如大型商业银行可能有一个相当规模的自有云平台团队，构建其自身的私有云；而一些小型金融机构可能就只有一个小型的云赋能团队，保证业务开发团队能够使用好公司合作的云平台。这样的考虑在过去的IT组织里是一个经典辩论：购买还是自建（Buy or Build）。
咨询详情基于这样的两个考虑，行业里已经有一定认可度的Wardley Map进入了我们的视野（https://learnwardleymapping.com/）。当然这里我们更多是采用Wardley Map的坐标体系，并不会当做战略定位工具来使用。
咨询详情Wardley Map采用了“价值链”（Value Chain）作为纵轴，横轴则直接从“演进”的视角来审视地图上的这些组件。我们就横、纵轴做了简单翻译和解释如下，帮助大家理解这个坐标体系。
咨询详情
敏捷建模的价值观AM的价值观包括了XP的四个价值观：沟通、简单、反馈、勇气，此外，还扩展了第五个价值观：谦逊。
沟通. 建模不但能够促进你团队内部的开发人员之间沟通、还能够促进你的团队和你的project stakeholder之间的沟通。
简单. 画一两张图表来代替几十甚至几百行的代码，通过这种方法，建模成为简化软件和软件（开发）过程的关键。这一点对开发人员而言非常重要－它简单，容易发现出新的想法，随着你（对软件）的理解的加深，也能够很容易的改进。
勇气. 勇气非常重要，当你的决策证明是不合适的时候，你就需要做出重大的决策，放弃或重构（refactor）你的工作，修正你的方向。
反馈. Kent Beck在Extreme Programming Explained中有句话讲得非常好：“乐观是编程的职业病，反馈则是其处方。”通过图表来交流你的想法，你可以快速获得反馈，并能够按照建议行事。
谦逊. 的开发人员都拥有谦逊的美德，他们总能认识到自己并不是无所不知的。事实上，无论是开发人员还是客户，甚至所有的project stakeholder，都有他们自己的专业领域，都能够为项目做出贡献。一个有效的做法是假设参与项目的每一个人都有相同的价值，都应该被尊重。
全面认识敏捷建模思想
这项实践是从XP的编码标准改名而来，基本的概念是在一个软件项目中开发人员应该同意并遵守一套共同的建模标准。遵守共同的 编码惯例能够产生价值：遵守你选择的编码指南能够写出干净的代码，易于理解，这要比不这么做产生出来的代码好得多。同样，遵守共同的建模标准也有类似的价 值。目前可供选择的建模标准有很多，包括对象管理组织（OMG）制定的统一建模语言(UML)，它给通用的面向对象模型定义了符号和语义。UML开了一个 好头，但并不充分－就像你在Be Realistic About The UML中看到的，UML并没有囊括所有可能的的建模artifact。而且，在关于建立清楚可看的图表方面，它没有提供任何建模风格指南。那么，风格指南 和标准之间的差别在何处呢。对源代码来说，一项标准可能是规定属性名必须以attributeName的格式，而风格指南可能实说在一个单元中的一段控制 结构（一个if语句，一段循环）的代码缩进。对模型来说，一项标准可能是使用一个长方形对类建模，一项风格指南可能是图中子类需要放在父类的下方。
咨询详情
高效的建模者会学习通用的架构模式、设计模式和分析模式，并适当的把它们应用在模型之中。然而，就像Martin Fowler在Is Design Dead中指出的那样，开发人员应当轻松的使用模式，逐渐的应用模式。这反映了简单的价值观。换言之，如果你猜测一个模式可能适用，你应当以这样的方式建 模：先实现目前你需要的小的范围，但你要为日后的重构留下伏笔。这样，你就以一种可能的简单的方式实现了一个羽翼丰满的模式了。就是说，不要超出你的 模型。举一个例子，在你的设计中，你发现有个地方适合使用GoF的Strategy模式，但这时候你只有两个算法要实现。简单的方法莫过于把算法封装为 单独的类，并建立操作，能够选择相应的算法，以及为算法传递相关的输入。这是Strategy模式的部分实现，但你埋下了伏笔，日后如有更多的算法要实 现，你就可以重构你的设计。并没有必要因为Strategy模式需要，就建立所有的框架。这种方法使你能够轻松的使用模式。
咨询详情
只要一个电话
我们免费为您回电
