模板(templates)被定义为包含了构建复杂模型所需的70到80的数据模式（data schemas）。数据模式利用通用的制造数据模型，以确保模型开发人员不必从头构建复杂的仿真模型。这意味着在Simio开发环境上开发复杂仿真模型时，您可以选择利用模板来减少与从零开始建模相关的80的耗时过程（即您可以省去原先80的时间就能构建出一个初具规模和复杂性的模型）。Simio对模板的定义突出了它重要的几个收益——减少建模时间、简化复杂的建模活动、减少人为错误、集成实践(best-in-class)和敏捷建模(agile modeling)。
Simio敏捷建模技术—Simio Templates
软件测试模型-敏捷模型
在V模型中，描述了基本的开发过程和测试行为，它的优点在于，非常明确地标明了测试过程中存在的不同级别，并且清楚地描述了测试各阶段和开发各阶段的对应关系。
同时，它的局限性也相当明显，测试介入时间太晚，只是把测试作为编码后的一个活动，需求分析等前期产生的错误，直到后期的验收测试才能发现。
虽说“亡羊补牢”，但是测试越晚介入，付出的成本代价越大。基于V模型的痛点，引入了敏捷模型。
采用敏捷模型，相当于项目一诞生，就给它打了预防针。立即预约课程
敏捷建模是（不是）什么？
当在描述事物的范围时，你需要说明它是什么，它不是什么。不管你谈论的是系统还是案例中的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）作为纵轴，横轴则直接从“演进”的视角来审视地图上的这些组件。我们就横、纵轴做了简单翻译和解释如下，帮助大家理解这个坐标体系。
咨询详情
