2011年9月27日,星期二10:11

整理您的敏捷积压订单以获得成功

撰写者

Rgalensept27th1在此博客文章中,我想分享一些有关为敏捷团队创建合理的产品待办事项列表的准则。虽然这当然是产品经理或产品负责人的领域,但往往要由BA来帮助或“拥有”敏捷团队中的Backlog详细信息。

总的来说,我发现团队的修饰时间太少了。这会导致类似的问题–

  • 漫长的冲刺计划会议
  • 很少考虑将其放入设计中
  • 计划和执行不力
  • 解决业务问题时缺乏创造力
  • 预测不佳

将积压整理视为超出简单需求定义的内容。它包括项目计划,设计&体系结构和策略制定。因此,在这里花一些时间是一项巨大的投资-包括短期的sprint执行和长期的发布策略开发。

产品积压&整理“质量”清单

  1. Scrum Master主持了美容会议。不是产品负责人,而是一切。 Scrum核心角色很好地发挥了作用……
    1. Scrum Master作为主持人;流程指南;教练
    2. 产品负责人是业务需求和价值驱动力;定义什么而不是如何(设计)或多长时间(时间)
    3. 团队作为合作伙伴与产品负责人一起参与产品积压的实时发展
  1. 待办事项的长度–待办事项的长度应包含足够的详细项目,以使您的团队满意以进行发布;使用团队速度和释放节奏作为乘数。还有足够的史诗物品可以容纳2个版本。 (无论您如何在组织环境中定义“发布”)
    1. 另一个经验法则是将Backlog定位/限制在50-100个用户故事之间
    2. 每个待办事项都应具有独特的,周到的优先级-顺序
  1. 修饰–每周进行两次修饰会议。记住Schwaber提供的10%的投资指导–因此每个小组成员每个冲刺周4小时(无论是个人还是在会议中)
    1. 另一个指南是,在执行Sprint之前,与团队反复探索每个用户故事至少4倍。
      1. 作为高级史诗;至少在执行前发布
      2. 作为一个故事或一组故事,距离执行3-4个冲刺
      3. 故事1-2冲刺离执行
      4. 作为一个故事 就在之前 执行
  1. 对于更复杂的工作,新功能,硬重构等,请确保确定了对这些故事进行脱机,协作整理的子团队,重点是
    1. 早期设计讨论
    2. 识别故事工作流程& breakdown
    3. 迎接挑战& risks

并始终在故事或Wiki中留下足够的工作笔记。通常我将其捕获为SPIKE。记住有关尖峰的两件事:

    1. 您应该明智地使用Spike Stories作为一种方法,让您的团队将复杂的史诗精炼成有意义的故事和工作流程。我想说大约有20%的用户案例是Spikes的候选人。不要短缩它们!
    2. 尖刺应该在冲刺中进行 之前 将执行目标定位的Sprint。这鼓励团队进行一些健康的预见。
  1. 产品积压应首先设置为优先顺序,并始终由产品所有者按优先顺序重新排序。订单可以更改,但也应该稳定-代表产品所有者的市场/客户意识来满足业务需求并增强团队信心。因此,不要无休止地积压待办事项积压,因为这会降低团队的信心。
  1. 美容会议着重于3 等级 积压的
    1. 史诗般的故事:将大型史诗分解为多个部分;估计其规模,复杂性并确定优先级/工作流程;可能不超过两个版本。
    2. 中期故事:整理离执行2-3个冲刺的故事。让团队开始思考设计;执行效率,
    3. 短期故事:在目标冲刺之前“修饰”故事。
  1. 运行端到端的Blitz计划,以获取团队对工作流的反馈。我认为经常进行Blitz Planning是有益的。例如,在计划好发布之前要多次。您也可以在一个发行版的中期进行此操作,以便尽早猜测下一个发行版中的内容可能性。不要害怕经常与您的团队一起执行这些端到端视图!
  1. 分配时间来修复每个Sprint的错误!即使您将这些设置为团队的“伸展故事”,也需要将时间分配给用户意图和接受标准。
  1. 分配时间用于每个冲刺的硬化和测试时间。这些是用户故事,在进行闪电战计划时特别有用。他们应该具有接受标准,以指导团队达到实现“完成”所需的LOE。
  1. 说到完成,应该对整个组织有一个明确的“ Done-Ness”定义,并在适当的情况下为团队唯一定义。所有故事的评估和验收标准都应牢记这一成熟度水平来创建。其中应包括以专业和负责任的方式完成每个故事的工作。

Rgalensept27th2

积压的积压有哪些“气味”?

  1. Sprint Planning令人难以置信的清晰,简短而轻松;通常需要2个小时或更短的时间才能进行2周的冲刺。会议内没有任何建筑或设计讨论,这些讨论的相关部分早已发生。
  1. 团队成员正在讨论将来针对冲刺2-3-4冲刺的史诗和故事-在每个冲刺中几乎每天都在进行,并且很自然地与产品所有者的愿景保持一致。
  1. 团队可以轻松地为Backlog贡献新故事,以代表基于非功能的工作;例如:测试工件,非功能性测试工作,重构,自动化开发,性能调整,SPIKE等。 他们认为这是共同的责任。
  1. 团队对产品的长期发展有一种感觉,并为该愿景制定了工作计划,设计,主题建议和权衡方案。
  1. 每个Sprint的目标都可以轻松地从积压中得出;即,在待办事项列表中容易浮现出一些周到且有意义的主题。有时将它们视为“包装”。
  1. 产品负责人在每次冲刺中都包含团队反馈(错误,重构,改进,测试等),并以一定百分比为重点。他们清楚地表明了团队对他们的反馈,判断和技术意见的信心。
  1. 由于尺寸估算,产品负责人很少更改元素的优先级。这不包括将它们拆分为Now&后来的位。说明优先级主要来自翻译成故事的外部业务需求。
  1. 闪电战计划每2-3周进行一次,不仅作为计划工具,而且作为风险/调整工具。 对于XP专业人员,可以将发布计划视为类似的练习。关键是,针对下一个发布里程碑的端到端计划非常频繁地发生。
  1. 团队正在尝试一些弹力项目,并在每次冲刺中投入更多工作。有一种热情,可以通过创造性地权衡故事子元素来朝目标提供更多目标。
  1. 待办事项映射到团队的技能和能力,扩大了他们的能力–是的,但不是要求他们去做他们无法通过技能或经验来做的事情。
  1. 产品负责人的每个冲刺都会根据与团队的互动进行微调整,以调整范围。永远-寻找最小的可销售功能集!
  1. 团队在Sprint计划中从未感到惊讶。甚至没有一个故事。 我知道,应该发生变化,但是让最后一刻发生变化的团队感到惊讶……不是!而是–等到下一个冲刺。
  1. 团队认为他们在待办事项列表,功能与改进项的分配方面都有发言权。但是他们的观点不能完全是狭och的。他们需要从客户POV提出业务案例,以应对Backlog中引入的所有非功能性工作。而且他们乐于做到这一点!

希望对您有所帮助...

鲍勃

不要忘记在下面留下您的评论。

罗伯特·加伦

罗伯特·鲍勃·加伦 是RGCG L.L.C的总裁兼首席顾问。基于NC的Cary敏捷方法指导&培训顾问。他是一位经验丰富的敏捷教练,活跃于敏捷社区并定期撰写文章。&讲授与敏捷方法有关的所有主题。鲍勃写了这本书 Scrum产品所有权,重点放在团队交付中的角色和驱动价值上。鲍勃可以在 [email protected] 并通过他的LinkedIn进行联网 个人资料.

©BA Times.com 2020

麦格雷戈徽标白色网站