赢得面试——关于敏捷方法论和敏捷开发你所需要知道的-白红宇

赢得面试——关于敏捷方法论和敏捷开发你所需要知道的

阅读量：4040 次

发布时间：2019-05-24

本文共 4386 字，大约阅读时间需要 14 分钟。

赢得面试——关于敏捷方法论和敏捷开发你所需要知道的

敏捷方法的一些特性

敏捷允许向最终用户频繁交付产品。

客户反馈和变更将根据其优先级包含在迭代中。

它强调跨职能团队的协作工作。

它注重更多的互动和面对面的交流。

它促进对整个开发过程的定期审查，并在需要时进行微调。

敏捷方法的优势

敏捷非常适合于需求和最终产品不太清楚的项目。

当顾客的反馈和改变被接受时，它会提升顾客满意度。

它减少了风险因素，因为最终用户可以看到早期的交付成果。

在开发过程开始时不需要详尽的规划。

它易于管理，规则最少，灵活性更高。

将项目划分为可交付的增量构建会使我们更加关注产品的质量。

敏捷方法的缺点

因为它是高度以客户为中心的，所以当客户对产品和流程没有清晰的理解时，它可能会带来问题。

由于缺乏正式的文件和设计，培训和其他任务对个人的依赖性非常高。

对于复杂的项目，资源需求和工作量很难估计。

对于某些客户来说，频繁的交付、反馈和协作可能要求很高。

由于不断发展的特点，总是有一个风险的永恒的项目。

Agile方法和瀑布模型（Waterfall）的对比

瀑布模型方法论 Waterfall Methodology	敏捷方法论 Agile Methodology
瀑布涉及到一个大的团队规模，团队之间的协调减少。 Waterfall involves a large team size where coordination among teams decreases.	敏捷的目的是为了更高的协调而减少团队规模。 Agile intends a smaller team size for higher coordination.
客户只有在完成开发过程后才进行干预。 The customer intervenes only after completing the development process.	从客户那里获得持续的反馈，以提供可靠和高质量的产品。 Continuous feedback is taken from the customer to deliver robust and high-quality products.
它的方法是相当循序渐进的。 Its methodology is quite sequential.	敏捷方法论是增量和迭代的。 Agile methodology is incremental and iterative.
没有任何测试或开发级别相互重叠。 None of the testing or development levels overlap each other.	测试和开发级别经常相互重叠 The testing and development levels often overlap each other
验收测试只在最后阶段进行一次。 Acceptance tests are carried out only once, at the last stage.	验收测试在每次迭代后持续进行。 Acceptance tests are taken continuously after every iteration.
可交付成果的变更成本高昂。 Changes in deliverables are costly.	更改是显而易见的，所以它不会对可交付成果产生太大影响。 Changes are obvious so it doesn’t impact that much on the deliverable.
测试在项目结束时进行。当你要完成它的时候，你不知道它是否有效。任何功能中的任何故障都会让您回到产品的开始，从那里开始查找其根本原因。 Testing is performed towards the end of the project. You don’t know whether the deliverable works when you are about to finish it. Any failure in any of the functionality takes you back to the beginning of the product from where it started to find the root cause of it.	测试是分块并行进行的，这样如果有任何功能失败，就可以快速轻松地进行分析和纠正。 Testing is done parallelly in pieces so that if any functionality fails it can be analyzed quickly and easily rectified.

瀑布模型方法论

Waterfall Methodology

敏捷方法论

Agile Methodology

瀑布涉及到一个大的团队规模，团队之间的协调减少。

Waterfall involves a large team size where coordination among teams decreases.

敏捷的目的是为了更高的协调而减少团队规模。

Agile intends a smaller team size for higher coordination.

客户只有在完成开发过程后才进行干预。

The customer intervenes only after completing the development process.

从客户那里获得持续的反馈，以提供可靠和高质量的产品。

Continuous feedback is taken from the customer to deliver robust and high-quality products.

它的方法是相当循序渐进的。

Its methodology is quite sequential.

敏捷方法论是增量和迭代的。

Agile methodology is incremental and iterative.

没有任何测试或开发级别相互重叠。

None of the testing or development levels overlap each other.

测试和开发级别经常相互重叠

The testing and development levels often overlap each other

验收测试只在最后阶段进行一次。

Acceptance tests are carried out only once, at the last stage.

验收测试在每次迭代后持续进行。

Acceptance tests are taken continuously after every iteration.

可交付成果的变更成本高昂。

Changes in deliverables are costly.

更改是显而易见的，所以它不会对可交付成果产生太大影响。

Changes are obvious so it doesn’t impact that much on the deliverable.

测试在项目结束时进行。当你要完成它的时候，你不知道它是否有效。任何功能中的任何故障都会让您回到产品的开始，从那里开始查找其根本原因。

Testing is performed towards the end of the project. You don’t know whether the deliverable works when you are about to finish it. Any failure in any of the functionality takes you back to the beginning of the product from where it started to find the root cause of it.

测试是分块并行进行的，这样如果有任何功能失败，就可以快速轻松地进行分析和纠正。

Testing is done parallelly in pieces so that if any functionality fails it can be analyzed quickly and easily rectified.

敏捷方法论

Agile methodology is an iterative and incremental approach to software development. In Agile, we have small incremental builds presented in multiple iterations to the end-user and other stakeholders for their feedback. Based on the feedback, changes are incorporated in the next iterations of the build on the basis of their priority.

敏捷方法是一种迭代和增量的软件开发方法。在敏捷中，我们在多个迭代中向最终用户和其他涉众提供小的增量构建，以获得他们的反馈。根据反馈，更改将根据优先级合并到构建的下一个迭代中。

基本上，敏捷是一种方法论，遵循这种方法论有不同的实现。下面是一些最广泛使用的敏捷实现：

Scrum —— Scrum是最流行的敏捷实现之一，在敏捷实现中，产品所有者、Scrum管理员和团队成员等不同的角色被分配给不同的软件开发参与者。每天的scrum会议都是为更新而组织的，构建是在两到三周的周期内完成的，称为sprint。

Extreme Programming（XP）—— 极限编程是一种敏捷的实现，它将频繁的客户反馈和更改与高质量软件相结合。软件的质量是通过遵循诸如成对编程（代码评审、单元测试等）之类的编码实践来保持的。因此，极限编程被称为极限编程。

Kanban —— Kanban 是一种开发方法，其中任务被组织在看板板中，在看板中我们可以跟踪工作的进展，帮助决策。

Crystal —— Crystal 的开发和其他敏捷方法一样，专注于频繁的交付和反馈。它是一种轻量级方法，基于这样一个事实，即需要定制过程和实践来满足项目特定的需求。

Lean 精益软件开发——精益软件开发方法论基于七个精益原则—消除浪费（就像任何没有增值的代码一样）、扩大学习、延迟决策、快速交付、增强团队能力、建立完整性和整体观（将产品视为一个整体）。

敏捷方法论它侧重于增量开发方法，其中方法论的目标是快速交付产品。

敏捷方法论和其他传统方法论的主要区别在于，敏捷方法论遵循增量开发模型，而传统方法论遵循顺序模型。

在敏捷方法中，开发阶段和测试阶段同时运行。在传统方法中，一旦开发阶段结束，测试阶段就开始了。

敏捷方法提供了灵活性，因为引入变更更容易。在传统的方法论中，合并变更是困难的，因为在开发工作开始之前，需求被冻结。

敏捷方法需要较少的文档；由于交付速度快，开发人员可以根据需要对代码进行更改。而在传统的方法论中，开发过程只有在团队获得完整的文档化需求之后才开始。

客户参与敏捷软件生命周期的每一个阶段，评审产品并在需要时提出变更建议。在传统方法中，客户主要参与需求收集阶段；他们通常在开发生命周期的最后阶段看到最终产品。

下面是一些敏捷框架（Agile Frameworks）

Scrum

Crystal

Dynamic Systems Development Method (DSDM)

Feature Driven Development (FDD)

Kanban

Adaptive Software Development (ASD)

Lean Software Development (LSD)

极限编程（Extreme Programming）的12个实践

XP的关注点：

实现简单的设计

开发人员与客户的沟通协作

不断地测试代码库

重构以适应规格说明书的变更

寻求用户的反馈

XP 更倾向于适合中小规模的软件开发，这些软件的规格说明变更非常频繁，而且它们还可以进行接近实时的沟通。

实践	注解
1. 计划与需求分析	将市场和业务开发人员集中起来，共同确认每个软件特性的最大商业价值以使用场景的形式重新编写每个重要的软件特性程序员估计完成每个使用场景的时间客户根据估计时间和商业价值选择软件的功能特征
2. 小规模，递增地发布	努力添加细微的、实在的、可增值的特征和新功能，频繁发布新版本
3. 系统隐喻	编程小组确认隐喻，便于建立命名规则和程序流程。
4. 简要设计	实现最简单的设计，使代码通过单元测试。假设变更即将发生，因此不要在设计上花费太多的时间，只是不停地实现。
5. 连续测试	在编写模块之前就生成单元测试用例。模块只有在通过单元测试之后才告完成。此外，程序只有在通过了所有的单元测试和验收测试之后才算结束。
6. 重构	清理和调整代码库。单元测试有助于确保在此过程中不破坏程序的功能。应在任何重构之后重新进行所有的单元测试。
7. 结对编程	两位程序员协同工作，在同一台机器开发代码库。这样就可以对代码进行实时检查，能极大地提高缺陷的发现率和纠正率。
8. 代码的集体所有权	所有代码归全体程序员所有，没有哪一个程序员只致力于开发某一个代码库
9.持续集成	每天在变更通过单元测试Unit Testing 之后将其集成到代码库中
10. 每周40小时工作	不允许加班。如果每周都会全力工作了40小时，就不需要加班。在重大发布前的一周例外。
11. 客户在现场	开发人员和编程小组可以随时接触客户，这样可以快速、准确地解决问题、使开发过程不至于中断
12. 按标准编码	所有的代码看上去必须是一致的。设计一个系统隐喻有助于满足该原则。