プロセス・エンアクトメント
Rational Team Concertの記事があったのでメモ。
【元ネタ】
Eclipseの開発手法を受け継いだ 分散アジャイル開発のためのプラクティス(1/4):CodeZine
はじめて使うJazz (2) ― プロジェクトのリリース計画・反復計画・タスク実行(1/8):CodeZine
Rational Team ConcertはIBMが作ったアジャイル開発を支援する製品。
IBMと言えば、RUPのように、反復開発というよりもウォーターフォール型開発っぽいプロセスをやっていると思っていた。
この製品を使えば、Eclipseプラットフォームで、アジャイル開発を実践できるみたい。
興味を惹いたのは下記の2つの記事。
はじめて使うJazz (5) ― プロセス・エンアクトメント(1/6):CodeZine
(前略)
ソフトウエア開発のプロジェクトにおいて「誰が、何をして、何を作成する」といった定義は開発プロセスと呼んでいます。通常プロジェクトを運用するためにさらにこれらに付随する「うまくいくための経験則」や、やってはいけない「べからず集」も含まれていることが多いものです。
こうしたプロセスを、それを定義しただけの単なる読み物ではなく実質的な効力を持たせるようにすることをJazzでは、「プロセス・エンアクトメント(Process Enactment)」と呼びます。つまり、Jazzが狙っているのはツールがプロセス・エンアクトメントを実現し、開発者が自然とプロセスに従うようにするというものです。
(後略)
「プロセス・エンアクトメント(Process Enactment)」という言葉は初めて知ったけれど、感覚は分かる。
RedmineやTestLinkの機能に慣れると、プロジェクト管理やテスト管理はこういう風に実践するのがベストプラクティスなのだ、と分かってくる。
何故なら、OSSであるRedmineやTestLinkのそれらの機能は、世界中の開発者が実践してみて、より良いプロセスを実現するための機能であるからだ。
だから、自分たちの開発プロセスをツールに当てはめるよりも、一度頭を空にして、ツールがスムーズに使えるように運用した方が良いと思う。
そうすれば、自然にベストプラクティスが身に付く。
ツールがプロセスを改善してくれるのだ。
はじめて使うJazz (6) ― ダッシュボードでリアルタイムにプロジェクトの状況を見える化(1/4):CodeZine
(前略)
ダッシュボードと聞いてすぐに思いつくのは車のダッシュボードでしょう。車を運転するために必要な各種情報が集められています。車のスピード、エンジンの回転数、ガソリンタンクの残量、走行距離、各種警告灯などです。例えば、ガソリンの残量があとどのくらいかを判断して、運転者はどのタイミングでガソリンスタンドに行くかを判断することができます。ここに表示される情報はリアルタイムの情報です。当たり前のことですが、運転者はこのデータが正しくまさに今のガソリンの残量を示しているから正しい判断ができるのです。もし、ダッシュボードに表示されるガソリンの残量が1日前のものだったらどうなるでしょうか?ダッシュボードではまだ残量があることが示されていますが、実際には既に残量がなく、ガス欠で車が止まってしまうという事態になってしまうでしょう。
これをソフトウェア開発の現場に置き換えてみると、プロジェクト・マネージャが定期的にプロジェクトの状況を経営層やお客様に報告してさまざまな判断がされています。そのためにプロジェクトのメンバーが自分の作業をまとめてプロジェクト・マネージャに報告し、プロジェクト・マネージャがそれらを集計、グラフ化などを行うといったことが行われていると思います。これらの報告までの作業が1週間かかるとすると、1週間前の状況に対して判断することになります。これでは、プロジェクトがガス欠で止まってしまうという事態が起こる可能性があるかもしれません。
(後略)
PFでは「見える化」を実現するために三つのツールが用意されている。
それは、かんばん、ダッシュボード、あんどん。
ダッシュボードで良く出る例はバーンダウンチャート。
バーンダウンチャートを見れば、プロジェクトの進捗や今後の進捗も予測できる。
上記のように、ダッシュボードなどのツールは、プロジェクトの状態を計測する計測器。
車の運転席には速度メーター、ガソリンメーター、走行距離など各種計測器があり、ドライバーはそれを見ながら車の状況を把握する。
同様にプロジェクトも計測器が必要だ。
PMBOKの言うPMISは、単にプロジェクトのインプットとアウトプットを管理するシステムだけでなく、プロジェクトの状況を見える化するためのツールであるべきだ。
プロジェクトを見える化して、問題がどこにあるか分かれば、人は自然に解決の方向へ動き出す。
問題を解決しようと言う積極的な力は、人間に本来備わっているのだ。
ファシリテーションは、人間に本来備わっている能力を引き出すためのツール。
PF(プロジェクトファシリテーション)は、ITプロジェクトに特化したファシリテーションなので、アジャイル開発にも相性がいい。
ツールがプロセスもプロジェクトも改善してくれるきっかけを作り出してくれる。
| 固定リンク
「プロジェクトマネジメント」カテゴリの記事
- チームトポロジーの感想~大規模アジャイル開発でも組織構造は大きく変化する(2025.01.01)
- 「スクラムの拡張による組織づくり」のScrum@Scaleの感想(2024.03.31)
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart2~プロセスのレイヤと達成目標のレイヤが異なる(2023.02.18)
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart1~CSFはWBSみたいなものと捉える(2023.02.14)
- PM理論では課業志向の方が関係志向よりも生産性が高いことを主張しているのではないか(2023.01.22)
「ソフトウェア工学」カテゴリの記事
- チームトポロジーの感想~大規模アジャイル開発でも組織構造は大きく変化する(2025.01.01)
- Redmineは組織のナレッジ基盤として実現可能なのか~島津製作所の事例を読み解く #redmineT(2024.12.29)
- アーキテクチャ設計はベストプラクティスを参照するプロセスに過ぎないのか?~Software Processes are Software, Too(ソフトウェアプロセスもまたソフトウェアである)(2024.09.22)
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
- 「システムアーキテクチャ構築の原理」の感想(2024.05.06)
「プロジェクトファシリテーション」カテゴリの記事
- PM理論では課業志向の方が関係志向よりも生産性が高いことを主張しているのではないか(2023.01.22)
- 「世界を動かすプロジェクトマネジメントの教科書」の概念図(2022.01.16)
- 【資料公開】チケット駆動開発の解説~タスク管理からプロセス改善へ #redmine(2022.01.14)
- 昭和の管理者の承認処理は判子押印、令和の管理者の承認処理はいいねボタンを押すこと(2021.12.31)
- チケット駆動開発のプロセスとチケット管理システムの全体像 #Redmine(2021.12.28)
コメント