scrum - 在 Scrum 中规划和处理最后期限

Question

已结束。此问题不符合 Stack Overflow guidelines .它目前不接受答案。

---

这个问题似乎与 help center 中定义的范围内的编程无关。 .

关闭 5 年前。

Improve this question

来自 wikipedia :

During each “sprint”, typically a two to four week period (with the length being decided by the team), the team creates a potentially shippable product increment (for example, working and tested software). The set of features that go into a sprint come from the product “backlog,” which is a prioritized set of high level requirements of work to be done. Which backlog items go into the sprint is determined during the sprint planning meeting. During this meeting, the Product Owner informs the team of the items in the product backlog that he or she wants completed. The team then determines how much of this they can commit to complete during the next sprint. During a sprint, no one is allowed to change the sprint backlog, which means that the requirements are frozen for that sprint. After a sprint is completed, the team demonstrates the use of the software.

我正在读这篇文章，两个问题立即出现在我的脑海中:

1) 如果一个 sprint 只有几个星期，在一次 session 上就决定了，那么您如何准确地计划可以实现的目标？根据我的经验，高级任务无法准确估计，并且可以轻松地将看似合理的任务加倍。作为一名开发人员，我讨厌根据一组客户要求被迫 promise 我在下个月可以交付的内容。这与我所知道的关于生成可靠估计而不是粗略估计然后加倍的知识背道而驰!

2) 既然需求应该被锁定并且最终可以交付可交付的产品，那么当某件事确实需要两倍的时间时会发生什么？如果这个功能在 sprint 结束时只完成了 1/2 怎么办？

wiki 文章继续讨论 Sprint 计划，其中将事情分解为更小的任务以进行估算(<1 天)，但这是在 Sprint 功能已经计划好并且发布同意之后，不是吗？有点像推销员在不咨询开发人员的情况下 promise 某事。

顺便说一句:

Although the word is not an acronym, some companies implementing the process have been known to spell it with capital letters as SCRUM. This may be due to one of Ken Schwaber’s early papers, which capitalized SCRUM in the title.

Answer 1

1. 您应该使用 velocity计划下一个冲刺。速度巧妙地处理了您的估计 错误的事实，但它们始终是错误的。另请注意，故事应该很短，我会说最多 2-3 天。比这更大的故事应该被分解成更小的故事。

2. 如果一个故事没有按计划完成，那么你的速度就会下降，你将无法在下一次迭代中承担同样多的工作。