定义“扩展”敏捷，第4部分：在产品开发之外共享敏捷
到目前为止，我们在这里讨论“扩展”敏捷方法的含义：
- 第1部分：创建跨职能要素团队 （可以定期生成要素的团队 ）
- 第2部分：跨功能功能团队的程序（定期提供功能的程序（多个团队合作）
- 第3部分：敏捷产品开发 （针对所有产品开发，产品和项目组合（而不仅仅是项目）的自适应和持续计划）
这是第4部分，其他功能希望使用敏捷方法。 我称之为“共享”敏捷。 如果这些人是计划或项目的一部分，则产品开发团队已要求他们以敏捷的方式参与。 这部分是关于将敏捷方法嵌入到其他函数中（我不确定这是正确的词）。
有些功能是工作组，其中的人员通常独自工作，但可以合作。 以客户支持为例。 客户支持具有单一功能的工作流。 其他职能工作组具有多个工作流。
在“支持”中，人们经常独自出票（即将到来的工作队列）。 他们处理票证直到解决票证。 这是一个可能的看板，用于显示这些票证的流向。 门票队列一直在左边。 请注意，有两个可能的“就绪”列：“准备排名”和“准备开始”。
客户支持团队可能会在一天内多次对他们的工作进行排名和排名。 当然，他们在一周中这样做。 他们对一些工作进行排名，因此可以开始了。 他们可能正在测试中进行中的工作，已升级为其他团队/小组/职能。 根据产品的不同，他们可能需要Deploy列，然后完成工作。
客户支持人员经常发现他们的“周期”时间不一致。 也就是说，某些工作只需要很少的时间（以小时为单位），某些工作需要永久的时间（以几周为单位），而一些工作则以几天的形式位于中间。 以我的经验，这些周期时间范围取决于产品开发团队发布的内容。
客户支持小组如何使用敏捷方法？ 他们不一起工作。 他们可能无法计划下周，没关系两个星期。 （第3层支持小组也许可以计划更多的时间，但我对此表示怀疑。）这么多的计划没有太多价值。 站立站立没有任何价值，尽管在一段时间后走动木板以查看是否有任何卡住可能是有价值的。 我会要求董事会进行升级，有时升级是支持经理的工作。）
客户支持小组可以在管理WIP（进行中的工作）和管理升级（其等待状态和潜在瓶颈）中找到更多价值。 并且，在根本原因分析的回顾中具有巨大的价值。 尽管支持人员可能会在产品开发版本中发现问题，但他们经常发现他们的流程需要调整。 客户支持可以在回顾中利用双环学习。
多年前，当我管理一个Tier 3支持小组时，我问我的员工是否可以回顾一个星期的节奏。 对于某些巨大的问题，这种情况经常发生。 但是，它大部分都起作用。 我与升级的人一起检查了升级的状态。 我并没有这样做，因为问题是如此不同。 那会浪费每个人的时间。 我们确实每周进行一次小组学习。 那时我还不够聪明，无法使用纸板。 我使用了电子表格。
即使是我，由于我对纸板的热爱，也不建议所有支持小组都使用纸板。 支持通常需要最有效的电子工具。 我确实建议该小组添加足够的列以查看其流程。 有时，支持小组会将升级内容取出并放在纸板上进行跟踪，因为这些列中不同人员和团队之间的工作周期不同。
工作组的敏捷方法与团队不同。 团队有相互依存的工作。 小组有（主要）独立的工作。
我还将针对具有多个流的工作组做有关敏捷的另一篇文章。 是的，在创建您的成功敏捷项目中 ，我有一章关于工作组的敏捷方法。