我们的敏捷计划是标准吗？

Question

我们一直在尝试Scrum，但现在已经有一段时间了，并且正在尝试将其正式化为我们自己的敏捷应用程序开发版本。以下是我们当前流程的工作方式。它目前有两个主要的缺点。想了解您是否有类似的方法，以及社区是否对我们目前存在的障碍有任何实用的建议。

• Scrum team =4名开发人员，2名QA，1名技术撰稿人，1名PO(PM)，1名Scrum Master (Engg Dir)
• Release =3 Sprint
• Sprint=2 weeks

宝洁和客户创建产品积压的用户故事和相关的验收标准。

每次迭代开始时的1周Sprint计划

• Day 1#估计Sprint待办事项并商定优先级
• Day 2-5# Scrum团队讨论故事并处理Sprint中每个故事的细节(获取故事细节、流程流程(如果有的话)、标识要应用的UE指南、UI项/字段/小部件的详细信息及其行为(如果需要的话)、理解验收标准和创建测试)
• 2 week Sprint，每天scrum
• 重复3周周期

F 217

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

1. 在春季计划周中讨论的细节没有被有效地捕捉到，并且在wiki上被注意到。因为在Scrum中没有捕获这些细节的标准格式，所以通常在日常scrum中浪费时间，或者需要随后的会议来进一步了解故事细节。在sprint计划中，为功能相当复杂的产品捕获故事细节的最佳方法是什么？大多数问题似乎都与UI有关，开发人员无法在没有详细模拟的情况下决定如何布局屏幕/字段。
2. ，当团队处于冲刺周期时，您如何预测从客户那里回来的关键的显示停止错误。目前，开发人员不得不支持出现的这些红色帐户问题，从而扰乱了sprint.

。

对于我们如何改进这个问题，有什么建议吗？

Answer 1

1. 没有“标准”敏捷计划。计划并不重要。计划就是。我的意思是，定期调整你的计划，以反映实际情况。如果我没有弄错的话，制定一个计划，让它被赋予权力，然后在开发人员面前束手无策的话，traditionally.
2. Sprint规划就不应该超过一天。scrum的关键思想之一是不要花费太多的时间规划。如果他们这样做了，当你有更清楚的时候，停下来重新召集。不要跋涉前进。
   • 从客户到3小时
   • 开发人员的优先事件集，以估计~3小时
   • 显示估计值，并让客户更改他们的桶以反映业务需求(在sprint配额范围内) ~rem

​

记录决定：

• 有好的抄写员吗？能打字快到4个人的人.将核心声明/决定放在一个高能见度区域，如图表..。或者维基..。对你有用的东西，

，

UX研究：

• 试图将UX的工作流水线化。确保用户界面用户已经完成了UI细节、模拟屏幕、工作流等工作，直到开发人员到达它为止。当开发人员正在执行迭代n时，UX正在为迭代n+1编写故事。有点困难，但如果UX给您造成了很多“重击”，则可以完成。

臭虫-责任：

• 的一种方法是将所有的bug作为下一次迭代的常规待办项。让客户在短跑计划期间购买哪些产品，如果这不可行的话，
• ，趋势错误流入，修复率和计划。将x天标记为专门用于这些请求的按需修复程序。

改进的空间：你需要一个专门的人在“客户”角色(或教练/BA谁可以为客户)，开发人员可以得到实时联系。每天的scrum会议应该有30分钟的时间，不应该包括故事“澄清”。坚持三个问题-你昨天做了什么？今天你干什么？有什么障碍需要帮忙吗？

负责某一特定事件的开发人员或子团队在处理特定任务时，应与客户/前线合作，以防出现疑问。他们负责提取细节，作为开发工作的一部分。如果这有帮助的话，他们也可以向在相关领域工作过的其他开发人员寻求帮助。与客户合作，保持正确的轨道。

HTH

Answer 2

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

开发人员必须与最终用户交谈。PO也应该在那里，用于文档所发现的。这是我在大多数开发项目中看到的最大问题，即开发人员与用户的分离。

Answer 3

你为什么一周都在冲刺计划会议？冲刺计划的目标是获得足够的细节，让团队感到舒适，拥有您可以完成的功能，并致力于完成这些功能。这通常需要不到一天(~4小时)。开发人员在sprint期间及时发现了实际的实现细节。这就是为什么他们能够访问PO和用户是如此重要。如果你想知道在哪里捕捉细节，那么在规划会议上，你就设计了很多细节。在sprint过程中，细节应该直接进入代码中，因为它们是工作的。

什么才是停止表演的人？PO看到每个sprint (2周)结束时的进度，然后决定业务价值是否足以保证发布。如果有任何关键问题，那么PO可能不会发布那个sprint。希望您可以在功能完成后，让PO和用户每天查看该产品，从而减少在sprint结束时出现问题的可能性。