22 lines
1.5 KiB
Markdown
22 lines
1.5 KiB
Markdown
|
---
|
|||
|
|
title: Spikes
|
|||
|
|
localeTitle: 钉鞋
|
|||
|
|
---
|
|||
|
|
## 钉鞋
|
|||
|
|
|
|||
|
|
并非您的团队在Sprint期间所做的一切都是用户故事。有时，用户故事无法有效估计或需要进行研究。也许需要帮助来决定不同的架构，排除一些风险，或者可能是一个概念证明（POC）来展示一种能力。
|
|||
|
|
|
|||
|
|
在这些情况下，Spike会添加到Sprint Backlog中。尖峰的接受标准应该是对提出的问题的回答。如果实验比预期的更困难，那么答案可能是否定的。 （这就是Spike应该及时限制的原因。）
|
|||
|
|
|
|||
|
|
投入Spike的时间和精力是有意限制的，因此可以在Sprint内完成工作，而其他用户故事受到的影响微乎其微。 Spike通常不会收到故事点评估，但会给出固定的小时数。
|
|||
|
|
|
|||
|
|
在Sprint评论中展示Spike的结果。根据新信息，原始问题在未来的Sprint中被重新定义为新的用户故事。
|
|||
|
|
|
|||
|
|
您的团队获得了做出更好决策所需的信息;减少不确定性。通过少量的，可测量的资源来提高未来Sprint的工作质量和价值，而不是根据猜测工作做出决策。
|
|||
|
|
|
|||
|
|
#### 更多信息：
|
|||
|
|
|
|||
|
|
* Mountain Goat软件[峰值](https://www.mountaingoatsoftware.com/blog/spikes)
|
|||
|
|
* Scrum.org论坛[如何整合尖峰](https://www.scrum.org/forum/scrum-forum/5512/how-integrate-spike-scrum)
|
|||
|
|
* Scrum联盟的[飙升和努力与悲伤的比率](https://www.scrumalliance.org/community/articles/2013/march/spikes-and-the-effort-to-grief-ratio)
|
|||
|
|
* 维基百科[穗](https://en.wikipedia.org/wiki/Spike_(software_development))
|