Scrum和极限编程（XP）：最佳实践

Question

我们在组织中遵循Scrum进行软件开发。虽然我们对Scrum有丰富的经验，但我们还是不能在一天结束时生成好的源代码。人们正在谈论将极限编程（XP）与Scrum结合起来以产生可预测的结果。

我已经阅读了极限编程材料，但无法获得良好的效果。

如何在软件开发中使用Scrum和极限编程？

Answer 1

Scrum是一种灵活的项目管理方法。它没有涉及创建任何类型的“商品”所需的实践，而是提供了过程，它将把我们从愿景的开始带到最终产品，无论实际的开发过程如何。 Scrum流程不会告诉您如何来创建质量。它向您展示了质量，问题所在，以及您需要解决的问题。

极限编程是一种灵活的软件开发方法。它为我们提供了一个以敏捷和富有成效的方式创建软件的过程。它涉及，但并不专注于开发过程的管理，并主要关注提供软件质量所需的工程实践。

当采用Scrum进行软件开发时，工程实践是从敏捷软件开发实践中导入的，通常来自XP。这些实践是那些可以与其他开发实践分离的方式采用的实践。大多数情况下，这些做法是：测试驱动开发，重构和＆amp;配对编程和用户故事，但这些在Scrum中并不是必需的，或者是做事的唯一方法（强烈推荐）。 Agile Modeling是敏捷工程实践的另一个常见来源。

简而言之，在混合Scrum和XP时，这是迄今为止最常见的混合，你可以使用Scrum的所有管理工件，例如： Sprint，每日Scrums，回顾，烧毁图表等，并通过用户故事添加XP的TDD，重构，结对编程和JIT设计。

当然，Scrum是Scrum，这就是你的开始，你不断适应（重构，如果你愿意）这个过程来回答你组织的特定需求。

Answer 2

检查和调整。
没有银弹

没有神奇的血清可以让团队成功，因为他们正在使用Scrum / XP / Agile et.all;找到你的瓶颈并一次消除它们

更新：有些人觉得我的答案不够有用。我声称'敏捷伤疤'让我这样离开 - （戴上我的帽子）也许你应该阅读Scrum and XP from the trenches

Answer 3

Scrum对编程没什么可说的。

在我看来，如果没有允许您在技术层面快速响应变更的软件工程实践，您就不能“敏捷”：增量设计，单元和验收测试，重构，持续集成，集体代码所有权。

这是所有其他需要的事情之上，例如客户的高度参与以及团队内外的有效沟通。

除了这里提到的其他书籍之外，James Shore和Shane Warden的The Art of Agile Development是关于敏捷软件开发的最佳书籍。

[edit]其他人在这里提到的一些来源链接：

Continuous integration

Refactoring

Henrik Kniberg的{p> Scrum and XP from the Trenches (great presentation on infoq.com)

Answer 4

实用程序员（Jim Ferrans提到）和Clean Code都是敏捷程序员的优秀资源。您可能还想看一下极限编程系列中的书籍。

Answer 5

Scrum实践适合与产品所有者协作和确定优先级。但是，Scrum本身并不会让开发团队实现可持续发展的步伐。

XP的重点是工程实践，例如测试驱动开发（TDD），共享代码库，简单和简单的实践。进化设计，配对编程，自动化测试，持续集成，技术债务等。

在所有工程实践中，TDD是最难学的，总的来说，工程实践的学习曲线比管理（Scrum）实践更高。但是，如果没有工程实践，代码将无法保持速度。原因是代码将花费更长时间来测试并变得脆弱以进行更改。

如果您要接受工程实践，最好将团队中的技术或工程教练嵌入其中。教练将为每个练习提供入门培训，并通过配对快速传播整个团队的实践。

Scrum和XP是一个很棒的匹配。一些研究表明，将Scrum和XP结合起来可以产生最有效的敏捷团队。鉴于每个焦点都是独特但又互补的，在任何敏捷团队中使用Scrum和XP都是明智之举。

Answer 6

Scrum是项目管理的敏捷过程，因此除了在每2-4周“冲刺”结束时始终拥有潜在的可交付系统时，它对代码质量没有影响。通过保持短跑并获得日常反馈，项目经理可以更好地了解新功能需要多少工作量，并且团队可以很好地了解每个新功能的相对重要性。

你仍然需要努力编程。关于这方面有许多好书（例如McConnell的Code Complete，以及Hunt和Thomas的The Pragmatic Programmer），你应该仔细研究它们并将它们应用到你的工作中。

Answer 7

你写的是错误的代码，因为：

1. 您的团队不知道如何。
2. 没有人在权限检查，批准需要良好的代码。
3. 你没有足够的时间？
4. 过分依赖糟糕的遗留代码。
5. 不提供适当的工具（来源控制，开发环境，通讯等）

我不确定这些与Agile / Scrum有什么关系。

Answer 8

每个开发人员，他/她的风格，技能以及始终沉浸在新信息中的愿望都与代码的质量和最终产品在开发过程中的成功有关。

如果你没有合适的人，没有PM技术会帮助你。首先找到合适的人，分别能够生成良好代码的人，然后再担心在团队合作中将它们组合在一起。一个人可能会破坏整个团队的努力。

另一方面，我讨厌SCRUM的一件事是每日站立会议。 Yarrr。

Answer 9

Krish， 你的立场是什么？团队经理？ 我发现作为Scrum团队领导者做的最好的事情就是在团队面前提出问题并让团队提出解决方案。 例如，我们总是在冲刺结束时脱离目标。 因此，在一次冲刺回顾中，我提出了一个问题“给我代表我们团队冲刺能力的小时数”。 有三个结果：

• 我们从来没有接近过我们的标记
• 这个数字高于我的估计： - ））
• 所有团队成员都付出了额外的努力

我们正在使用软件工具（在我们的案例中为OnTime）来跟踪所有重要措施，并在每次冲刺后讨论我们的统计数据。 此外，我们的做法是在每个冲刺中改变至少一件事。

希望这有帮助，请随时提出更多要求

马捷

Answer 10

看看this matrix比较James Shore制作的SCRUM和XP的良好实践。顺便说一下，如果你想了解XP，我发现他的book非常有用。还有一些articles可以让你了解一些实践。

Answer 11

除了敏捷/ scrum之外，我还建议如下（管理层必须实施一些想法......祝你好运）：

• 在编写一行代码之前与他人进行分析和讨论;这包括引入相关的开发者和非开发者
• 登记前的代码审查（这在TFS和其他源控制系统中是强制性的）
• 鼓励组织上的自由思想流动（以身作则）;从不惩罚某人分享他们的想法（好吧，有理由），因为这样做与公司更敏捷（更有利可图）的思想自由流动相矛盾。
• 为可能从外部聘请的开发人员建立一个“高级”或“架构师”职位，他非常称职，但也不善于为了良好的s / w架构而推迟管理，避免“ “损害长期可扩展性等”的特征

Answer 12

你的意思是什么'好代码'？为什么好的代码很重要？您是在谈论可维护性 - 这需要良好的代码还是良好的文档？您是在谈论可靠性 - 这是否需要良好的代码或良好的测试和记录的要求？等

运用常识，建立合理的标准和评估系统，尽量忽略归因于某种技术或工具的未经证实的成功主张。

Answer 13

SCRUM方法非常受欢迎。软件公司使用SCRUM的最佳方式是对每个程序员在个人级别上执行SWOT分析。在程序开发过程的特定部分中将程序员与XP一起使用。然后关闭SWOT分析，使用生鱼片或基于个体SWOT的其他项目生命周期。虽然这在项目中似乎是一堆乱七八糟的东西，但没有“银弹”。为团队提供完美的方法论或生命周期。项目经理必须根据他或她认为在项目中提高工作效率的位置来理解和分配每个成员角色。我的2美分。