アジャイル開発と品質管理の関係
「アジャイル開発はMTTRを重視している」指摘を受けたのでメモ。
【元ネタ】
MSDN:可用性の概要
ソフトウェアやハードウェアの信頼性や可用性に関する用語として、MTBF・MTBR・稼働率などがある。
MTBF=稼働時間/稼動回数
MTBR=修理時間/故障回数
稼働率=MTBF/MTBF+MTBR
故障率=1/MTBF
MTTRは可用性、MTBFは信頼性・障害密度に密接に関係するのは周知の通り。
MTBFが大きいほど信頼性は高いが、ソフトウェアのMTBFは格段に小さいように思う。
SRATS:Software Reliability Assessment Tool on Spreadsheet Softwareのサンプルでも、MTBFはわずか16時間に過ぎない。
つまり、16時間後には必ず障害(バグ)が出る。
しかし、MTTRが「0」に近ければ、信頼性が低くても稼働率は100%に近くなる。
つまり、バグ修正工数が少ないほど、ユーザ側から見るとシステムはずっと稼動しているように見える。
アジャイル開発で、「開発の一番重要なファクターは時間である。平均バグ修正時間をみれば品質がわかる」という話を聞いた。
つまり、アジャイル開発ではMTTRを重視している、と。
確かにそうだろうと思う。
リファクタリング、テスト自動化、継続的インテグレーション等のプラクティスは、保守性を高めてソースを修正しやすくすることにつながる。
つまり、バグ修正工数と言うMTTRを短くすることにも注力していると言っていい。
Googleでも、サーバーは故障するものであり冗長化することに力点を置いているという話もある。
極論な話だが、HDDが1時間に1回壊れたとしても、予備のHDDにすぐに取替えできるならば、問題ないという考え。
つまり、MTBFが小さくてもMTTRがほぼ0ならば、実際のシステムの利便性は問題ない。
システム開発でもそうだ。
度重なる機能改善やバグ修正があったとしても、修正工数を小さくできる余裕があるならば、自信を持ってプログラミングできる。
つまり、保守性が高く、可読性の高いシステムならば、どんどん機能改善できる余裕が出てくる。
すなわち、アジャイル開発と相性がいい。
プログラミングの保守性を高くする為のノウハウがGoFのデザインパターンでもある。
マネジメントのノウハウとしては、イテレーションという単位にシステム開発を分割して、スコープを制御する事によって、システムの安全性と継続性を重視する選択肢も取れる。
アジャイル開発と品質管理の関係についても色々考えてみたい。
| 固定リンク
「プロジェクトマネジメント」カテゴリの記事
- チームトポロジーの感想~大規模アジャイル開発でも組織構造は大きく変化する(2025.01.01)
- 「スクラムの拡張による組織づくり」のScrum@Scaleの感想(2024.03.31)
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart2~プロセスのレイヤと達成目標のレイヤが異なる(2023.02.18)
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart1~CSFはWBSみたいなものと捉える(2023.02.14)
- PM理論では課業志向の方が関係志向よりも生産性が高いことを主張しているのではないか(2023.01.22)
「Redmine」カテゴリの記事
- Jiraの機能はTracに似ている気がする #redmine(2025.06.01)
- Redmineは組織のナレッジ基盤として実現可能なのか~島津製作所の事例を読み解く #redmineT(2024.12.29)
- 「RedmineのUbuntu+Docker構築への移行」の感想 #redmineT(2024.11.24)
- 第27回redmine.tokyo勉強会の感想 #redmineT(2024.11.10)
- Redmineのバージョン設定でプロジェクトの設定方法が違う(2024.06.23)
「ソフトウェア工学」カテゴリの記事
- Jiraの機能はTracに似ている気がする #redmine(2025.06.01)
- チームトポロジーの感想~大規模アジャイル開発でも組織構造は大きく変化する(2025.01.01)
- Redmineは組織のナレッジ基盤として実現可能なのか~島津製作所の事例を読み解く #redmineT(2024.12.29)
- アーキテクチャ設計はベストプラクティスを参照するプロセスに過ぎないのか?~Software Processes are Software, Too(ソフトウェアプロセスもまたソフトウェアである)(2024.09.22)
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
「チケット駆動開発」カテゴリの記事
- Jiraの機能はTracに似ている気がする #redmine(2025.06.01)
- Redmineは組織のナレッジ基盤として実現可能なのか~島津製作所の事例を読み解く #redmineT(2024.12.29)
- 第26回redmine.tokyo勉強会の感想~多様性はコミュニティが成功する重要な要因の一つ #redmineT(2024.06.15)
- チケットはデータでとプロセスの二面性を持つ #redmine(2023.12.24)
- 小説活動にプルリクエスト駆動が必要になってきた(2022.05.08)
「Agile」カテゴリの記事
- Jiraの機能はTracに似ている気がする #redmine(2025.06.01)
- チームトポロジーにおける4チームのインタラクションをUMLで整理してみた(2025.01.12)
- チームトポロジーの感想~大規模アジャイル開発でも組織構造は大きく変化する(2025.01.01)
- 「世界一流エンジニアの思考法」の感想(2024.12.08)
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
コメント