当开发是持续时，需求的收集是如何变化的？

对于敏捷团队来说，持续需求收集可能很熟悉。随着向持续交付或持续开发过渡，敏捷团队所发生的变化有多种途径，但大致相同：迭代变短，每个项目的范围减少，以及需求变得更加灵活。

持续开发的不同在于沟通、建模和设计讨论的发生是持续的，并不仅限于定期的会议中。团队不必须围一个圈、举起手不唱“Kumbaya”。但他们必须要习惯于问问题、提出想法，进行集体讨论——如果可能，要重复进行。团队之间的讨论非常重要。会议不限形式，可以是面对面，可以是即时通讯、邮件或电话会议。重点是要进行讨论。

许多团队使用白板来记下设计想法；而另外一些人使用建模或流程图技术，根据变化的规模或复杂度的不同，或变化对其它部分的影响。重要的是团队所决定的沟通方式对他们是最好的。最合适的工具是它最适合于特殊人群。

存档需求对于敏捷团队的成功也很重要。他们可以是用户故事的一部分，或任何其它类型的文档。目的在于持续记录想法，以及跟踪代码有效性。团队成员变了，业务先后顺序变了，所以设计决策也必须持续记录。

通常情况下，复杂的变化应该打散成小部分。小部分易于管理，它也是持续成功的秘诀。持续开发并没删除定义需求的职责，但它要求他们随着功能的设计，要持续收集。