術(shù)語：SAFe(Scaled Agile Framework) 規(guī)模化敏捷架構(gòu)。
敏捷中的質(zhì)量內(nèi)建Built-In Quality
質(zhì)量內(nèi)建保證每個解決方案在增量解決方案時滿足開發(fā)過程中的質(zhì)量標準。企業(yè)在最短的可持續(xù)交付周期內(nèi)發(fā)布新功能并適應(yīng)快速變化的企業(yè)環(huán)境，取決于解決方案的質(zhì)量。
不用驚訝于質(zhì)量內(nèi)建是SAFe的核心價值之一，同時也是敏捷宣言的原則之一。持續(xù)關(guān)注技術(shù)卓越和良好的設(shè)計可增強敏捷性。質(zhì)量內(nèi)建也是精益敏捷思維的核心原則，有助于避免與召回、返工和修復缺陷相關(guān)的延遲成本 (CoD)。 SAFe質(zhì)量內(nèi)建的理念應(yīng)該使用用系統(tǒng)思維來優(yōu)化整個系統(tǒng)，確保整個開發(fā)價值流的快速流動，讓質(zhì)量成為每個人的工作。
所有的團隊，包括軟件、硬件、運營、產(chǎn)品營銷、法律、安全、合規(guī)等，共享質(zhì)量內(nèi)建的目標和原則。但是，實踐因?qū)W科而異，因為它們的產(chǎn)品不同。
SAFe以團隊和產(chǎn)品的技術(shù)為中心的質(zhì)量內(nèi)建的五個方面：Flow、架構(gòu)和設(shè)計質(zhì)量內(nèi)建Architecture & Design Quality、代碼質(zhì)量Code Quality、系統(tǒng)質(zhì)量System Quality 、發(fā)布質(zhì)量Release Quality?；跇I(yè)務(wù)的團隊在質(zhì)量內(nèi)建實踐時，可將參考這五個方面。
Establishing flow是所有團隊基本的，因為它描述了如何消除錯誤，返工和其他降低吞吐量的浪費。其他四個方面描述了適用不同領(lǐng)域的質(zhì)量內(nèi)建，包括測試為先test-first、 自動化automation、 基于集合的設(shè)計探索替代方案。
1. 通過測試為先和持續(xù)交付流水線實現(xiàn)流 Achieving Flow with Test-First? and a Continuous Delivery Pipeline
敏捷團隊在一個快速的、基于流的系統(tǒng)中運轉(zhuǎn)，可以快速開發(fā)和發(fā)布高質(zhì)量的業(yè)務(wù)能力。Agile teams operate in a fast, flow-based system to quickly develop and release high-quality business capabilities.
敏捷團隊不是在最后執(zhí)行大多數(shù)測試，而是盡早、經(jīng)常和在多個維度上定義和執(zhí)行大多數(shù)測試。Instead of performing most testing at? the end, Agile teams define and execute? many tests early, often, and at multiple? levels.?
使用測試驅(qū)動開發(fā)TDD來定義代碼更改測試，使用行為驅(qū)動BDD來定義故事卡、特性和能力驗收標準，使用Lean-UX定義特性收益假設(shè)。Tests are? defined for code? changes using Test-Driven Development , Story, Feature, and Capability acceptance criteria using Behavior-Driven Development (BDD), and Feature benefit hypothesis? using Lean-UX.
構(gòu)建質(zhì)量可確保頻繁更改的敏捷開發(fā)不會引入新錯誤并實現(xiàn)快速、可靠的執(zhí)行。Building in quality ensures that Agile? development’s frequent changes do not? introduce new errors and enables fast,? reliable execution.
1.1 以測試為先Think Test-First
敏捷團隊為一切生成測試，包括特性，故事卡和代碼(Features, Stories, and code)等等，理想情況下，在創(chuàng)建item之前或同時，或測試為先。
測試為先的理念同時適用于功能需求(特性和故事卡)和非功能需求的性能和可靠性等。通過開發(fā)生命周期中盡早創(chuàng)建測試的一個測試為先的方法來改善傳統(tǒng)的“V 模型” 。Test-first applies to both functional requirements (Feature and Stories) as well as non-functional requirements (NFRs) for performance, reliability, etc.? A test-first approach collapses the traditional “V-Model” by creating tests earlier in the development cycle。
為了支持更快的流，測試需要跑的更快，團隊努力使它們自動化。至今，大型的基于UI的端到端的測試比小型的自動測試跑的更慢些，我們期望平衡下測試用例，有大量小型快速的測試和少量慢的測試。To support fast flow, tests need to run quickly, and teams strive to automate them. Since larger, UI-based, end-to-end tests run much slower than small, automated tests, we desire a balanced testing portfolio with many small fast tests and fewer large slow tests.
測試為先的理念創(chuàng)建一個平衡的測試金字塔。但不幸，很多組織機構(gòu)的測試不平衡，有太多大量的慢的昂貴的測試和少量快速的性價比高的測試。通過構(gòu)建大量代碼和故事卡測試，組織將減少對慢速的端到端的昂貴的測試的依賴。Test-first thinking creates a balanced Testing Pyramid. Unfortunately, many organizations testing portfolios are unbalanced, with too many large, slow, expensive tests, and too few small, quick, cheap tests. By building large amounts of code and Story-level tests, organizations reduce their reliance on slower, end-to-end, expensive tests.
1.2 構(gòu)建持續(xù)的交付流水線Build a Continuous Delivery Pipeline
質(zhì)量內(nèi)建實踐有助于構(gòu)建一個持續(xù)的交付流水線(CDP：Continuous Delivery Pipeline)和培養(yǎng)根據(jù)需求發(fā)布的能力。下圖展示了CDP的持續(xù)集成部分，展示了在未被產(chǎn)品集成前跨多個環(huán)境都要測試組件構(gòu)建的變更。通過用更快、性價比更高的代理（例如內(nèi)存數(shù)據(jù)庫代理）替換緩慢或昂貴的組件（例如企業(yè)數(shù)據(jù)庫）。Built-in quality practices help create a Continuous Delivery Pipeline (CDP) and the ability to Release on Demand. Figure 5 illustrates the Continuous Integration portion of the CDP and shows how changes built into components are tested across multiple environments before arriving in production. ‘Test doubles’ speed testing by substituting slow or expensive components (e.g., enterprise database) with faster, cheaper proxies (e.g., in-memory database proxy).
1.3 減少測試套件以加速反饋Accelerate Feedback with Reduced Test? Suites
隨著測試時間的推移而增長，它們將延遲敏捷團隊。完整的測試套件可能需要很大的時間來設(shè)置和執(zhí)行。 團隊可以創(chuàng)建減少的測試套件和測試數(shù)據(jù)(“冒煙測試”)，以確保最重要功能，在切換到其他流水）線之前。 他們與系統(tǒng)團隊合作以平衡速度和質(zhì)量，并有助于確保流。As tests can grow over time, they delay Agile teams. Complete test suites can take significant time to set up and execute.? Teams may create reduced test suites and test data (a ‘smoke test’) to ensure the most important functionality before moving through other pipeline stages.? They collaborate with the System Team to balance speed and quality and help ensure flow.
2. 架構(gòu)和設(shè)計質(zhì)量Achieving? Architecture and Design Quality
系統(tǒng)的架構(gòu)和設(shè)計無疑決定了系統(tǒng)支持當前和將來的業(yè)務(wù)需要。架構(gòu)和設(shè)計中的質(zhì)量將未來需求更容易實現(xiàn)，系統(tǒng)更容易測試，更能滿足非功能性特性。A system’s architecture and design ultimately determine how well a system can support current and future business needs. Quality in architecture and design make future requirements easier to implement, systems easier to test, and helps to satisfy NFRs.
2.1 支持未來業(yè)務(wù)需要Support Future Business Needs
隨著市場變化的需求，開發(fā)發(fā)現(xiàn)或其他原因，架構(gòu)和設(shè)計必須要解決。傳統(tǒng)流程中早期決策可能影響次優(yōu)選項，導致慢流或返工的低效率。識別最佳決策需要知識，通過實驗，建模，模擬，原型制作和其他學習活動獲得。它還需要一種基于集的設(shè)計方法，從多種替代方案中找到最佳決策。一旦確定，開發(fā)人員使用架構(gòu)跑道來實現(xiàn)最終決策。敏捷架構(gòu)為團隊間的設(shè)計和實現(xiàn)同步提供指導。
2.2 設(shè)計質(zhì)量Design for Quality
隨著系統(tǒng)的需求發(fā)展，系統(tǒng)設(shè)計必須要支持需求。低質(zhì)量的設(shè)計難以理解和修改，影響到面臨多種困難的慢速的交付。應(yīng)用良好的耦合/凝聚和適當?shù)某橄?封裝使實現(xiàn)更易于理解和修改。SOLID原理使系統(tǒng)靈活具有彈性，因此可以更輕松地支持新的需求。設(shè)計模式描述了解支持這些原則的知名方法，并提供一種簡化的語言，以便于理解和可讀性。 命名元素“工廠”或“服務(wù)”快速描述系統(tǒng)內(nèi)更廣泛的含義。
Applying good coupling/cohesion and appropriate abstraction/encapsulation make implementations easier to understand and modify.?
2.3 設(shè)計和架構(gòu)使測試容易Architecting and Designing to Ease Testing
架構(gòu)和設(shè)計決定了系統(tǒng)的可測性。通過定義好的接口進行通信的模塊化組件創(chuàng)建接縫，允許測試人員和開發(fā)人員使用測試替身來代替昂貴的慢速的組件。Architecture and design also determine a system’s testability. Modular components that communicate through well-defined interfaces create seams that allow testers and developers to substitute expensive or slow components with test doubles.
3. 代碼質(zhì)量Achieving Code Quality
所有系統(tǒng)的功能最終都是由系統(tǒng)的代碼執(zhí)行起來提供的。添加新功能的速度和難易程度取決于開發(fā)人員對其進行修改的速度和可靠性。受極限編程 (XP) 的啟發(fā)，列出了幾種實踐。All system capabilities are ultimately executed by the code (or components) of a system. The speed and ease to add new capabilities depend on how quickly and reliably developers can modify it. Inspired in part by Extreme Programming (XP) [9], several practices are listed here.
3.1 單元測試和測試驅(qū)動開發(fā)Unit Testing and Test-Driven Development
單元測試實踐將代碼劃分成段，并保證每一段可以自動測試。每個片段變更后會自動測試，開發(fā)人員可以快速修改并相信修改不會影響到系統(tǒng)中其它部分。測試同樣可以作為文檔，組件接口間可執(zhí)行的案例，展示了組件怎樣使用的。The unit testing practice breaks the code into parts and ensures that each part has automated tests to exercise it. These tests run automatically after each change and allow developers to make fast changes, confident that the modification won’t break another part of the system. Tests also serve as documentation and are executable examples of interactions with a component’s interface to show how that component should be used.
測試驅(qū)動開發(fā)指導我們單元測試的創(chuàng)建，為變更點指明測試點。這迫使開發(fā)人員在實施之前更廣泛地考慮問題，包括邊緣情況和邊界條件。更好的理解導致更快的開發(fā)，更少的錯誤和更少的返工。 Test-Driven Development (TDD) guides the creation of unit tests by specifying the test for a change before creating it. This forces developers to think more broadly about the problem, including the edge cases and boundary conditions before implementation. Better understanding results in faster development with fewer errors and less rework.
3.2 結(jié)對工作Pair Work
結(jié)對將有兩個開發(fā)人員在同樣工作條件下做相同的變更。開發(fā)角色變換頻繁。一個充當編寫代碼的驅(qū)動程序，而另一個充當提供實時審查和反饋的導航器。 開發(fā)人員經(jīng)常轉(zhuǎn)換角色。 結(jié)對創(chuàng)造和維護質(zhì)量，因為代碼將包含每個成員的共享知識、觀點和最佳實踐。 隨著隊友相互學習，它還提高和拓寬了整個團隊的技能組合。
Pairing has two developers work the same change at the same workstation. One serves as the driver writing the code while the other as the navigator providing real-time review and feedback. Developers switch roles frequently. Pairing creates and maintains quality as the code will contain the shared knowledge, perspectives, and best practices from each member. It also raises and broadens the skillset for the entire team as teammates learn from each other.
3.3 集體所有和代碼標準Collective Ownership and Coding Standards
集體所有可以減少了團隊之間的依賴關(guān)系，并確保任何開發(fā)人員或團隊都不會阻礙價值交付的快速流動。任何人都可以添加功能、修復錯誤、改進設(shè)計或重構(gòu)。因為代碼不是一個團隊或個人所有，支持編碼標準鼓勵一致性，以便每個人都可以理解和維護每個組件的質(zhì)量。
Collective ownership reduces dependencies between teams and ensures that any individual developer or team will not block the fast flow of value delivery. Any individual can add functionality, fix errors, improve designs, or refactor. Because the code is not owned by one team or individual, supporting coding standards encourages consistency so that everyone can understand and maintain the quality of each component.
4. 實現(xiàn)系統(tǒng)質(zhì)量Achieving System Quality
當代碼質(zhì)量和設(shè)計質(zhì)量保證系統(tǒng)可以很容易理解和變更，系統(tǒng)質(zhì)量確保系統(tǒng)按期望操作，每個人對每次變更都都保持一致。下面是實現(xiàn)系統(tǒng)質(zhì)量的幾點建議。
While code and design quality ensure that system artifacts can be easily understood and changed, system quality confirms that the systems operate as expected and that everyone is aligned on what changes to make. Tips for achieving system quality are highlighted below.
4.1創(chuàng)建任務(wù)實現(xiàn)快速流Create Alignment to Achieve Fast Flow
共享理解和一致理解將減少開發(fā)延遲和返工，以建立快速流程。Alignment and shared understanding reduce developer delays and rework, enabling fast flow.
行為驅(qū)動開發(fā) (BDD) 定義了一種協(xié)作實踐，產(chǎn)品負責人和團隊成員對故事卡或特性的理解要達成一致。BDD可以幫助開發(fā)人員在第一時間構(gòu)建正確并減少返工和錯誤。基于模型的系統(tǒng)工程 (MBSE) 將這種對齊方式擴展到整個系統(tǒng)。通過分析和綜合過程，MBSE提供了系統(tǒng)所有功能的高級完整視圖，以及系統(tǒng)設(shè)計如何實現(xiàn)它。
Behavior-Driven Development (BDD) defines a collaborative practice where the Product Owner and team members agree on the precise behavior for a story or feature. Applying BDD helps developers build the right behavior the first time and reduces rework and errors. Model-Based Systems Engineering (MBSE) scales this alignment to the whole system. Through an analysis and synthesis process, MBSE provides a high-level, complete view of all the proposed functionality for a system, and how the system design realizes it.
4.2 持續(xù)端到端解決方案集成Continuously Integrate the End-to-End Solution
擴展敏捷性導致許多工程師進行許多小更改，必須不斷檢查沖突和錯誤。持續(xù)集成 (CI) 和持續(xù)交付 (CD) 實踐為開發(fā)人員提供快速反饋。每個變更都會快速構(gòu)建，然后在多個級別進行集成和測試，包括部署環(huán)境。 CI/CD在所有階段將變更這一流程自動化，并在測試失敗時如何做出響應(yīng)。NFR的質(zhì)量測試也是自動化的。 雖然 CI/CD努力使所有測試自動化，但某些功能（探索性）和 NFR（可用性）測試只能手動執(zhí)行。
Scaling agility results in many engineers making many small changes that must be continually checked for conflicts and errors. Continuous integration (CI) and continuous delivery (CD) practices provide developers with fast feedback (Figure 8). Each change is quickly built then integrated and tested at multiple levels, including the deployment environment. CI/CD automates the process to move changes across all stages and knows how to respond when a test fails. Quality tests for NFRs are also automated. While CI/CD strives to automate all tests, some functional (exploratory) and NFR (usability) testing can only be performed manually.
5. 發(fā)布質(zhì)量Achieving Release? Quality
產(chǎn)品發(fā)布時企業(yè)會衡量一個特性的收益假設(shè)有效性。一個組織發(fā)布的越快，學習的越快，交付的價值就越大。組件之間定義了標準接口，這樣的模塊化架構(gòu)允許獨立發(fā)布更小的組件級的變更。 較小的變更允許更快、更頻繁、風險更低的發(fā)布，但需要自動化流水線來保證質(zhì)量。
Releasing allows the business to measure the effectiveness of a Feature’s benefit hypothesis. The faster an organization releases, the faster it learns and the more value it delivers. Modular architectures that define standard interfaces between components allow smaller, component-level changes to be released independently. Smaller changes allow faster, more frequent, less risky releases, but require an automated pipeline (shown in Figure 2) to ensure quality.
與傳統(tǒng)的服務(wù)器基礎(chǔ)設(shè)施不同，“不可變基礎(chǔ)設(shè)施”不允許手動和直接對生產(chǎn)服務(wù)器進行變更。 相反，應(yīng)用于服務(wù)器鏡像的變更，驗證后啟動并替換當前運行的服務(wù)器。這種方法創(chuàng)建了更加一致、更可預測的發(fā)布。它允許自動恢復。如果操作環(huán)境檢測到生產(chǎn)錯誤，它可以通過啟動先前的鏡像來替換錯誤的鏡像來回滾版本。
Unlike a traditional server infrastructure, an ‘immutable infrastructure’ does not allow changes to made manually and directly to production servers. Instead, changes are applied to server images, validated, and then launched to replace currently running servers. This approach creates more consistent, predictable releases. It also allows for automated recovery. If the operational environment detects a production error, it can roll back the release by simply launching the previous image to replace the erroneous one.
5.1 支持合規(guī)Supporting Compliance
對于必須要證明其合規(guī)或?qū)徲嫷目陀^證據(jù)的系統(tǒng)，發(fā)布具有附加條件。這些組織必須證明該系統(tǒng)符合預期目的并且沒有意外的有害后果。 如合規(guī)性文章所述，精益質(zhì)量管理體系 (QMS) 定義了支持精益敏捷、基于流的持續(xù)集成-部署-發(fā)布流程的批準實踐、政策和程序
For systems that must demonstrate objective evidence for compliance or audit, releasing has additional conditions. These organizations must prove that the system meets its intended purpose and has no unintended, harmful consequences. As described in the Compliance article, Lean Quality Management System (QMS) defines approved practices, policies, and procedures that support a Lean-Agile, flow-based, continuous integrate-deploy-release process.
5.2 完成的可擴展定義Scalable Definition of Done
完成的定義是確保增值的一種重要方式。增量系統(tǒng)功能的持續(xù)開發(fā)需要對完成進行可擴展定義，以確保在正確的時間做正確的工作，有些是提前完成的，有些只是為了發(fā)布。 示例如表 1 所示，但每個團隊、培訓和企業(yè)都應(yīng)建立自己的定義。 雖然每個ART或團隊的可能不同，但它們通常共享一組參數(shù)項的核心集合。
Definition of Done is an important way of ensuring increment of value can be considered complete. The continuous development of incremental system functionality requires a scaled definition of done to ensure the right work is done at the right time, some early and some only for release. An example is shown in Table 1, but each team, train, and enterprise should build their own definition. While these may be different for each ART or team, they usually share a core set of items.
參考資料
