本文翻譯來自SAFe DevOps社群帥哥網(wǎng)友?
賈磊：高級(jí)質(zhì)量經(jīng)理&敏捷教練?
曾就職于外企、國(guó)企、大型上市企業(yè)等，擔(dān)任過測(cè)試工程師、測(cè)試經(jīng)理、項(xiàng)目經(jīng)理、敏捷教練、質(zhì)量總監(jiān)、高級(jí)質(zhì)量經(jīng)理等崗位。是一名敏捷變革的愛好者和踐行者。愛好網(wǎng)球、羽毛球。

正文

原文鏈接：https://www.scaledagileframework.com/continuous-exploration/“Specifically, you can take the time to develop and bring to the table an outside-in, market-centric perspective that is so compelling and so well informed that it can counterbalance the inside-out company-centric orientation of last year’s operating plan.?—Geoffrey Moore, Escape Velocity”

“具體來說，您可以花時(shí)間開發(fā)并提出一種由外向內(nèi)、以市場(chǎng)為中心的觀點(diǎn)，這種觀點(diǎn)包含的信息如此豐富而又令人信服，以至于可以平衡掉去年運(yùn)營(yíng)計(jì)劃中由內(nèi)向外以公司為中心的取向。”

-- 杰弗里·摩爾，《逃逸速度》

?持續(xù)探索

continuous Exploration

Continuous exploration is the first element in the four-part Continuous Delivery Pipeline, preceding Continuous Integration(CI), Continuous Deployment(CD), and Release on Demand.?

持續(xù)探索是組成持續(xù)交付流水線的四個(gè)實(shí)踐模塊中的第一個(gè)要素，后面分別是持續(xù)集成(CI)、持續(xù)部署(CD)和按需發(fā)布(RoD)。

Continuous Exploration (CE) is the process that fosters innovation and builds alignment on what should be built by continually exploring market and Customer needs, and defining a Vision, Roadmap, and set of Features for a Solution that addresses those needs.?

持續(xù)探索(CE)是通過持續(xù)探索市場(chǎng)和客戶需求，并為實(shí)現(xiàn)這些需求定義產(chǎn)品愿景、產(chǎn)品路線圖和一系列特性，來促進(jìn)創(chuàng)新及構(gòu)建必要一致性的過程。

During CE, new ideas are raised, refined, and prepared as a list of prioritized features in the Program Backlog. They are pulled into implementation during PI Planning, which begins the continuous integration process. Thereafter, the continuous deployment cycle pulls the features into production, where they are validated and made ready for release.?

在持續(xù)探索的過程中，新提出的想法經(jīng)過提煉，成為Program Backlog中的按優(yōu)先級(jí)排序的特性列表。它們?cè)诔掷m(xù)集成過程開頭的項(xiàng)目群增量規(guī)劃中被引入實(shí)施。此后，持續(xù)部署的循環(huán)會(huì)將這些特性引入生產(chǎn)，并在那里對(duì)它們進(jìn)行驗(yàn)證和發(fā)布準(zhǔn)備。

Inputs to continuous exploration come from Customers, Agile Teams, Product Owners, Business Owners as well as stakeholders, and strategic portfolio concerns. Under the direction of Product and Solution Management, research and analysis activities are used to further define and evaluate the feature. The result of this process is a set of outputs, including the vision, a set of features in the backlog sufficiently defined for implementation, and a roadmap forecast of when those features might be delivered.

持續(xù)探索的輸入來自客戶、敏捷團(tuán)隊(duì)、產(chǎn)品負(fù)責(zé)人、業(yè)務(wù)負(fù)責(zé)人和利益相關(guān)者，以及戰(zhàn)略投資組合的關(guān)注點(diǎn)。在產(chǎn)品和解決方案管理方向的指導(dǎo)下，研究和分析活動(dòng)用于進(jìn)一步定義和評(píng)估特性。這一過程的結(jié)果是一組輸出，包括產(chǎn)品愿景、為進(jìn)一步實(shí)現(xiàn)而充分定義在待辦列表中的一組特性，以及這些特性將何時(shí)交付的產(chǎn)品路線圖預(yù)測(cè)。

?詳述

Details

DevOps and Release on Demand is one of the five core competencies of the Lean Enterprise. It provides the enterprise with the ability to deliver increasingly valuable solutions to end users with optimal frequency. Continuous exploration is integral to that process and focuses on gaining alignment on new opportunities and what needs to be built, while understanding that all such ideas are hypotheses that need to be validated.?

研發(fā)運(yùn)維一體化和按需發(fā)布是精益企業(yè)的五大核心競(jìng)爭(zhēng)力之一。它使企業(yè)能夠以最佳頻率向最終用戶提供越發(fā)有價(jià)值的解決方案。持續(xù)探索是這一過程不可或缺的一部分，它側(cè)重于在新機(jī)遇間取得一致性并定義所需構(gòu)建的內(nèi)容，同時(shí)理解所有這些想法都是需要驗(yàn)證的假設(shè)。

In place of the traditional waterfall approach, CE mitigates the more extensive, and theoretically complete, up-front definition of requirements for the work to be done. Instead, it applies a continuous exploration process, providing a consistent flow of new work that is sufficiently ready for the teams to implement. New functionality is defined and available in small batches that can travel easily through continuous integration, continuous deployment, and on to release.?

與傳統(tǒng)的瀑布模式相比，在更廣泛的、理論上完整的預(yù)先定義方面，持續(xù)探索減輕了對(duì)要完成的工作的要求。取而代之，它通過持續(xù)的探索過程，提供了一致性的新工作流程，并為團(tuán)隊(duì)實(shí)施做足了準(zhǔn)備。定義好的新功能以小批量投入，就可以輕松地通過持續(xù)集成、持續(xù)部署和進(jìn)行發(fā)布了。

持續(xù)探索的四個(gè)子維

Four Sub-dimensions of Continuous Exploration?

SAFe describes four sub-dimensions of Continuous Exploration as illustrated in Figure 1:?

• Hypothesize– covers the skills necessary to identify ideas, and the measurements needed to validate them with customers?
• Collaborate and research – covers the skills needed to work with customers and stakeholders to refine the understandings of potential needs?
• Architect – covers the skills necessary to envision a technological approach that enables quick implementation, delivery and support of ongoing operations?
• Synthesize– encompasses the skills that organize the ideas into a holistic vision, a roadmap, a prioritized program backlog, and supports final alignment during PI Planning

規(guī)模化敏捷框架為連續(xù)探索描述了四個(gè)子維度，如圖1所示:?

• 假設(shè)–涵蓋甄別靈感和想法所需的技能，以及向取得客戶驗(yàn)證所需的度量方法。
• 協(xié)作和研究–涵蓋與客戶及利益相關(guān)方合作，以完善對(duì)潛在需求理解所需的技能?。
• 架構(gòu)設(shè)計(jì)–涵蓋預(yù)見技術(shù)方法所需的技能，用以實(shí)現(xiàn)快速實(shí)施、交付，并對(duì)持續(xù)運(yùn)營(yíng)加以支撐。
• 整合–包含將靈感和想法組織成整體愿景、產(chǎn)品路線圖的能力，以及轉(zhuǎn)化出帶優(yōu)先級(jí)的項(xiàng)目群待辦任務(wù)列表(Program Backlog)的技能，以實(shí)現(xiàn)項(xiàng)目群增量規(guī)劃過程中的一致性。

圖1 - 持續(xù)探索的四個(gè)子維度

?

構(gòu)建解決方案假設(shè)

Create a Solution Hypotheses

New ideas start as hypotheses—one never really knows whether they will work or not. Product and Solution Management have notions of what needs to be developed that from their understanding of the marketplace, as well as from the Strategic Themes, and Portfolio Vision and roadmap. These ideas might also be initiated by Portfolio Epics, or alternatively, they might spawn new Portfolio Epics.?

新的靈感始于假設(shè)——人們永遠(yuǎn)不會(huì)真正知道它們是否可行。產(chǎn)品和解決方案管理對(duì)需要研發(fā)的內(nèi)容有自己的看法，這些看法源于他們對(duì)市場(chǎng)的理解，以及戰(zhàn)略主題、產(chǎn)品組合愿景和產(chǎn)品路線圖。這些想法也可能是由史詩組合發(fā)起，或者，它們可能產(chǎn)生新的史詩組合。

Two specific skills contribute to the ability to hypothesize:?

• Lean startup thinking – The definition of Minimal Viable Products (MVPs) helps evaluate hypotheses quickly before too much investment has been made. The MVP is the smallest thing that can be built to evaluate whether the hypothesis is valid.?

• Innovation Accounting – Evaluating hypothesis requires different metrics than those used to measure end-state working solutions. Innovation Accounting focuses on how to measure the intermediate, and predictive business outcomes of the hypothesis both during initial incremental solution development and evaluation of the MVP. (Read more in the Innovation Accounting article.)?

兩種能促進(jìn)假設(shè)的特定技能：

• 精益創(chuàng)業(yè)思維——最小可行產(chǎn)品(MVP)的定義有助于在投資過多之前迅速對(duì)假設(shè)進(jìn)行評(píng)估。最小可行產(chǎn)品是能用來評(píng)估假設(shè)是否有效的最小單元。
• 創(chuàng)新會(huì)計(jì)——評(píng)估假設(shè)需要不同于度量解決方案最終狀態(tài)所用的指標(biāo)。創(chuàng)新會(huì)計(jì)關(guān)注于如何在最初的增量解決方案開發(fā)和最小可行產(chǎn)品評(píng)估過程中，度量假設(shè)的過程值并預(yù)測(cè)業(yè)務(wù)成果。(更多內(nèi)容，請(qǐng)參閱文章《創(chuàng)新會(huì)計(jì)》。)

客戶協(xié)作與需求研究

Collaborate and research customer needs??

To create a compelling and differentiated vision, Product Management enables and facilitates a continuous and collaborative process that solicits input from a diverse group of stakeholders as Figure 2 shows. Primary sources include:?

為了構(gòu)建一個(gè)令人矚目的差異化產(chǎn)品愿景，產(chǎn)品管理支持并促進(jìn)了一個(gè)持續(xù)的協(xié)作過程，該過程從不同的利益相關(guān)方中征求意見，如圖2所示。其主要信息來源包括:?

• System Architects/Engineers – System Architects/Engineers have in-depth technical knowledge of the solution and are responsible for understanding it at the system level, as well as its ‘use cases’ and Nonfunctional Requirements (NFRs). Although it’s natural to view these roles as technically and internally inclined, architects should also have significant and ongoing customer engagement.?

• 系統(tǒng)架構(gòu)師/工程師–系統(tǒng)架構(gòu)師/工程師對(duì)實(shí)現(xiàn)解決方案有深入的技術(shù)知識(shí)儲(chǔ)備，并負(fù)責(zé)從系統(tǒng)層面理解它，以及它的“用例”和非功能性需求(NFRs)。雖然這些角色天然的被視作有技術(shù)和內(nèi)部的傾向，但架構(gòu)師在持續(xù)的客戶參與中也具有重要作用。?

• Customers–By voting with their wallets or their feet, customers are the ultimate judge of value. They’re the most obvious and primary source of input. But a note of caution: customers motivations are often heavily bound to their current solution context, so they are often motivated only to improve things incrementally. In other words: the sum total of customer input does not a strategy make. But failing to meet real and evolving customer needs is a sure path to extinction. A sense of balance is required. As the SAFe Lean-Agile mindset says, “Producers innovate. Customers validate.”?

• 客戶——通過用錢包或腳投票，客戶是價(jià)值的最終評(píng)判者。他們是最明顯和最主要的信息輸入來源。但需要注意的是：客戶的動(dòng)機(jī)通常與他們當(dāng)前的解決方案環(huán)境緊密相關(guān)，所以他們提出的通常只是基于現(xiàn)有方案的不斷改進(jìn)。換句話說：客戶輸入信息的總和并不能組成一個(gè)策略。然而，若不能滿足真實(shí)的和不斷發(fā)展的客戶需求，產(chǎn)品終將會(huì)消亡。所以找到一種平衡感很重要。正如規(guī)模化敏捷框架中的精益敏捷思維模式所說，“生產(chǎn)者創(chuàng)新，客戶驗(yàn)證。”

• Business Owners and stakeholders–Business Owners have the business and market knowledge needed to set the mission and vision. They also have specific responsibilities throughout the development process. A solution that doesn’t meet their expectations is probably no solution at all.?

• 業(yè)務(wù)負(fù)責(zé)人和利益相關(guān)方——業(yè)務(wù)負(fù)責(zé)人具備設(shè)定產(chǎn)品使命和產(chǎn)品愿景所需的業(yè)務(wù)及市場(chǎng)知識(shí)。他們?cè)谡麄€(gè)研發(fā)過程中也有特定的職責(zé)。不符合他們期望的解決方案可能根本就不是解決方案。

• POs and teams–Product Owners and teams have some of the foremost expertise in the domain. In most cases, they developed the existing solution and are closest to both technical and user concerns. Their input is integral and invaluable.

• 產(chǎn)品負(fù)責(zé)人和交付團(tuán)隊(duì)——產(chǎn)品負(fù)責(zé)人和交付團(tuán)隊(duì)在擁有一些該領(lǐng)域最重要的專業(yè)知識(shí)。在大多數(shù)情況下，他們研發(fā)了現(xiàn)有的解決方案，并且最關(guān)心技術(shù)和用戶問題。他們所輸入的信息是不可或缺的，也是無價(jià)的。

Figure 2. Product Management collaborates with multiples stakeholders to refine requirements?

圖2 – 產(chǎn)品管理與多個(gè)利益相關(guān)方協(xié)作完善需求

Six specific skills help drive collaboration and research:?

• Lean UX thinking–Lean UX [5] is a collaborative process of working with stakeholders to define Minimal Marketable Features (MMFs) and validate them quickly with customers. (The Lean UX article provides more information about this process.)?
• Customer visits– There’s no substitute for first-person observation of the daily activities of the people doing the work. Whether structured or informal, Product Managers and Product Owners are responsible for understanding how people actually use systems in their actual work environments. They can’t do that at their desk, so there is no substitute for observing users in their specific Solution Context.?
• Gemba walks– Many times, customers are the internal people who implement the operational values streams that our development systems support. The Gemba walk (‘Gemba’ is the place where the work is performed [2]) can be used by developers to observe how these stakeholders execute the steps and specific activities in their operational value streams.?
• Elicitation– There are a variety of structured elicitation techniques that Product Management and Product Owner professionals use to generate input and prioritize user needs. These include research methods such as interviews and surveys, brainstorming and idea reduction, questionnaires, and competitive analysis. Other techniques include requirements workshops, user experience mock-ups, user personas, review of customer requests, and use-case modeling. [3, 4]?
• Trade studies– Product Owners and Product Managers often engage in trade studies to determine the most practical characteristics of a solution. They review numerous solutions to a technical problem, as well as vendor-provided products and services that address the subject area or an adjacent need. Solution alternatives are then evaluated against the benefit hypothesis to determine which ones are the most effective for a particular context.?
• Market research – To broaden their thinking, Product Owners and Product Managers also conduct original market research, analyze secondary research and market/industry trends, identify emerging customer segments, interview industry analysts, and review competitive solutions.?

六項(xiàng)有助于推動(dòng)協(xié)作和研究的具體技能:?

• 精益用戶體驗(yàn)思維–精益用戶體驗(yàn)是一個(gè)與利益相關(guān)方協(xié)作的過程，旨在定義最小可銷售特性(MMFs)，并快速向客戶驗(yàn)證這些特性。(精益用戶體驗(yàn)的文章中提供了有關(guān)這一過程的更多信息。)
• 客戶拜訪——對(duì)工作人員的日常活動(dòng)進(jìn)行第一人稱觀察是無可替代的。無論是結(jié)構(gòu)化的還是非正式的，產(chǎn)品經(jīng)理和產(chǎn)品所有者都有責(zé)任理解人們?cè)趯?shí)際工作環(huán)境中是如何實(shí)際使用系統(tǒng)的。他們不能在辦公桌上這樣做，所以沒有什么可以替代在特定的解決方案環(huán)境中觀察用戶。
• 作業(yè)現(xiàn)場(chǎng)走查——很多時(shí)候，對(duì)于我們研發(fā)的系統(tǒng)所支持的運(yùn)營(yíng)價(jià)值流，客戶是參與其實(shí)現(xiàn)的內(nèi)部人員。研發(fā)人員可以通過作業(yè)現(xiàn)場(chǎng)走查(“Gemba”就是執(zhí)行工作的場(chǎng)所)來觀察這些利益相關(guān)者是如何執(zhí)行其運(yùn)營(yíng)價(jià)值流中的環(huán)節(jié)和具體活動(dòng)的。
• 啟發(fā)——產(chǎn)品管理和產(chǎn)品負(fù)責(zé)專家可以通過使用各種結(jié)構(gòu)化的啟發(fā)技術(shù)，來生成信息輸入項(xiàng)以及確定用戶需求的優(yōu)先級(jí)。其中包括的調(diào)查方法，如訪談和調(diào)查、頭腦風(fēng)暴和想法簡(jiǎn)化、問卷調(diào)查和競(jìng)爭(zhēng)分析。其他技術(shù)包括需求研討會(huì)、用戶體驗(yàn)原型、用戶畫像、客戶需求審查和用例建模。
• 貿(mào)易研究–產(chǎn)品負(fù)責(zé)人和產(chǎn)品經(jīng)理經(jīng)常參與貿(mào)易研究，以確定解決方案的最實(shí)際的應(yīng)用特征。他們審查技術(shù)問題的眾多解決方案，也包括用以解決主題領(lǐng)域或相鄰需求的供應(yīng)商端的產(chǎn)品和服務(wù)。然后根據(jù)效益假設(shè)對(duì)解決方案進(jìn)行評(píng)估，以確定哪一個(gè)對(duì)特定環(huán)境最有效。
• 市場(chǎng)研究–為了拓寬思路，產(chǎn)品負(fù)責(zé)人和產(chǎn)品經(jīng)理還會(huì)進(jìn)行原始市場(chǎng)研究，分析和研究次級(jí)市場(chǎng)/行業(yè)趨勢(shì)，鎖定新興客戶群，訪談行業(yè)分析師，并審查競(jìng)爭(zhēng)解決方案。

?解決方案架構(gòu)設(shè)計(jì)??

Architect the solution

Architects on all levels play an important role in understanding how the architecture drives and enables the continuous delivery pipeline, and in guiding Agile Teams in the design process that will support this. Five skills support this effort:?

• Architecting for releasability – Different parts of the solution require different release strategies. The solution must be designed to enable various incremental release strategies and shift them over time based on business demand.?

• Architecting for testability– Systems that can’t be easily tested can’t be readily changed. Systems which are designed and architected in a modular way enable continuous testing.

• Separating deploy and release– In order to continuously deploy, the ability to release may need to be separate from the work of deploying to production. This separation requires architectural enablers that will allow functionality to be in production but hidden from Customers.?

• Architecting for operations– Operational needs must be considered. Build telemetry and logging capabilities into every application and into the solution as a whole. Allow services to be downgraded or even removed in times of high loads or in response to incidents. Build capabilities for fast recovery and for fix-forward.?

• Threat modeling– Information security consideration should start early, identifying threats to proposed architecture, infrastructure, and applications.?

各級(jí)架構(gòu)設(shè)計(jì)在理解架構(gòu)如何驅(qū)動(dòng)和啟動(dòng)持續(xù)交付流水線方面發(fā)揮著重要作用，并且在指導(dǎo)敏捷團(tuán)隊(duì)進(jìn)行設(shè)計(jì)的過程中對(duì)此進(jìn)行有力支持。五項(xiàng)支撐解決方案架構(gòu)設(shè)計(jì)的技能:

• 可發(fā)布性架構(gòu)——解決方案的不同部分需要不同的發(fā)布策略。該解決方案必須設(shè)計(jì)為支持各種增量發(fā)布策略，并根據(jù)業(yè)務(wù)需求隨著時(shí)間推移進(jìn)行轉(zhuǎn)換。
• 測(cè)試性架構(gòu)——不容易測(cè)試的系統(tǒng)也不會(huì)容易改變。以模塊化方式設(shè)計(jì)和架構(gòu)的系統(tǒng)支持持續(xù)的測(cè)試。
• 分離部署和發(fā)布——為了持續(xù)部署，發(fā)布能力可能需要與部署到生產(chǎn)環(huán)境的工作分開。這種分離需要架構(gòu)上的啟動(dòng)開關(guān)，這些啟動(dòng)開關(guān)將允許功能投入生產(chǎn)，而客戶不可見。
• 運(yùn)維架構(gòu)——必須考慮運(yùn)維需求。在每個(gè)應(yīng)用程序和整個(gè)解決方案中建立遙測(cè)和日志功能。在高負(fù)載時(shí)或進(jìn)行事故響應(yīng)時(shí)，允許服務(wù)降級(jí)甚至移除。構(gòu)建快速恢復(fù)和前向修復(fù)的能力。
• 威脅建模——信息安全方面的考慮應(yīng)該盡早開始，確定威脅并據(jù)此提出建議的系統(tǒng)架構(gòu)、基礎(chǔ)架構(gòu)和應(yīng)用程序。

同步產(chǎn)品愿景，產(chǎn)品路線圖以及項(xiàng)目群待辦工作列表??

Synthesize the vision, roadmap, and program backlog?

The most critical alignment activity in SAFe is PI Planning. The inputs to PI Planning are a vision, a roadmap, and a prioritized backlog of features. The synthesis sub-dimension is all about getting these assets ready for PI planning. To accomplish this, six skills are needed:?

• Creating the solution vision– The vision serves as the cornerstone for teams to understand the why for the features being developed.?
• Maintaining the solution roadmap– The solution roadmap provides a view into the near future for the ART. It helps Product Management prioritize the work, enables System Architects to prioritize the runway, and provides visibility for Business Owners.?
• Writing clear features– Defining clear features that fit in a PI is critical for ARTs to align on what is needed and for teams to be able to plan.?
• Behavior-driven development (BDD)– BDD fosters collaboration between Product Management, Product Owners, and Agile Teams which clarifies requirements by adding acceptance criteria.?
• Economic prioritization– Features must be prioritized for development to be effective. The budget guardrails of capacity allocation, investment horizons, and continuous Business Owners engagement are critical in prioritization.?
• PI Planning – This is the culmination of the exploration work as the ART comes together to plan the next PI and gain alignment on what should be done in the next program increment.?

規(guī)模化敏捷框架中最關(guān)鍵的對(duì)齊活動(dòng)是項(xiàng)目群增量規(guī)劃。項(xiàng)目群增量規(guī)劃的輸入是一個(gè)產(chǎn)品愿景、一個(gè)產(chǎn)品路線圖和帶有優(yōu)先級(jí)排序的特性待辦列表。綜合子維度是關(guān)于準(zhǔn)備好這些內(nèi)容來進(jìn)行項(xiàng)目群增量規(guī)劃的。為此，需要六項(xiàng)技能:

• 構(gòu)建解決方案愿景——該愿景是團(tuán)隊(duì)理解為何開發(fā)該特性的基礎(chǔ)。
• 維護(hù)解決方案路線圖——解決方案路線圖為敏捷發(fā)布火車提供了對(duì)近期的展望。它有助于產(chǎn)品管理部門對(duì)工作進(jìn)行優(yōu)先級(jí)排序，使系統(tǒng)架構(gòu)師能夠?qū)Πl(fā)布軌道進(jìn)行優(yōu)先排序，并為業(yè)務(wù)責(zé)任人提供可視性。
• 編寫清晰的特性——定義符合項(xiàng)目群增量規(guī)劃的清晰特性，對(duì)于敏捷發(fā)布火車根據(jù)需求進(jìn)行調(diào)整和團(tuán)隊(duì)進(jìn)行規(guī)劃至關(guān)重要。
• 行為驅(qū)動(dòng)開發(fā)(BDD)——行為驅(qū)動(dòng)開發(fā)促進(jìn)產(chǎn)品管理、產(chǎn)品負(fù)責(zé)人和敏捷團(tuán)隊(duì)之間的協(xié)作，并通過增加可接受標(biāo)準(zhǔn)來闡明需求。
• 效益優(yōu)先級(jí)排序——特性必須經(jīng)過優(yōu)先級(jí)排序，開發(fā)才能有效。容量分配、投資范圍和業(yè)務(wù)負(fù)責(zé)人持續(xù)參與的預(yù)算護(hù)欄對(duì)于優(yōu)先排序至關(guān)重要。
• 項(xiàng)目群增量規(guī)劃——這是探索工作的高潮，因?yàn)槊艚莅l(fā)布火車集合在一起計(jì)劃下一個(gè)項(xiàng)目群增量，并就下一個(gè)項(xiàng)目群增量中應(yīng)該做什么達(dá)成共識(shí)。

When the ART is aligned with what needs to be built, the features move smoothly to the continuous integration segment of the continuous delivery pipeline. However, this does not mean that exploration is over. Feedback is constantly flowing back from developed, deployed, and released features. This feedback informs new decisions about what the ART should work on next and is integral to the CE process.

當(dāng)敏捷發(fā)布火車與需要構(gòu)建的內(nèi)容對(duì)齊時(shí)，這些特性會(huì)平穩(wěn)地轉(zhuǎn)移到持續(xù)交付流水線的持續(xù)集成區(qū)間。然而，這并不意味著探索工作已經(jīng)結(jié)束。研發(fā)、部署和已發(fā)布的特性中不斷有反饋提出來。這種反饋為敏捷發(fā)布火車下一步應(yīng)該做什么提供了新的決策，也是組成持續(xù)探索過程的一環(huán)。

后 記

在SAFe 最新發(fā)布的4.6版本中，與時(shí)俱進(jìn)，新增加了對(duì)企業(yè)DevOps能力的支持，因?yàn)閷?duì)于多團(tuán)隊(duì)協(xié)作而言，沒有持續(xù)交付DevOps的支撐，協(xié)作將會(huì)是非常痛苦的，發(fā)布速度也很難提升上去！所以，SAFe把“DevOps按需發(fā)布能力”作為精益企業(yè)的五大核心能力之一！

總結(jié)

以上是生活随笔為你收集整理的【干货】规模化敏捷DevOps四大实践之持续探索CE（中英对照版）的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。