敏捷如何估算“研究阶段”所需的时间？

Question

根据规范的敏捷开发，在实现问题解决方案之前，工程师应该学习多少知识？

如果工程师知道她对某个给定的主题(例如压缩)太无知，无法开始实现，她就会去了解她认为需要知道的内容，然后实现一个解决方案。

显然，加深对上述主题的理解可能会导致更好的实现，但代价是灵活性。另一方面，如果一个工程师对一个话题了解太少，那么她就有可能实现一个严重不足/失败的实现，从而在近期或不久的将来对客户产生负面影响。在某些情况下，不需要进行大量的研究，在某些情况下，开发人员也面临着一个主题--即使是高级开发人员--大多数开发人员对此知之甚少，因此，这个问题的答案包括一个可伸缩性的元素，以满足这两种情况。

敏捷的指导原则是否能引导工程师达到这个规模的哪一个目的？或者敏捷是否将其作为一个滑动尺度，在任何特定情况下，答案都可能不同？

换句话说，我希望了解的不是敏捷开发研究何时/如何进行，而是如何估计在研究阶段学习某个主题的“良好”时间，然后再着手实现解决方案。

Answer 1

当需要学习时，敏捷团队可能会考虑使用研究尖峰。

但是，当考虑到研究所需的时间长度时，团队应该尊重首席开发人员的判断。事实上，研究高峰的持续时间完全取决于目标用户故事的复杂性和团队的技能水平。

Answer 2

贯穿敏捷的一个基本主题是团队应该做足够多的“x”来感到舒适和负责任地向前迈进，而不是更多。这适用于软件开发生命周期的许多方面，如设计、文档、测试和研究。

将任意的、僵化的时间框放在其中任何一个(“花四个小时来编写这个功能，但不要更多”)都不是非常敏捷的。如果在四个小时后，您对功能的完成感到不舒服怎么办？转移到下一个特性将是不负责任的。

同样，考虑一下研究时间(“最多花四个小时研究这个功能，但不要更多了”)。如果，四个小时后，你不舒服地做出设计决定呢？对团队不满意的设计做出承诺是不负责任的。

然而，显然，一个人不需要掌握某一特定技术的所有特性才能对它感到满意。研究人员应该花足够的时间去感觉自己是一个好的、负责任的决定，而不是更多，也不是更少。

Answer 3

当我在敏捷中工作时，我们使用了一个叫做“技术尖峰”的东西来处理这类工作。

这个概念很简单:您在sprint中投入了一段时间来研究手头的技术问题(例如，使用对您的团队来说是新技术的工作所需的时间)。然后，将其分配给具有估计值的人。这个估计值将成为您的sprint计划的一部分。

这真的很好用。或者至少在我们如何使用它的背景下是这样做的，这主要是为了研究使用某个API来完成一项任务。当然，它也有局限性--如果学习任务太大(比如从头开始学习c++或诸如此类的疯狂的事情)，它就不能很好地工作。