敏捷发展如何通过暴风雨走向世界
2018-09-27 08:34:32
曾几何时，在编程领域，多年可以在识别业务需求和启动软件之间传递以满足它。在过渡期间，原始商业案例很可能已经发展，这意味着该软件在发布时已经过时。项目的复杂性越大，最终构建时软件解决方案可能就越过时。一旦构建正在进行，用于开发软件的严格方法几乎不允许范围的灵活性。
当80年代推出的航天飞机计划使用了60年代的技术 - 开发需要几十年而不是几年。在软件开发过程中，需求和系统不断发展。
早期的编程方法遵循最初为桥梁和水坝等物理工程项目开发的方法。这些项目往往采用严格的规划阶段，旨在减少构建本身的时间，功能专家交给新的专家组，并将学科保存在不同的团队中。
在这种方法下，目标是计划在构建工作开始时停止。建筑师在设计阶段结束时将计划移交给施工经理，他们不应该在那之后修改设计。如果在构建过程中修改了计划，它通常被视为一个运行不良的项目。
但是，甚至在IT革命之前就采用了其他硬件工程方法。在20世纪50年代，迭代和增量开发方法被用于创建X-15高超音速喷射。“随你学习”的方法更适合这种创新技术。
丰田使用这种方法在汽车设计和生产方面进行创新，团队在构建过程中开始以跨学科协作方式开展工作。最终，使用这些更具协作性的方法将设计新车所花费的时间减半。
在2000年左右的某个时候，这种软件开发方法成为一种有意识的学科。最主要的特点是在项目开始时没有任何内容：在不整个项目崩溃的情况下，它的每个元素都可以改变。
开发团队根据用户需求构建他们的第一个响应，由这些用户进行测试，并在必要时进行重建，以更好地适应这些用户真正想要和需要的内容。
这是一种开发方法，旨在获得用户的快速反馈，并将其纳入正在进行的开发过程中。产品的工作版本定期向利益相关者展示，这意味着他们在构建期间获得了输入。
快速反应
在当今竞争激烈的技术领域，敏捷方法对于快速将产品推向市场特别有用。通常在其他技术或开发项目的背后发展，新的项目需要在竞争对手将其淘汰之前快速启动。
处理敏捷开发的一种方法是使用Scrum开发框架，该框架擅长于为任何开发团队中的不同功能学科提供沟通框架。在Scrum工作，设计和用户体验专家与前端和后端开发人员合作，并且客户也有正式的角色让他们参与进来。有一个定期会议的框架，有不同类型的会议，包括每日定期会议和定期会议。
Scrum提供了一个非常扁平的团队结构，对于来自更加层次化的工作文化的团队成员来说，这可能是不熟悉的。但是因为它使通信正规化并让每个成员参与进步会议，所以正确运行的敏捷项目通常会提供足够的结构，以便创建自己的内部工作文化，并让人们跨学科进行交流。
你可以争辩说，Scrum坚持团队遵循的仪式创造了一个每个人都可以使用的工作文化。这是一个独特的工作环境，可以帮助人们以最佳方式完成项目。
当团队由来自不同工作文化和背景的人组成时，这尤其有价值。现代发展项目很可能有来自不同背景的人，他们在一系列学科中工作。
逻辑的，以细节为中心的后端开发人员与以人为本的业务分析师和以语言为中心的内容专家，有组织的项目经理和产品所有者一起工作，这些都是完全以用户为中心的。
这些不同的学科将有非常不同的思维方式和解决问题的方法。为他们的工作生活提供一个相当坚固的结构是有价值的，因为它有助于团结来自不同方向的人。
目前，整个技术领域存在技能短缺问题，虽然业内许多人都接触过这门学科，但仍然缺乏具有敏捷工作经验的人才。很难找到优秀的Scrum管理员或用户体验管理人员，很少有内容设计师具备开展敏捷开发所需的经验。但无处不在的敏捷工作意味着开发人员至少可以轻松适应使用熟悉的框架（如Scrum）的新工作环境。
反弹
敏捷可能已被全球采用作为开发框架，但不是每个人都迷恋它。敏捷工作方法的“邪教”本质使许多人感到沮丧，一些评论家抱怨说，过分关注无意义的仪式，例如Scrum概述的忽视良好发展决策的仪式。甚至有人批评敏捷采用的语言。
批评者经常忽略的敏捷的一个要素是，通过为日常交流铺平道路，它帮助跨文化和跨语言团队在共享的工作文化中融合在一起。在一个通常需要从全球范围内采购开发人才的世界中，敏捷是创造实现成果的工作文化的好方法。
对于敏捷收到的所有批评，它很受欢迎，因为它是任何人都能想到的软件开发的最佳方法。
