极限编程:迭代应该有多长时间？
我当时正在研究极限编程，并开始阅读肯特·贝克的一本书，名为“极限编程解释”。在那里，他提到了一些做法和原则，其中之一使我感到困惑。它说迭代必须缩短。
如果迭代很好，我们将使迭代非常非常短-秒、分钟和小时，而不是周、月、年(解释-序言)。
在同一本书的后面，Kent Beck使用了几个星期的迭代：
在发行版中，XP使用一到四周的客户请求特性迭代，以获得关于进度的细粒度反馈。(极限编程解释-第一章)
术语表再次提到了1-4周的迭代：
迭代一到四周的周期。在开始时，客户选择要在迭代中实现的故事。最后，客户可以运行他们的功能测试，看看迭代是否成功。(极端编程解释-词汇)
然而，当我在极限编程网站上阅读时，它说迭代的时间是1-3周。然而，我找到了视频(从时间7:09开始)，其中提到了以天、分钟和秒为单位的迭代。
在极端编程中，迭代有多长时间，它们是如何工作的？迭代对一个用户故事进行2周的工作吗？这似乎不算什么。这让我感到困惑的原因之一是因为Scrum在一个sprint中完成了多个用户故事，这个过程持续了2周。当我进一步研究这个问题时，它说开发人员更喜欢2周迭代。那是哪一个？我是不是把它和别的东西搞混了？
回答 1
Software Engineering用户
发布于 2015-12-28 02:48:02
我觉得这有点令人困惑，但我认为序言中的这一段(在Kent Beck的书中提到的迭代时间小于数周的唯一地方)有助于澄清一些事情：
当我第一次连接XP时，我的脑海中就有了控制板上的旋钮。每个旋钮都是一种实践，根据我的经验，我知道这种练习效果很好。我会把所有的旋钮都转到10，看看发生了什么。我有点惊讶地发现，整个实践包是稳定、可预测和灵活的。
极限编程规模的实践效果很好。
让我们以规划游戏为例。计划游戏是在一个发布级别(计划将进入发行版的故事)和再次在迭代级别(计划将在迭代中完成的任务)完成的。理论上，你可以继续使用“计划游戏”来计划和管理每一项活动--例如，一个人也可以用它来规划他们的一天。然而，在某种程度上，它开始不增加价值。
极限编程确实把良好的软件工程实践带到了极致。对编程是XP的一个核心部分，它需要同行评审并使它们连续进行。测试驱动开发(TDD)鼓励创建和频繁运行单元测试(甚至在编写代码之前)。客户和用户可以在每次迭代之后提供反馈，而不仅仅是每个版本。
从业务的角度来看，项目的迭代时间短于1周或超过4周并不总是有意义的。客户--短于一周的可见迭代可能是浪费的--您经常将客户带来，以便对软件中几乎每一个微小的更改提供反馈。超过4周的时间可以防止对不断变化的需求和环境的响应(您的敏捷程度较低)。但是，仅仅因为在项目级别上不存在迭代，并不意味着实践不会在几分钟或几秒钟内对开发人员产生明显的影响，在这种情况下，这些事情是同行评审(通过对编程)、失败的测试(单元测试/ TDD)或构建(持续集成)的结果。不过，一些公司，如谷歌、亚马逊和Facebook (1、2、3.、4.)，每周都可以对客户进行多次更改，有时是几秒钟。这些公司处于极端编程的最极端阶段。
https://softwareengineering.stackexchange.com/questions/305965
复制相似问题
腾讯云开发者
