距敏捷开发宣言的发布已经过去了将近二十年，现在很多团队都在思考“敏捷”的工作方式。营销团队想要尝试Sprint的方式来加速盈利，运营团队正在采用Scrum敏捷项目管理，而人力资源团队则正在寻求如何为公司战略注入更多的灵活可变性。
那么对于研发团队而言，敏捷实际上只是一套帮助解决大型且复杂项目的方法论。在工作中，如何正确的运用敏捷方法哪种方式，一直存在很多争论。
通常而言，复杂、大型的研发项目需要跨部门的协调，项目经理总是希望可以快速实施并交付产品。但是当你想要调动全部资源去推动此项目时，这又将对其他部门的业务和工作产生影响，这是不现实的。因此在项目研发过程中，团队需要采用敏捷开发方法，并以不断迭代的方式来应对快速变化的需求。
敏捷并非意味着在项目开始之前就定义最终需求并安排好全部工作内容。但对于跨公司的庞大项目而言，需要了解产品需求和路线，否则每个人工作都有可能出现差错。那么是否有可能将敏捷开发应用于类似上述的庞大项目呢？
我认为是可行的，但需要实行真正意义上的的敏捷开发。
请记住，敏捷并不是每个人都必须遵循的一套固定规则。它是一种方法论，是帮助团队应对快速变化的需求、提高工作效率的一种理念和价值观。在产品研发过程中，团队通常使用Scrum或看板之类的框架来提高效率，但是对于这些框架不适用的工作场景，尤其是在项目的初期，也并不一定意味着无法实行敏捷开发了。敏捷可以很简单，例如确定项目目标，将其拆解为几项可以实现的小任务，然后以此为基点进行迭代和开发。
在产品研发过程中，通常团队采用瀑布式开发的方法是：每次聚焦于一个阶段，每当一个阶段的任务完成后，团队才会开始下一阶段工作。这将导致团队在开发过程中无法适应需求的改变，不断试错，需求变更成本也会随之增加。
整个开发工作的流程是相通的，但不一定会彼此适用。此情况就好比一个公司在价格相同的情况下，是应该购买多种不同类型的办公软件，还是购买一款可以解决不同场景的办公软件，答案一定是后者更能将工作简化，提高工作效率。
那么瀑布式开发的弊端如何改善呢？是在产品开发的第一个阶段就引入第二阶段的成员吗？如果多个需求互相关联，但每个需求的开发进度不一样，又该如何协调处理呢？
由于以上瀑布开发的种种弊端，敏捷开发逐渐打破了传统的瀑布开发方式。
当项目开始时，第一步要做的事情就是定义产品的业务需求和产品路线，等到所有业务需求和实施方案都落实敲定后，再开始编写第一行代码。敏捷开发的过程是需要团队全员参与的，从定义产品需求到不断迭代交付都是整个团队的工作，因此产品经理、研发工程师以及其他所有成员都应积极参与其中，在每个环节中都可以表达自己的声音和想法。在此过程中团队需要制定迭代计划并进行站立会议，以此来持续性的学习、发布、迭代，逐步完善产品。
不管您处于何种行业，在定义产品需求的阶段，应当首先考虑产品的合法、合规性，医疗、能源或制造业等重点监管行业更应注意这一点。这也会大大避免以此带来的交付时间延迟和项目预算超支。
不可避免的是，开发过程一旦开始，新的问题也会随之而来，比如产品上线后，用户的需求可能发生变化；新的政策可能会影响产品的合规性等等。因此敏捷开发提倡在项目开发阶段，通过每天的站立会议，来确认每个成员是否遇到的问题，从而确认问题并及时沟通解决，并以此来制定迭代计划。随着产品的不断迭代和新功能发布，企业也会获得更大的价值。
人们开始逐渐意识到，时间管理成为了每个人都无法回避的问题，而有时必须放慢速度认真思考才会更有效率。随着每个团队对工作方式的认知从传统流水线的旧思维，逐步转变为紧凑且自我组织型团队的新观念，同时团队也需要更多地思考如何来实现敏捷开发， 而不是一股脑地去盲目试错。
由于敏捷开发中涉及大量的任务管理、计划、协调、监控等事务，我们需要使用统一的工具来管理这些需求并将它们可视化，建议大家可以试试Worktile Agile敏捷开发工具，它包含了需求管理、迭代规划、效能度量等功能，可以帮助团队实时追踪项目进度，并且可以和Testhub测试管理等产品打通，来实现一站式DevOps开发流程。