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.
46:12
コメント
スクロール