sakata_akinori さんに "アジャイル開発は品質が悪い" という言説、統計的品質管理、ウォーターフォールで利用されるバグ密度などの指標の有効性、代用特性などについて語っていただいたエピソードです。
- JaSST Tokyo 2022 アジャイルソフトウェア開発への統計的品質管理の応用
- 書籍: エクストリームプログラミング
- 「アジャイル開発は品質が悪い？」という風評・言説
- この言説はどこからやってきたのか？なぜ生まれたのか？
- ハイブリッドアジャイル、ハイブリッドウォーターフォール、ウォータースクラムフォール
- コードの複雑性をマネジメントできない状態
- マネジメントプロセスの原因はどこにあるのか？
- 絶対イヤだ or 偉くなる
- バグ密度曲線などの指標は、どこからきて、何がしたかったのか？
- 品質指標は、いつもと同じかどうかを見ていただけ
- メインフレーム や COBOL
- いつもと同じかどうか、を見るのは過去において意味があったのではないか
- ウォーターフォールのメトリクスはコストに由来しているのではないか
- 2022年において、いつもと同じかどうかを見る手法は意味があるのか？
- 統計的品質管理の考え方自体は現代でも有効
- アジャイル開発では、何を指標として追えばいいのか？
- スピードに着目したメトリクス
- リードタイム、サイクルタイム
- 審議プロセスにおける納得感とは？
- そもそもリスクを小さくしている、ということで納得する
- 常に上限値におさまるというのは統計的にありえない
- 代用特性とは？ と 温度計での例
- ソフトウェアにおける品質特性(国際規格ISO/IEC 9126)
- 狩野モデル
- "品質は誰かにとっての価値である" / ワインバーグ
- SQuBOK
- ホーソン実験
- 魅了的品質をどう高めていくか？
See Privacy Policy at https://art19.com/privacy and California Privacy Notice at https://art19.com/privacy#do-not-sell-my-info.
