敏捷转型
跨团队故事：如何让他们工作
读：
跨团队故事：如何让他们工作
思考这种情况......
假设您基于由服务团队管理的数据API的敏捷团队构建应用程序。假设您无法更改组织的结构。如果需要更改以从API获取不同的数据字段，以支持您的应用程序中的功能 - 您可以做什么？
答案是一个跨团队的故事。一个跨团队的故事真的是两个部分：故事的验证部分与确定需要的团队保持，而实际的开发工作故事将参加完成工作的团队。
如果两个团队在Sprint中运行，则完成跨团队故事的最短时间是两个冲刺。为团队进行工作的一个冲刺，以及一个Sprint用于确定工作的团队的验证。
跨团队的故事工作流程可能看起来像这样：
1.在释放规划或冲刺规划期间，团队识别必须由不同的团队提供的工作。
2.识别工作的团队创造了两个故事。
3.各个团队的产品所有者谈判故事的优先权和范围。
工作的团队在他们的冲刺中计划这个故事。如果在进行工作的团队使用Kanban方法，则跳过冲刺规划，并将预期的日期传达给识别团队。
5.工作完成后，识别团队扮演他们的验证故事。本故事本故事可以根据Sprint的Sprint，或工作团队的预期日期。
6.在发布计划之前确定跨团队故事有机会播放风险卡，以确保两个团队都知道故事的优先事项，并且依赖可以由计划团队或投资组合团队成为经理。可以在Scrums会议的Scrum中完成依赖关系的跟踪。
在大多数组织中，跨团队故事很少见。许多跨团队故事增加了交付延迟的风险。如果您注意到您的团队始终依赖其他团队以完成任何功能，这可能是技能组或架构未与业务优先级对齐的指示。亚博vip9通道这种未对准应升级到投资组合团队进行分辨率。
评论（3）
ramesh.
如果练习Kanban应该跳过Sprint规划。你可以澄清。
ramesh.
如果练习Kanban应该跳过Sprint规划。你可以澄清。
srikanth.
似乎复杂的jann。您可以在统一的产品积压中创建一个功能，将这两个（或更多）的故事连接在一起。功能可以在释放而不是故事中释放。