敏捷方法论_敏捷方法论完整指南

敏捷方法论

故事点和复杂点 (Story Points and Complexity Points)

In Scrum/Agile, the functionality of a product in development is explored by way of stories a user might tell about what they want from a product. A team uses Story Points when they estimate the amount of effort required to deliver a user story.

在Scrum / Agile中，正在开发的产品的功能通过用户可能会讲述他们想要的产品故事来进行探索。 团队在评估交付用户故事所需的工作量时使用故事点 。

Notable features of story points are that they:

故事点的显着特征是：

• represent the contributions of the whole team
  代表整个团队的贡献
• do not equate directly to time the task might take
  不直接等于任务可能要花费的时间
• are a rough measure for planning purposes - similar to orders of magnitude
  是用于规划目的的粗略度量-类似于数量级
• are assigned in a Fibonacci-like sequence: 0, 1, 2, 3, 5, 8, 13, 20, 40, 100
  以类似于斐波那契的顺序分配：0、1、2、3、5、8、13、20、40、100

• estimate the ‘size’ of stories relative to each other

  估计故事彼此之间的“大小”

The concept of story points can be quite elusive if you are new to Agile ways of doing things. You will find many online sources discussing story points in different ways, and it can be hard to get a clear idea of what they are and how they are used.

如果您不熟悉敏捷的做事方式，那么故事点的概念可能很难捉摸。 您会发现许多在线资源以不同的方式讨论故事点，并且很难清楚地了解它们是什么以及如何使用它们。

As you learn about the principles and terminology of practices like Scrum, the reasons for some of these properties will become apparent. The use of story points, especially in ‘ceremonies’ such as planning poker, is much easier to understand by observing or taking part than in a written explanation!

当您了解诸如Scrum之类的实践的原理和术语时，其中某些特性的原因将变得显而易见。 通过观察或参与，比起书面解释，更容易理解故事点的使用，尤其是在诸如计划扑克之类的“仪式”中！

更多信息： (More Information:)

• User Stories: freeCodeCamp

  用户故事： freeCodeCamp

并行开发 (Parallel Development)

Parallel Development stands for the development process separated into multiple branches, to provide a versatile product with stable releases and new features. In a more common straightforward software development process you have only one branch with bug fixes and improvements, alongside with new features. In parallel development multiple branches can coexist.

并行开发表示将开发过程分为多个分支，以提供具有稳定版本和新功能的多功能产品。 在更常见，更直接的软件开发过程中，只有一个分支包含错误修复和改进以及新功能。 在并行开发中，多个分支可以共存。

Usually parallel development contains a main, “master” branch which is the most stable and contains important fixes for existing code. From the main branch, more branches are created to add new “paths” to the existing code. These branches provide new features, but do not include fixes, applied in the mean time from the master branch. Clients know about these releases and have special equipment, or test machines to be able to test the new features. When QA tests are passed, side branch can be merged with the main branch to introduce new features to the release version.

通常，并行开发包含一个主要的“ master”分支，该分支最稳定，并且包含对现有代码的重要修复。 从主分支开始，将创建更多分支，以向现有代码添加新的“路径”。 这些分支提供了新功能，但不包括同时从master分支应用的修复程序。 客户了解这些版本，并拥有特殊的设备或测试机以能够测试新功能。 通过质量检查测试后，可以将分支分支与主分支合并以向发行版引入新功能。

燃尽图和燃尽图 (Burndown Charts and Burnup Charts)

Burndown and burnup charts are used to measure progress of a project— usually a development sprint under the Agile methodology. Both charts visually represent work versus time.

燃尽图和燃尽图用于衡量项目的进度-通常是敏捷方法下的开发冲刺。 两个图表都直观地表示了工作与时间的关系。

Burndown charts show how much work is left to be done versus the amount of time remaining. The Y axis represents work left to be done— usually relating to a time estimate assigned to each task, e.g. story points— and the X axis represents time left. Two lines are used; the first— “Ideal Work Remaining Line”— represents an ideal burndown, where each day an amount of work proportional to the total amount of time is completed, resulting in a straight line. The second “Actual Work Remaining Line” is used to plot actual progress as taks move through development to a done state. An example of a burndown chart is shown below.

燃尽图显示剩余的工作量与剩余时间。 Y轴表示尚待完成的工作-通常与分配给每个任务的时间估计(例如，故事点)有关，而X轴表示剩余的时间。 使用两行； 第一个代表“理想的工作剩余线”，代表理想的燃尽状态，每天完成与总时间成比例的工作量，形成一条直线。 第二条“实际剩余工作量”用于绘制taks从开发到完成状态的实际进度。 燃尽图的示例如下所示。

Many Scrum Teams use burndown charts in order to see how they are doing during the sprint. Having an even and steady burndown might be an indicator that the stories are small and manageable. If a team notices in the middle of a sprint that the “Actual Work Remaining Line” is above the “Ideal Work Remaining Line” they can make adjustments to the scope: stories can be taken out of the sprint or the scope of stories can be made smaller. Looking at the burndown during the retrospective in the end of the sprint might spark some interesting discussions and result in process improvements.

许多Scrum团队使用燃尽图来查看他们在冲刺期间的表现。 均匀稳定的消耗可能表明这些故事很小且易于管理。 如果团队在冲刺中发现“实际工作剩余线”在“理想工作剩余线”上方，则可以调整范围：可以将故事从冲刺中删除，也可以将故事范围变小。 在sprint结束时的回顾期间查看燃尽情况可能会引发一些有趣的讨论并导致流程改进。

Burnup charts are very similar, but they show the work that has been completed versus the total amount of work and time remaining. Three lines are used— an ideal line, a completed work line, and a total work line. In this chart, the total work line should be somewhat steady across the top of the chart, and is a good representation of scope change. The completed work line should move steadily up towards the total work line for the amount of time in the project— its ideal trajectory is shown by the ideal line. An example is shown below.

燃尽图非常相似，但是它们显示了已完成的工作与总工作量和剩余时间。 使用三条线-理想线，完成的工作线和总工作线。 在此图表中，整个工作线在图表顶部应比较稳定，并且可以很好地表示范围的变化。 完成的工作线应在整个项目时间内稳定地朝总工作线向上移动-理想线表示其理想轨迹。 一个例子如下所示。

Image courtesy of Effective PMC

图片由有效PMC提供

设计模式 (Design Patterns)

A design pattern is a common design solution to a common design problem. A collection of design patterns for a related field or domain is called a pattern language. Note that there are also patterns at other levels: code, concurrency, architecture, interaction design …

设计模式是针对常见设计问题的通用设计解决方案。 相关领域或领域的设计模式的集合称为模式语言。 请注意，其他级别也存在模式：代码，并发性，体系结构，交互设计……

In software engineering, a software design pattern is a general reusable solution to a commonly occurring problem within a given context in software design. It is not a finished design that can be transformed directly into source or machine code. It is a description or template for how to solve a problem that can be used in many different situations. Design patterns are formalized best practices that the programmer can use to solve common problems when designing an application or system.

在软件工程中，软件设计模式是对软件设计中给定上下文中常见问题的通用可重用解决方案。 它不是可以直接转换为源代码或机器代码的最终设计。 它是关于如何解决可以在许多不同情况下使用的问题的描述或模板。 设计模式是形式化的最佳实践，程序员可以在设计应用程序或系统时用来解决常见问题。

Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved. Patterns that imply mutable state may be unsuited for functional programming languages, some patterns can be rendered unnecessary in languages that have built-in support for solving the problem they are trying to solve, and object-oriented patterns are not necessarily suitable for non-object-oriented languages.

面向对象的设计模式通常显示类或对象之间的关系和交互，而无需指定最终的应用程序类或对象。 暗示可变状态的模式可能不适用于功能性编程语言，某些模式可能在内置支持解决其试图解决的问题的语言中变得不必要，而面向对象的模式不一定适用于非对象面向语言。

Design patterns may be viewed as a structured approach to computer programming intermediate between the levels of a programming paradigm and a concrete algorithm.

设计模式可以看作是一种计算机编程的结构化方法，介于编程范式和具体算法之间。

The book that popularised the field is Gang of Four’s (GoF) Design Patterns: Elements of Reusable Object-Oriented Software (1994). It present a series (23) of patterns for an conventional (C++) OO language classified in three types:

普及该领域的书是《四人帮》(GoF) 设计模式：可重用的面向对象软件的元素 (1994)。 它提供了针对传统(C ++)OO语言的一系列模式(23)，分为三种类型：

• Creational (to create objects): abstract factory, builder, factory method, prototype, singleton.

  创意 (创建对象)：抽象工厂，构建器，工厂方法，原型，单例。

• Structural (to compose objects): adapter, bridge, composite, decorator, facade, flyweight, proxy.

  结构性 (组成对象)：适配器，桥梁，复合材料，装饰器，门面，轻量化，代理。

• Behavioral (to communicate between objects): chain of responsibility, command, interpreter, iterator, mediator, memento, observer, state, strategy, template method, visitor.

  行为 (在对象之间进行通信)：责任链，命令，解释器，迭代器，介体，纪念品，观察者，状态，策略，模板方法，访问者。

Patterns can be used for multiple objectives (learning, communication, improving your tooling) but in agile they should be refactored from code with technical debt and not just added at the start (emergent design/architecture) as initially you don’t have enough knowledge about the (future) system that is going to evolve. Note that what requires a pattern in a language or tool may not be needed or already be part of another language or tool. A framework is a set of cooperating classes that make up a reusable design for a specific type of software and are typically pattern-heavy.

模式可以用于多个目标(学习，交流，改善工具)，但在敏捷中，应该从具有技术负担的代码中重构它们，而不仅仅是在开始时(紧急设计/体系结构)添加它们，因为起初您没有足够的知识关于将要发展的(未来)系统。 请注意，可能不需要某种语言或工具中需要模式的内容，或者已经成为另一种语言或工具的一部分。 框架是一组协作类，它们构成用于特定类型软件的可重用设计，并且通常是模式繁重的。

任务板和看板 (Task Boards and Kanban)

Kanban is an excellent method both for teams doing software development and individuals tracking their personal tasks.

对于从事软件开发的团队和个人跟踪其个人任务，看板都是一种极好的方法。

Derived from the Japanese term for “signboard” or “billboard” to represent a signal, the key principal is to limit your work-in-progress (WIP) to a finite number of tasks at a given time. The amount that can be In Progress is determined by the team’s (or individual’s) constrained capacity. As one task is finished, that’s the signal for you to move another task forward into its place.

从日语中的“招牌”或“广告牌”代表信号的术语衍生而来，关键原则是在给定时间将正在进行的工作(WIP)限制为有限数量的任务。 可以进行的数量取决于团队(或个人)的受约束能力。 完成一项任务后，这就是您将另一项任务移到其位置的信号。

Your Kanban tasks are displayed on the Task Board in a series of columns that show the state of the tasks. In its simplest form, three columns are used

您的看板任务显示在任务板上的一系列列中，这些列显示了任务的状态。 最简单的形式是使用三列

• To Do
  去做
• Doing
  在做
• Done
  完成了

Image courtesy of Wikipedia

图片由维基百科提供

But many other columns, or states, can be added. A software team may also include Waiting to Test, Complete, or Accepted, for example.

但是可以添加许多其他列或状态。 例如，软件团队可能还包括等待测试，完成或接受。

Image courtesy of leankit

图片由leankit提供

整合地狱 (Integration Hell)

Integration Hell is a slang term for when all the members of a development team goes through the process of implementing their code at random times with no way to incorporate the different pieces of code into one seamless string of code. The development team will have to spend several hours or days testing and tweaking the code to get it all to work.

Integration Hell是一个s语，是指开发团队的所有成员在随机时间执行代码的过程时，无法将不同的代码段合并到一个无缝的代码串中。 开发团队将不得不花费数小时或数天的时间进行测试和调整代码，以使其全部正常工作。

In practice, the longer components are developed in isolation, the more the interfaces tend to diverge from what is expected. When the components are finally integrated at the end of the project, it would take a great deal more time than allocated, often leading to deadline pressures, and difficult integration. This painful integration work at the end of the project is the eponymous hell.

实际上，隔离开发的组件越长，接口与预期的差异就越大。 当最终在项目结束时集成组件时，将花费比分配更多的时间，这通常会导致截止日期的压力和困难的集成。 在项目结束时，这项艰巨的集成工作就是地狱。

Continuous Integration, the idea that a development team should use specific tools to “continuously integrate” the parts of the code they are working on multiple times a day so that the tools can match the different “chunks” of code together to integrate much more seamlessly than before.

持续集成，即开发团队应该使用特定的工具每天“多次集成”他们正在处理的代码部分的想法，以便工具可以将不同的“块”代码匹配在一起，以更加无缝地集成比以前。

Code Repositories, like Git (and it’s open source interface we all know and love, GitHub) allow development teams to organize their efforts so that more time can be spent coding and less time on worrying if the different parts of the code will all integrate.

像Git这样的代码存储库(以及我们大家都知道和喜欢的开源接口，GitHub)使开发团队可以组织工作，以便花更多的时间进行编码，而减少了担心代码的不同部分是否全部集成的时间。

Continuous Integration is the Agile antidote to this problem. Integration is still painful, but doing it at least daily keeps interfaces from diverging too much.

持续集成是解决此问题的捷径。 集成仍然很痛苦，但是至少每天进行一次，可以防止接口差异太大。

用户故事 (User Stories)

According to Mountain Goat Software, user stories are:

根据Mountain Goat Software的说法，用户案例如下：

...part of an agile approach that helps shift the focus from writing about requirements to talking about them. All agile user stories include a written sentence or two and, more importantly, a series of conversations about the desired functionality.

...这是敏捷方法的一部分，可帮助将重点从编写需求转移到谈论需求。 所有敏捷的用户故事都包含一个或两个书面句子，更重要的是，有关所需功能的一系列对话。

User stories are typically written using the following pattern:

用户故事通常使用以下模式编写：

As a [ type of user ], I want [ some goal ] so that [ some reason or need ]

作为[用户类型]，我想要[一些目标]，以便[一些原因或需要]

User stories should be written in non-technical terms from the perspective of the user. The story should emphasize the need of the user, and not the how. There should be no solution provided in the user story.

从用户的角度来看，应该以非技术性的术语来编写用户故事。 这个故事应该强调用户的需求，而不是如何。 用户故事中不应提供任何解决方案。

One common mistake that is made when writing user stories is writing from the perspective of the developer or the solution. Be sure to state the goal and the need, and the functional requirements come later.

编写用户故事时常犯的一个错误是从开发人员或解决方案的角度进行写作。 请确保陈述目标和需求，然后提出功能要求。

调整用户故事的大小：史诗和较小的故事 (Sizing a User Story: Epics and Smaller Stories)

An is like the headline or placeholder for user stories. Epics are typically serve as big, broad strokes, and are then broken down into several user stories.

An就像用户故事的标题或占位符。 史诗通常用作较大的笔触，然后分解为多个用户故事。

By starting with an epic, you can plan out the functionality of the product without committing to exact details. Taking this approach gives you time to learn more about your users and how to address their needs.

从史诗入手，您可以计划产品的功能而无需承诺确切的细节。 采用这种方法可以使您有时间了解有关用户以及如何满足其需求的更多信息。

When thinking about possible stories, it is also important to consider “mis-user cases” and “unhappy path” stories. How will exceptions be handled by the system? What kind of messaging will you provide back to user? How would a malicious user abuse this application function? These mal-stories can save rework and become useful test cases in QA.

在考虑可能的故事时，考虑“误用案例”和“不愉快的道路”故事也很重要。 系统如何处理异常？ 您将向用户提供什么样的消息？ 恶意用户将如何滥用此应用程序功能？ 这些错误的故事可以节省返工，并成为QA中有用的测试用例。

规划扑克 (Planning Poker)

介绍 (Introduction)

Planning poker is an estimation and planning technique in the Agile development model. It is used to estimate the development effort required for a user story or a feature.

规划扑克是敏捷开发模型中的一种估算和规划技术。 它用于估计用户故事或功能所需的开发工作。

处理 (Process)

The planning poker is done for one user story at a time.

计划扑克一次完成一个用户故事。

Each estimator holds an identical set of poker cards consisting of cards with various values. The card values are usually from the Fibonacci Sequence. The unit used for the values can be the number of days, story points, or any other kind of estimation unit agreed on by the team.

每个估算器都持有一组相同的扑克牌，这些扑克牌由各种值的牌组成。 卡值通常来自斐波那契数列。 值所使用的单位可以是天数，故事点或团队同意的任何其他类型的估算单位。

The product owner (PO) or stakeholder explains the story that is to be estimated.

产品负责人(PO)或利益相关者解释了要评估的故事。

The team discusses the story, asking any clarifying questions that they might have. This helps the team get a better understanding on what the PO wants.

团队讨论这个故事，询问他们可能有的任何澄清问题。 这帮助球队拿到上PO想要什么更好的理解。

At the end of the discussion, each person first selects a card (representing their estimate for the story) without showing it to the others. Then, they reveal their cards at the same time.

在讨论的最后，每个人首先选择一张卡片(代表他们对故事的估计)，而不向其他人展示。 然后，他们同时显示自己的卡片。

If all the cards have the same value, the value becomes the estimate for the story. If there are differences, the team discusses the reasons for the values that they have chosen. It is of high value that the team members who gave the lowest and highest estimates provide justifications for their estimates.

如果所有卡具有相同的值，则该值将成为故事的估计。 如果存在差异，团队将讨论选择其值的原因。 给出最低和最高估计值的团队成员为其估计提供理由是非常有价值的。

After this discussion, the process of picking a card in private and then revealing it at the same time is repeated. This is done until there is a consensus on the estimate.

讨论之后，将重复执行以下步骤：私下提取卡，然后同时将其公开。 这样做直到对估计达成共识。

Because planning poker is a tool to moderate a joint expert estimation, it leads to a better common understanding and perhaps even refinement of the feature request. It is of high value even when the team is operating in a No-Estimates mode.

因为计划扑克是调节联合专家估算的工具，所以它可以导致更好的共识，甚至可以完善功能请求。 即使团队在“无估算”模式下运行，它也具有很高的价值。

A moderator should try to avoid confirmation bias.

主持人应尽量避免确认偏差。

Things worth mentioning:

值得一提的事情：

• Estimations are not comparable between teams, as every team has its own scala.
  各个团队之间的估算值不可比，因为每个团队都有自己的标度。
• Estimations should include everything that needs to be done in order for a piece of work to be done: designing, coding, testing, communicating, code reviews (+ all possible risks)
  估算应包括完成一项工作所需完成的所有工作：设计，编码，测试，沟通，代码审查(以及所有可能的风险)
• The value of using planning poker is in the resulting discussions, as they reveal different views on a possible implementation
  使用规划扑克的价值在于最终的讨论中，因为它们揭示了对可能实施的不同观点

行为驱动的发展 (Behavior Driven Development)

Behavior Driven Development (BDD) is a software development process that emerged from Test Driven Development (TDD). Behavior Driven Development combines the general techniques and principles of TDD with ideas from domain-driven design and object-oriented analysis and design to provide software development and management teams with shared tools and a shared process to collaborate on software development. It is a software development methodology in which an application is specified and designed by describing how its behavior should appear to an outside observer.

行为驱动开发(BDD)是一种从测试驱动开发(TDD)出现的软件开发过程。 行为驱动开发将TDD的一般技术和原理与领域驱动设计以及面向对象的分析和设计的思想相结合，为软件开发和管理团队提供共享的工具和共享的流程，以进行软件开发方面的协作。 它是一种软件开发方法，其中通过描述应用程序的行为应如何表现给外部观察者来指定和设计该应用程序。

Although BDD is principally an idea about how software development should be managed by both business interests and technical insight, the practice of BDD does assume the use of specialized software tools to support the development process.

尽管BDD原则上是关于如何通过商业利益和技术见解来管理软件开发的想法，但是BDD的实践的确假定使用专用软件工具来支持开发过程。

Although these tools are often developed specifically for use in BDD projects, they can be seen as specialized forms of the tooling that supports test-driven development. The tools serve to add automation to the ubiquitous language that is a central theme of BDD.

尽管这些工具通常是专门为BDD项目使用而开发的，但可以将它们视为支持测试驱动开发的工具的特殊形式。 这些工具用于将自动化添加到作为BDD中心主题的无处不在的语言中。

BDD focuses on:

BDD专注于：

• Where to start in the process
  从哪里开始
• What to test and what not to test
  测试什么，不测试什么
• How much to test in one go
  一口气测试多少
• What to call the tests
  什么叫测试
• How to understand why a test fails
  如何理解测试失败的原因

At the heart of BDD is a rethinking of the approach to the unit testing and acceptance testing that naturally arise with these issues. For example, BDD suggests that unit test names be whole sentences starting with a conditional verb (“should” in English for example) and should be written in order of business value. Acceptance tests should be written using the standard agile framework of a user story: “As a role I want feature so that benefit”. Acceptance criteria should be written in terms of scenarios and implemented as classes: Given initial context, when event occurs, then ensure some outcomes.

BDD的核心是对这些问题自然产生的单元测试和验收测试方法的重新思考。 例如，BDD建议单元测试名称应该是一个完整的句子，以一个条件动词(例如英语中的“ should”)开头，并且应该按照商业价值的顺序来写。 验收测试应该使用用户故事的标准敏捷框架这样写：“作为一个角色我想要的功能 ，这样的好处 ”。 接受标准应按照情景来编写，并作为类来实现：在给定初始上下文的情况下 ，当事件发生时 ，请确保有一定结果 。

Example

例

Story: Returns go to stock

As a store owner
In order to keep track of stock
I want to add items back to stock when they're returned.

Scenario 1: Refunded items should be returned to stock
Given that a customer previously bought a black sweater from me
And I have three black sweaters in stock.
When he returns the black sweater for a refund
Then I should have four black sweaters in stock.

Scenario 2: Replaced items should be returned to stock
Given that a customer previously bought a blue garment from me
And I have two blue garments in stock
And three black garments in stock.
When he returns the blue garment for a replacement in black
Then I should have three blue garments in stock
And two black garments in stock.

Along with it are some Benefits:

附带一些好处：

1. All development work can be traced back directly to business objectives.
   所有开发工作都可以直接追溯到业务目标。
2. Software development meets user need. Satisfied users = good business.
   软件开发可满足用户需求。 满意的用户=好的生意。
3. Efficient prioritization - business-critical features are delivered first.
   高效的优先级划分-首先交付关键业务功能。
4. All parties have a shared understanding of the project and can be involved in the communication.
   各方对项目有共同的理解，可以参与交流。
5. A shared language ensures everyone (technical or not) has thorough visibility into the project’s progression.
   共享的语言可确保每个人(无论是技术人员还是非技术人员)都能够全面了解项目的进度。
6. Resulting software design that matches existing and supports upcoming business needs.
   与现有软件相匹配并支持即将到来的业务需求的最终软件设计。
7. Improved quality code reducing costs of maintenance and minimizing project risk.
   改进的质量代码减少了维护成本并最大程度地降低了项目风险。

Scrum (Scrum)

Scrum is one of the methodologies under the Agile umbrella. The name is derived from a method of resuming play in the sport of rugby, in which the entire team moves together to make ground. Similarly, a scrum in Agile involves all parts of the team working on the same set of goals. In the scrum method, a prioritized list of tasks is presented to the team, and over the course of a “sprint” (usually two weeks), those tasks are completed, in order, by the team. This insures that the highest-priority tasks or deliverables are completed before time or funds run out.

Scrum是敏捷框架下的方法之一。 该名称源于一种恢复橄榄球运动的方法，在该方法中，整个团队一起运动以取得发展。 同样，敏捷中的Scrum涉及团队的所有部分，他们致力于同一组目标。 在scrum方法中，优先级任务列表被呈现给团队，并且在“冲刺”过程中(通常为两周)，这些任务由团队依次完成。 这样可确保在时间或资金用尽之前完成最优先的任务或可交付成果。

Scrum的组成 (Components of a Scrum)

Scrum is one of the methodologies under the Agile umbrella. It originates from ‘scrummage’ which is a term used in rugby to denote players huddling together to get possession of the ball. The practice revolves around

Scrum是敏捷框架下的方法之一。 它起源于“ scrummage”，这是橄榄球中用来表示球员挤在一起拥挤球的术语。 实践围绕

• A set of roles (delivery team, product owner, and scrum master)
  一组角色(交付团队，产品负责人和Scrum负责人)
• Ceremonies (sprint planning, daily standup, sprint review, sprint retrospective, and backlog grooming)
  仪式(冲刺计划，每日站立，冲刺审查，冲刺回顾和积压整理)
• Artifacts (product backlog, sprint backlog, product increment, and info radiators and reports).
  工件(产品积压，冲刺积压，产品增量以及信息发送器和报告)。
• The main goal is to keep the team aligned on project progress to facilitate rapid iteration.
  主要目标是使团队与项目进度保持一致，以促进快速迭代。
• Many organisations have opted for Scrum, because unlike the Waterfall model, it ensures a deliverable at the end of each Sprint.
  许多组织选择了Scrum，因为与Waterfall模型不同，它确保了每个Sprint末尾的交付。

伪像 (Artifacts)

• Sprint: It is the time duration, mostly in weeks, for which a Team works to achieve or create a deliverable. A deliverable can defined as a piece of code of fragment of the Final Product which the team wants o achieve. Scrum advises to keep the duration of a Sprint between 2-4 weeks.
  冲刺(Sprint)：这是团队为实现或创建可交付成果而进行的持续时间(通常为几周)。 可交付成果可以定义为团队希望实现的最终产品的一部分代码。 Scrum建议将Sprint的持续时间保持在2-4周之间。
• Product Backlog: It is the list of tasks a Team is supposed to finish within the current Sprint. It is decided by the Product Owner, in agreement with the Management as well as Delivery Team.
  产品待办事项列表：这是团队应在当前Sprint中完成的任务的列表。 它由产品负责人与管理层以及交付团队达成一致。

的角色 (Roles)

• Product Owner(PO): The ONLY Accountable person to the Management. PO decides what goes in or out of the Product Backlog.
  产品负责人(PO)：管理层的唯一负责人。 采购订单决定产品积压清单中的内容。
• Delivery Team: They are required to work in accordance with the tasks set by their PO in the product backlog and deliver the required delivarable at the end of the sprint.
  交付团队：要求他们按照他们的PO在产品待办事项列表中设置的任务进行工作，并在冲刺结束时交付所需的内容。
• Scrum Masters: - Scrum Master’s has to strictly adhere to Scrum Guide and make the team understand the need to adhere to Scrum guide when following Scrum. It is a Scrum Master’s job to ensure all Scrum ceremonies being conducted on time and participated by all the required people as per the scrum guide. The SM has to ensure that the Daily Scrum is conducted regularly and actively participated by the team.
  Scrum Master：-Scrum Master必须严格遵守Scrum Guide，并让团队了解在遵循Scrum时必须遵守Scrum Guide的需求。 确保Scrum仪式按时进行并按照Scrum指南由所有需要的人员参加，这是Scrum Master的工作。 SM必须确保团队定期进行Daily Scrum并积极参与。

每日站立和每日Scrum (Daily Stand-Up and Daily Scrum)

The Daily Stand-Up (DSU) or Daily Scrum meeting is one of the integral parts of scrum methodology.

每日站立会议(DSU)或每日Scrum会议是Scrum方法论不可或缺的部分之一。

As the name suggests, you hold the meeting daily, at the same time and, for a co-located team, in the same location. The meeting should be brief, finished in less than 15 minutes.

顾名思义，您每天都在同一时间举行会议，对于一个位于同一地点的团队来说，您在同一地点举行会议。 会议应简短，不到15分钟即可完成。

Only members of the Development team are required to attend the Daily Stand-up. Typically, the Scrum Master and Product Owners will also attend, but they are not required.

只有开发团队的成员才需要参加每日站立。 通常，Scrum主管和产品负责人也将参加，但不是必需的。

The standard agenda for each person is:

每个人的标准议程是：

• What have you done since the last DSU
  自上次DSU以来您做了什么
• What are you doing after this DSU
  DSU之后您在做什么
• What are the major obstacles that are stopping your progress, and where do you need help
  阻碍您前进的主要障碍是什么？在哪里需要帮助

Team members are to listen carefully to each other’s contributions and attempt to identify areas where they can assist each other’s progress. The standup meeting will also surface more lengthy topics of discussion that need to take place between different members of the team. These lengthier discussions that arise should then be halted and taken outside of the standup, involving only the relevant participants, and not the entire team.

团队成员应认真倾听彼此的贡献，并尝试确定可以帮助彼此进步的领域。 站立会议还将浮出水面，讨论范围更长，需要在团队的不同成员之间进行。 然后，应该停止这些引起的冗长讨论，并在站立会议之外进行讨论，仅涉及相关参与者，而不是整个团队。

站立会议的例子 (Example of Stand-up Meeting)

https://www.youtube.com/watch?v=_3VIC8u1UV8

https://www.youtube.com/watch?v=_3VIC8u1UV8

海盗指标 (Pirate Metrics)

Dave McClure identified five high-level metric categories critical to a startup’s success: Acquisition, Activation, Retention, Revenue, Referral.

戴夫·麦克卢尔(Dave McClure)确定了对创业公司成功至关重要的五个高级指标类别：获取，激活，保留，收入，推荐。

He coined the term “Pirate Metrics” from the acronym for these five metric categories (AARRR).

他从这五个度量标准类别(AARRR)的缩写中创造了“海盗度量标准”一词。

In their book Lean Analytics, Croll and Yoskovitz interpret these metrics visually as a funnel:

Croll和Yoskovitz在他们的《精益分析》一书中将这些指标可视化地解释为一个漏斗：

Lean Analytics, 2013

精益分析，2013年

And with more pointed explanations as a table:

并附有更明确的说明作为表格：

Lean Analytics, 2013

精益分析，2013年

非功能需求 (Nonfunctional Requirements)

A non-functional requirement (NFR) is a requirement that specifies criteria that can be used to judge the operation of a system, rather than specific behaviors (a functional requirement). Non-functional requirements are often called “quality attributes”, “constraints” or “non-behavioral requirements”.

非功能需求(NFR)是指定可用于判断系统运行的标准的需求，而不是特定行为(功能需求)。 非功能性需求通常被称为“质量属性”，“约束”或“非行为性需求”。

Informally, these are sometimes called the “ilities”, from attributes like stability and portability. NFRs can be divided into two main categories:

非正式地，它们有时被称为“污秽”，源于诸如稳定性和可移植性之类的属性。 NFR可以分为两个主要类别：

• Execution qualities, such as safety, security and usability, which are observable during operation (at run time).

  在运行过程中(运行时)可以观察到的执行质量 ，例如安全性，安全性和可用性。

• Evolution qualities, such as testability, maintainability, extensibility and scalability, which are embodied in the static structure of the system

  演化质量 ，例如可测试性，可维护性，可扩展性和可伸缩性，体现在系统的静态结构中

Usually you can refine a non-functional requirement into a set of functional requirements as a way of detailing and allowing (partial) testing and validation.

通常，您可以将非功能性需求细化为一组功能性需求，作为详细说明和允许(部分)测试和验证的方式。

例子： (Examples:)

• The printer should print 5 seconds after the button is pressed
  按下按钮5秒钟后，打印机应打印
• The code should be written in Java
  该代码应使用Java编写
• The UI should be easily navigable
  用户界面应该易于导航

基于特征的计划 (Feature Based Planning)

Feature Based Planning is a planning methodology that can be used to decide when to release software based on the features that will be delivered to the customers, rather than an arbitrary deadline based release.

基于功能的计划是一种计划方法，可用于根据将交付给客户的功能来决定何时发布软件，而不是基于任意期限的发布。

In this method of release planning, teams decide what feature/features should be prioritised. Based on the scope of these features the team can then predict when the next release can be deployed.

在这种发布计划方法中，团队决定应优先考虑哪些功能。 基于这些功能的范围，团队可以预测何时可以部署下一个版本。

职能经理 (Functional Managers)

A functional manager is a person that have management authority over group of people. That authority comes from the formal position of that person in the organization (eg. director of the department, quality department manager, development team manager). Role of functional managers is different then Project Managers or ScrumMasters and is not project based.In more agile organizations different models exists. Functional manager often are responsible for developing people in their groups, securing budgets and time for people. However there are also some Agile company models where functions usually assigned to functional managers are distributed to other roles within organization (eg. Spotify model with Tribes, Guilds, Chapters, Squads).

职能经理是对一群人拥有管理权限的人。 该权限来自该人员在组织中的正式职位(例如部门主管，质量部门经理，开发团队经理)。 职能经理的角色不同于项目经理或ScrumMaster，并且不是基于项目的。在更敏捷的组织中，存在不同的模型。 职能经理通常负责在团队中发展人员，确保预算和人员时间。 但是，也存在一些敏捷公司模型，这些模型通常将分配给职能经理的职能分配给组织内的其他角色(例如，具有部落，行会，章，小队的Spotify模型)。

Out in the traditional world of work companies organize people into a hierarchy. People with similar work roles are grouped into functional areas and led by a Functional Manager. The functional manager is generally responsible for the guidance and well-being of the employees who report directly to her.

在传统的工作世界中，公司将人们组织成一个等级。 具有相似工作角色的人员被分为功能区域，并由功能经理领导。 职能经理通常负责直接向她报告的员工的指导和福祉。

Agile project teams will often work with functional managers who control the resources the team needs to get work done. An example would be working with a functional manager in procurement to assign a person to work with the team to procure software licenses.

敏捷项目团队通常会与职能经理合作，后者负责控制团队完成工作所需的资源。 例如，与采购部门的职能经理合作，指派一个人与团队一起采购软件许可。

建立度量学习 (Build Measure Learn)

The Build-Measure-Learn loop is a method used to build the right product. Coined in the “Lean Startup” book by Eric Reis, the loop enables rapid experimenting, in the sole purpose of achieving market fit. In other words, it is a powerful system to validate assumptions concerning a product you set out to deliver. Breaking down the loop, it consists of the following parts:

Build-Measure-Learn循环是一种用于构建正确产品的方法。 该循环是由Eric Reis撰写的“精益创业”一书中创造的，其循环的唯一目的是实现市场契合度，从而进行快速实验。 换句话说，它是一个强大的系统，可以验证有关您要交付的产品的假设。 分解循环，它包括以下部分：

理念 (Idea)

Each loop starts with an idea that will supply business value to some users. Such idea must be consisted of a vision for a product - which will direct you at what to build, and a metric that will point out to whether your assumptions about the business value were correct.

每个循环都从一个为某些用户提供业务价值的想法开始。 这样的想法必须包括对产品的愿景-可以指导您构建什么产品，以及可以指出您对业务价值的假设是否正确的度量标准。

建立 (Build)

To validate your idea, you set out to build a Minimal Viable Product (MVP), combined with predefined metrics (one is preferred), whose purpose is to validate your theory, and help you decide whether you should preserve or pivot.

为了验证您的想法，您着手构建最小可行产品(MVP)，并结合预定义的指标(首选指标)，其目的是验证您的理论，并帮助您决定是否保留或转折。

测量 (Measure)

This stage is focused on collecting data & metrics from the MVP.

这个阶段的重点是从MVP收集数据和指标。

学习 (Learn)

Next, using the data collected, a decision has to be made, whether or not your product is used by users and so you should preserve, or whether users are not interested in the product, and as such you must pivot. The learn phase is therefore ending with an idea (either how to expand the product, or how to pivot from the original product), applicable for the next Build Measure Learn loop.

接下来，必须使用收集到的数据做出决定，用户是否使用了您的产品，因此您应该保留，或者用户是否对该产品不感兴趣，因此必须做出决定。 因此，学习阶段以适用于下一个Build Measure Learn循环的想法(如何扩展产品或如何从原始产品转变)结束。

冲刺计划会议 (Sprint Planning Meeting)

The Sprint Planning is facilitated by the team’s Scrum Master and consists of the Scrum Team: Development Team, Product Owner (PO) and Scrum Master (SM). It aims to plan a subset of Product Backlog items into a Sprint Backlog. The Scrum Sprint is normally started in after the Sprint Planning meeting.

Sprint计划由团队的Scrum Master推动，并由Scrum团队组成：开发团队，产品所有者(PO)和Scrum Master(SM)。 它旨在将产品待办事项的子集计划为Sprint待办事项。 Scrum Sprint通常在Sprint计划会议之后开始。

主要部分 (Main part)

It is of high value for the team to part the meeting in two parts by asking this two questions:

通过问这两个问题，团队将会议分为两个部分具有很高的价值：

• What should the team plan for the upcoming Sprint?

  团队应该为即将到来的Sprint计划什么 ？

• How should the team (roughly) takle the items planned?

  团队应该如何 (大致)处理计划的项目？

什么 (What)

In What phase the team starts with the top of the ordered Product Backlog. The team at least implicitly estimates the items by forecasting what they could take into Sprint Backlog. If needed they could ask / discuss items with the PO, who has to be in place for this meeting.

在哪个阶段，团队从订购的产品待办事项列表的顶部开始。 团队至少通过预测Sprint待办事项中所包含的内容来隐式估算项目。 如果需要，他们可以与采购员询问/讨论项目，采购员必须参加这次会议。

怎么样 (How)

In How phase the team shortly discusses every picked Sprint Backlog item with the focus on how they will takle it. SM helps the team not to deep dive into discussion and implementation details. It is very likely and good if more questions to the PO are asked or refinements to the items, or backlog is done by the team.

在“如何”阶段，团队简短地讨论了每个选中的“ Sprint待办事项”项目，重点是他们将如何处理该项目。 SM帮助团队避免深入讨论和实施细节。 如果对PO提出更多问题或对项目进行细化，或者团队进行了积压，则很有可能也是很好的。

冲刺目标/结束 (Sprint Goal / Closing)

The team should come up with a shared Sprint Goal for the Sprint to keep the focus in the Sprint time box. At the end of the Sprint Planning the team forecasts that they can achieve the Sprint Goal and complete most likely all Sprint Backlog items. The SM should prevent the team to overestimate by providing useful insights or statistics.

团队应该为Sprint提出一个共享的Sprint目标，以将焦点保持在Sprint时间框中。 在Sprint计划结束时，团队预测他们可以实现Sprint目标并完成所有Sprint Backlog项目。 SM应该通过提供有用的见解或统计数据来防止团队高估自己。

精益软件开发 (Lean Software Development)

介绍 (Introduction)

Lean Software Development is the process of building software with the focus on using techniques which minimize extra work and wasted effort. These techniques are borrowed from the Lean manufacturing movement and applied to the context of software development.

精益软件开发是构建软件的过程，其重点是使用可以减少额外工作和浪费精力的技术。 这些技术是从精益制造运动中借用的，并应用于软件开发的环境中。

关键概念 (Key Concepts)

There are seven principles within the methodology which include:

该方法论包含七项原则，其中包括：

1. Eliminate waste
   消除浪费
2. Amplify learning
   扩大学习
3. Decide as late as possible
   决定越晚越好
4. Deliver as fast as possible
   尽快交付
5. Empower the team
   授权团队
6. Build integrity in
   建立诚信
7. See the whole
   看到整个

隐喻 (Metaphors)

The act of programming is viewed as an assembly line, where every feature or bug fix is called a “change request”. This assembly line of “change requests” can then be considered as a “value stream” with the goal being to minimize the time that each “change request” is on the line prior to being delivered.

编程行为被视为一条装配线，其中每个功能或错误修复都称为“更改请求”。 然后，可以将这种“变更请求”组装线视为“价值流”，目标是最大程度地减少每个“变更请求”在交付之前在生产线上的时间。

Software which is not yet delivered is considered as “inventory” since it has not yet provided value to the company or the customer. This includes any software which is partially complete. Therefore to maximize throughput it is important to deliver many small complete working pieces of software.

尚未交付的软件被认为是“库存”，因为它尚未为公司或客户提供价值。 这包括部分完成的所有软件。 因此，为使吞吐量最大化，交付许多小型完整的软件非常重要。

In order to minimize the “inventory” it is important to secede control to the “workers” who would be the software developers, as they would be best equipped to create automated processes to “mistake proof” the various parts of the assembly line.

为了最大程度地减少“库存”，将控制权割让给作为软件开发人员的“工人”非常重要，因为他们最有能力创建自动化流程来“错误地”验证装配线的各个部分。

参考文献 (References)

The original source of written documentation on the Lean techniques is the book Lean Software Development, An Agile Toolkit by Mary and Tom Poppendieck.

有关精益技术的书面文档的原始来源是Mary和Tom Poppendieck撰写的《精益软件开发》，《敏捷工具包》一书。

Additional books by the author(s) include:

作者的其他书籍包括：

• Implementing Lean Software Development: From Concept to Cash by Mary Poppendieck
  实施精益软件开发：从概念到现金作者：Mary Poppendieck
• Leading Lean Software Development: Results Are not the Point by Mary Poppendieck
  领先的精益软件开发：结果并非重点作者：Mary Poppendieck

搭配与分布式 (Collocation Vs Distributed)

• Co-located refers to a team that sits together; same office. Ideally, everyone sitting together in adjacent offices or an open workspace.
  协同办公是指一个坐在一起的团队。 同一间办公室。 理想情况下，每个人都坐在相邻的办公室或开放的工作空间中。
• Distributed team members are scattered geographically; different buildings, cities, or even countries. In case of distributed team, infrastructure should facilitate processes in order to resolve time difference and distance between team members, thus providing an efficient way of working altogether.
  分散的团队成员在地理位置上分散； 不同的建筑物，城市甚至国家。 对于分散的团队，基础架构应促进流程以解决团队成员之间的时差和距离，从而提供一种有效的整体工作方式。

持续集成 (Continuous Integration)

At its most basic, continuous integration (CI) is an agile development methodology in which developers regularly merge their code directly to the main source, usually a remote master branch. In order to ensure that no breaking changes are introduced, a full test suite is run on every potential build to regression test the new code, i.e. test that the new code does not break existing, working features.

最基本的持续集成(CI)是一种敏捷的开发方法，开发人员可以定期将其代码直接直接合并到主要源(通常是远程master分支)中。 为了确保不引入重大更改，将在每个潜在的版本上运行完整的测试套件，以对新代码进行回归测试，即测试新代码不会破坏现有的有效功能。

This approach requires good test coverage of the code base, meaning that a majority, if not all, of the code has tests which ensure its features are fully functional. Ideally continuous integration would be practiced together with full Test-Driven Development.

这种方法要求对代码库进行良好的测试覆盖，这意味着，即使不是全部，大多数(如果不是全部)代码都具有可以确保其功能完全正常运行的测试。 理想情况下，将与完整的测试驱动开发一起进行连续集成。

主要步骤 (Main Steps)

The following basic steps are necessary to do the most standard current approach to continuous integration.

为了执行当前最标准的持续集成方法，必须执行以下基本步骤。

1. Maintain a central repo and an active master branch.

   维护中央存储库和活动的master分支。

There has to be a code repository for everyone to merge into and pull changes from. This can be on Github or any number of code-storage services.

必须有一个代码库，每个人都可以合并并从中提取更改。 可以在Github上或任何数量的代码存储服务上。

1. Automate the build.
   自动化构建。

Using NPM scripts or more complex build tools like Yarn, Grunt, Webpack, or Gulp, automate the build so that a single command can build a fully functional version of the product, ready to be deployed in a production environment. Better yet, include deployment as part of the automated build!

使用NPM脚本或更复杂的构建工具(例如Yarn，Grunt，Webpack或Gulp) ，可以使构建自动化，以便单个命令可以构建产品的完整功能版本，并准备将其部署在生产环境中。 更好的是，将部署作为自动构建的一部分！

1. Make the build run all the tests.
   使生成运行所有测试。

In order to check that nothing in the new code breaks existing functionality, the full test suite needs to be run and the build needs to fail if any tests within it fail.

为了检查新代码中是否没有任何东西破坏现有功能，需要运行完整的测试套件，并且如果其中的任何测试失败，则构建也必须失败。

1. Everyone has to merge changes to master every day.

   每个人每天都必须合并更改以master 。

2. Every merge into master has to be built and fully tested.

   每次合并到master都必须构建并经过全面测试。

最佳实践 (Best Practices)

There are further best practices that make the best use of what CI has to offer and the challenges it presents, such as:

还有其他最佳实践可以充分利用CI所提供的功能以及它所带来的挑战，例如：

1. Keep the build fast, so that lots of developer time isn’t wasted waiting for a build.
   保持构建速度快，以免浪费大量开发人员时间来等待构建。
2. Test the build in a full clone of the production environment.
   在生产环境的完整克隆中测试构建。

If you have, for example, an app deployed on something like Heroku or Digital Ocean, have a separate test deployment there that you can deploy test builds to, to make sure they work not just in tests but in a real production environment. This test environment should be functionally identical to the actual production environment, in order to ensure the test is accurate.

例如，如果您有一个部署在Heroku或Digital Ocean之类的应用程序，则可以在其中进行单独的测试部署，您可以将测试构建部署到其中，以确保它们不仅可以在测试中工作，而且可以在实际生产环境中工作。 此测试环境在功能上应与实际生产环境相同，以确保测试准确。

1. Make it easy to stay up to date.
   轻松保持最新状态。

Coders should pull regularly from the master branch to keep integrating their code with the changes from their team. The repo should also be made available to stakeholders like product managers, company executives, or sometimes key clients, so that everyone is easily able to see progress.

编码人员应定期从master分支撤出，以保持其代码与团队变更的集成。 该回购协议还应该提供给利益相关者，例如产品经理，公司高管或有时是关键客户，以便每个人都可以轻松查看进度。

1. Keep records of builds, so that everyone can see the results of any given build, whether it succeeded or failed, and who or what introduced new changes.
   保留构建记录，以便每个人都能看到任何给定构建的结果，无论是成功还是失败，以及是谁或什么引入了新更改。
2. Automate deployment.
   自动部署。

Keep your app fully up-to-date with any new changes by automating deployment in the production environment as the final stage of the build process, once all tests have passed and the test deployment in the production environment clone has succeeded.

一旦所有测试都通过且生产环境克隆中的测试部署成功，则通过自动在生产环境中部署作为构建过程的最后阶段，使您的应用程序保持最新状态，并进行新的更改。

CI服务 (CI Services)

Lots of services exists to handle the process of continuous integration for you, which can make it a lot easier to establish a solid CI pipeline, or build process. When evaluating these, take into account factors like budget, build speed, and what kind of project you’re working on. Some services, like Travis CI offer free services for open-source projects, which can make them an easy choice for projects like that, but they might have slower builds than other services, like Circle CI or Codeship, to name just a few.

存在许多服务来为您处理持续集成的过程，这可以使建立可靠的CI管道或构建过程变得容易得多。 在评估这些项目时，请考虑预算，构建速度以及您正在从事的项目类型等因素。 Some services, like Travis CI offer free services for open-source projects, which can make them an easy choice for projects like that, but they might have slower builds than other services, like Circle CI or Codeship , to name just a few.

Acceptance Criteria (Acceptance Criteria)

The User Story, as an item in your backlog, is a placeholder for a conversation. In this conversation, the Product Owner and the Delivery Team reach an understanding on the desired outcome.

The User Story, as an item in your backlog, is a placeholder for a conversation. In this conversation, the Product Owner and the Delivery Team reach an understanding on the desired outcome.

The Acceptance Criteria tells the Delivery Team how the code should behave. Avoid writing the “How” of the User Story; keep to the “What”. If the team is following Test Driven Development (TDD), it may provide the framework for the automated tests. The Acceptance Criteria will be the beginnings of the test plan for the QA team.

The Acceptance Criteria tells the Delivery Team how the code should behave. Avoid writing the “How” of the User Story; keep to the “What” . If the team is following Test Driven Development (TDD), it may provide the framework for the automated tests. The Acceptance Criteria will be the beginnings of the test plan for the QA team.

Most importantly, if the story does not meet each of the Acceptance Criteria, then the Product Owner should not be accepting the story at the end of the iteration.

Most importantly, if the story does not meet each of the Acceptance Criteria, then the Product Owner should not be accepting the story at the end of the iteration.

Acceptance criteria can be viewed as an instrument to protect the Delivery Team. When the Delivery Team commits to a fixed set of stories in the Sprint planning they commit to fixed set of acceptance criteria as well. This helps to avoid scope creep.

Acceptance criteria can be viewed as an instrument to protect the Delivery Team. When the Delivery Team commits to a fixed set of stories in the Sprint planning they commit to fixed set of acceptance criteria as well. This helps to avoid scope creep.

Consider the following situation: when accepting the user story the Product Owner suggests adding something that was not in the scope of the User story. In this case the Delivery team is in the position to reject this request (however small it might be) and ask the Product owner to create a new User story that can be taken care of in another Sprint.

Consider the following situation: when accepting the user story the Product Owner suggests adding something that was not in the scope of the User story. In this case the Delivery team is in the position to reject this request (however small it might be) and ask the Product owner to create a new User story that can be taken care of in another Sprint.

Code Smells (Code Smells)

A Code Smell in computer programming is a surface indication that there might be a problem regarding your system and the quality of your code. This problem might require refactoring to be fixed.

A Code Smell in computer programming is a surface indication that there might be a problem regarding your system and the quality of your code. This problem might require refactoring to be fixed.

It is important to understand that smelly code works, but is not of good quality.

It is important to understand that smelly code works, but is not of good quality.

例子 (Examples)

1. Duplicated code - Blocks of code that have been replicated across the code base. This may indicate that you need to generalize the code into a function and call it in two places, or it may be that the way the code works in one place is completely unrelated to the way it works in another place, despite having been copied.
   Duplicated code - Blocks of code that have been replicated across the code base. This may indicate that you need to generalize the code into a function and call it in two places, or it may be that the way the code works in one place is completely unrelated to the way it works in another place, despite having been copied.
2. Large classes - Classes having too many lines of code. This may indicate that the class is trying to do too many things, and needs to be broken up into smaller classes.
   Large classes - Classes having too many lines of code. This may indicate that the class is trying to do too many things, and needs to be broken up into smaller classes.

More info on Agile Development: (More info on Agile Development:)

• How to make sure your development process is actually Agile

  How to make sure your development process is actually Agile

• How to fix tech debt

  How to fix tech debt

• Does Agile really mean what you think?

  Does Agile really mean what you think?

翻译自: https://www.freecodecamp.org/news/complete-guide-to-agile-methodology/

敏捷方法论