マイクロソフトのAgileの事例
マイクロソフトのAgileの事例の記事を見つけたのでメモ。
【元ネタ】
マイクロソフトにおけるアジャイル開発はこんな風に進められている - Publickey
Visual Studio 2005では当初の予定24ヶ月を大きくオーバーして39ヶ月もかかったらしい。
そこで、Visual Studio 2008の開発プロセスを根本的に変えたとのこと。
Redmineによるチケット駆動開発の経験から類推すると、下記のように置き換えられると思う。
フィーチャー単位の開発は、ユーザストーリー単位の開発と同じ。
進捗はタスクの達成率ではなく達成したユーザーストーリーの規模で測定するのは、ストーリーポイントと似ている。
「「クオリティゲート」を通過したもの以外、アクティブなブランチに統合してはならない」とは、メインラインモデルによる構成管理。
Yellow/Red Gameは、チケットの取捨選択。
進捗のためのチェックポイントはマイルストーンでもあり、リリース判定の場でもある。
面白いと思ったのは、一つは、組織がマトリックスモデルであること。
フィーチャーとロールによるマトリクス型組織。
多分、プロジェクトマネージャーの方がラインマネージャーよりも強いだろうから、プロジェクトを運営しやすく、柔軟に人員を配置しやすく、変化に強いはず。
普通の会社では、マトリクス型組織と言っても、事業部の権限が強く、プロジェクトマネージャーは与えられた範囲内でやり繰りするしかない。
もう一つは、柔軟なビュー。
これは、チケット集計機能を意味する。
バグダッシュボードは、日別のバグ発生数のグラフのようだ。
これを見れば、システムの品質が良いか誰でも分かる。
IBMやMSの商用のプロジェクト管理ツールは、集計や分析の機能が強いので、色んな観点でプロジェクトの現状を追跡できるのが強み。
できれば、Redmineもプラグインでチケット集計機能を強化して欲しい。
そうすれば、プロジェクトが自然に見える化するし、現場リーダーの意思決定が楽になる。
| 固定リンク
「ソフトウェア工学」カテゴリの記事
- 「ソフトウェアアーキテクチャ・ハードパーツ」の情報リンク~マイクロサービスの設計技法の課題は何なのか(2023.11.12)
- パッケージ原則とクラス原則の違いは何なのか(2023.10.14)
- パッケージ設計の原則の意義は変化しているのか(2023.09.30)
- QAエンジニアの役割は開発チームのガードレールみたいなものという考え方(2023.08.21)
- テストアーキテクチャ設計モデルとJSTQB概念モデルの比較(2023.07.02)
「Agile」カテゴリの記事
- 概念モデリングや設計原則は進化しているのか(2023.10.21)
- パッケージ設計の原則の意義は変化しているのか(2023.09.30)
- 日本のアジャイル開発の先人による話が良かった(2023.07.15)
- JSTQBのテストプロセスの概念モデルを描いてみた(2023.05.26)
- PM理論では課業志向の方が関係志向よりも生産性が高いことを主張しているのではないか(2023.01.22)
コメント