是否有研究表明哪种敏捷方法最适合于特定类型的项目？(在本例中是一个重新开发项目，Javato.NET)

Question

据说看板方法适合软件维护和支持领域，而Scrum更适合新产品开发。没有一个过程或方法是完整的。使用正确的方法会帮助你成功，但它们并不能保证成功。

是否有研究表明哪种敏捷方法最适合于特定类型的项目？(根据项目类型来衡量项目的实际成功程度，例如，项目的最佳敏捷方法是一种从一种技术到另一种技术的重组，比如从Java到.NET，这表明看板比Scrum更容易成功)。

Answer 1

据说kanban方法适用于软件维护和支持领域，而scrum则适用于新产品开发。

我认为敏捷社区中的大多数人都会不同意。看板和Scrum都适合新产品开发(我曾与Kanban合作过一个绿地项目)。

的确，它们有不同的优点和弱点，当快速响应至关重要时，最初形式的Scrum并不适合软件维护，但是大多数团队并不使用“纯”方法，而是根据他们的需要定制它。

哪种敏捷方法最适合于一个基本上是从一种技术到另一种技术(比如从java到.net)的重组的项目。

敏捷的答案是:不要。彻底重写很少是个好主意，最重要的是违背敏捷开发的基本思想之一，即专注于快速交付价值:如果你完成了一次完整的重写，那么你很可能在完成之前不会交付任何价值(如果你失败了，也可能永远不会)。例如，请参见：重写或不重写和Joel on Software --你永远不应该做的事情，第一部分。通常最好是修复那些造成最大痛苦的部分，可能会一点一点地迁移到不同的技术中(例如，一个模块一个模块地)。在开始的时候，这看起来可能比较困难，但会给你带来更快的结果，并降低风险。

也就是说，如果你觉得你必须重写，方法并不取决于它是重写的事实。相反，这应该取决于您的团队是如何组成的，他们希望如何工作，您如何与涉众沟通，等等。看板和Scrum都非常适合。