贾磊：高级质量经理&敏捷教练
曾就职于外企、国企、大型上市企业等，担任过测试工程师、测试经理、项目经理、敏捷教练、质量总监、高级质量经理等岗位。是一名敏捷变革的爱好者和践行者。爱好网球、羽毛球。
正文
原文链接：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”
“具体来说，您可以花时间开发并提出一种由外向内、以市场为中心的观点，这种观点包含的信息如此丰富而又令人信服，以至于可以平衡掉去年运营计划中由内向外以公司为中心的取向。”
-- 杰弗里·摩尔，《逃逸速度》
持续探索
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.”
- 客户——通过用钱包或脚投票，客户是价值的最终评判者。他们是最明显和最主要的信息输入来源。但需要注意的是：客户的动机通常与他们当前的解决方案环境紧密相关，所以他们提出的通常只是基于现有方案的不断改进。换句话说：客户输入信息的总和并不能组成一个策略。然而，若不能满足真实的和不断发展的客户需求，产品终将会消亡。所以找到一种平衡感很重要。正如规模化敏捷框架中的精益敏捷思维模式所说，“生产者创新，客户验证。”
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按需发布能力”作为精益企业的五大核心能力之一！
