鑽石舞台

我並不是故意要把 POC 和 Scrum 與低質量的軟件聯繫在一起，它們的流行確實令人生畏，但我們應該客觀地考慮構建高質量軟件涉及的所有因素。準確地說，POC 和 Scrum 並沒有本質上的缺陷會導致它們成為低質量軟件的促成因素，但經常會產生導致低質量軟件的副作用。

雖然它們不是唯一的因素，但正是因為它們本身並沒有缺陷，當我們意識到它們的副作用時，發現它們是最容易和最值得解決的因素之一，所以我們現在關注它們是有意義的。我們將在以後的文章中討論其他因素。

本文分為兩個主要部分：在第一部分中，我們將仔細研究什麼是質量以及如何量化它。如果你對定義不感興趣，可以直接跳到第二部分。在第二部分中，我們將討論 POC 和 Scrum 如何影響質量以及如何解決這些問題。

在本文的其餘部分，為了簡潔起見，我將把「高質量」稱為「質量（Quality）」，用了大寫的 Q。

質量不是對完美的無止盡追求。如果我們有量化質量的方法，就有可能實現我們的質量目標。在我看來，質量包含了三個層次，我們需要分別量化每一層。

人們普遍認為質量是「產品的可靠性」。正如古典科學所認為的，"可靠性"是指在相同的條件下持續得到相同結果的屬性。在這個經典的觀點中，構建質量解決方案意味着我們需要構建出永不失敗的產品。具有諷刺意味的是，以這種方式理解可靠性會損害質量，而不是提升質量。以構建永不失敗的產品為目標只會導致極其難以維護的複雜系統，導致質量隨着時間的推移而下降。經典的可靠性的問題在於錯誤地假設了我們可以控制所有的條件，而實際上我們並沒有（硬件故障、網絡延遲、外部服務節流，等等）。我們需要對可靠性的含義進行擴展，以適應條件不一致的情況：質量不僅是軟件產品啟動和運行時的可靠性度量，也是軟件產品發生故障時的可靠性度量。

要實現這一層次的質量，我們需要考慮兩種情況：對於解決方案的每個組件 / 服務，它們好的場景和最壞的場景是什麼。

要量化這一層次的質量，我們需要確定我們想要的可用性、恢復時間目標（Recovery Time Objective，RTO）和恢復點目標（Recovery Point Objective，RPO），這樣我們就能清楚地知道我們的系統能夠滿足的可接受範圍。

簡而言之：高可用性設計、優雅地失敗以及在可接受的範圍內實現第一層次的質量。

可靠性是質量的核心，但靠可靠性還不足以體現整個質量的概念。試想一下：如果你有兩台機器，它們具有完全相同的功能和可靠性指標，那麼機器越簡單質量就越好。

質量和性能指標可以一致，但它們不是同一個東西。隨着時間的推移，更簡單的產品更容易開發、操作和維護。

第二個層次的質量可以通過解決方案組件是否有可以由需求直觀解釋的目標來量化。在本文的第二部分中，我們將討論複雜性，並將為你提供如何讓你的項目變得更簡單的實用建議。我們先來完成質量的量化定義，我們還剩下一個層次要討論。

UI 可能會有一個裝飾層（顏色、字體等），視覺上的吸引力是很重要的，但我在這裡從一個更全面的角度來談論 UI——把 UI 看作是向用戶呈現產品功能的良好程度。你的產品可能是一組 API，那麼 UI 可能就是一個門戶，用戶可以在其中獲得示例請求 / 響應並測試端點。UI 也可以是一個命令行界面，或者被嵌入到用戶的系統中（如 Teams/Slack 等等），或者所有這些方法的組合。創建一個高質量的後端是一回事，以一種讓用戶能夠簡單有效使用功能的方式來表示後端功能是另一回事。優質的產品以用戶體驗為中心。

要在這一層構建高質量的產品，你要不斷訓練你的思維，從用戶的角度思考解決方案。記住，技術最終是為人類服務的。

你可以通過執行用戶測試來量化這一層，聚合併分析客戶滿意度驅動因素，並根據這些有形的結果衡量你的解決方案。

隨着時間的推移，複雜性會呈指數級增長，所以越早緩解它越好。如果仔細觀察一下，你會發現複雜性始於過早地將 POC 轉為開發管道。Scrum 的短 Sprint 通常會創造一種環境，有助於對不斷變化的需求（這些需求讓開發人員很難在項目過程中確定優先級並實現質量目標）做出反應。正如我在這篇文章的引言中提到的，這並不是 POC 和 Scrum 固有的，一旦意識到了，我們就可以解決這些問題。

POC（概念驗證）的主要目的是證明一個新想法在概念上是可能的。POC 與實現細節無關。一個人可以騎馬去辦公室，以此來證明它比開車節省時間，但即使這種 POC 是成功的，也並不意味着騎馬去辦公室是最好的方式或唯一的方式（更不用說驗證簡單性、用戶體驗或邊緣情況）。不過，這種 POC 的價值在於「提供了一種比開車更快到達辦公室的方法」，所以我們可以把這個概念提升到一個新的層次，尋找替代方案，並比較結果。

需要注意的是，將「尋找解決方案」的過程與「尋找最簡單的解決方案」的過程結合起來是違反直覺的。通常情況下，我們解決問題的第一次嘗試並不是解決問題的最簡單方法。看看你以前的 POC，你很可能會發現有「額外的連接」可以被移除。一個成功的 POC 並不意味着可以馬上開始開發，我們需要嘗試替代方案，在交付其中一個 POC 並進入下一階段之前嘗試多個 POC。

不過，證明「新穎的想法是可行的」並不是我們進行 POC 的唯一方法。POC 是學習 / 感受新技術的一種方法，其中的風險是我們可能在新技術上浪費了時間，然後在清理這些混亂之前進入開發階段。這就是經常出現「技術債務」的地方。

解決這個問題的辦法不是少一些混亂，實際上恰恰相反，我們需要更多混亂！很多時候，我們無法清理這些混亂，因為我們通常沒有足夠的時間去完全掌握新技術。基於開源代碼庫部署現有的解決方案，創建一個沙盒，這是一種很好的方式，但你應該繼續在沙盒中，直到能夠映射所有的結果和它們的原因，當你離開沙盒環境時，就可以移除任何不需要的部分。

「考慮替代方案和清理 / 簡化」階段有時是由開發人員（作為 POC 工作的一部分）完成的，但在快速交付的壓力下，這一階段往往被壓縮或跳過。考慮到當今大多數解決方案的複雜性，這個重要的階段變得勢在必行，因此是時候給它專門的時間，並將其作為項目生命周期的一部分。POC 必須經歷一個 PONC 階段，然後才能變成開發管道。

PONC（無複雜性驗證）是讓簡單性 / 質量走上正軌的護欄。在這個階段，你希望從 POC 轉向開發管道之前簡化並消除 POC 中的複雜性。

我在之前的一篇文章中已經寫過關於複雜性和簡單性的文章，當每個組件的目的很容易在與需求的聯繫中識別出來時，就實現了簡單性。當實現相對於需求來說太過複雜，複雜性（「非直觀的複雜性」）就出現了。PONC 旨在解決這兩個問題。

將 PONC 付諸實踐。

指定你的需求。把它們寫下來，與你的團隊分享，不要基於模糊的需求來解決問題，因為這可能會導致你解決不存在的問題。

考慮前面討論過的替代方案。比較結果，寫下你選擇這個實現而不是其他實現的原因 *。實現一個解決方案可能都會有幾種方法，特別是當涉及到雲的時候，前期的技術選擇是構建高質量軟件的最重要因素。

從 POC 中移除與需求不直接相關的內容。如果你只有基本需求（因為你還處於項目的開始階段），那就不要害怕移除所有與這些需求無關的內容，即使只剩下很少的內容。只要堅持好的原則（SOLID/12-factor），然後去掉其他的東西——你可以在需求變得清晰的時候再添加。

使用託管服務來減少基礎設施的責任。只要有可能，就向右移動，從 IaaS 到 PaaS，到無服務器，再到 SaaS。如果你做不到這一點，那就把阻礙你的技術障礙記錄下來。科技在不斷發展，這些障礙可能在未來會被消除，所以了解到底是什麼阻礙了你會很有用。「這是我們習慣的做法」並不是堅持 IaaS 的好理由。

如果你的解決方案可以從拆分服務中受益，那麼現在是時候這麼做了（例如，一些部分可以遷移成無服務器架構，一些可以遷移到 PaaS，另一些可以保留為 IaaS……等等）。

如果你正在重新實現一個現有的系統，請格外注意不要陷入「第二系統效應」（過度工程，因為你想要舊系統中擁有的所有功能。第二系統效應一詞在 Fred Brooks 的《人月神話》一書中首次出現）。清楚你想要實現什麼，這樣你就可以在一段時間內保持簡單性（像上面描述的那樣，指定需求總是很關鍵的）。

（* 當我提到你應該「寫下來」或「記錄」替代方案 / 結果時，我並不是說你應該寫三頁紙的文檔——一行重點突出的句子就足夠了，通常比一份很長的文檔更好。例如，你可以這樣寫：「我們選擇了一個 Web 應用程序，因為 Azure 函數不支持 Ruby」——如果將來你回頭來看你的解決方案，向看看早期的技術決策，並在當初的理由不再成立時需要做出修改，這些信息已經足夠了。）

即使在你認為你的 POC 不需要簡化的情況下，你仍然可以從與團隊進行「如果」這樣做而不是那樣做的 PONC 討論中受益。當你能夠清楚地說明為什麼一個解決方案不能進一步簡化時，它會讓你相信自己正在正確的軌道上。

讓我們來看看積極的方面——Scrum 將整個項目定義為「用戶項目」，這很好，因為它可以幫助我們實現第三個層次的質量。「用戶故事」不斷提醒我們要從用戶的角度來看待產品。

但消極面如下所述。

「無第零個 Sprint」的方式通常會導致開發者將他們混亂的 POC 變成 MVP。

教科書對第零個 Sprint 的描述似乎各不相同。一些 Scrum 教科書 /Scrum Master 反對第零個 Sprint，因為它違背了 Scrum 的基本前提，即「每個 Sprint 都應該產生一個價值」。其他的則採取更務實的方法，並接受第零個 Sprint（只要你將它稱為「啟動 Sprint」）。關於你是否可以 / 應該有第零個 Sprint，網上有一個很長的討論，但無論你的立場是什麼，在你清楚需求和了解所有潛在的解決方案之前，請不要急於着手解決問題。

事實上，我相信我們可以通過擴展我們對「價值」的看法（這裡的「價值」指的是 Scrum 規則中「每個 Sprint 都應該產生的價值」）來實現「第零個 Sprint」和「無第零個 Sprint」兩個目標。

你會驚訝地發現，通過向產品負責人展示你的早期工作成果能給 Scrum 團隊帶來多大的好處。儘早獲取他們的反饋不僅能讓你更接近他們的願景，還能讓開發團隊使用正確的業務術語，而不是每個人都使用自己的術語，因為這些術語對不同的開發人員來說可能意味着不同的東西。

將「價值」的範圍降到一個 MVP 或一件功能性產品，這對質量是有害的，因為這將迫使開發人員在有機會掌握所有需求之前過早地做出技術決策。當需求在隨後的 Sprint 中變得清晰時，改變這些早期的技術決策通常是非常困難的，這導致開發人員添加越來越多的變通方法來滿足需求，而不是通過使用正確的技術來解決它們。一開始缺少 MVP，然後在 Sprint 中進行修補，這樣只會導致糟糕的產品質量。如果質量是一個人，他 / 她會對在第一個 Sprint 就把一個混亂的 POC 變成最終部署到生產中的 MVP 感到驚恐。

（我想藉此機會邀請 Scrum 指南的創建者在他們的 Scrum 指南中闡明「價值」，加入可視化原型和架構構件，這些構件可以分享給產品所有者並收集他們的反饋。這將讓想要正確實現 Scrum 的開發人員變得輕鬆一些。）

最後，這裡有一些東西可能可以幫你駕馭「第零個 Sprint」，具體取決於你的項目 / 團隊的成熟度和項目交付的時間線。

在某些情況下，設計 Sprint 可以給你帶來很大的好處。雖然它們的結果不一定是可發布的（如 Scrum 所期望的），但在某些情況下，它們可以提供很多價值。

如果你在完成架構討論 /POC/PONC 之前必須創建一個 MVP，可以考慮創建一個（完全或部分）帶有模擬後端（例如使用 Azure APIM）的 MVP，這樣你就可以在後續改變後端技術，同時給產品所有者 / 測試人員機會接觸到具體的東西。

第三層對 Scrum 的關注給第一層和第二層帶來了違背質量的風險。

第一層和第二層的質量（想想災難恢復、保持簡單性，等等）就像其他非功能性需求（NFR）一樣，在緊急交付項目的壓力下，通常會被剝奪優先級。將 NFR 放在產品待辦事項列表中是一個很好的實踐（如果可能的話，還可以將其中一些放到你的「完成定義」中），這肯定會帶來透明度，並將極大地促進 Scrum 團隊對這些事項的討論。但你仍然面臨一個挑戰，你需要優先考慮實現這些事項。這說起來容易做起來難，尤其是在 Scrum 這樣的敏捷環境中。

敏捷的主要目標是將你從阻止你對變更做出響應的僵化的項目計劃中解放出來，這非常好，因為它保證你不會偏離利益相關者對其產品的設想。然而，變化是不可避免的，如果你不響應這些頻繁發生的變化，敏捷性的主要目標就會被削弱。其副作用是你將經常優先考慮這些變更，而不是質量相關的工作。當可能不會從每個單獨的 Sprint 中注意到它的反應性，但如果你把視野放大到整個項目，你會發現你處在一個反應性的環境中，在這個環境中，NFR 的優先級需要特別的關注才能被發現。沒有兩個 Scrum 團隊是相同的，所以我不知道是否有關於如何在各個層次上優先考慮質量的通用規則，但既然你已經意識到這一點，我相信你是在項目中優先考慮質量的最佳人選。

在本文中，我們討論了質量的三個層次以及如何量化每一層。較差的質量始於早期，在把 POC 變成開發管道之前，應該先進行 PONC。Scrum 幫助我們在第三層實現質量，但我們需要有一個策略，並在第一層和第二層特別關注質量的優先級。

作者簡介：

Alaa Tadmori 是微軟雲解決方案架構師。他是雲計算模型的早期採用者和愛好者。Alaa 相信我們今天構建的解決方案正在塑造我們的世界，而這也將是孩子們的世界，所以我們每天都有責任讓我們的世界變得更美好。不工作的時候，Alaa 喜歡和家人呆在一起，閱讀非小說類書籍。

原文鏈接：

https://www.infoq.com/articles/poc-scrum-quality/

相關閱讀：

我同情所有的 Scrum 團隊，因為他們經常被指導得死去活來

https://www.infoq.cn/article/Vd3rNRQjziCvDrxl93SC

一文搞懂 Scrum 中的工作量評估和預測

https://www.infoq.cn/article/6Z5T4MrjudHzLzgGJd0C

點擊底部閱讀原文訪問 InfoQ 官網，獲取更多精彩內容！