什么是冲刺任务看板

---

什么是冲刺任务看板？

冲刺任务看板是一个时间盒。每个冲刺都有开始和结束日期，在此期间必须完成并确认一组选定的用户故事。下图展示了冲刺的关键要素，包括一组用户故事、参与的Scrum成员、工作分配、持续时间和结束日期（右上角）。

在冲刺开始时，产品负责人、利益相关者和开发团队会聚在一起，对用户故事进行优先级排序，然后选择在本次冲刺中要完成的用户故事。由于各方对项目和项目进度有不同的偏好、考虑和关注点，会议的目的是让不同参与者有机会倾听并理解彼此的观点，从而达成一个所有各方都同意的用户故事集合。

冲刺周期

快速交付高质量的工作是软件团队希望采用敏捷软件方法论的原因之一。因此，尽管冲刺周期没有放之四海而皆准的固定选择，但普遍认为周期应尽可能短。但究竟应该多短呢？

虽然较长的冲刺周期并不理想，但过于短的冲刺周期可能会削弱开发团队完成重要工作的积极性，甚至可能导致交付成果质量低下。

因此，冲刺周期的选择是整个团队——包括产品负责人、Scrum主管以及数据库设计师、程序员、UX设计师、测试人员、分析师等Scrum成员——共同讨论的结果。但最终，必须有人做出决定。此时，Scrum主管通常会给出答案。

传统上，冲刺持续三周到一个月，但如今越来越多的团队在两周冲刺中取得了成功。毕竟，冲刺周期并没有固定的选择。一个好的Scrum主管应具备协作和引导能力，以确定合适的冲刺周期，确保工作按预期完成。以下是Scrum主管可能考虑的一些因素：

1. 商定的项目进度
2. 客户/利益相关者/产品负责人的可及性（能够澄清潜在疑问的人）
3. 客户的职场文化
4. Scrum团队的能力
5. Scrum经验

一旦团队达成一致，未来的所有冲刺都将遵循相同的冲刺周期，不会在每次冲刺之间频繁更改。然而，Scrum团队持续审查冲刺的有效性，并找出最适合每个人的最优冲刺周期，是一种良好的实践。

冲刺中工作（用户故事）的确认

冲刺开始后，开发活动围绕用户故事展开，随着冲刺的推进，越来越多的用户故事被实现。然而，用户故事的完全实现并不是故事的终点。仍然有一个重要的步骤需要完成——确认。

确认一个用户故事，就是尝试已实现的功能，判断该功能是否按预期实现。判断应完全基于在详细说明用户故事时确立的标准，这些标准以确认项的形式列出。在确认过程中，产品负责人会获得一个测试环境或设备来测试已实现的工作。产品负责人将逐一检查用户故事中列出的确认项。如果所有项目均确认完成，则认为该用户故事已确认。如果发现任何项目未完成或未按预期工作，产品负责人将要求开发团队进行修复。修复和确认过程将重复，直到用户故事完全确认。

何时进行确认？

冲刺，事实上敏捷开发是一个持续交付过程。不应等到冲刺结束才确认用户故事，而应在任何用户故事完成后立即进行确认。然而，如果产品负责人无法参与持续确认，可以安排每周一次、每次1到2小时的会议。在会议中，产品负责人将与团队一起确认已完成的用户故事。会议还包括一个讨论环节，用于澄清在实现冲刺中其他故事时发现的疑问。

确认并不等同于测试

如前所述，确认的目的是确保用户故事被正确实现。判断应完全基于在详细说明用户故事时确立的确认项，不多也不少。检查的范围远远不足以确保功能已准备好用于生产环境。那么，何时进行‘真正的测试’呢？

不同的团队在软件测试方面有不同的实践。一些团队倾向于在每个冲刺结束时进行测试，包括集成测试和回归测试。另一些团队则更倾向于设立一个稳定冲刺，顾名思义，用于测试和修复缺陷。在此冲刺中不会进行任何新的开发活动。

无论你选择哪种方法，都要记住，这个选择不是某个人的决定，而是全体成员的共同决定。

Visual Paradigm 提供您在 敏捷软件开发 中所需的所有工具，包括 UML用例图工具 , (敏捷) 用户故事, 冲刺, 故事板 和 线框图 用于用户体验设计，任务管理工具，等等