 |
||||||||||||||
|
||||||||||||||
| 前のページ 1 2 3 | ||||||||||||||
|
||||||||||||||
| プロジェクトファシリテータ | ||||||||||||||
|
アジャイル開発では、ソフトウェア開発の方法や手順の選択を開発者本人にまかせます。このことにより、開発者は自由に自己の裁量でソフトウェアを開発することができるようになります。しかし、プロジェクト全体の進捗の管理や運営までを担うとなると大きな負担となり、ソフトウェア開発作業へ影響を与えてしまいます。 そこで、プロジェクトを円滑に運営するために、アジャイル開発の導入の際にはXPのコーチやScrumのスクラムマスタやプロジェクトファシリテータなどと呼ばれるチームを円滑に運営していく専任者（以下、プロジェクトファシリテータ）を設けることをお勧めします。 プロジェクトファシリテータは、リーダやマネージャのような要素も持ち合わせていますが、リーダのような牽引者的な役割よりも「場を作り維持していく役割」を担っています。プロジェクトファシリテータは、開発されるソフトウェアよりもプロジェクトが円滑に進められているかどいうことに注力します。プロジェクトファシリテータには開発とファシリテーションを兼任させずに、専任させることが必要です。  図2：リーダとファシリテータ |
||||||||||||||
| チームへの導入 | ||||||||||||||
|
アジャイル開発をはじめてチームに導入する場合を考えてみましょう。 アジャイル開発を実施したことのないチームに導入した場合、一通りの問題を経験し、改善を繰り返して学習し慣れて軌道に乗るまでには多くの時間を必要とします。プロジェクトマネージャやプロジェクトファシリテータに実施経験があって開発者だけが未経験のチームであっても開発者がプロセスを学習し慣れるまでの時間を必要とします。 チームへ導入した場合にはチームが軌道に乗るまでに多くの時間が必要となることを知っておく必要があります。プロジェクトマネージャやプロジェクトファシリテータをチームに採用することがチームのアジャイル開発の導入の近道となります。 また多くの開発者は、従来のような製造工程が存在せずに開発の自由が与えられることにもっとも戸惑うようです。さらに、開発の自由を与えられたので開発の見積もりも開発者自身がしなければならなくなります。 この開発の見積もり作業も開発者にとって大きな戸惑いとなります。ある開発者はアジャイル開発を歓迎しますが、ある開発者にとってアジャイル開発は負担となることも考慮しておかなければなりません。 |
||||||||||||||
| 導入のまとめ | ||||||||||||||
|
アジャイル開発を導入するには、まずプロジェクトの目的を明確にし、プロジェクトとして最適なプロセスを決定し、その中に実施するプラクティスを自由に選択します。 あるプロジェクトマネージャは、開発時の生産性を下げたくないはないのでペアプログラミングを導入しませんでした。また、あるプロジェクトマネージャは、開発時の生産性よりも保守・運用までを考慮し、ペアプログラミングにより品質を維持させることを選択しました。前述のマネージャは、ペアプログラミングを実施しないかわりに別のプラクティスで品質を維持し保守・運用に備えました。 この2人のマネージャのどちらが正しいということはありません。どのようなプロセスを採用し、どのようなプラクティスを採用するかは、チームやプロジェクトの目的によって変わるものです。 プロジェクトマネージャが明確に意思をもってアジャイル開発を導入することができればアジャイル開発はスムーズに導入することができるでしょう。 次回は、アジャイル開発のプラクティスをプロジェクトマネジメントに活用するお話をいたします。 |
||||||||||||||
|
前のページ 1 2 3 |
||||||||||||||
|
|
||||||||||||||
|
|
||||||||||||||
|
||||||||||||||
|
|
||||||||||||||
|
||||||||||||||
|
|
||||||||||||||
|
||||||||||||||
-
-
連載
