檢驗不能提高質(zhì)量，也不能保證質(zhì)量。檢查太遲了。產(chǎn)品的質(zhì)量，無論好壞，都已經(jīng)存在。產(chǎn)品或服務(wù)的質(zhì)量不能檢驗;它必須融入其中?！?/p>
- w。愛德華茲·戴明
內(nèi)置的質(zhì)量實踐確保每個解決方案元素在每個增量中都符合整個開發(fā)過程中的適當質(zhì)量標準。
企業(yè)能否以最短的可持續(xù)交付時間交付新功能，并適應(yīng)快速變化的業(yè)務(wù)環(huán)境，取決于解決方案的質(zhì)量。因此，內(nèi)置的質(zhì)量是安全的核心價值之一，也是敏捷宣言“持續(xù)關(guān)注技術(shù)卓越性和良好的設(shè)計增強敏捷性”的原則之一，這一點也不奇怪。內(nèi)置的質(zhì)量也是精益敏捷思維的核心原則，有助于避免與召回、返工和修復(fù)缺陷相關(guān)的延遲成本(CoDs)。外管局的內(nèi)在品質(zhì)理念，運用系統(tǒng)思維，優(yōu)化整個系統(tǒng)，確保整個價值流的快速流動，讓品質(zhì)成為每個人的工作。
軟件和硬件共享內(nèi)置質(zhì)量的目標和原則。然而，硬件的工作物理和經(jīng)濟學(xué)有些不同。本文將討論這兩個問題。
企業(yè)必須不斷地對市場變化作出反應(yīng)。建立在穩(wěn)定技術(shù)基礎(chǔ)上的軟件和系統(tǒng)更容易更改和適應(yīng)。對于大型解決方案，這甚至更為關(guān)鍵，因為即使是小缺陷和錯誤假設(shè)的累積效應(yīng)也可能產(chǎn)生不可接受的結(jié)果。
構(gòu)建高質(zhì)量的系統(tǒng)是一項嚴肅的工作，需要持續(xù)的培訓(xùn)和承諾，但業(yè)務(wù)利益需要投資:
更高的客戶滿意度
提高了速度和交付的可預(yù)測性
更好的系統(tǒng)性能
改進了創(chuàng)新、擴展和滿足法規(guī)遵循需求的能力
圖1說明了內(nèi)置質(zhì)量的五個維度。首先，流說明了一個事實，即內(nèi)置質(zhì)量是實現(xiàn)連續(xù)值流狀態(tài)的必要條件。另外四個描述了應(yīng)用于系統(tǒng)本身的質(zhì)量。下面將討論每個維度。
圖1所示。內(nèi)置質(zhì)量的五個維度
通過連續(xù)的輸送管道和測試優(yōu)先來實現(xiàn)流程
內(nèi)置的質(zhì)量使安全的連續(xù)輸送管道和能力釋放的需求。圖2演示了SAFe的DevOps雷達的持續(xù)集成部分，并展示了如何在進入生產(chǎn)之前跨多個環(huán)境測試內(nèi)建組件的更改。通過用更快的代理(如內(nèi)存中的數(shù)據(jù)庫代理)替換慢速或昂貴的組件(如企業(yè)數(shù)據(jù)庫)，“測試加倍”速度測試。
圖2。連續(xù)的輸送管道確保了產(chǎn)品出廠前的質(zhì)量
為了支持管道的測試需求，組織必須在開發(fā)周期的早期將測試左移。作為規(guī)范的一部分，每個系統(tǒng)行為—故事、特性、功能、非功能需求(NFR)—都包括自動化測試。這種測試優(yōu)先的方法允許團隊盡早并持續(xù)地應(yīng)用質(zhì)量實踐，以及為管道創(chuàng)建一組豐富的測試。
本文的其余部分將討論內(nèi)置質(zhì)量體系結(jié)構(gòu)和設(shè)計、代碼、系統(tǒng)和發(fā)布的其他四個維度。
內(nèi)置質(zhì)量從體系結(jié)構(gòu)和設(shè)計開始，這最終決定了系統(tǒng)能夠多好地支持當前和未來的業(yè)務(wù)需求。體系結(jié)構(gòu)和設(shè)計中的質(zhì)量使未來的需求更容易實現(xiàn)，系統(tǒng)更容易測試，并有助于滿足NFRs。
支持未來的業(yè)務(wù)需求
隨著需求基于市場變化、開發(fā)發(fā)現(xiàn)和其他原因的發(fā)展，架構(gòu)和設(shè)計也必須發(fā)展。傳統(tǒng)過程迫使早期的決策常常導(dǎo)致兩個糟糕的選擇，要么重新工作以更改決策，要么忍受次優(yōu)決策的低效。確定最佳決策需要通過實驗、建模、仿真、原型化和其他學(xué)習活動獲得知識。它還需要一種基于集的設(shè)計方法來評估多個備選方案，以獲得最佳決策。一旦確定了，開發(fā)人員就使用架構(gòu)跑道來實現(xiàn)最終的決策。敏捷架構(gòu)為團隊間的設(shè)計和實現(xiàn)同步提供了有意的指導(dǎo)。
幾個設(shè)計特性是良好質(zhì)量的預(yù)測器，確保工件是可理解和可維護的，包括高內(nèi)聚和低耦合、良好的抽象和封裝、可讀性和關(guān)注點分離。堅實的[2]原則創(chuàng)造了這些特點的設(shè)計。
架構(gòu)和設(shè)計以簡化測試
體系結(jié)構(gòu)和設(shè)計也決定了系統(tǒng)的可測試性。通過定義良好的接口進行通信的模塊組件包含seam[3]，它允許測試人員和開發(fā)人員用測試替身替換昂貴或緩慢的組件。例如，圖3顯示了一個速度控制器組件，需要從GPS位置組件獲得當前車輛位置來調(diào)整其速度。測試帶有GPS定位的速度控制器需要相關(guān)的GPS硬件和信號發(fā)生器來復(fù)制GPS衛(wèi)星。將這種復(fù)雜性替換為測試加倍，可以減少開發(fā)和測試速度控制器或任何與GPS定位接口的其他組件的時間和精力。
圖3。模塊組件創(chuàng)建接縫以簡化測試
將設(shè)計質(zhì)量應(yīng)用于網(wǎng)絡(luò)物理系統(tǒng)
這些設(shè)計原則也適用于網(wǎng)絡(luò)物理系統(tǒng)。許多學(xué)科的工程師使用建模和仿真來獲得設(shè)計知識。例如，集成電路(IC)設(shè)計技術(shù)(VHDL, Verilog)是類似軟件的，并且從這些設(shè)計特性和堅實的原理[4]中共享相同的好處。硬件設(shè)計還應(yīng)用了通過模擬和模型進行測試的概念，或者在切割金屬之前提供木材原型。
這通常需要改變心態(tài)。和軟件一樣，硬件也會發(fā)生變化。通過構(gòu)建質(zhì)量來規(guī)劃未來的變化，而不是根據(jù)當前的需求進行優(yōu)化來完成設(shè)計，從而提供更好的長期結(jié)果。
實現(xiàn)代碼質(zhì)量
所有系統(tǒng)功能最終都由系統(tǒng)的代碼(或組件)執(zhí)行。添加新功能的速度和容易程度取決于開發(fā)人員修改新功能的速度和可靠程度。受極限編程(XP)[5]的啟發(fā)，這里列出了一些實踐。
單元測試和測試驅(qū)動開發(fā)
單元測試實踐將代碼分解為多個部分，并確保每個部分都有自動化測試來執(zhí)行它。這些測試在每次更改后自動運行，允許開發(fā)人員快速地進行更改，并確信修改不會破壞系統(tǒng)的其他部分。測試還充當文檔，并且是與組件接口交互的可執(zhí)行示例，以顯示應(yīng)該如何使用該組件。
測試驅(qū)動開發(fā)(TDD)通過在創(chuàng)建變更之前指定變更的測試來指導(dǎo)單元測試的創(chuàng)建。這迫使開發(fā)人員更廣泛地考慮問題，包括實現(xiàn)之前的邊界用例和邊界條件。更好的理解導(dǎo)致更快的開發(fā)，更少的錯誤和更少的返工。
結(jié)伴工作
結(jié)對讓兩個開發(fā)人員在同一工作站上進行相同的更改。一個充當編寫代碼的驅(qū)動程序，另一個充當提供實時評審和反饋的導(dǎo)航器。開發(fā)人員頻繁地轉(zhuǎn)換角色。結(jié)對創(chuàng)建并維護質(zhì)量，因為代碼將包含來自每個成員的共享知識、觀點和最佳實踐。當隊友們互相學(xué)習時，它也能提高和擴大整個團隊的技能。
集體所有權(quán)和編碼標準
集體所有權(quán)減少了團隊之間的依賴關(guān)系，并確保任何一個開發(fā)人員或團隊都不會阻礙快速的價值交付流。作為更改的一部分，“任何開發(fā)人員都可以更改任何代碼行來添加功能、修復(fù)bug、改進設(shè)計或重構(gòu)。因為代碼不是由一個團隊或個人擁有的，所以支持編碼標準可以促進一致性，這樣每個人都可以理解并維護每個組件的質(zhì)量。
在網(wǎng)絡(luò)物理系統(tǒng)中應(yīng)用代碼質(zhì)量
雖然并非所有硬件設(shè)計都有“代碼”，但物理構(gòu)件的創(chuàng)建是一個協(xié)作過程，可以從這些實踐中獲益。用于硬件開發(fā)的計算機輔助設(shè)計(CAD)工具以斷言的形式為電子設(shè)計提供“單元測試”，然后在機械設(shè)計中進行模擬和分析。切分、集體所有權(quán)和編碼標準可以產(chǎn)生類似的好處，從而創(chuàng)建更容易維護和修改的設(shè)計。
一些硬件設(shè)計技術(shù)非常類似于代碼(例如VHDL)，具有明確定義的輸入和輸出，非常適合TDD[4]之類的實踐。
實現(xiàn)系統(tǒng)質(zhì)量
雖然代碼和設(shè)計質(zhì)量確?？梢暂p松理解和更改系統(tǒng)構(gòu)件，但是系統(tǒng)質(zhì)量確認系統(tǒng)按預(yù)期工作，并且每個人都對要做的更改保持一致。下面重點介紹實現(xiàn)系統(tǒng)質(zhì)量的技巧。
創(chuàng)建對齊以實現(xiàn)快速流
對齊和共享理解減少了開發(fā)人員的延遲和返工，從而支持快速流。行為驅(qū)動開發(fā)(BDD)定義了一種協(xié)作實踐，在這種實踐中，產(chǎn)品所有者和開發(fā)團隊就故事或特性的精確行為達成一致。應(yīng)用BDD可以幫助開發(fā)人員在第一時間構(gòu)建正確的行為，并減少返工和錯誤?；谀Ｐ偷南到y(tǒng)工程(MBSE)將這種對齊擴展到整個系統(tǒng)。通過一個分析和綜合過程，MBSE提供了一個高層次的、完整的視圖，展示了系統(tǒng)的所有建議功能，以及系統(tǒng)設(shè)計如何實現(xiàn)這些功能。
持續(xù)集成端到端解決方案
如圖2所示，持續(xù)集成(CI)和持續(xù)部署(CD)為開發(fā)人員提供了對更改的快速反饋。每個變更都是快速構(gòu)建的，然后在多個級別進行集成和測試，包括在部署環(huán)境中。CI/CD自動將更改移動到各個階段，并在測試失敗時做出響應(yīng)。NFRs的質(zhì)量測試也是自動化的。當CI/CD努力使所有測試自動化時，一些功能性(探索性)和NFR(可用性)測試只能手工執(zhí)行。
將系統(tǒng)質(zhì)量應(yīng)用于網(wǎng)絡(luò)物理系統(tǒng)
網(wǎng)絡(luò)物理系統(tǒng)還可以支持快速流、CI/CD方法——即使物理部件的交付時間很長。如前所述，仿真、模型、以前的硬件版本和其他代理可以替代最終的系統(tǒng)組件。圖4展示了一個系統(tǒng)團隊，該團隊提供了一個可演示的平臺，通過連接這些組件代理來測試增量行為。隨著每個組件的成熟(通過增加紅色來顯示)，端到端集成平臺也會成熟。使用這種方法，組件團隊將負責支持其最終解決方案的一部分，以及成熟的增量端到端測試平臺。
圖4。網(wǎng)絡(luò)物理系統(tǒng)的持續(xù)集成(CI)
實現(xiàn)發(fā)布質(zhì)量
發(fā)布允許業(yè)務(wù)度量特性的效益假設(shè)的有效性。一個組織發(fā)布得越快，它學(xué)習得就越快，提供的價值也就越多。定義組件間標準接口的模塊化體系結(jié)構(gòu)允許獨立地發(fā)布較小的組件級更改。較小的更改允許更快、更頻繁、風險更小的版本，但是需要一個自動化的管道(如圖2所示)來確保質(zhì)量。
與傳統(tǒng)的服務(wù)器基礎(chǔ)設(shè)施不同，“不可變的基礎(chǔ)設(shè)施”不允許手動或直接對生產(chǎn)服務(wù)器進行更改。相反，更改應(yīng)用于服務(wù)器映像，經(jīng)過驗證，然后啟動，以替換當前運行的服務(wù)器。這種方法創(chuàng)建了更一致、更可預(yù)測的版本。它還允許自動恢復(fù)。如果操作環(huán)境檢測到一個生產(chǎn)錯誤，它可以通過簡單地啟動前一個映像來替換錯誤的映像來回滾發(fā)布。
支持合規(guī)
對于必須為遵從性或?qū)徲嬜C明客觀證據(jù)的系統(tǒng)，發(fā)布還有其他條件。這些組織必須證明該系統(tǒng)符合其預(yù)期目的，并且沒有意外的、有害的后果。如法規(guī)遵循文章所述，精益質(zhì)量管理系統(tǒng)(QMS)定義了經(jīng)過批準的實踐、策略和過程，這些實踐、策略和過程支持精益敏捷的、基于流程的、持續(xù)的集成部署發(fā)布過程。
完成的可伸縮定義
“已完成”的定義是保證增值能夠被認為是完整的重要方法。增量系統(tǒng)功能的持續(xù)開發(fā)需要對已完成的工作進行縮放定義，以確保在正確的時間完成正確的工作，有些是早期的，有些只是為了發(fā)布。表1顯示了一個示例，但是每個團隊、培訓(xùn)和企業(yè)都應(yīng)該構(gòu)建自己的定義。雖然對于每個藝術(shù)或團隊來說這些可能是不同的，但它們通常共享一組核心項目。
表1。示例安全可伸縮的完成定義
在網(wǎng)絡(luò)物理系統(tǒng)中實現(xiàn)發(fā)布質(zhì)量
對于發(fā)布質(zhì)量的看法是不要讓變更閑置，等待集成。相反，要快速且頻繁地通過系統(tǒng)的較大部分集成更改，直到更改到達驗證環(huán)境為止。一些網(wǎng)絡(luò)物理系統(tǒng)可以在客戶環(huán)境中驗證(例如，車輛的空中更新)。其他人使用一個或多個模型代理該環(huán)境，這些模型努力獲得早期反饋，如圖4所示。端到端平臺會隨著時間的推移而成熟，提供更高的保真度，從而支持更早的驗證和驗證(V&V)以及遵從性工作。對于許多系統(tǒng)，早期的V&V和遵從性反饋對于理解發(fā)布能力是至關(guān)重要的。
敏捷軟件開發(fā)的[1]宣言。www.AgileManifesto.org。
[2] Robert Martin，《OOD的原則》，http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod
Michael， [3] Feathers，《使用遺留代碼進行有效測試》，Prentice Hall, 2005。
《VHDL的有效編碼原理與最佳實踐》，麻省理工學(xué)院出版社，2016年。
《極限編程解釋:擁抱變化》，Addison-Wesley, 1999。
[6]www.extremeprogramming.org/rules/collective.html
原文：https://www.scaledagileframework.com/built-in-quality/
本文：https://pub.intelligentx.net/safe-built-quality
