アジャイルソフトウェアマネジメント
@papandaさんが「アジャイルソフトウェアマネジメント」を読んでいると聞いて、ネット上で検索した結果をリンクしておく。
ラフなメモ書き。
【元ネタ】
制約理論を読みほどく - @IT情報マネジメント
日々是感謝: アジャイルソフトウェアマネジメントを考える - その①
日々是感謝: アジャイルソフトウェアマネジメントを考える - その②
日々是感謝: アジャイルソフトウェアマネジメントを考える - その③
日々是感謝: アジャイルソフトウェアマネジメントを考える - その④
日々是感謝: アジャイルソフトウェアマネジメントを考える - その⑤
日々是感謝: アジャイルソフトウェアマネジメントを考える - その⑥
日々是感謝: アジャイルソフトウェアマネジメントを考える - その⑦
日々是感謝: アジャイルソフトウェアマネジメントを考える - その⑧
日々是感謝: アジャイルソフトウェアマネジメントを考える - その⑨
日々是感謝: アジャイルソフトウェアマネジメントを考える - その⑩
制約理論を読みほどく - @IT情報マネジメントを読むと、TOCで出てくるリソースごとのスケジュールのボトルネックを探す手法を使って、ソフトウェア開発プロセスをバリューチェーンとみなして分析するやり方みたい。
バリューチェーンは、リーンソフトウェア開発のバリューストリームマップと同等だろう。
すると、どの工程で待ち時間が多くて、価値を生み出す時間が短くなっているのかを探すことができる。
ScrumやXPの分析では、スプリントないしイテレーションによるタイムボックス開発がそれらのボトルネックを小さくする意味があることが書かれている。
でも、FDD(フィーチャ駆動開発)がお勧めと言う。
多分その意味は、日々是感謝: アジャイルソフトウェアマネジメントを考える - その⑩に書かれている「プロダクト指向」「フィーチャ指向」という考え方から来ているのだろう。
(引用開始)
そして、アジャイルソフトウェア生産システムによる、望ましい適応性のある振る舞いとは、”顧客にとって価値がある正常に機能するコード”で示されるのです。
でした。
これは、アジャイルソフトウェアマネジメントが、完全にプロダクト志向であることを意味しています。
昨日、私はこのように述べました。
でもクライアントにとって重要なのは、時間とコストを費やしたという結果ではなく、クライアントにとって必要なソフトウェア(プロダクト)が、どれだけのスコープでどこまでの品質を確保してデリバリされたかということ。
つまり顧客にとって意味を持つのは、顧客にとって価値がある正常に機能するコード、でしかないのです。そして、顧客にとって価値があるとは、顧客の要求を満たしているものに他なりません。
よってアジャイルソフトウェアマネジメントにおいては、”顧客の要求=フィーチャー”がすべてのベースラインとなるのです。従って、フィーチャー駆動型開発であるべきなのです。
だからアジャイルソフトウェアマネジメントは、完全に顧客志向の、よってプロダクト(成果物)志向の、フィーチャー駆動型の、さらに言い換えると品質駆動型のアプローチなのです。
品質とは誰かにとっての価値である。
ワインバーグ
(引用終了)
もう少し調べてみる。
| 固定リンク
「プロジェクトマネジメント」カテゴリの記事
- 「スクラムの拡張による組織づくり」のScrum@Scaleの感想(2024.03.31)
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart2~プロセスのレイヤと達成目標のレイヤが異なる(2023.02.18)
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart1~CSFはWBSみたいなものと捉える(2023.02.14)
- PM理論では課業志向の方が関係志向よりも生産性が高いことを主張しているのではないか(2023.01.22)
- 現代日本人の弱点はリーダーシップ不足と生産性が著しく低いこと、そしてリスク許容度が著しく低いことだ(2022.12.23)
「Agile」カテゴリの記事
- 「世界一流エンジニアの思考法」の感想(2024.12.08)
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
- 「スクラムの拡張による組織づくり」のScrum@Scaleの感想(2024.03.31)
- ソフトウェア工学の根本問題から最近のソフトウェア設計を考えてみる(2024.03.03)
- 「GitLabに学ぶ 世界最先端のリモート組織のつくりかた」の感想(2023.12.10)
コメント