摘要
敏捷開發(Agile Development)是一種以人為核心、迭代、循序漸進的開發方法。在敏捷開發中,產品/軟體開發專案的構建被切分成多個子專案,各個子專案的成果都經過測試,具備整合和可運行的特徵。換言之,就是把一個大專案分為多個相互聯繫,但也可獨立運行的小專案,並分別完成,在此過程中產品/軟體一直處於可使用狀態。ISO 9001 品質管理系統(QMS)是一套國際通用的品質管理工具,用以維持企業提供之產品與服務的品質,確保品質一致性。ISO 9001 條款可以直接對應到敏捷產品/軟體開發環境中的敏捷開發/Scrum 框架,如何對應呢?本文讓我們看看我們所遵循的 ISO 要求和相應的敏捷開發的實踐。
前言
品質管理系統(Quality Management System, QMS)可以最簡單的定義為組織的政策和程序。QMS 的組成部分將包括品質手冊,其中規定了組織的品質政策、品質程序或要求的實踐,以及有關如何執行這些實踐的工作指導或文件化的步驟。
隨著敏捷方法(Agile Approach)的飛速發展,一些開發人員感到 ISO 9001 和其他品質管理標準已變得無關緊要或不再需要。這種想法似乎是表明 ISO 9001 的流程與敏捷開發流程不兼容。我們的目標是表明,在現實中存在更多的聯合/融合/整合,而不是將這兩種策略分開,並且如果將它們組合在一起,兩者都會為產品開發專案帶來收益。
許多潛在客戶要求開發公司提供 ISO 證書,然後才能簽訂合約。這適用於政府機構和私人公司。主要原因是由 ISO 9001 認證建立的公認性。檢查公司是否擁有 ISO 9001 證書比檢查他們是否有良好的開發過程要容易得多。另外,有許多公司已經通過 ISO 9001 認證,並且希望保留其證書,同時又能夠進行敏捷開發(Agile Development)。協調敏捷開發和 ISO 9001 的構想可能幾乎與敏捷開發本身一樣古老。即使敏捷開發的發明者不認為這是一個問題,但仍有很多管理人員和品質管理人員如此認為。
敏捷開發過程(Agile Development)
敏捷產品/軟體開發是一種有組織的開發過程,強調直接的和頻繁溝通的方式-最好是面對面,頻繁交付工作產品/軟體增量,短期迭代,在整個開發生命週期中積極參與客戶以及改變響應能力,而不是避免變更。敏捷宣言中簡要描述了敏捷軟體開發的基本概念。敏捷軟體開發可以看作是一種哲學,並且正在使用基於這些思想的幾種定義的方法,所有這些方法都共享一組共同的價值觀和原則。
在敏捷框架(Scrum)中,我們主要負責三個角色:產品所有者(Product Owner)、敏捷教練(Scrum Master)和敏捷團隊(Scrum Team)。他們負責實施流程。ISO 還建議開發一個層次結構,以幫助提高整體過程性能(Process Performance)。
ISO 致力於持續改善;敏捷也同樣專注。ISO 建議規劃、實施、衡量和改善所有 QMS。敏捷開發專案還可以在類似的方面工作-衝刺規劃(Sprint Plan)、衝刺執行(Sprint Execution)、衝刺審查(Sprint Review)和衝刺回顧(Sprint Retrospective)。敏捷開發中使用的主要構造包括:
◆ 迭代(Iteration):在短時間內(2 - 4 週)進行分析、設計、開發和測試。在 Scrum 中,迭代稱為 Sprint(衝刺)。
◆ 產品待辦事項(Product Backlog):產品優先要求的清單。
◆ 衝刺或迭代待辦事項(Sprint or Iteration Backlog):從正在迭代開發的產品待辦事項中選擇項目(Items)。
◆ 衝刺審查(Sprint Review):與客戶合作對衝刺結果進行評估,以確定滿足的要求和需要進一步改進的要求。這也可以視為回顧(Retrospective)。因此,這裡的術語「審查」是指對正在開發的產品/軟體的審查。
◆ 衝刺規劃(Sprint Planning):在迭代或衝刺的開始階段完成,並導致衝刺待辦事項,其中的項目可以由當前的開發團隊在迭代的時間內(Timeframe) 總體上開發。
◆ 站立會議(Standup-meeting):每天的簡短會議,每一個團隊成員報告進度、計畫和問題。這可能包括產品和過程相關的問題。
與嚴格的瀑布模型(Water-fall Model)相比,敏捷過程在最初、每次迭代及最終確定中都涉及並吸引客戶。在每次迭代中,客戶與開發團隊合作進行需求規範(Requirements Specification)、知識轉移(Knowledge Transfer)和驗收測試(Acceptance Testing),見圖一所示的 V-Scrum 框架的敏捷開發過程。
敏捷產品/軟體開發背後的思想顯然是受敏捷和精實製造(Agile and Lean Manufacturing)的啟發而來的。 然而,需要進行一些重要的更改才能使這種思惟適合軟體的開發。應用精實開發(Lean Development)的最基本原則是減少浪費的原則:所有對產品/軟體開發沒有直接貢獻的工作和工作產品都應視為浪費,因此應避免或減少。
對敏捷方法的一種批評是故意避免使用文件,因為這可能被認為是浪費。文件不是軟體,軟體開發應開發的是軟體而不是文件。這是一個嚴格的概念,可能解釋了通常的看法,即敏捷軟體開發與眾所周知的品質管理標準(例如:ISO 9001)不兼容。但是,正如我們稍後將要說明的那樣,這不一定是正確的。
敏捷開發組織要如何導入 ISO 9001 品質管理系統呢?透過 ISO 9001 認證的組織要求(參見圖二)對其產品/軟體開發過程進行嚴格的展示,並在各種抽象級別上遵循一套準則。更具體地說,這些組織需要證明其敏捷產品/軟體開發過程的設計和實施方式允許達到符合 ISO 9001 要求的一定水平的配置和操作。因此,想要獲得 ISO 9001 認證的敏捷產品開發組織必須提供 ISO 9001 符合性的證據,並且他們需要開發自己的程序、工具和方法來做到這一點。最好的方法就是先了解敏捷框架與 ISO 9001 的對應關係,以建構符合 ISO 9001 的敏捷開發框架(程序、工具和方法等)。
品質管理系統如何適應敏捷實踐
品質管理系統(QMS)可以與諸如 ISO 之類的標準保持一致。ISO 9001 建議從品質手冊開始進行產品/軟體開發專案。這將確保並改善產品/軟體開發生命週期中的品質,並監控客戶滿意度。一旦有了描述產品/軟體開發過程的品質手冊,下一步就是實施它。基於 ISO 9001 品質手冊的產品品質實現將使用敏捷框架(Agile Framework)。
在最高層次上,ISO 9001 的要求總結如下:
◆ 公司必須有品質保證管理程序:第 4 部分。
◆ 產品的品質是管理層的責任:第 5 部分。因此,公司管理層必須為品質保證工作和培訓提供必要的資源:第 7 部分。
◆ 公司應該有一個或多個文件化的產品實現過程:第 7 部分。該過程必須產生可以 ① 審查接受和 ② 用作一致性證明的文件。
◆ 產品或過程的所有不合格報告都應該進行報告和分析,並應採取矯正措施:第 8 部分。
新版 ISO 9001 標準的根本變化就是提升營運敏捷力(Agility)。傳統思維得出的結論是,敏捷 (Agile)和 ISO 必定不兼容。畢竟,ISO 的特徵通常是過程繁重/文件繁重-恰與敏捷相反。就像敏捷幾乎沒有文件的錯誤假設一樣,即 ISO 需要成為一個繁重的過程/文件的假設也是錯誤的。ISO 9001 不僅與敏捷兼容,而且可以提供足夠的結構來幫助並確保您遵循敏捷流程(Agile Processes)。
ISO 條款對應到相應的敏捷實踐
下表將產品/軟體開發所需的所有 ISO 條款映射到相應的敏捷/Scrum 實踐。由對應表看出, 敏捷開發的步驟還是在 ISO 9001 品質管理系統中實施各項開發工作,而依據 ISO 9001 實施產品開發可以結合敏捷開發程序,以縮短產品上市時間並確保產品開發過程品質。
結語
ISO 9001 和敏捷方法之間的主要區別在於,ISO 9001 堅持要進行審查文件並證明過程的一致性。敏捷方法試圖避免對最終系統沒有幫助的軟體編寫或產品開發文件。另一方面,如果客戶需要特定的文件,則使用敏捷方法並不妨礙開發它們。
有多種方法可以處理 ISO 9001 要求的許多文件。我們可以添加諸如審查會議、編寫設計文件等活動。該流程仍將保留最重要的敏捷構想,例如短迭代、逐步增量(包括客戶),在需要時重新確定需求的優先級,並在專案合約的範圍內不斷調整範疇、時間和成本。
ISO 9001 品質管理系統和敏捷(Scrum)框架並不是兩回事。它們都試圖改善產品/軟體開發過程。一家想要使客戶滿意並提高品質的公司需要同時採用這兩種方法。融合這兩種方法的挑戰是,我們要如何協調敏捷開發對速度和精實開發的關注與 ISO 9001 對於文件、可追溯性和控制的要求。已經建立 ISO 9001 的公司可以直接應用敏捷框架於產品開發,以提升敏捷開發專案過程的品質及產品品質。
HOT 熱門文章
【企業驗證訊息】2022-05-11
【財稅專欄】2022-07-28
【專欄文章】2024-12-25
【國際標準新知】2024-12-05
【法律專欄】2024-12-05