【规模化敏捷系列10】这一期为继续大家分享规模化敏捷–从精益开始内容。对规模化敏捷感兴趣的小伙伴持续关注我们哦。
流管理
精益思想的一个核心理念就是连续流。在精益组织里，通过单件流或连续流的方式，将全面正确的产品，端到端的无中断地，快速的交付给客户。
敏捷团队在定义，开发，整合和部署产品时，应该通过将产品分解为功能特性或用户故事流的方式来践行这个理念。一个功能特性或者更细粒度的“用户故事”代表着“单件”的商业价值，需要从客户端以最快的速度无中断的通过开发，测试和部署流程回流到客户端。我们可以通过创建一个类似我同事Bob Payne发明的，称为项目集对齐墙（Program Alignment Wall, PAW）的可视化管理系统，用来跟踪监控项目或产品的功能特性或用户故事流的进展状态。
图12的项目集对齐墙PAW（Program Alignment Wall）样例曾用来管理过4个敏捷团队和17个瀑布团队一共21个团队的复杂项目集。
项目集对齐墙PAW（Program Alignment Wall）通过二维的格式展示：
-
每一行代表一个功能“泳道”。
-
每一列代表一个Sprint或迭代。
-
每一张卡片代表一个史诗级的用户故事（一大块工作），卡片按照整体发布计划排列。
-
卡片上的点状标签用来标记团队与团队之间，或项目与项目之间的依赖关系。
同时在项目集对齐墙PAW（Program Alignment Wall）上的内容会同步到一个敏捷全生命周期管理工具套件上，比如VersionOne, Rally, Agile Craft或微软的TFS（Team Foundation Server）。
为了避免在产品研发过程中瓶颈，我们使用PAW （Program Alignment Wall）来管理功能特性或用户故事流，从创建到完成。必须确保功能特性或用户故事流的小批次规模，稳定的流服务速率和松弛度，如下所述：
· 小批次规模。在批次规模大小上，我们要同时控制发布和迭代开发两个层次。我们需要和客户一起确保系统功能已经被明确定义，创建和发布到每一个小的批次中。在发布层面，每个功能特性批次尽量的小，应该将功能特性拆分为不超过3周实施周期的用户故事，而且即使是大的项目，每个发布也不应该超过3-4月。
一个Sprint或迭代中的每个用户故事不应该超过3天的工作量，迭代周期控制在一，二或三周内。
当项目团队待办列表（Backlog）中的用户故事完成后，我们只需要在项目集对齐墙PAW （Program Alignment Wall）上简单更新它所属的史诗级的用户故事的状态即可追踪进度。
· 稳定的流服务速率。项目集对齐墙PAW （Program Alignment Wall）上的每一个行是一个队列，我们要监控这些队列确保用户故事集的流入与服务的速率都是均衡稳定的。当一个用户故事集已经在生产流水线上时，要确保我们记录它从每个状态演变的时间周期，以及它的引入到完成的总时间周期。同时，我们也要监控所有史诗级用户故事的平均时间周期，来确保项目进展的顺畅。
· 松弛度。为了保证快速机动，系统必须保持一定的松弛度。没有松弛度的系统所产生的负面效应就如同过载的网络，交通高峰时的高速公路，大多数公司的IT部门。按照队列理论，当更多个体进入队列时，系统的处理机能就会下降，导致破坏性相互作用，从而拖慢整个队列和其他一切相关的所有东西。
我们在做资源分配时要依从队列理论的原则：如果团队成员精力被分散在多个项目时，当他们遇到需要快速转变的情况，意外需求或复杂问题时，就会处境艰难。核心资源的专注可以帮助我们缓解这些问题。
所以我们要避免分配给团队成员超过80%的工作量，且一直保持20%的团队松弛度。在Google和Atlassian公司，这就是用来推动创新的20%原则。团队成员被允许将他们20%的时间用来做他们自己所选的有兴趣的事情，这仍会创造额外的商业价值。
培植小而稳定的团队
哈佛商业评论已经借由Wheelwright和Clark以及相关人士的研究表明，当我们每次致力于一件或者两件事物时，我们的生产效率最高，如图13所示，多任务对生产效率的影响。
因此，敏捷团队理应每次专注于一个单一的项目，相比传统的工作环境，敏捷团队通过与我们的商业赞助者紧密合作，应该能够更快更准确的完成项目。当团队完成项目并且把系统作为产品交付给客户时，团队将能够启动下一个项目。
此外，美国项目管理学协会（PMI）的项目管理知识体系（PMBOK）指南告诉我们，如果要达到一个高绩效的状态，团队必须历经塔克曼（Tuckman）团队发展阶段模型：形成期、震荡期、规范期、成熟期。也就是说，要让团队进入高绩效的状态，需要花费时间和相当大的努力。那么，我们究竟为什么要把老团队拆散，而且试图在下一个项目时重新组建新团队呢？
我们需要建立稳定的团队作为每次专注于某个产品或项目的高绩效单位，而不是把钱花在组建一些只是为了在项目完成之后解散的团队上。因此，我们要创建整合的跨职能团队，团队成员要来自不同的职能部门：包括业务分析师、设计师、研发人员、测试人员和项目经理（或者Scrum Master）。我们把至少80%或者更多的这些核心团队成员投入到项目中去。现在，为了最大化项目的产出，我们只根据专用团队的可用性来启动相应数目的项目。
我们可以将项目按优先级排序，并在有团队可用的时候分配优先级最高的候选项目。图14，将优先需求带给稳定的敏捷团队，表明了这个关键概念。
我们的底线是稳定的团队构成了我们资源分配的基本单位。
建立团队间的工作关系网
“…对于一个运转的大型组织而言，它必须表现的像个具有团体相关性的小型组织群一样”- E.F.Schumacher，《小即是美》
一旦敏捷团队在高绩效的状态下运行良好，却达到了组织的规模限制，比如说团队大约有9名成员了，我们将不会继续扩大现有团队的规模限制，并且会构建一个新的团队。为了保证新团队被正确建立，一个小的种子组可能会从原团队中脱离，形成新团队的核心。这个核心组，通常包括了经理、研发组长和业务分析师，确保把原团队的愿景和文化完整地传播给新的团队。重要的是，作为稳定的团队，核心原始团队继续保持不变。
这种方式避免了团队的臃肿，也确保了团队保持他们的敏捷性。图15，分治法规模化团队，表明了这种方式。
现在，我们如何确保团队结构保持灵活以适应快速的变化呢？有个很棒的方法是利用特性团队的变化来实施Jeff De Luca所创造的特性驱动开发（FDD）的敏捷方法。
在FDD中，首席程序员承担在迭代过程中交付指定特性的责任。她识别出类的所有者——特定代码模块的所有者，并在1-3周的迭代周期内交付指定的特性。除了核心组保持一致性和连续性，团队中的一些成员的“位置”，可能会根据所交付的功能不同，在不同的“Sprint”中会有所不同，如图16所示，动态团队成员关系。
为了在团队之间建立联系，著名的敏捷专家和作家Johanna Rothman首先推荐了一种网络而不是等级制度。如图17所示，小团队网络。
随着多个团队的形成，我们希望这些网络能够在团队中有机的浮现，而不是呈现出自上而下的支配。比如，团队成员可以关联在某个共同的规范领域中，像横跨团队之间的、专注于改进自动化测试的工作组中。或者，他们可以关联在类似于持续改进改善小组中，以实施横跨团队的回顾行动。
持续改进
从本质上讲，所有敏捷方法都包含戴明的（W.Edwards Deming）提出的“计划-执行-检查-改进”的持续改进循环。学习是通过持续的环境反馈来实现的，而改进则是通过对策略和规则的增量式调整来实现的。在我们规模化敏捷方法的时候，我们可以去现场检查，并实施改善以期持续改进。
现场（Gemba）是一个日语术语，意思是“真正的地方”。在商业中，它指的是创造价值的地方; 或者我们的敏捷团队所在的地方。在精益思想中，现场检查认为，问题在现场表现得最明显，因此通过亲自观察现场正在进行的工作更容易找到最佳的改进方法。如图18所示，走动管理是一项活动，它将管理层带入到那些进行实际价值交付的工作前，来发现浪费和实施改善或实践性改进的机会。
将管理层与现场或完成工作的“真实地点”联系起来有多重要？要充分理解这个问题的答案，可以考虑一下汽车制造业的另一个不同场景。多年来，底特律的高管们都把自己从车间——他们的现场里隔离出来。来自《西雅图时报》的报道:
“几代以来，通用汽车公司(General Motors Corp.)总部的第14层，有着厚厚的地毯、桃花心木墙壁和电子控制的玻璃门，世界上最大的公司权力的终极象征，这一层只有被邀请才能进入。”
高管们与通用汽车的其他员工完全隔离开了。在地下室的车库中，通用汽车的领导乘坐私人电梯来到14楼的行政楼层，在那里，他们的餐点都在私人餐厅里用餐。
这一狂妄自大的结果是不可避免的——通用汽车最终申请破产。
在2008年的汽车危机中，克莱斯勒也经历了类似的命运。然而，在破产和紧急救助之后，Sergio Marchionne（图19），菲亚特和克莱斯勒的新任首席执行官采取了几项大胆的措施来扭转克莱斯勒的颓势。
其中之一就是放弃了远程董事长办公室的工作。旧办公室现在变成了一个空荡荡的“旅游陷阱”。
用马尔奇奥尼（Marchionne）的话说,“办公室里现在是空的…因为在里面发生不了有价值的事情。我和所有的工程师一起都在现场。我可以和所有一线的人员一起造一辆车。这才是我所关心的。”
一旦这些核心的实践——限制在制品（WIP）数量、流管理、培植小而稳定的团队、建立团队间的工作关系网、以及持续改进都被一一实现，我们就可以此为基础，根据选择构建一个规模化的敏捷框架。
完整的框架选择包括SAFe®，LeSS，DAD和Nexus。接下来，我们将提供这些框架的简要概述，以及一些其他的技术，包括Scrum of Scrums会议和敏捷精益项目集管理办公室(PMO)。
