我可以使用敏捷开发方法单独开发我的应用程序吗？

Question

我可以使用敏捷开发方法单独开发我的应用程序（我认为这种方法是针对团队开发的）。我可以使用的原则是什么？抱歉我的英文不好

Answer 1

虽然之前的所有答案都是正确的，因为你当然可以使用敏捷技术，同时作为一个人的团队（在理性中，正如Oded所指出的那样，你自己站起来或回顾是没什么价值的），我会质疑您采用的每种做法的价值。

• 有没有关于构建的重点，或许，持续整合怎么样 - 浪费时间，你有更大的鱼来煎炸。
• 经常发布可能是一个好主意。
• 您是否需要积压工作，这完全取决于谁定义您的要求以及您正在构建的软件的大小。
• 您是否需要迭代 - 即使敏捷社区中的人们已开始质疑其价值。

这件软件总是由你维护，还是你交出来？如果你要把它交给一个好的测试套件是有礼貌的事情，但如果它永远是你，不要打扰任何大规模只测试你不确定的位。我当然不会打扰TDD，没有人会对你的测试方式印象深刻，除非你是专家，否则会减慢你的速度。

当天结束时，在自行开发软件时，我认为您需要密切关注奖励，即在合理的时间内提供工作系统。只要你牢记这一点，你最终使用的是什么过程并不重要，除了你自己之外，没有人会被奇怪的做法绊倒。

Answer 2

是的，你可以。

完成任务，分解任务，估计它们并确定它们的优先级，并在短时间内对它们进行处理。

如果您选择，也可以自己站起来;）

Answer 3

是的，你可以！

• 经常发布
• 保持管理的待办事项
• TDD
• 每次迭代展示一些新的工作
• 有一个持续的集成循环

Answer 4

大多数敏捷方法都以反馈循环为中心。你越频繁地重新检查和调整你正在做的事情，你就会越敏捷。

• 经常构建：如果可以的话，每次提交，编写自动化测试以在构建时运行，越早知道某些事情就越好。
• 使用短迭代：重点是在迭代结束时没有工作软件（你将试图不打破它的周期）。迭代背后的要点是检查和适应。承诺自己（错误修复，新功能等），实现它，然后回顾你做对了什么，你做错了什么，改变了一些有意改进的东西。
• 保持积压的新鲜事：没有什么比陈旧的积压更糟糕了，如果可以，请及时了解新的反馈和想法。将单个积压项保留为大，直到您准备好在迭代中提交它们，然后将它们分解为块。这些块应该足够小，以便您可以看到迭代中的每日进度。
• 保持简单。与一个人保持敏捷非常简单，但很容易陷入为大型团队设计的解决方案中。估计可能被认为是开销，只需承诺您认为可以在合理的时间内完成的工作。

Answer 5

敏捷意味着出色的响应能力。适应变化，在这里我将“变化”看作是软件开发的常规方式的变化 - 你自己而不是团队。为什么不使用 G-71软件方法来回应它，就像你遵循敏捷软件方法那样：）