基于DAD方法的可扩展的ASM敏捷框架

　　在敏捷的初期，往往敏捷开发是在小范围内进行且项目管理相对简单。小型的且集中的敏捷团队管理思想仍然可以在这些情况指导我们完成任务。而如今，因为机遇和环境已经显著改变，我们希望敏捷开发应用于更广泛的项目，我们需要更庞大的团队，为了降低地区经济和市场领域的风险，同时在全球各个地区展开业务，CEO们希望利用分布式方式组织庞大的敏捷开发团队;同时，他们还想与其他组织的成为合作伙伴。因此，他们需要遵守法规和行业标准，他们有着显著的技术或文化环境问题需要克服，他们需要超越单系统的思维方式，真正有效地考虑跨系统的因子 - 团队规模，地理分布，合规性，领域的复杂性，技术的复杂性，组织分布和企业规范。

　　图表 XXVI：ASM是DAD模型基础上面向八个维度拓展

　　不是每个项目团队面临所有这些可变维度带来的新问题，也没有任何两个团队面临同一个问题具有相同的严重性，但所有这些问题增加了敏捷交付的复杂性。以你的情况，你的DAD敏捷交付过程需要适应新环境，而你必须找到策略来克服这些独特的挑战。

　　团队规模 –核心敏捷方法能够很好的工作于十到十五人的团队，但如果团队要大得多呢?有五十人，百人，或者一千人?随着你团队规模的增长，团队沟通和协调的会更加困难。书面沟通反而比核心敏捷所提倡的面对面沟通更加有效，或者书面沟通以及面对面的沟通都显得无力。

　　地理分布 – 如果我们的团队分开来，他们不存在同一间会议室中，他们或许在同一建筑物内的不同楼层，或许在同一个城市的不同位置，甚至在不同的国家，这会发生什么有趣的事情呢?或者你让你的一些工程师在家工作会又会发生什么呢?又或当你的团队成员在不同的时区，又会发生什么?突然，我们发现有效的协作变得更加具有挑战性，团队的联结被断开将更有可能发生。

　　合规性 - 如果行业或地方监管法案出台，所有的移动设备均需送检过关后方能投入运营网络，又或者企业要求所有流程必须合规企业ISO9000认证，请问这些将带给产品交互过程何程度的影响呢?其实，往往是我们从外部强加的，除了客户驱动的产品要求外的许多规则、需求增加了团队的工作流程环节、工作内容。

　　领域的复杂性 - 有些项目团队发现自己解决一个非常简单的问题，如开发数据录入、查询应用程序或以信息公开为主的网站。有时候，问题领域是比较复杂的，如需要监控医疗药品用品的生物化学工艺或大数据采集、存储和分析以辅助交通管制决策等。或者，也许情况正在发生迅速变化，如金融系统从前台转向后台，端到端的服务走上电子平台，需要较高的安全保障和兼顾易用性。有人认为，变化领域内的速度，系统的临界性，以及商业模式是影响软件过程中的关键因素。更复杂的领域需要更加注重探索和实验，以降低风险，这其中的活动包括原型验证，建模和仿真等。

　　组织分布 - 有时候，一个项目团队包括来自不同部门的成员，不同的合作伙伴，或由外部服务公司雇佣、委派的成员。更多的组织上分散的团队，越有可能的关系将是合同联结的方式，而不是协作。例如，在一些项目的人虽然在要求，架构，设计，甚至是代码上产出，但实际上因为处于安全原因，他们不得访问源代码所属空间，不得获得资源执行测试，对真正的产品的理解有极大的偏移，且缺乏组织凝聚力，这将大大增加您项目实施的风险。由于缺乏彼此的信任，从而减少合作意愿，甚至可能会增加与知识产权(IP)斗争的风险。因此，许多组织都在努力重新调整他们的人力资源采购流程和与合作伙伴的新合同，以便更好地构建分布式环境中成功的交付产品、解决方案的信任。

　　技术的复杂性 - 有些应用程序从头开始，易于提升整体的质量和满足客户需求;但如果你的工作与现有的遗留系统和遗留数据源存在极大的耦合需求，你的产品就有可能变得不完美了。同理，使用一个单一的平台来建立一个系统，会相对容易;如果你正在构建一个运行时系统又需要在多种平台上被使用，或兼用几个不同的技术来构建。这个时候，你一定感到有难度。另一方面，技术复杂度还是相对主观的因素，例如在敏捷计划中，每个人针对工作项的复杂度的理解会因为个人经验和技术水平的不同而不同。换句话说，不同的团队成员评估同一工作项会有不同的结果，所以针对技术复杂度，我们在思考交付过程时需要一个复杂的解决方案。

　　组织的复杂性 - 你现有的组织结构和文化可能直接反映了瀑布式交付的价值理念;在组织内采用和推广敏捷策略的因此增加了难度。更糟的是，你的组织内的不同团队可能有不同的看法，因为他们认为应该如何工作需要考虑更多其自身的需求。而差异性策略即使是相当有效的，但作为一个整体，因为他们并不是向一个方向努力，因而可能大大增加了您项目的风险，也可能闭门造车般地重复投入资源开发着同一个轮子。

　　企业规范 - 大多数企业希望利用共同的基础架构平台，以降低生产成本，缩短产品上市时间，提高一致性，并促进可持续发展的步伐。如果你的项目团队只专注于他们的迫切需要，理念和实际就要脱离了。为了充分利用公共平台和资源，项目团队需要采取有效的企业架构，企业业务建模，战略性重用和资源组合。这些学科必须同心协力和更好的提升你的纪律敏捷交付流程。但是，这不是免费的，你的敏捷开发团队需要招募企业的专业人士– 例如企业架构师和企业资产重用工程师 - 如果不是自己权力范围内可以调动的资源。该企业的专业人士也需要学习纪律性敏捷交付的方式工作，因为，未来的工作相比于他们在传统的团队工作方式非常的不同。

　　需要指出的是，每个比例因子代表的范围内的复杂度才是关键，而每个项目团队都将面临这些复杂性的不同组合。言下之意是，他们将需要调整。实际操作中我们发现前四个比例因子 - 团队规模，地理分布，合规性，以及组织分布 - 是相对简单的，能够通过工具，采用适当的技术来解决。而其他四个缩放因子– 领域的复杂性，技术的复杂性，组织复杂性和企业规范 – 则更难解决。许多企业正努力实现(尽管期望如此)。

原文转自：http://blog.csdn.net/u012936954/article/details/19502629