マイクロソフトのAgileの事例
マイクロソフトのAgileの事例の記事を見つけたのでメモ。
【元ネタ】
マイクロソフトにおけるアジャイル開発はこんな風に進められている - Publickey
Visual Studio 2005では当初の予定24ヶ月を大きくオーバーして39ヶ月もかかったらしい。
そこで、Visual Studio 2008の開発プロセスを根本的に変えたとのこと。
Redmineによるチケット駆動開発の経験から類推すると、下記のように置き換えられると思う。
フィーチャー単位の開発は、ユーザストーリー単位の開発と同じ。
進捗はタスクの達成率ではなく達成したユーザーストーリーの規模で測定するのは、ストーリーポイントと似ている。
「「クオリティゲート」を通過したもの以外、アクティブなブランチに統合してはならない」とは、メインラインモデルによる構成管理。
Yellow/Red Gameは、チケットの取捨選択。
進捗のためのチェックポイントはマイルストーンでもあり、リリース判定の場でもある。
面白いと思ったのは、一つは、組織がマトリックスモデルであること。
フィーチャーとロールによるマトリクス型組織。
多分、プロジェクトマネージャーの方がラインマネージャーよりも強いだろうから、プロジェクトを運営しやすく、柔軟に人員を配置しやすく、変化に強いはず。
普通の会社では、マトリクス型組織と言っても、事業部の権限が強く、プロジェクトマネージャーは与えられた範囲内でやり繰りするしかない。
もう一つは、柔軟なビュー。
これは、チケット集計機能を意味する。
バグダッシュボードは、日別のバグ発生数のグラフのようだ。
これを見れば、システムの品質が良いか誰でも分かる。
IBMやMSの商用のプロジェクト管理ツールは、集計や分析の機能が強いので、色んな観点でプロジェクトの現状を追跡できるのが強み。
できれば、Redmineもプラグインでチケット集計機能を強化して欲しい。
そうすれば、プロジェクトが自然に見える化するし、現場リーダーの意思決定が楽になる。
| 固定リンク
「ソフトウェア工学」カテゴリの記事
- アーキテクチャ設計はベストプラクティスを参照するプロセスに過ぎないのか?~Software Processes are Software, Too(ソフトウェアプロセスもまたソフトウェアである)(2024.09.22)
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
- 「システムアーキテクチャ構築の原理」の感想(2024.05.06)
- ソフトウェア工学の根本問題から最近のソフトウェア設計を考えてみる(2024.03.03)
- マイクロサービス設計は従来のアーキテクチャ設計と何が違うのか(2024.01.02)
「Agile」カテゴリの記事
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
- 「スクラムの拡張による組織づくり」のScrum@Scaleの感想(2024.03.31)
- ソフトウェア工学の根本問題から最近のソフトウェア設計を考えてみる(2024.03.03)
- 「GitLabに学ぶ 世界最先端のリモート組織のつくりかた」の感想(2023.12.10)
- 概念モデリングや設計原則は進化しているのか(2023.10.21)
コメント