我们的敏捷计划标准是什么？

Question

我们一直在尝试Scrum，但现在正试图将其正式化为我们自己的敏捷应用程序开发版本。以下是我们当前流程的工作原理。它现在有两个主要缺点。想要了解你是否有类似的方法，以及社区是否有任何关于我们目前遇到的障碍的实用技巧。

• Scrum团队= 4名开发人员，2名QA，1名技术作家，1名PO（PM），1名Scrum Master（Engg Dir）
• 发布= 3 Sprint
• Sprint = 2周

PO和客户创建产品积压的用户故事和相关的验收标准 在每次迭代开始时进行1周的Sprint计划

• 第1天＃估算Sprint积压并同意优先级
• Day 2-5＃Scrum团队讨论故事并处理Sprint积压中每个故事的详细信息（获取故事的详细信息，流程流程，如果有的话，确定要应用的UE准则，UI项目/字段的详细信息/小部件及其行为，如果需要任何特定的内容，了解验收标准并创建测试）
• 2周Sprint，每天15分钟scrum
• 重复3周周期

我们在这方面遇到的两个主要缺点是：

1. 春季计划周讨论的详细信息无法有效捕获并在维基上注明。由于在Scrum中没有用于捕获此类详细信息的标准格式，因此通常会在每日Scrum中浪费时间，或者需要后续会议来进一步了解故事详细信息。什么是在sprint计划中捕获功能相当复杂的产品的故事细节的最佳方法？大多数问题似乎是围绕用户界面和开发人员无法决定如何在没有详细模拟的情况下布置屏幕/字段。
2. 当团队处于冲刺周期时，您如何预测客户带来的关键showstopper错误？目前，开发人员不得不撤回支持这些突然出现的红色帐户问题，从而扰乱冲刺。

关于我们如何改善这一点的任何意见？

Answer 1

1. 没有“标准”敏捷计划。计划并不重要..计划是。我的意思是定期调整您的计划以反映现实情况。制定计划，让它受到权力的赐福，然后捆绑开发人员，但传统上并没有发挥作用。
2. 如果我没有弄错的话，冲刺计划不应该超过一天。 scrum的一个关键想法是你不会花太多时间计划。如果他们这样做，当你有更好的清晰度时停下来并重新召开。不要跋涉。
   • 从客户那里获得优先的故事集~3小时
   • 开发人员蜷缩估计~3小时
   • 显示估算值，让客户更改其存储桶以反映业务需求（在sprint配额内）~rem time。

记录决定：

• 找个好抄写员？能够像4人一样快速打字的人说话......在图表......或维基等高可见性区域内获取核心陈述/决定......对你有用的东西
用户体验研究：
• 尝试管道用户体验工作。确保UX人员在开发人员到达时已经使用过UI细节，模拟屏幕，工作流程等。当开发人员正在进行迭代时，UX正在处理Iteration n + 1的故事。有点困难，但如果用户体验会给你带来很多“颠簸”，那就可以了。

Bug-Duty：

• 一种方法是将所有错误作为下一次迭代的常规积压项目。在sprint计划期间，让客户支持哪些人需要进入。
• 如果这不可行，趋势错误流入，修复率和计划。保留x天标记为专用于这些请求的按需修复开发工具。

改善范围： 您需要具有“客户”角色的专职人员（或可以为客户提供服务的教练/ BA），开发人员可以实时联系。每日Scrum会议的时间应为30分钟，不应包括故事“澄清”。坚持3个问题 - 你昨天做了什么？今天你在做什么？您需要帮助的任何障碍？
负责特定故事的开发人员或子团队应与客户/前台合作，以防他们在处理特定任务时遇到疑问。作为开发工作的一部分，他们负责提取细节。如果有帮助，他们也可以向在相关领域工作过的其他开发者寻求帮助。与客户合作，保持正确的轨道 HTH

Answer 2

是的。我注意到，在您的过程中，开发人员无法倾听/与实际最终用户交谈。这是失败的秘诀。您不能希望您的“PO”能够捕捉到实际用户所表达的所有细微差别。

开发人员必须与最终用户交谈。 PO也应该存在，记录发现的内容。这是我在大多数开发项目中看到的最大问题，即开发人员与用户的分离。

Answer 3

为什么一周的冲刺计划会议？ sprint计划的目标是获得足够的细节，让团队感到舒适，拥有可以完成的功能并承诺执行这些功能。这通常需要不到一天（约4小时）。实际的实现细节是在sprint期间由开发人员及时发现的。这就是为什么它们能够访问PO和用户非常重要的原因。如果您在询问捕获详细信息的位置，那么您正在计划会议中进行大量设计。细节应该在sprint期间直接进入代码，因为它们已经解决了。

什么是showstopper？ PO在每个sprint（2周）结束时查看进度，然后决定业务价值是否足以保证发布。如果有任何关键问题，PO可能不会发布该sprint。希望您可以获得您的采购订单，也许用户可以在功能完成后每天查看产品，从而降低冲刺结束时出现问题的可能性。