セーフティのためのスクラム (Scrum for Safety)
鉄道などの安全重視（セーフティクリティカル）なソフトウェアの設計と開発に向けて、Barbareschi らが提案したスクラムの拡張手法（S4S）である。スクラムの役割に、スクラムが持たない独立した検証・妥当性確認の役割を足し、各スプリントで、適用される規格に照らして検証された新しいインクリメントを作る。この論文は手法の提案であり、効果を実証した研究ではない。
- アジャイルの中核原則とスクラムの価値基準に、安全重視ソフトウェアの要件から導いた目標を足した 8 つの原則を置く。すべての選択肢を網羅する、頻繁に実験して失敗する、ユーザーにソフトウェアを継続的に提供する、他の関係者と継続的に統合する、継続的に検証と妥当性確認を行う、作業の追跡可能性を確保する、リスクに基づくアプローチをとる、すでに達成した品質を損なわない、の 8 つである。
- 役割は、鉄道安全規格 CENELEC EN 50128 の役割と対応づけられる。プロダクトオーナー・スクラムマスター・開発チームは、要件管理者・設計者・実装者と対応する。スクラムには品質保証の独立した役割がないため、検証者・妥当性確認者・評定者（アセッサー）を足す。この 3 つの役割は、スクラムチームの外部の人員である。
- 同じスプリントの中で、同じ開発者が実装と検証の両方を担当することはできない。テストと統合の担当者は、ソフトウェアの設計に参加しない。
- 基本の単位はセーフスプリント（Safe-Sprint）で、適用される規格に照らして検証・妥当性確認された新しいインクリメントを作る、タイムボックスのイテレーションである。この概念は R-Scrum が先に導入したもので、S4S は開発者とテスターの独立性の徹底と、ドキュメント管理の実践的な方法を足した。ドキュメントはプロセスを牽引するものでなく、成果物として各セーフスプリントで更新される。
- 検証した事例は、イタリアの鉄道インフラ会社が出資した産業研究プロジェクト 1 件（鉄道信号システムのメッセージ指向ミドルウェア）である。SIL 4 の安全機能を含み、チームは大学の若手研究者で、プロダクトバックログは 126 件、セーフスプリントは 4 週間だった。
- 1 組織・1 プロジェクトで、著者らが提案した手法を自分たちの事例で検証した記述にとどまる。安全重視という限られた文脈の話で、一般のスクラムに広げて言えない[1]
- 所属タグ: Agile Safety-Critical Framework S4S
- カテゴリー: Related Fields
-
Scrum for safety: an agile methodology for safety-critical software systems — 「本稿では、安全性重視（セーフティクリティカル）領域、特に鉄道領域におけるソフトウェアコンポーネントの設計および開発を導き支援するのに適した、スクラムアジャイル手法の拡張であるS4Sを提案した。」（訳）（ライセンス: CC BY 4.0） ↩