9个关于敏捷的误解

敏捷的软件开发方法已被许多不同行业的众多公司采用。正如其名称一样，敏捷开发强调灵活性，速度和客户关注。当团队做到正确时，它可以缩短发布时间，提高团队效率并提高客户满意度。然而，许多公司继续弄错。经验表明，一些发展问题的根源可能是对敏捷开发的误解。为了直接记录，这里有九个误解和评论来对抗这些神话，并帮助你做到正确。

 

1.敏捷消除了计划

敏捷方法的成功实施，如瀑布式开发方法，取决于支持业务流程，包括规划和预算。敏捷计划和瀑布计划之间的一个区别是计划发生的时间。敏捷采用迭代过程，其规划过程也是渐进式的。相比之下，瀑布模型要求在项目的初始阶段进行规划。反过来，敏捷项目在一个时间点的规划范围与使用瀑布模型的规划范围不同，规划周期的数量也是如此。

2.敏捷避开所有文档。

为了设定项目的方向，软件开发团队依赖于指定系统应如何工作的文档。这些文档符合开发人员，IT架构师，最终用户和其他业务利益相关者的目标。因此，与传统项目文档不同，敏捷项目文档可作为团队成员协作的基础，也可作为该协作的反映。然而，敏捷项目文档的生成时间与瀑布文档的生成时间不同：前者可能包含在整个项目生命周期中生成的大量文档; 后者包括在项目开始时创建的单个全包文档。

3.敏捷仅适用于小型点解决方案项目。

敏捷团队模型对于小型，点解决方案项目和大型复杂系统都是有效的。特别是，在开发需要多个跨职能组支持的多维系统期间，创建多个小的跨职能组可能特别有益。例如，大型综合系统的开发可以从多个团队的复杂或多样化需求的划分和分配中受益。在这种情况下，通过软件功能或IT架构组件组织各个团队可以关注团队成员的工作并限制冗余工作。

4.敏捷的利益相关者和开发者共处一地。

虽然敏捷项目依赖于整个软件开发过程中各种不同专业知识的参与者，但没有必要共同定位团队成员。相反，无论团队成员的位置如何，团队都可以依靠电信系统进行正式和非正式的沟通。此外，支持通信和协作的视觉辅助工具采用多种形式，例如允许一位同事查看另一位同事的计算机屏幕的屏幕共享工具。

5.使用AGILE，产品在整个开发过程中仍未定义。

Waterfall模型允许在编码开始之前完全定义最终产品的需求规范。但是设计，业务流程，利益相关者需求或数据要求可能在以后的日期仍然未知，并且可能会发生变化。在这些情况下，由于成本和时间问题，瀑布模型可能不如敏捷方法所需。敏捷产品规划，如瀑布模型规划，发生在早期开发阶段。随着敏捷开发的进行和每个系统迭代的构建和改进，计划细节出现了一个主要差异。

6.敏捷开发过程是临时的：非结构化和无纪律的。

成熟的敏捷框架调用了有序且可重复的软件开发方法。事实上，由瀑布模型引导的软件开发周期与敏捷方法所指导的相比，协调性和面向过程更少。使用用户故事优先级来管理项目范围，定义角色和事件以指导项目管理以及定期的利益相关者审核，敏捷流程比其他软件开发模型或方法指导的流程更加严格。

7.敏捷是SCRUM的代名词。

Scrum是一个部署在复杂敏捷项目中的框架，部分原因在于它能够适应最后一刻的变化。但事实上，除了Scrum之外，还存在多种敏捷方法：精益编程，极端编程和其他混合方法。例如，开发人员可以通过合并特定的敏捷原则（例如增量开发和交付软件）来简单地修改现有流程，以扩展利益相关者协作。

8.敏捷开发过程不符合联邦开发要求。

如果与敏捷开发人员签订合同，一些与收购，企业架构，安全认证和认证相关的联邦SOP可能会出现问题。即便如此，法规也没有明确排除敏捷开发。例如，一个主要问题可能源于敏捷开发过程本身…即，注意到敏捷的自发变化可能与传统合同投标和变更单，延迟和预算超支的机构要求相悖。

9.敏捷否定了大多数软件开发难题。

敏捷具有相对优势：利益相关者参与和协调，快速交付生产版本，及早识别项目风险等。但是，敏捷开发并不适用于任何和所有项目。例如，敏捷最适合项目工作，可以分为小增量，每个项目都可以在几周内完成。此外，组织的文化和实际项目方法必须支持增量交付方法。更重要的是，一些计划比其他计划更适合敏捷。例如，敏捷是分析和移动项目的一个很好的选择，但对于ERP和大型系统现代化的努力则更少。

敏捷开发是许多代表各种行业的公司所依赖的方法，部分原因在于它在软件开发过程中产生的速度，客户关注度和灵活性。因此，敏捷有助于提高客户满意度。但是，一些公司将敏捷开发的采用基于长期存在的误解，因此无法获得方法的回报。希望这些评论能够对抗其中的一些误解，并在此过程中帮助公司获得正确的敏捷。

 

-----

更多推薦的Scrum文章

Scrum中Definition of Ready的定义是什么？

 

The product owner can work with the team to define an artifact called Definition of Ready to ensure that at the top of the backlog projects are ready to move to sprint so that the development team can confidently submit and complete them. The end of the sprint. (产品所有者可以与团队一起定义一个名为“ Definition of Ready的定义”的工件，以确保积压顶部的项目已准备好移动到sprint中，以便开发团队可以在冲刺的结束之前自信地提交并完成它们。)

完成 vs. 接受标准的定义

 

Completion (DoD) is defined as a list of requirements that user stories must comply with in order for the team to complete the PBI. The difference between the two is that DoD is universal to all user stories, and acceptance criteria are applicable to specific user stories. The acceptance criteria for each user story will vary according to the requirements of the user story. (完成（DoD）的定义 是用户故事必须遵守的要求列表，以便团队完成调用。这两者之间的区别在于，DoD对于所有用户故事都是通用的，而接受标准适用于特定的用户故事。每个用户故事的接受标准将根据该用户故事的要求而有所不同。)

Scrum工件是什么？

 

Scrum artifacts provide key information that Scrum teams and stakeholders need to understand in order to understand the products being developed, the activities being planned, and the activities completed in the project. The following artifacts are defined in the Scrum Process Framework. (Scrum工件提供了Scrum团队和利益相关者需要了解的关键信息，以便了解正在开发的产品，正在计划的活动以及项目中完成的活动。Scrum Process Framework中定义了以下工件。)

从长远来看: Scrum Master角色是否会消失？

 

Scrum Masters coaches, coaches, coaches and enables their teams to develop excellent products. This can be a challenging and time-consuming task for new teams in organizations that are also novices to Scrum. Over time, the team improved. Does the Scrum Master role disappear completely and continue to zero? (Scrum Masters教练，指导，指导并使他们的团队能够开发出优秀的产品。对于同时也是Scrum新手的组织中的新团队而言，这可能是一项具有挑战性且耗时的工作。随着时间的推移，团队改善了。Scrum Master 角色是否完全消失一直持续到零？)

作为Scrum Master，您如何帮助您的产品产品拥有者？

 

The common goal of Scrum master and products is to create viable products through the use of Scrum best practices. The two roles overlap in some of their skill combinations. Therefore, product owners and Scrum Master should make every effort to work closely in many different areas of the project. (Scrum master和产品的所共同目标是通过使用Scrum最佳实践创建可行的产品。者两个角色在他们有一些技能组合中重叠。因此，产品负责人和Scrum Master应尽一切努力在项目的许多不同领域密切合作。)

####敏捷开发: 什么是跨职能团队？

The advantages of cross-functional teams in Agile Development lie in improving cross-functional coordination, increasing product and process innovation, and shortening the development cycle of critical customer contact point feedback. (跨职能团队在敏捷开发中的优势在于改进跨职能协调，增加产品和流程创新，缩短关键客户联系点反馈的开发周期。)

什么是Scrum Master？角色和责任

 

Scrum master is the driver of agile development teams. Scrum is a method that allows teams to organize themselves and change quickly based on agile principles. Scrum master manages the process of information exchange. (Scrum master是敏捷开发团队的推动者。Scrum是一种方法，允许团队根据敏捷原则自我组织并快速进行更改。Scrum master管理信息交换的过程。)

Scrum: 三个角色？

 

The roles in Scrum are clearly defined roles and expectations help individuals accomplish their tasks effectively. In Scrum, there are three roles: product owner, development team and Scrum Master. These are called Scrum teams. (Scrum中的角色是明确定义的角色，期望可以帮助个人有效地完成任务。在Scrum中，有三个角色：产品所有者、开发团队和Scrum管理员。这些被称为Scrum团队。)