AM（敏捷建模）是一种态度，而不是一个说明性的过程。AM是敏捷建模者们坚持的价值观、敏捷建模者们相信的原则、敏捷建模者们应用的实践组成的集合。 AM描述了一种建模的风格。当它应用于敏捷的环境中时，能够提高开发的质量和速度，同时能够避免过度简化和不切实际的期望。 AM可不是开发的“食谱”，如果你寻觅的是一些细节的指导，如建立UML顺序图或是画出用户界面流图，你可以看看在建模Artifacts中列出的许多建模书籍。
敏捷建模的价值观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模式需要，就建立所有的框架。这种方法使你能够轻松的使用模式。
咨询详情
培训对象
学企业需要的敏捷算法建模能力
人工智能时代，如何用机器来提高生产力？在这里，你可以学到前沿且实用的技术，挖掘数据的魅力。
教你用可落地、易操作的数据科学思维和技术模板构建出优秀模型。
课程中安排了Sklearn/LightGBM、Tensorflow/PyTorch、Transformer等工具的应用实现，并根据输出的结果分析业务需求，为进行合理、有效的策略优化提供数据支撑。
聚焦策略分析技术及企业常用的分类、NLP、深度学习、特征工程等数据算法，只教实用干货，以专精技术能力提升业务效果与效率。
课程涉及大量企业项目案例：精准营销预测、营销策略优化、客户行为分析、风险管理、客户管理、智能推荐、情感分析、反欺诈等，加持实战经验，为你进入名企做项目背书
