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 瀑布式 生命周期