大规模敏捷实践从0-1的方法：1、将团队协调放在首位；2、使用架构跑道来管理技术复杂性；3、协调基于特征的开发和系统分解；4、使用质量属性方案来阐明体系结构上重要的要求；5、使用测试驱动开发并持续关注。其中，团队协调是大规模敏捷实践的基础。
1、将团队协调放在首位
Scrum是当今最常用的敏捷项目管理方法，主要涉及团队管理实践。在最简单的实例化中，Scrum开发环境由单个Scrum团队组成，该团队具有指定需求，架构，设计，编码和测试系统所需的技能，权限和知识。 随着系统规模和复杂性的增加，单团队模式可能不再满足开发需求。如果一个项目已经决定使用类似Scrum的项目管理技术，那么Scrum方法可以扩展到使用“Scrum的Scrum”来管理多个团队，这是一个特殊的协调团队，其作用是（1）定义开发团队之间和之间将流动的信息（解决团队之间的依赖关系和沟通）和（2）识别，分析和解决具有潜在更广泛后果的协调问题和风险（例如， 对于整个项目）。Scrum of Scrums 通常由每个团队的成员组成，他们被选中解决端到端功能或跨领域问题，例如用户界面设计、架构、集成测试和部署。创建一个负责团队间协调的特殊团队有助于确保在团队之间和团队之间传达正确的信息，包括度量、问题和风险。但是，当Scrum团队本身变得庞大以至于不会压倒团队时，需要小心。这种扩展可以通过组织团队和Scrum团队本身以及功能和服务亲缘关系来实现。我们将进一步讨论这种在基于特征的开发和系统分解实践中组织团队的方法。这种编排对于管理大型团队（包括敏捷团队）取得成功至关重要。
2、使用架构跑道来管理技术复杂性
严格的安全或关键任务要求增加了技术复杂性和风险。当工作花费的时间超过单个迭代或发布周期，并且无法轻松分区并分配给不同的技术能力（或团队）以独立并发开发解决方案部分时，就会出现技术复杂性。管理技术复杂性的成功方法包括尽早定义最紧迫的系统或软件架构功能（甚至在组织级别预先定义，例如，作为基础架构平台或软件产品线）。
开发团队可以利用的这种架构功能的预阶段的敏捷术语是“架构跑道”。架构跑道的目标是提供支持未来开发迭代所需的稳定性。这种稳定性对于多个团队的成功运作尤为重要。系统或软件架构师通过确定对系统具有体系结构重要性的质量属性要求来决定必须首先开发哪些体系结构功能。通过最初定义（并不断扩展）架构跑道，开发团队能够迭代开发使用该跑道的客户所需功能，并从他们赋予的质量属性（例如，安全性和可靠性）中受益。
拥有明确的架构跑道有助于在生命周期的早期发现技术风险，从而有助于管理系统复杂性（并避免在集成阶段出现意外）。在生命周期后期（即经过几次迭代之后）发现质量属性问题，例如基础体系结构的安全性、性能或可用性，通常会导致大量返工和计划延迟。当新功能的基础结构到位时，交付功能更具可预测性，因此必须持续关注体系结构上重要的要求，并估计开发团队何时依赖于实现体系结构解决方案的代码。
3、协调基于特征的开发和系统分解
敏捷团队中的一种常见方法是在系统的所有组件中实现功能（或用户故事）。这种方法使团队能够专注于具有利益相关者价值的事情。团队控制该功能的每个实现部分，因此他们不需要等到团队外部的其他人完成一些必需的工作。我们称这种方法为“垂直对齐”，因为实现该功能所需的系统的每个组件都仅在团队要求的程度内实现。
但是，根据系统的体系结构需求，系统分解也可以是水平的。此方法侧重于促进重用的共同服务和可变性机制。创建基于特征的开发和系统分解方法的目标是提供水平、垂直或组合对齐团队的灵活性，同时最大限度地减少耦合以确保进度。尽管组织在非常不同的领域（从嵌入式系统到企业系统）中创建产品，但当需要平衡快速进展和敏捷稳定性时，会出现类似的架构模式和策略。团队创建一个平台，其中包含常用的服务和开发环境，作为框架或平台插件，以实现基于功能的快速开发。
4、使用质量属性方案来阐明体系结构上重要的要求
Scrum强调面向客户的需求 – 最终用户关注的功能 – 事实上，这些对成功很重要。但是，当对最终用户功能的关注变得独占时，底层的体系结构重要需求可能会被忽视。高级实践是在建筑跑道开发期间引出、记录、交流和验证潜在的质量属性方案。当项目通常具有显着的寿命和可持续性需求时，这种方法在规模上变得更加重要。在项目早期，评估质量属性方案，以确定在早期开发增量中应解决哪些具有体系结构重要性的需求（请参阅上面的架构跑道实践），或者是否可以采取战略捷径来更快地交付最终用户功能。
5、使用测试驱动开发并持续关注
这种做法可以概括为“在编写系统之前编写测试”。当只关注“晴天”场景（典型的开发人员心态）时，项目变得过于依赖项目结束时的广泛测试来识别被忽视的场景和交互。因此，请务必关注雨天场景（例如，考虑不同的系统故障模式）以及晴天场景。首先编写测试的做法，特别是在业务或系统级别（称为验收测试驱动开发）加强了识别系统更具挑战性的方面和属性的其他实践，尤其是质量属性和体系结构问题（请参阅上面的体系结构跑道和质量属性方案实践）。
延伸阅读
三种大规模敏捷框架
- LeSS – Large Scale Scrum：在LeSS中，和Scrum一样，有三个角色，三个工件，五个会议。不同点在于，增量的交付拆分到了各个子团队中。因为涉及到各个子团队的合作和协同，所以子团队的拆分设计就非常重要，通常推荐按照特性拆分，每个团队都可以交付一定数量的对业务有价值的特性，减少互相之间的依赖。但是这同时对每个团队成员的要求也比较高，因为他们可能需要掌握更多技能和知识以实现跨组件开发。
- SAFe – Scaled Agile Framework：相对于LeSS, SAFe的团队容量更大，同时角色更多，结构设计也更加复杂。
如下图，从上倒下，分为了项目组合层，解决方案层和价值流层，其涵盖的不仅仅是研发环节的敏捷运行方式，也扩展到了整个企业的组织架构管理以及目标导航。 - DAD – Disciplined Agile Delivery：此流程框架是一种以人为本，面向学习的混合敏捷方法来实现IT解决方案交付。它具有风险价值的生命周期，是目标驱动的，并且是企业意识。 DAD的四大优先事项是：人名列前茅；学习型；敏捷；混合动力。
文章标题：大规模敏捷实践怎么从0-1，发布者：Z, ZLW，转载请注明出处：https://worktile.com/kb/p/34023
微信扫一扫 
支付宝扫一扫 
