持续交付:看板，SCRUM还是其他？

Question

我想知道是否有SDLC (软件开发生命周期)或方法论(看板、SCRUM、瀑布等)。这特别适合于连续交付系统，为什么呢？

我相信每种方法都有优点/缺点，使其适合CD的某些组成部分，但必须有一种结合原则/价值观的方法，使其更适合CD.

Answer 1

坦白说，我觉得你应该看看他们所有人。Scrum是因为它非常强调迭代和增量开发。XP是因为它在开发的技术方面提供了很多建议。看板，因为它强调WIP的限制和流程。

不管怎样，这就是我认识他们的方式；我注意到，这些年来，他们都对彼此产生了重大影响。在这两种情况下，没有任何一种方法能得到所有的答案。

对我来说，对于所有“连续的”(包括连续的交付和连续的部署)来说，一个非常重要的核心思想是使事情尽可能小:使故事更小，这样它们就能更快地完成，这使得您专注于迭代的、具有快速反馈的紧急开发。但是，还可以使应用程序本身中的组件更小、更解耦。

也就是说，如果您专注于通过某种形式的消息传递彼此通信的小型服务，那么这些服务将变得更容易理解、更容易测试，并且您的更改无意中波及到代码的其他部分的可能性也会更小。

关于后者的更详细但更“极端”的解释，下面是两个非常有趣的视频：https://vimeo.com/79866979，https://vimeo.com/74452550

Answer 2

我从SCRUM开始。SCRUM有强大的原则，可以指导您的团队完成项目。

它是一个强大、简单和灵活的框架。因为它是一个框架，所以它并不能处理SDLC中可能需要的每一个步骤。它只提供了基本的指导原则，这就是为什么SCRUM通常与XP和持续交付等其他实践一起使用的原因。

SCRUM和其他原则的示例实现：

• SCRUM和对编程(XP)
• SCRUM和持续交付
• SCRUM和计划游戏(XP)

Answer 3

我坚信看板更适合连续运送(CD)。以下是一些原因：

• 看板和CD是相辅相成的，因为这两种技术都专注于实时(和一次)价值的交付。
• 看板团队专注于优化向客户输出的工作流程。
• 看板帮助您创建一个更稳定的工作流，您可以更容易地吸收计划外的工作(如bug修复)。你可以重新安排工作的优先次序，集中精力完成你已经开始的工作，而不是在任务之间切换。
• 看板不需要对sprint进行时间装箱，因此可以快速转移优先级以满足业务需求。一种紧急的解决办法或高度优先的改进措施可以以快速的速度通过。
• 看板促进渐进式改进，这对持续交付的成功至关重要。
• 与Scrum更注重过程的角色相比，看板对于服务请求和交付管理人员的角色更符合CD的流。
• Scrum是基于固定长度的常规sprint，而Kanban则是基于连续流，而不需要尊重sprint的长度。
• 在Scrum中，如果每个sprint都得到了Product的批准，那么交付是在每个sprint的末尾完成的，而看板则是基于持续的交付。