Questions tagged «extreme-programming»

极限编程是90年代的一种软件开发方法论，如今被认为是敏捷编程的子类。它涉及典型功能，例如结对编程，YAGNI和非常迭代的编程。

6
敏捷与XP有何不同？
我在网上阅读了几篇文章，以了解敏捷，XP，Scrum，结对编程之间的区别/彼此之间的相互关系，并得出以下结论： Scrum和XP几乎相同。XP的发布时间比Scrum短 敏捷和XP方法中都采用了结对编程 但是我无法确定敏捷与XP有何不同。 除了提供URL，我将很高兴阅读您对此的经验和想法。
6
Scrum如何适应志愿者设置？
我最近加入了一个年轻的hackerspace，但仍处于自我设置过程中。我们很幸运，因为该空间有一些需要开展的内部项目，并且不乏志愿者来开展工作。 关于如何组织这些项目已经进行了一些讨论。我最近的专业经验是在Scrum上工作的，因此我正在考虑为我们的软件项目推荐一种Scrum方法，但是我不确定这是否合适。 尽管我已经看到Scrum在小型全职团队中表现良好，但该组织的性质却有所不同： 成员是志愿者。有些是全日制学生。其他人全职工作。我们不能指望任何人会持续不断地贡献自己的生命，因为他们的现实生活被放在首位。 尽管几乎每个人都有多年编写软件的经验，但很少有成员以专业或团队的方式这样做。 目前没有任何商品所有者。这些项目的要求由委员会确定。该委员会的成员还将致力于实施。这意味着我们将没有一个专门的产品负责人。 我们没有最后期限（无论是硬性还是硬性）。项目完成后将完成。 这些是相当大的差异，但是我不相信它们会阻碍应用Scrum。我认为一些小的调整可以使我们克服这一障碍： 如果我们将Sprint更改为具有固定的故事点大小，但持续时间（时间）固定，我们仍然可以从迭代发布中受益，而不会给志愿开发人员带来不切实际的交付压力。 我们可以抛弃燃尽图和速度计算。如果我理解正确，那么这些工具和指标可以充当开发团队和管理层之间的桥梁。它们以对开发人员和利益相关者都有意义的形式报告进度。考虑到我们没有人要报告（没有项目经理，没有产品负责人，也没有外部利益相关者），我相信我们可以完全放弃。 我认为我们可以从中受益的事情不需要进行调整： 在需求收集会议（一个或多个）。每个人都围坐在一张桌子旁讨论用户故事，草拟UI模拟，并建立产品待办清单。 冲刺回顾。对于我们来说，这将是一种有趣的方式，使其可以汇聚成一个对我们作为志愿者团队有效的开发过程。 我不确定的事情： 每日站立训练应如何治疗？我想知道它们在我们的环境中是否会具有很大的价值。我对站立仪式的理解是，它可以通过在团队中自然传播信息来帮助交流。考虑到我们的Sprint所提供的复杂性可能比普通Sprint少得多，因此与其他团队成员的进度/发展并驾齐驱的需求可能会更少。 我应该为XP推动诸如持续集成，代码审查和TDD之类的事情吗？我担心这会要求很多。一旦人们更加熟悉Scrum并以团队的方式工作，我会更倾向于将这些概念引入未来的项目中。 我的问题： Scrum是否可以适应基于志愿者的环境？ 而且，到目前为止，我计划的方法是否朝着正确的方向发展？
8
一个成熟的敏捷团队是否需要任何管理？
在最近对Scrum进行激烈辩论之后，我意识到我的问题是我认为管理对于完全敏捷的团队来说是非常不必要和多余的活动。我相信成熟的敏捷团队不需要管理或任何非技术性的决策过程。在我看来（显然犯了错误）的眼中，唯一合适的，能够管理一支成熟的开发团队的人就是他们的教练（他是技术上最胜任的，具有适当沟通能力的同事）。我无法想象Scrum大师如何为这样的团队做出贡献。 作为一名经验丰富的开发人员，当团队中有一名教练时，我不是一个经验丰富的开发人员，但却善于计划生产周期，因此我很难在Scrum和经理中实现和理解这些东西的价值。那有什么意思？没有发展技能的人到底如何管理一支技术含量高的团队？也许这里的管理意味着其他？ 我认为管理是浪费时间，是不成熟的副产品。以我的理解，一个成熟的团队完全可以自我管理。显然，我错了，因为很多伟大的人都说了相反的话，但我无法说服自己。
5
极限编程（XP）与Peopleware中表达的思想不兼容吗？
我刚刚读完Peopleware（DeMarco，Lister），并在不久之前对极限编程（XP）进行了研究。正如我现在所看到的，这两种方法几乎是互斥的。 Peopleware建议使程序员免受任何干扰，并为不间断的工作设置优先级，以帮助程序员实现流程。另一方面，XP建议确保尽可能多的通信，甚至建议程序员“坐在一起”，成对编码并通常在同一房间内工作（产生大量噪音）。 是这两种相互竞争的思想流派，也许其中之一被证明是对/错，还是有有效的折衷办法？我可以看到双方提出的要点，但是看不到任何合理的妥协。 我对研究软件开发管理非常陌生，因此可能我只是误解了一些东西。欢迎所有评论。 PS作为一个附加的小问题，作为一名程序员，您会发现哪个更有生产力？
6
正在创建您认为需要在TDD中进行第一次测试的对象
我对TDD相当陌生，在创建任何测试代码之前的第一个测试时遇到了麻烦。在没有任何实现代码框架的情况下，我可以随意编写我的第一个测试，但是它似乎总是被我的Java / OO问题思考方式所困扰。 例如，在我的Github ConwaysGameOfLifeExample中，我编写的第一个测试（rule1_zeroNeighbours）首先创建了一个尚未实现的GameOfLife对象。称为不存在的set方法，不存在的step方法，不存在的get方法，然后使用断言。 随着我编写了更多测试并进行了重构，这些测试也在不断发展，但最初看起来是这样的： @Test public void rule1_zeroNeighbours() { GameOfLife gameOfLife = new GameOfLife(); gameOfLife.set(1, 1, true); gameOfLife.step(); assertEquals(false, gameOfLife.get(1, 1)); } 当我根据在早期阶段决定编写此第一项测试的方式来强制实施设计时，这感觉很奇怪。 以您理解TDD的方式可以吗？我似乎遵循TDD / XP的原则，因为我的测试和实现随着时间的推移随着重构的发展而发展，因此，如果这种最初的设计被证明是无用的，那就可以改变了，但是感觉就像我在向开发者强加一个方向。通过这种方式解决。 人们还如何使用TDD？我可以从没有GameOfLife对象开始，而只有原语和静态方法开始，进行更多的重构迭代，但这似乎太虚构了。
6
为什么极限编程（XP）已过时而支持敏捷，看板等？
我喜欢XP（极限编程），尤其是在同一屏幕上有2个程序员的部分，因为通常只有您解释自己在做什么，而结对编程会迫使您解释自己在做什么，这样才能更快地找到问题的解决方案在做。 在过去的10年左右的时间里，XP的工作方式似乎已经过时，倾向于使用工作方法：敏捷和/或看板。为什么？因为XP在我看来是一种很好的工作方式，并且与编程有关，而敏捷和看板则与过程有关。
1
配对编程是否消除了极限编程（XP）项目中的代码审查需求？
在一个极端的编程项目中，程序员大部分时间都会进行配对编程。 由于这些对也轮换使用，也就是说，您将程序与不同的人配对，并且具有集体所有权感，因此经常对源代码进行检查和更新。 这样的话，是否需要代码审查？我的意思是，停止编程，实际上只是进行代码审查。
1
与推和拉开发模型有什么区别？
我正在阅读《极限编程说明》第二版，在第11章“约束理论”中，作者讨论了过时和过时的“推”开发模型以及XP方式（“拉”开发模型）。它看起来像一个非常重要的概念，但是只用了一个很小的段落和两个图像，它们只是“瀑布”和迭代过程的说明，除了图像标题外，这些模型没有其他具体说明。我进行了搜索，在本书的其余部分中对此没有任何进一步的说明。我也无法在Internet上找到任何进一步的解释或讨论。 如果关于它们的唯一区别是一个是“瀑布”而另一个是迭代的，那么它们为什么推，为什么拉？ 有人知道这两者之间的真正区别是什么，并举一些很好的例子吗？
6
使用敏捷方法重写软件
假设您必须使用敏捷方法重写整个应用程序，您将如何做？ 我猜您可以根据当前系统的行为编写大量用户案例。然后以小的迭代形式实现它们。但这并不意味着我们具有UP FRONT的要求？ 另外，什么时候开始发布？敏捷说我们应该早并且经常发布，但是在完全重写完成之前发布并没有多大意义。
1
面向单个开发人员的极限编程[关闭]
已关闭。这个问题需要更加集中。它当前不接受答案。 想改善这个问题吗？更新问题，使其仅通过编辑此帖子来关注一个问题。 4年前关闭。 在过去的两周中，我一直在研究一些基本的极限编程概念，用于小型，营利，多人，街机游戏。我花了一个星期来开发用户故事并确定创建发布计划的要求。我还花了一周的时间编码并应用我想出的第一个迭代计划。我已经确定了一些对于单个开发人员有用的概念。 持续集成 永远不要尽早添加功能 测试驱动开发 选择一个系统隐喻 使用单个集成点 测试所有错误 不断重构 设定可持续的步伐 简单 频繁发布 我很好奇我是否缺少特别适合与单个开发人员项目一起工作的任何东西？ 同样，鉴于这种简单性和测试驱动开发的思想，使用建立的，功能丰富的，现成的平台更好吗？ 还是应该在可行的情况下从头开始工作，以避免遇到规则不断提出的问题，例如不断进行重构并且永远不要尽早添加功能？
10
用户故事水平太高且太概念化，管理层希望开发人员填补空白
我受雇于一家非常有才华的公司，真正的目的是从事XP。沟通很好，管理人员也可以进行富有建设性的讨论，但是由于时间紧迫，某些事情被认为是RUP，无法讨论。 目前，我对实施故事时需要进行的大量更改感到有些困惑。我相信其中许多发现（当然，这需要花费时间和精力）是故事编写者（客户，最终用户和产品所有者）的责任，而不是开发人员的责任。简而言之，用户故事太概念化，只是传达了基本意图，但缺乏足够的细节（特别是前提条件和后置条件，与其他故事的相关性，依赖关系等）。由于XP开发人员同时是设计师和分析师，因此开发人员可以自行决定填补空白。问题在于许多空白是在发现错误的假设进入评估时间和代码之后才发现的，因为注意到比最初预期的情况更加复杂。即使到那时，找到合适的东西来填补也要花费时间，在不同程度上，这被认为是与初始估计的偏差。 我正在寻找一种建设性的方式来将这些含义传达给管理层，而这种方式不会使我成为试图不必要地使事情变得复杂的人。我是新手，但我尚未建立起很高的信誉。 我们欢迎您的见识。 密切相关并且以某种方式给出了答案：开发人员可以期望多少有关用户故事的细节？
5
关于Scrum和XP的好书[关闭]
按照目前的情况，这个问题不适合我们的问答形式。我们希望答案会得到事实，参考或专业知识的支持，但是这个问题可能会引起辩论，争论，民意调查或扩展讨论。如果您认为此问题可以解决并且可以重新提出，请访问帮助中心以获取指导。 7年前关闭。 我想知道您建议阅读Scrum和XP的内容。我从Trenches那里获得了Scrum和xp，但我希望看到更多有价值的参考。
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.