sdlc 瀑布式 生命周期

When I decided to teach myself how to code almost four years ago I had never heard of, let alone thought about, the software development life cycle.

当我差不多四年前决定教自己如何编码时，我从未听说过软件开发生命周期，更不用说思考了。

As a brand new developer I was focused on learning the technologies that would help me land that coveted first developer job, not the nuances of how those teams operated.

作为一个崭新的开发人员，我专注于学习可以帮助我着迷于第一个开发人员工作的技术，而不是那些团队如何运作的细微差别。

When I did learn of them, I thought they would be useless to me because I considered myself a web developer not a software developer.

当我确实了解了它们之后，我认为它们对我毫无用处，因为我认为自己是Web开发人员而不是软件开发人员。

I've since learned that this couldn't be further from the truth and these principles/practices play a large role in my day-to-day activities (whether I realize it or not).

从那以后我就知道，这离事实还远，这些原则/实践在我的日常活动中起着重要作用(无论我是否意识到)。

I'm fortunate enough to see how the code I write, the features I build, and the bugs I inadvertently introduce (more than I care to admit) affect the end user and their experience. That experience has helped shape how I think about the process of building products and solving problems for my users.

我很幸运地看到了我编写的代码，所构建的功能以及我无意间引入的错误(我不愿承认的错误)如何影响最终用户及其体验。 这种经验帮助塑造了我对产品构建过程和为用户解决问题的看法。

I've had some time to think about the differences (and similarities) each of these approaches offer. At their core, each is focused on delivering high quality software as efficiently and as cost effectively as possible.

我花了一些时间考虑这些方法所提供的差异(和相似性)。 它们的核心都是致力于尽可能高效，经济地交付高质量软件。

Professionally, I've only used one or two of these methodologies. But I still find value in at least a basic understanding of all of them.

专业上，我只使用了其中一种或两种方法。 但是我仍然至少从对所有这些方面的基本理解中发现了价值。

All of these methodologies follow a series of phases similar to this diagram:

所有这些方法论都遵循与该图相似的一系列阶段：

So, here are the software development life cycle methods (in no particular order):

因此，以下是软件开发生命周期方法(无特定顺序)：

• Lean

  靠

• Agile

  敏捷

• Waterfall

  瀑布

• Iterative

  迭代式

• Spiral

  螺旋

• Dev Ops

  开发运营

Let's dig in to the differences and similarities of each method.

让我们深入探讨每种方法的异同。

靠 (Lean)

The Lean methodology relies heavily on and is comprised of seven principles.

精益方法在很大程度上依赖于七项原则。

In no specific order they are:

按无特定顺序排列的是：

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建立诚信
7. See/Optimize The Whole查看/优化整体

Each principle has a specific purpose with benefits that compliment each other.

每种原则都有一个特定的目的，彼此互补。

Eliminating waste (extra features, incomplete work, managerial engagements, etc) creates more value for the customer which, in turn, enhances satisfaction.

消除浪费 (额外功能，不完整的工作，管理人员参与等)可为客户创造更多价值，进而提高满意度。

Amplifying learning allows teams to reinvest in their ability to deliver products to customers.

加强学习使团队可以重新投资于向客户交付产品的能力。

Deciding as late as possible refers to all major decisions, giving teams an option based or a set based approach.  This allows teams to gather facts rather than opinions to help influence decisions when made.

尽可能晚地做出决定是指所有重大决定，为团队提供基于选项或基于集合的方法。 这使团队可以收集事实而不是意见，以帮助制定决策。

Delivering as fast as possible is self explanatory - build the product as quickly as possible to deliver it to customers for evaluation/iteration.

尽快交付是不言而喻的- 尽快构建产品以将其交付给客户进行评估/迭代。

In a typical scenario, the managers dole out assignments/work to the developers. In the Lean methodology developers "teach" managers how to listen to the "people in the trenches" thus influencing the decisions/choices of management.

在典型情况下，管理人员将任务/工作分配给开发人员。 在精益方法论中，开发人员“教”经理们如何倾听“战people中的人”的声音，从而影响管理的决策/选择。

This helps teams feel more empowered to speak up about ides and solutions.

这有助于团队更有能力谈论想法和解决方案。

Making integrity a rule instead of an exception means that the customer is confident in the system being built. The customer knows the system is being built to withstand the appropriate amount of growth and "stretching" if need be.

将完整性作为规则而不是例外意味着客户对所构建的系统充满信心。 客户知道该系统的构建可以承受适当的增长和“扩展”(如果需要)。

I like to think of the integrity part along the same lines as sitting in a chair. When you sit in the chair you believe it was constructed with the best material that will hold you up every time you sit in it for the life of the chair. The customer needs to that same confidence in the product being built.

我喜欢像坐在椅子上一样去思考完整性部分。 当您坐在椅子上时，您会相信它是由最好的材料制成的，这种材料将使您每次坐在椅子上一生都可以坐下来。 客户对所生产的产品也要有同样的信心。

Lastly, seeing and optimizing the whole refers to the entirety of the system being built. By optimizing for the whole we look at software not as a sum of many components, but as one large entity that is optimized for efficiency.

最后， 查看和优化整体是指所构建系统的整体。 通过整体上的优化，我们不将软件视为许多组件的总和，而是将其视为针对效率进行了优化的一个大型实体。

This means that during development, the product is broken into manageable pieces and that inadvertent bugs are not only discovered but resolved swiftly.

这意味着在开发过程中，产品被分解为可管理的部分，不仅发现了无意的错误，而且Swift将其解决。

敏捷 (Agile)

This is the "fail fast" approach to building software.

这是构建软件的“快速失败”方法。

It places emphasis on small, incremental releases with on-going release cycles. With each iteration teams strive to identify and address small issues before they become big problems.

它着重于具有持续发行周期的小型增量发行。 在每次迭代中，团队都努力在小问题变成大问题之前识别并解决。

This also means that the teams must engage stakeholders (people/organizations that the code can ultimately affect such as managers, technical leads, CTOs, and customers) to get their feedback.

这也意味着团队必须与利益相关者(代码可能最终影响到的人员/组织，例如经理，技术负责人，CTO和客户)进行互动，以获得他们的反馈。

If you're a freelance, your stakeholder(s) would be your customers - ultimately you need to ensure their satisfaction with the work before moving on.

如果您是自由职业者，那么您的利益相关者将是您的客户-最终，您需要在继续之前确保他们对工作的满意度。

Agile is technically an offshoot of the Lean methodology with some notable differences - mainly it prioritizes customer satisfaction from the outset and allows teams to respond quickly to customer feedback.

从技术上讲，敏捷是精益方法的一个分支，但有一些显着差异-主要是它从一开始就将客户满意度放在首位，并允许团队快速响应客户的反馈。

Although it is beyond the purview of this article, there is another more complex framework within Agile that is called SCRUM. This methodology is used for large, extremely complex projects and has even been used outside of software development.

尽管超出了本文的范围，但敏捷中还有另一个更复杂的框架称为SCRUM 。 这种方法用于大型，极其复杂的项目，甚至在软件开发之外也已使用。

瀑布 (Waterfall)

The waterfall methodology is, by most accounts, the oldest one in the list. It was never meant to be a model for software development and got its start in the construction and manufacturing worlds.

在大多数情况下，瀑布方法是该列表中最古老的方法。 它从来没有成为软件开发的典范，并在建筑和制造领域起步。

This approach is simple in its structure - finish all parts of a phase before moving on to the next phase with more momentum building towards the project finish as stages are completed. Each stage's beginning (except for the first) and completion is contingent on the previous stage's completion/transfer of information.

这种方法的结构很简单-在进入下一阶段之前先完成一个阶段的所有部分，然后随着阶段的完成向项目完成提供更多动力。 每个阶段的开始(第一阶段除外)和完成取决于上一阶段信息的完成/传输。

Under the waterfall approach each stage has its own rigid project plan that finishes off with testing for previously completed work. It should be noted that this approach is not recommended for larger/longer lasting projects because of the aforementioned rigidity.

在瀑布式方法下，每个阶段都有自己的固定项目计划，该计划以对先前完成的工作的测试结束。 应该注意的是，由于上述的刚性，不建议将这种方法用于较大/较持久的项目。

Think about the genesis of this methodology and you'll understand it more. It came from the construction/manufacturing world where it is common to complete one phase at a time. During the building of a house you wouldn't start putting in the plumbing before the frame has been put up.

考虑一下这种方法的起源，您将了解更多。 它来自建筑/制造世界，通常一次完成一个阶段。 在建造房屋期间，您不会在框架刚架好之前就将管道插入。

That's not the way software development works generally. As we all know it sometimes becomes necessary to revisit a phase that was previously thought to be finished.

这不是软件开发通常的工作方式。 众所周知，有时有必要重新审视以前认为已经完成的阶段。

迭代式 (Iterative)

This is known as the "repetitive approach" or the "make it better the next go around" approach because of the different opportunities it provides to improve the product with each cycle iteration.

这被称为“重复性方法”或“使下一个循环更好”，因为它为每次循环迭代提供了改进产品的不同机会。

I'm biased (as we all are :D) but this happens to be my favorite life cycle for development.  I believe it works best for my current situation  both in my freelance and career path because it allows me to constantly "move forward while making things better."

我有偏见(大家都是：D)，但这恰好是我最喜欢的开发生命周期。 我认为，无论是在我的自由职业者还是职业道路上，它都对我当前的状况最为有效，因为它使我能够不断“前进，同时使事情变得更好”。

With the iterative approach, teams implement a solution, test that solution, evaluate its effectiveness/throughput, and then pinpoint further areas for improvement. This happens for each cycle (iteration) of the development process.

使用迭代方法，团队可以实施解决方案，测试该解决方案，评估其有效性/吞吐量，然后确定需要改进的地方。 在开发过程的每个周期(迭代)中都会发生这种情况。

With each version released comes another iteration until the final product is completed and ready for rollout to users.

随着每个版本的发布，都会有另一个迭代，直到最终产品完成并准备向用户推出为止。

One of the great features of the iterative approach is you and your team get a working version of software early on in the development process.  This can be especially useful to show to stakeholders to gauge their response/feedback.

迭代方法的主要功能之一是您和您的团队在开发过程的早期就可以获得软件的有效版本。 这对于向利益相关者显示评估他们的响应/反馈特别有用。

One of the big drawbacks to this approach is it can consume a large amount of resources very quickly. Imagine all of the people, hours, bug fixes and wages that go into each iteration of the development cycle and you'll get a good picture of the resource usage.

这种方法的主要缺点之一是它可能很快消耗大量资源。 想象一下开发周期的每个迭代中涉及的所有人员，工时，错误修复和薪水，您将清楚地了解资源的使用情况。

Within this approach is a subset of principles developed by Rational Software Corporation (bought by IBM) called the Rational Unified Process (R.U.P.) which consists of 4 phases:

在这种方法中，有一部分由Rational Software Corporation(由IBM购买)开发的原理称为Rational Unified Process(RUP) ，它由四个阶段组成：

• Inception起始时间
• Elaboration细化
• Construction施工
• Transition (product release)过渡(产品发布)

This set of principles is meant to be flexible and tailored to the needs of each team using it.

这套原则旨在灵活并且适合使用它的每个团队的需求。

螺旋 (Spiral)

The spiral methodology is likely the most flexible out of the six.  It's a methodology built on risks - identifying and negating them. Risk (identification & aversion) drives every decision in this model. It is broken into four sub-phases:

螺旋方法可能是六种方法中最灵活的一种。 这是建立在风险之上的方法-识别并消除风险。 风险(识别和厌恶)驱动该模型中的每个决策。 它分为四个子阶段：

• Planning (objectives)计划(目标)
• Risk Analysis (identify possible roadblocks)风险分析(确定可能的障碍)
• Develop & Test (current & next version)开发和测试(当前和下一版本)
• Evaluation (review of current phase & plan for next phase)评估(当前阶段的审查和下一阶段的计划)

Each iteration of each phase begins with planning for the next phase. This way potential risks are identified before they are encountered. This also allows for a plan of action when said risks arise.

每个阶段的每次迭代都从为下一个阶段进行计划开始。 这样，在遇到潜在风险之前就将其识别出来。 当上述风险出现时，这还允许制定行动计划。

During phases teams also work to mitigate these risks and their impact on future iterations of the spiral development.

在阶段中，团队还致力于减轻这些风险及其对螺旋式开发的未来迭代的影响。

As the development process continues, each of these four sub-phases is repeated in spiral fashion. This allows for multiple rounds of refinement for each sub-phase until completion.

随着开发过程的继续，这四个子阶段中的每个阶段都以螺旋方式重复进行。 这允许每个子阶段进行多轮优化，直到完成。

开发运营 (Dev Ops)

If you do a quick search, you will find no shortage of information on this development life cycle method. It is the new kid on the block that brings software development and information-technology operations teams into the same fold.

如果您进行快速搜索，则不会发现有关此开发生命周期方法的信息不足。 正是这一新手，将软件开发和信息技术运营团队整合到了一起。

These teams work in conjunction to provide small, but impactful, updates to products that come at a frequent pace. In turn, this creates a continuous feedback and improvement loop that drives development.

这些团队共同合作，为经常更新的产品提供小型但有影响力的更新。 反过来，这会创建一个持续的反馈和改进循环，以驱动开发。

This particular methodology is known for automating the manual parts of development as well (think deployment).

这种特殊的方法也可以自动完成开发的手动部分(考虑部署)。

The overall goal of this methodology is, like most others, the shorten the development life cycle and provide quality products.

与大多数其他方法一样，此方法的总体目标是缩短开发生命周期并提供优质的产品。

One of the drawbacks to this methodology is the significant mindset and culture changes within an organization. Teams that may have been accustomed to working on many things find their tasks narrowed to only one or two.

这种方法的缺点之一是组织内部的重大思维和文化变化。 可能习惯于处理许多事情的团队发现他们的任务仅限于一两个。

For example, a general purpose developer may find they are now being tasked with only the testing portion or the end-user experience portion.

例如，通用开发人员可能会发现，他们现在只承担测试部分或最终用户体验部分的任务。

把它带回家 (Bringing It All Home)

I hope you can now see the importance and the benefits of each of these methodologies. Each of these possess their own strengths and weaknesses.

我希望您现在可以看到每种方法的重要性和好处。 这些中的每一个都有自己的优点和缺点。

They are, at their most basic level, a set of guidelines and principles that seek to deliver high quality, efficient work to stakeholders.

它们是最基本的一组准则和原则，旨在为利益相关者提供高质量，高效的工作。

When I first started learning to code I didn't have a mentor. By sharing what I've learned I hope to help those who are learning to code when/where they can.

当我刚开始学习编码时，我没有指导者。 通过分享我所学到的知识，我希望能帮助那些正在学习的人尽可能地/尽可能地进行编码。

I want to share as much information and experience as I possibly can with other developers.  If you are teaching yourself to code or if you're a seasoned developer I hope this article helps, even if in a small way.

我想与其他开发人员分享尽可能多的信息和经验。 如果您正在教自己编写代码，或者如果您是一位经验丰富的开发人员，那么我希望本文对您有所帮助，即使以很小的方式。

Check out my blog where I frequently post articles about web development.

在我经常发布有关Web开发的文章的博客中查看。

While you're there why not sign up for my newsletter? You can do  that at the top right of the main blog page.  I like to send out  interesting articles (mine and others), resources, and tools for  developers every now and then.

当您在那里时，为什么不注册我的时事通讯？ 您可以在博客主页面的右上角进行操作。 我喜欢不时为开发人员发送有趣的文章(我的和其他文章)，资源和工具。

If you have questions about this article or just in general my DMs are open -- come say hi on Twitter or any of my other social media accounts which you can find below the  newsletter sign up on the main page or on my profile here :)

如果您对本文有疑问或只是一般而言我的DM是开放的-请在Twitter或我的任何其他社交媒体帐户上打个招呼，您可以在新闻通讯下面的主页上或我的个人资料上找到注册:)

Have an awesome day and happy coding, friend!

祝您有个美好的一天，并祝您编程愉快，朋友！

翻译自: https://www.freecodecamp.org/news/get-a-basic-understanding-of-the-life-cycles-of-software-development/

sdlc 瀑布式 生命周期