敏捷开发定义_定义“扩展”敏捷，第4部分：在产品开发之外共享敏捷-CSDN博客

敏捷开发定义

到目前为止，这里是“规模化”敏捷方法可能意味着什么的讨论：

第1部分：创建跨职能要素团队（可以定期生成要素的团队）
第2部分：跨功能功能团队的程序（定期提供功能的程序（多个团队合作）
第3部分：敏捷产品开发（针对所有产品开发，产品和项目组合（而不仅仅是项目）的自适应和连续计划）

这是第4部分，其他功能希望使用敏捷方法。我称之为“共享”敏捷。如果这些人是计划或项目的一部分，则产品开发团队已要求他们以敏捷的方式参与。这部分是关于将敏捷方法嵌入到其他函数中（我不确定这是正确的词）。

有些功能是工作组，其中的人员大多独自工作，但可以合作。以客户支持为例。客户支持具有单一功能的工作流。其他职能工作组具有多个工作流。

在“支持”中，人们经常独自出票（入场的工作队列）。他们处理票证直到解决票证。
这是一个看板，可能显示这些票证的流向。门票队列一直在左边。请注意，有两个可能的“就绪”列：“准备排名”和“准备开始”。

客户支持团队可能在一天中多次对他们的工作进行排名和排名。当然，他们在一周中这样做。他们对一些工作进行排名，因此可以开始了。他们可能正在测试中进行中的工作，已升级为其他团队/小组/职能。根据产品的不同，他们可能需要Deploy列，然后完成工作。

客户支持人员经常发现他们的“周期”时间不一致。也就是说，某些工作只需要很少的时间（以小时为单位），某些工作可以永久使用（以周为单位），而某些工作则以几天的形式位于中间。以我的经验，这些周期时间范围取决于产品开发团队发布的内容。

客户支持小组如何使用敏捷方法？他们不一起工作。他们可能无法计划下个星期，没关系两个星期。（第3层支持小组也许可以计划更多的时间，但我对此表示怀疑。）这么多的计划没有太多价值。站立站立没有任何价值，尽管在一段时间后走动木板看是否有卡住的现象可能有价值。我会要求董事会进行升级，有时升级是支持经理的工作。）

客户支持小组可以在管理WIP（进行中的工作）和管理升级（其等待状态和潜在瓶颈）中找到更多价值。并且，在根本原因分析的回顾中具有巨大的价值。尽管支持人员可能会在产品开发发布的内容中发现问题，但他们经常发现他们的流程需要调整。客户支持可以在回顾中利用双环学习。

多年前，当我管理一个Tier 3支持小组时，我问我的员工是否可以回顾一个星期的节奏。对于某些巨大的问题，这种情况经常发生。但是，它大部分都起作用。我与升级的人一起检查了升级的状态。我并没有这样做，因为问题是如此不同。那会浪费每个人的时间。我们确实每周进行一次小组学习。那时我还不够聪明，无法使用纸板。我使用了电子表格。

即使是我，由于我对纸板的热爱，也不建议所有支持小组都使用纸板。支持通常需要最有效的电子工具。我确实建议该小组添加足够的列以查看其流程。有时，支持小组会将升级内容取出并放在纸板上进行跟踪，因为这些列中不同人员和团队之间的工作周期不同。

工作组的敏捷方法与团队不同。团队有相互依存的工作。小组有（主要）独立的工作。

我将为具有多个流的工作组做另一篇关于敏捷的文章。是的，在创建您的成功敏捷项目中，我有一章关于工作组的敏捷方法。