GDS Digital Service Manual 中文翻譯網站 (beta)
by HPX-GOV 英國政府數位服務研究小組 GDS Study Group

品質 (Quality)

如何定義、測量和維護品質

如果想要人們使用並喜愛您的服務,務必把品質當成專案的最前線。

品質是團隊中每個成員的責任-打造出服務的人便打造了該服務的品質。從增進服務品質到修復程式錯誤,專案中每個人都會參與其中。

品質的定義

對團隊中每位成員,品質代表的意義都不同。基本上,品質一詞代表了該服務的使用者從開始使用到結束為止的體驗,其中可能包括:

  • 對於使用者(盡可能多數的),透種不同設備使用服務的無障礙性
  • 與該服務互動的容易程度
  • 服務提供者能快速提供適當協助的能力
  • 儲存和處理資料的方式是否適當並安全
  • 基礎設施以及必要軟體的強韌度和安全性
  • 確保服務的程式碼已經通過完整的測試
  • 同時服務大量使用者時,能否快速反應(負載測試)
  • 在處理異常大量的流量時,能否迅速進行規模調整
  • 團隊能夠快速新增或修改功能的能力,以反映需求或環境的改變

對技術債的注意事項

「技術債」這個詞彙常見於軟體開發領域,然而其定義多有不同。一般而言,技術債是指,為了及時完成一項產品的開發而犧牲品質、對時程妥協,而非建立起一個技術上乾淨、可延伸的設計。這些妥協意味著即使產品看起來整體已經完成,背後仍然還有許多工作要做。

開發軟體時,要完全沒有技術債是不可能的事,因此請確定你的所有團隊成員對系統中的技術債有共同的認識。

欠下大量的技術債將拖慢未來的發展。請瞭解你已有多少技術債,並且透過安排工作優先順序來減少技術債,如此在將來便可繼續快速的迭代下去。

優良品質人人有責

服務品質不是單靠測試就能確保的,也不是少數人的責任。系統的品質,是由創造出系統的人來定義。

團隊中的成員應能看出系統的品質是否有問題。參與專案的每個人都應該採取行動,以增進系統品質和修復問題。

測試

如果沒有測試過的話(包含在一般狀況和特殊狀況之下),你便無從得知你的產品有多好,或產品是否切合需求。

Dylan Robert 的書“Learning From First Responders”值得一讀,其中提供了很好的例子說明在測試軟體和團隊面臨不正常壓力時會發生什麼狀況。(該書描寫2012年總統大選的最後階段)

本手冊提供了更多關於測試的資訊:

團隊角色和品質確保專家

對任何數位服務而言,確保品質都是整個團隊的責任,但負起最終責任的則是服務經理人。

請確保你的服務經理人與其他團隊成員共同工作。否則你會讓團隊不知道該做什麼來確保品質。

你的團隊在撰寫使用者故事時,就該把服務品質考慮進去,並且可以把時間與資源用於:

  • 測試正在打造中的產品
  • 打造基礎建設,因此可以定期測試關於無障礙性的假設
  • 花些時間考量服務發生錯誤的情況,以及如何回應

利用特殊的技能和工具是一個很好的方式來確保測試的周全,通常被使用於:

  • 滲透測試 – 讓團隊以外的人來進行這項工作,可以從不同角度挑戰先前的假設並找出系統弱點,提供有價值的外部觀點
  • 聘雇品質確保專家 – 他們可以確保所有與品質相關的活動都協調進行,還能藉由下列活動,讓你的團隊獲得打造高品質服務所需的訓練與資源:
    • 擁有明確的職權範圍,並與你的團隊協同工作,將建立品質融入造到他們所進行的一切活動當中,而非僅僅在開發流程當中加上一場品質檢驗關卡而已
    • 作為一個短期的角色,讓你的團隊得以將品質管理當作標準開發程序以及服務迭代的一部份
  1. 資訊,並評估其安全水平、法律責任以及相關風險(當情況適合時可諮詢專家)。相關指南;

  2. 評估隱私風險,以確保個人資訊蒐集的要求是適當的。相關指南:

  3. 評估哪些工具和系統會用於構建、存放、營運和衡量服務,以及如何採購這些系統。相關指南:

  4. 利用指南中敏捷、迭代和使用者中心的方法去建立服務。相關指南:

譯者:
校稿:
原始出處:https://www.gov.uk/service-manual/agile/quality

請留言

你的email信箱不會被發布出來. Required fields are marked *

*

這個網站採用 Akismet 服務減少垃圾留言。進一步瞭解 Akismet 如何處理網站訪客的留言資料