事半功倍的规模化敏捷实践案例︱规模化敏捷

大量不同角色导致了流程的约束、沟通的不畅通以及工作的速度降低。

 

 

Figure 2. Roles decrease communication saturation

 图2 角色过多减少了沟通饱和度

 

As seen in Figure 2 from the Bell Labs Pasteur Project [23] involving the first 82 companies audited, communication saturation drops as roles are added. The circled area represents most companies with 20+ roles at ~25% communication saturation. Thus, fewer roles leads to improved communication among team and organization members. For Client Marketing, this directly impacted the target condition of all functions being focused on delivery.

 

图2来自贝尔实验室巴斯德项目[23]，在对于前82家公司的审计中发现，随着角色的增加，沟通饱和度下降。圆圈区域说明了，大多数公司拥有20多个角色，而且只有25%左右的沟通饱和度。因此，较少的角色可以改善团队和组织成员之间的沟通情况。对于客户营销发布火车而言，这直接影响了专注于交付价值的各个方面。

 

6.2 Deployments Too Far Apart 部署大相径庭

 

Inconsistent structures, tools, and techniques on Scrum teams were delaying deployments. A recent 7- year study with 13 preparatory case studies developed hypotheses to be tested using an academic framework for understanding what makes Scrum teams effective [24]. Findings indicate that two primary variables determine Scrum team results – frequent releases and a clear understanding of stakeholders' needs. At Client Marketing, deployments occurred only bi-weekly (after each Sprint), took on average two hours, and had to be done after 10 PM local time. These restrictions increased batch sizes and caused unacceptable delays in time-to-market for product enhancements, bug fixes, and new product deployments.

 

Scrum团队中不一致的结构、工具和技术延迟了规模化敏捷的实施。最近一项为期7年、包含13个专题的研究，提出了一些假设，这些假设将使用一个学术框架进行测试，以了解是什么让Scrum团队变得有效[24]。研究结果表明，两个主要因素决定了Scrum团队的结果——频繁的发布和对利益相关者需求的清晰理解。在客户营销发布火车中，部署仅每两周进行一次（每次冲刺之后），平均需要两个小时，并且必须在当地时间晚上10点之后完成。这些限制增大了批量规模，导致产品增强、缺陷修复和新产品部署的上市时间，出现不可接受的延迟。

 

6.3 Testing 测试

 

Analysis revealed that testing was a bottleneck, a problem often encountered in software development environments. Time to test and fix in a later Sprint compared to the current Sprint can be 24 times longer for complex hardware/software projects. This has been observed in Europe and Silicon Valley. A recent example was an investigation at Simplivity, a cloud infrastructure company that is now part of Hewlett Packard [25]. For a technology company like Rocket Mortgage, automation of testing and deployment is a good solution for this problem [26]. A small Scaled Agile implementation cut delivery time by 75% with an exemplary DevOps implementation [27].

 

分析表明，测试是一个瓶颈，这是软件开发环境中经常遇到的问题。对于复杂的软硬件项目来说，与在注入这个缺陷的同一个Sprint测试和修复这个缺陷的代价相比，在之后的Sprint测试和修复这个缺陷的代价要高出24倍之多。这种情况已经在欧洲和硅谷发生了。最近的一个例子是Simplify的一项调查，Simplify是一家云基础设施公司，现隶属于惠普[25]。对于Rocket Mortgage这样的科技公司来说，自动化测试和部署是解决这个问题的好办法[26]。通过标杆性的DevOps实施，一个小范围的规模化敏捷（SAFe）实施将交付时间缩短了75%。