本文翻譯來自SAFe DevOps社群帥哥網友?
賈磊：高級質量經理&敏捷教練?
曾就職于外企、國企、大型上市企業等，擔任過測試工程師、測試經理、項目經理、敏捷教練、質量總監、高級質量經理等崗位。是一名敏捷變革的愛好者和踐行者。愛好網球、羽毛球。

正文

原文鏈接：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”

“具體來說，您可以花時間開發并提出一種由外向內、以市場為中心的觀點，這種觀點包含的信息如此豐富而又令人信服，以至于可以平衡掉去年運營計劃中由內向外以公司為中心的取向?！?/p>

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

?持續探索

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.?

持續探索是組成持續交付流水線的四個實踐模塊中的第一個要素，后面分別是持續集成(CI)、持續部署(CD)和按需發布(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.?

持續探索(CE)是通過持續探索市場和客戶需求，并為實現這些需求定義產品愿景、產品路線圖和一系列特性，來促進創新及構建必要一致性的過程。

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.?

在持續探索的過程中，新提出的想法經過提煉，成為Program Backlog中的按優先級排序的特性列表。它們在持續集成過程開頭的項目群增量規劃中被引入實施。此后，持續部署的循環會將這些特性引入生產，并在那里對它們進行驗證和發布準備。

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.

持續探索的輸入來自客戶、敏捷團隊、產品負責人、業務負責人和利益相關者，以及戰略投資組合的關注點。在產品和解決方案管理方向的指導下，研究和分析活動用于進一步定義和評估特性。這一過程的結果是一組輸出，包括產品愿景、為進一步實現而充分定義在待辦列表中的一組特性，以及這些特性將何時交付的產品路線圖預測。

?詳述

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.?

研發運維一體化和按需發布是精益企業的五大核心競爭力之一。它使企業能夠以最佳頻率向最終用戶提供越發有價值的解決方案。持續探索是這一過程不可或缺的一部分，它側重于在新機遇間取得一致性并定義所需構建的內容，同時理解所有這些想法都是需要驗證的假設。

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.?

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

持續探索的四個子維

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

規模化敏捷框架為連續探索描述了四個子維度，如圖1所示:?

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

圖1 - 持續探索的四個子維度

?

構建解決方案假設

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.?

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

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.)?

兩種能促進假設的特定技能：

• 精益創業思維——最小可行產品(MVP)的定義有助于在投資過多之前迅速對假設進行評估。最小可行產品是能用來評估假設是否有效的最小單元。
• 創新會計——評估假設需要不同于度量解決方案最終狀態所用的指標。創新會計關注于如何在最初的增量解決方案開發和最小可行產品評估過程中，度量假設的過程值并預測業務成果。(更多內容，請參閱文章《創新會計》。)

客戶協作與需求研究

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:?

為了構建一個令人矚目的差異化產品愿景，產品管理支持并促進了一個持續的協作過程，該過程從不同的利益相關方中征求意見，如圖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.?

• 系統架構師/工程師–系統架構師/工程師對實現解決方案有深入的技術知識儲備，并負責從系統層面理解它，以及它的“用例”和非功能性需求(NFRs)。雖然這些角色天然的被視作有技術和內部的傾向，但架構師在持續的客戶參與中也具有重要作用。?

• 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.”?

• 客戶——通過用錢包或腳投票，客戶是價值的最終評判者。他們是最明顯和最主要的信息輸入來源。但需要注意的是：客戶的動機通常與他們當前的解決方案環境緊密相關，所以他們提出的通常只是基于現有方案的不斷改進。換句話說：客戶輸入信息的總和并不能組成一個策略。然而，若不能滿足真實的和不斷發展的客戶需求，產品終將會消亡。所以找到一種平衡感很重要。正如規?；艚菘蚣苤械木婷艚菟季S模式所說，“生產者創新，客戶驗證?！?/p>

• 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.?

• 業務負責人和利益相關方——業務負責人具備設定產品使命和產品愿景所需的業務及市場知識。他們在整個研發過程中也有特定的職責。不符合他們期望的解決方案可能根本就不是解決方案。

• 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.

• 產品負責人和交付團隊——產品負責人和交付團隊在擁有一些該領域最重要的專業知識。在大多數情況下，他們研發了現有的解決方案，并且最關心技術和用戶問題。他們所輸入的信息是不可或缺的，也是無價的。

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

圖2 – 產品管理與多個利益相關方協作完善需求

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.?

六項有助于推動協作和研究的具體技能:?

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

?解決方案架構設計??

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.?

各級架構設計在理解架構如何驅動和啟動持續交付流水線方面發揮著重要作用，并且在指導敏捷團隊進行設計的過程中對此進行有力支持。五項支撐解決方案架構設計的技能:

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

同步產品愿景，產品路線圖以及項目群待辦工作列表??

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.?

規模化敏捷框架中最關鍵的對齊活動是項目群增量規劃。項目群增量規劃的輸入是一個產品愿景、一個產品路線圖和帶有優先級排序的特性待辦列表。綜合子維度是關于準備好這些內容來進行項目群增量規劃的。為此，需要六項技能:

• 構建解決方案愿景——該愿景是團隊理解為何開發該特性的基礎。
• 維護解決方案路線圖——解決方案路線圖為敏捷發布火車提供了對近期的展望。它有助于產品管理部門對工作進行優先級排序，使系統架構師能夠對發布軌道進行優先排序，并為業務責任人提供可視性。
• 編寫清晰的特性——定義符合項目群增量規劃的清晰特性，對于敏捷發布火車根據需求進行調整和團隊進行規劃至關重要。
• 行為驅動開發(BDD)——行為驅動開發促進產品管理、產品負責人和敏捷團隊之間的協作，并通過增加可接受標準來闡明需求。
• 效益優先級排序——特性必須經過優先級排序，開發才能有效。容量分配、投資范圍和業務負責人持續參與的預算護欄對于優先排序至關重要。
• 項目群增量規劃——這是探索工作的高潮，因為敏捷發布火車集合在一起計劃下一個項目群增量，并就下一個項目群增量中應該做什么達成共識。

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.

當敏捷發布火車與需要構建的內容對齊時，這些特性會平穩地轉移到持續交付流水線的持續集成區間。然而，這并不意味著探索工作已經結束。研發、部署和已發布的特性中不斷有反饋提出來。這種反饋為敏捷發布火車下一步應該做什么提供了新的決策，也是組成持續探索過程的一環。

后 記

在SAFe 最新發布的4.6版本中，與時俱進，新增加了對企業DevOps能力的支持，因為對于多團隊協作而言，沒有持續交付DevOps的支撐，協作將會是非常痛苦的，發布速度也很難提升上去！所以，SAFe把“DevOps按需發布能力”作為精益企業的五大核心能力之一！

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。