今天看到一篇質(zhì)量內(nèi)建落地的實(shí)踐文章辖众，講了落地的三步法昏鹃，但從頭到尾沒看到什么是質(zhì)量內(nèi)建外冀？敏捷很火生闲，我們今天看下敏捷(SAFe)中怎么定義質(zhì)量內(nèi)建媳溺？
術(shù)語介紹：
SAFe(Scaled Agile Framework) 規(guī)模化敏捷架構(gòu)
Built-In Quality質(zhì)量內(nèi)建
Lean-Agile Mindset精益敏捷思維
Lean-UX精益用戶體驗(yàn)
Non-Functional Requirements (NFRs) 非功能需求
Continuous Delivery Pipeline(CDP)持續(xù)交付的流水線
質(zhì)量內(nèi)建
質(zhì)量內(nèi)建能保證每個(gè)增量解決方案滿足開發(fā)過程中的質(zhì)量標(biāo)準(zhǔn)碍讯。企業(yè)在最短的可持續(xù)交付周期內(nèi)是否能發(fā)布新功能和是否能適應(yīng)快速變化的企業(yè)環(huán)境悬蔽，取決于解決方案的質(zhì)量。
質(zhì)量內(nèi)建是SAFe的核心價(jià)值之一捉兴，同時(shí)也是敏捷宣言的原則之一蝎困。持續(xù)關(guān)注卓越的技術(shù)和良好的設(shè)計(jì)可增強(qiáng)敏捷性。質(zhì)量內(nèi)建也是精益敏捷思維的核心原則倍啥，有助于避免與召回禾乘、返工和修復(fù)缺陷相關(guān)的延遲成本 (CoD)。 SAFe質(zhì)量內(nèi)建的理念應(yīng)該應(yīng)用系統(tǒng)思維來優(yōu)化整個(gè)系統(tǒng)虽缕，確保整個(gè)開發(fā)價(jià)值流的快速流動始藕，讓質(zhì)量成為每個(gè)人的工作。
所有的團(tuán)隊(duì)氮趋，包括軟件伍派、硬件、運(yùn)營剩胁、產(chǎn)品營銷诉植、法律、安全倍踪、合規(guī)等系宫，共享質(zhì)量內(nèi)建的目標(biāo)和原則。但是建车，實(shí)踐因?qū)W科而異扩借，因?yàn)樗鼈兊漠a(chǎn)品不同。
SAFe以團(tuán)隊(duì)和產(chǎn)品的技術(shù)為中心的質(zhì)量內(nèi)建的五個(gè)方面：流缤至、架構(gòu)和設(shè)計(jì)質(zhì)量潮罪、代碼質(zhì)量、系統(tǒng)質(zhì)量领斥、發(fā)布質(zhì)量嫉到。基于業(yè)務(wù)的團(tuán)隊(duì)在質(zhì)量內(nèi)建實(shí)踐時(shí)月洛，可將參考這五個(gè)方面何恶。
建立流是所有團(tuán)隊(duì)基本的，因?yàn)樗枋隽巳绾蜗e(cuò)誤嚼黔，返工和其他降低吞吐量的浪費(fèi)细层。其他四個(gè)方面描述了適用不同領(lǐng)域的質(zhì)量內(nèi)建，包括測試為先唬涧、 自動化疫赎、 基于集合的設(shè)計(jì)探索替代方案碎节。
1. 通過測試為先和持續(xù)交付流水線實(shí)現(xiàn)流
敏捷團(tuán)隊(duì)在一個(gè)基于流的快速的系統(tǒng)中運(yùn)轉(zhuǎn)捧搞，可以開發(fā)和發(fā)布高質(zhì)量的業(yè)務(wù)能力狮荔。
敏捷團(tuán)隊(duì)不是在最后才進(jìn)行大多數(shù)測試轴合，而是盡早题涨、經(jīng)常和在多個(gè)維度上定義和執(zhí)行大多數(shù)測試总滩。
使用測試驅(qū)動開發(fā)TDD來定義代碼更改測試闰渔，使用行為驅(qū)動BDD來定義故事卡席函、特性和能力驗(yàn)收標(biāo)準(zhǔn)，使用精益用戶體驗(yàn)Lean-UX來定義特性收益假設(shè)冈涧。
質(zhì)量內(nèi)建可確保敏捷開發(fā)頻繁變更茂附，不會引入新錯(cuò)誤正蛙，以實(shí)現(xiàn)快速、可靠的執(zhí)行营曼。
1.1 以測試為先
敏捷團(tuán)隊(duì)為一切生成測試乒验，包括特性，故事卡和代碼等等蒂阱，理想情況下锻全，在創(chuàng)建事項(xiàng)之前或同時(shí)，或測試為先录煤。
測試為先的理念同時(shí)適用于功能需求(特性和故事卡)和非功能需求的性能和可靠性等鳄厌。一個(gè)測試為先的方法，通過開發(fā)生命周期中盡早創(chuàng)建測試的妈踊，來改善傳統(tǒng)的“V 模型” 了嚎。
為了支持更快的流，測試需要跑的更快响委，團(tuán)隊(duì)?wèi)?yīng)該努力使它們自動化新思。至今，大型的基于UI的端到端的測試比小型的自動的測試跑的更慢些赘风，我們期望平衡下測試用例，有大量小型快速的測試和少量慢的測試纵刘。
測試為先的理念創(chuàng)建一個(gè)平衡的測試金字塔邀窃。但不幸，很多組織機(jī)構(gòu)的測試不平衡假哎，有太多大量的慢的昂貴的測試和少量快速的性價(jià)比高的測試瞬捕。通過構(gòu)建大量代碼和故事卡測試，組織將減少對慢速的端到端的昂貴的測試的依賴舵抹。
1.2 構(gòu)建持續(xù)交付的流水線
質(zhì)量內(nèi)建實(shí)踐有助于構(gòu)建一個(gè)持續(xù)交付的流水線(CDP)和培養(yǎng)根據(jù)需求發(fā)布的能力肪虎。下圖展示了CDP的持續(xù)集成部分，展示了在未被產(chǎn)品集成前跨多個(gè)環(huán)境組件構(gòu)建的變更是如何測試的惧蛹。通過用更快扇救、性價(jià)比更高的代理（例如內(nèi)存數(shù)據(jù)庫代理）替換緩慢或昂貴的組件（例如企業(yè)數(shù)據(jù)庫）。
1.3 減少測試套件以加速反饋
隨著測試時(shí)間的推移而增長香嗓，它們將拖延敏捷團(tuán)隊(duì)迅腔。完整的測試套件可能需要很大的時(shí)間來設(shè)置和執(zhí)行。團(tuán)隊(duì)可以創(chuàng)建簡化的測試套件和測試數(shù)據(jù)(“冒煙測試”)靠娱，以確保最重要功能沧烈，在切換到其他流水線之前。他們與系統(tǒng)團(tuán)隊(duì)合作以平衡速度和質(zhì)量像云，并有助于確保流锌雀。
2. 架構(gòu)和設(shè)計(jì)質(zhì)量
系統(tǒng)的架構(gòu)和設(shè)計(jì)無疑決定了系統(tǒng)當(dāng)前支持的和將來業(yè)務(wù)的需要蚂夕。架構(gòu)和設(shè)計(jì)中的質(zhì)量將未來需求更容易實(shí)現(xiàn)，系統(tǒng)更容易測試腋逆，更能滿足非功能性特性婿牍。
2.1 支持未來業(yè)務(wù)的需要
隨著市場變化的需求，開發(fā)發(fā)現(xiàn)或其他原因闲礼，架構(gòu)和設(shè)計(jì)必須要解決牍汹。傳統(tǒng)流程中早期決策可能影響次優(yōu)選項(xiàng)，導(dǎo)致慢流或返工的低效率柬泽。識別最佳決策需要知識慎菲，通過實(shí)驗(yàn)，建模锨并，模擬露该，原型制作和其他學(xué)習(xí)活動獲得。它還需要一種基于集的設(shè)計(jì)方法第煮，從多種替代方案中找到最佳決策解幼。一旦確定，開發(fā)人員使用架構(gòu)跑道來實(shí)現(xiàn)最終決策包警。敏捷架構(gòu)為團(tuán)隊(duì)間的設(shè)計(jì)和實(shí)現(xiàn)同步提供指導(dǎo)撵摆。
2.2 設(shè)計(jì)質(zhì)量
隨著系統(tǒng)的需求發(fā)展，系統(tǒng)設(shè)計(jì)必須要支持需求害晦。低質(zhì)量的設(shè)計(jì)難以理解和修改特铝，影響到面臨多種困難的慢速的交付。應(yīng)用良好的耦合/凝聚和適當(dāng)?shù)某橄?封裝使實(shí)現(xiàn)更易于理解和修改壹瘟。SOLID原理使系統(tǒng)靈活具有彈性鲫剿，因此可以更輕松地支持新的需求。設(shè)計(jì)模式描述了解支持這些原則的知名方法稻轨，并提供一種簡化的語言灵莲，以便于理解和可讀性。 命名元素“工廠”或“服務(wù)”快速描述系統(tǒng)內(nèi)更廣泛的含義殴俱。
2.3 設(shè)計(jì)和架構(gòu)使測試容易
架構(gòu)和設(shè)計(jì)決定了系統(tǒng)的可測性政冻。通過定義好的接口進(jìn)行通信的模塊化組件創(chuàng)建接縫，允許測試人員和開發(fā)人員使用測試替身來代替昂貴的慢速的組件粱挡。
3. 代碼質(zhì)量
所有系統(tǒng)的功能最終都是由系統(tǒng)的代碼執(zhí)行起來的赠幕。添加新功能的速度和難易程度取決于開發(fā)人員對其進(jìn)行修改的速度和可靠性。受極限編程 (XP) 的啟發(fā)询筏，列出了幾種實(shí)踐榕堰。
3.1 單元測試和測試驅(qū)動開發(fā)
單元測試實(shí)踐將代碼劃分成段，并保證每一段可以自動測試。每個(gè)片段變更后會自動測試逆屡，開發(fā)人員可以快速修改并相信修改不會影響到系統(tǒng)中其它部分圾旨。測試同樣可以作為文檔，組件接口間可執(zhí)行的案例魏蔗，展示了組件怎樣使用的砍的。
測試驅(qū)動開發(fā)指導(dǎo)我們單元測試的創(chuàng)建，為變更點(diǎn)指明測試點(diǎn)莺治。這迫使開發(fā)人員在實(shí)施之前更廣泛地考慮問題廓鞠，包括邊緣情況和邊界條件。更好的理解導(dǎo)致更快的開發(fā)谣旁，更少的錯(cuò)誤和更少的返工床佳。
3.2 結(jié)對工作
結(jié)對將有兩個(gè)開發(fā)人員在同樣工作條件下做相同的變更。開發(fā)角色變換頻繁榄审。一個(gè)充當(dāng)編寫代碼的驅(qū)動程序砌们，而另一個(gè)充當(dāng)提供實(shí)時(shí)審查和反饋的導(dǎo)航器。 開發(fā)人員經(jīng)常轉(zhuǎn)換角色搁进。 結(jié)對創(chuàng)造和維護(hù)質(zhì)量浪感，因?yàn)榇a將包含每個(gè)成員的共享知識、觀點(diǎn)和最佳實(shí)踐饼问。 隨著隊(duì)友相互學(xué)習(xí)影兽，它還提高和拓寬了整個(gè)團(tuán)隊(duì)的技能組合。
3.3 集體所有和代碼標(biāo)準(zhǔn)
集體所有可以減少了團(tuán)隊(duì)之間的依賴關(guān)系莱革，并確保任何開發(fā)人員或團(tuán)隊(duì)都不會阻礙價(jià)值交付的快速流動赢笨。任何人都可以添加功能、修復(fù)錯(cuò)誤驮吱、改進(jìn)設(shè)計(jì)或重構(gòu)。因?yàn)榇a不是一個(gè)團(tuán)隊(duì)或個(gè)人所有萧吠，支持編碼標(biāo)準(zhǔn)鼓勵(lì)一致性左冬，以便每個(gè)人都可以理解和維護(hù)每個(gè)組件的質(zhì)量新娜。
4. 實(shí)現(xiàn)系統(tǒng)質(zhì)量
當(dāng)代碼質(zhì)量和設(shè)計(jì)質(zhì)量保證系統(tǒng)可以很容易理解和變更冯丙，系統(tǒng)質(zhì)量確保系統(tǒng)按期望操作，每個(gè)人對每次變更都都保持一致匕垫。下面是實(shí)現(xiàn)系統(tǒng)質(zhì)量的幾點(diǎn)建議狰腌。
4.1創(chuàng)建任務(wù)實(shí)現(xiàn)快速流
共享理解和一致理解將減少開發(fā)延遲和返工除破，以建立快速流程。行為驅(qū)動開發(fā) (BDD) 定義了一種協(xié)作實(shí)踐琼腔，產(chǎn)品負(fù)責(zé)人和團(tuán)隊(duì)成員對故事卡或特性的理解要達(dá)成一致瑰枫。BDD可以幫助開發(fā)人員在第一時(shí)間構(gòu)建正確并減少返工和錯(cuò)誤。基于模型的系統(tǒng)工程 (MBSE) 將這種對齊方式擴(kuò)展到整個(gè)系統(tǒng)光坝。通過分析和綜合過程尸诽，MBSE提供了系統(tǒng)所有功能的高級完整視圖，以及系統(tǒng)設(shè)計(jì)如何實(shí)現(xiàn)它盯另。
4.2 持續(xù)端到端的解決方案
擴(kuò)展敏捷性導(dǎo)致許多工程師進(jìn)行許多小更改性含，必須不斷檢查沖突和錯(cuò)誤。持續(xù)集成 (CI) 和持續(xù)交付 (CD) 實(shí)踐為開發(fā)人員提供快速反饋鸳惯。每個(gè)變更都會快速構(gòu)建商蕴，然后在多個(gè)級別進(jìn)行集成和測試，包括部署環(huán)境芝发。 CI/CD在所有階段將變更這一流程自動化绪商，并在測試失敗時(shí)如何做出響應(yīng)。NFR的質(zhì)量測試也是自動化的后德。 雖然 CI/CD努力使所有測試自動化部宿，但某些功能（探索性）和 NFR（可用性）測試只能手動執(zhí)行。
5. 發(fā)布質(zhì)量
產(chǎn)品發(fā)布允許企業(yè)衡量一個(gè)特性的收益假設(shè)的有效性瓢湃。一個(gè)組織發(fā)布的越快理张，學(xué)習(xí)的越快，交付的價(jià)值就越大绵患。組件之間定義了標(biāo)準(zhǔn)接口雾叭，這樣的模塊化架構(gòu)允許獨(dú)立發(fā)布更小的組件級變更。 較小的變更允許更快落蝙、更頻繁织狐、風(fēng)險(xiǎn)更低的發(fā)布，但需要自動化流水線來確保質(zhì)量筏勒。
與傳統(tǒng)的服務(wù)器基礎(chǔ)設(shè)施不同移迫，“不可變基礎(chǔ)設(shè)施”不允許手動和直接對生產(chǎn)服務(wù)器進(jìn)行變更。 相反管行，應(yīng)用于服務(wù)器鏡像的變更厨埋，啟動并替換當(dāng)前運(yùn)行的服務(wù)器。這種方法創(chuàng)建了更加一致捐顷、更可預(yù)測的發(fā)布荡陷。它允許自動恢復(fù)。如果操作環(huán)境檢測到生產(chǎn)錯(cuò)誤迅涮，它可以通過啟動先前的鏡像來替換錯(cuò)誤的鏡像來回滾版本废赞。
5.1 支持合規(guī)
對于必須要證明其合規(guī)或?qū)徲?jì)的系統(tǒng)，發(fā)布具有附加條件叮姑，即客觀證據(jù)唉地。這些組織必須證明該系統(tǒng)符合預(yù)期目的并且沒有意外的有害后果。如合規(guī)性文章所述，精益質(zhì)量管理體系 (QMS) 定義了支持精益敏捷渣蜗、基于流的持續(xù)集成-部署-發(fā)布流程的批準(zhǔn)實(shí)踐屠尊、政策和程序
5.2 完成的可擴(kuò)展定義
完成的定義是確保增值的一種重要方式。增量系統(tǒng)功能的持續(xù)開發(fā)需要對完成進(jìn)行可擴(kuò)展定義耕拷，以確保在正確的時(shí)間做正確的工作讼昆，有些是提前完成的，有些只是為了發(fā)布骚烧。每個(gè)團(tuán)隊(duì)浸赫、培訓(xùn)和企業(yè)都應(yīng)建立自己的定義。雖然每個(gè)團(tuán)隊(duì)的定義可能不同赃绊，但它們通常共享一組參數(shù)項(xiàng)的核心集合既峡。
參考資料
