InfoQ

InfoQ

News

マイブックマーク

ブックマークするためにログイン または 会員登録 する

ブックマークされました!

ブックマークがエラーになりました。もう一度お願いします。

アジャイルプロジェクトが遅れる理由

作者 Vikas Hazrati , 翻訳者 徳武 聡 投稿日 2009年12月29日

セクション
プロセス/プラクティス,
設計/アーキテクチャ
トピック
Agile ,
Agile in the Enterprise
タグ
Best Practices

原文(投稿日:2009/12/22)へのリンク

遅延とは、一般的に言えば、作業の実施が予定よりも後になることであり、それによって不満や作業が苦しみが生まれ、関係者に迷惑をかける。同じように、アジャイルプロジェクトでも遅延という言葉は無駄と考えられている。遅延はプロジェクトの流れを断絶してしまうので、再学習やタスクの変更などの更なる無駄を生み出す。

Jack Milunsky氏いくつかのありがちな遅延について、その原因を下記のように列挙している。

  • 事業認可 - 事業に認可がおりるのを開発者を抱えながら待つと時間とお金の無駄が生まれる。
  • 正式な優先順位がついた要求リストを待つ - 仕事を始めるために。
  • リソースが使えるようになるのを待つ – これは組織が働きすぎていないかどうか振り返るサイン。
  • 承認プロセスの変更– これ自体が無駄。頻繁に発生するようならスプリントを短くしたほうがいいかもしれない。
  • 仕掛かり作業の増加- 仕掛かり作業が増加すればするほど、開発者はコードを作業結果に反映できるようになるまで待たなければならない時間が長くなる。
  • 顧客の受け入れテストが完了の遅れ – テスト完了だけではなく、要求の定義やデモのフィードバックなどでも顧客側が原因で遅れることがある。

Jack氏はスプリントの間にも様々な種類の遅延があると説明している。チームは少し力をいれて遅延を特定し、根絶すべきだというのが氏の意見だ。曰く、

バックログが適切に整備されていることを確実にしなければなりません。そのためには、市場や顧客について理解しているプロジェクトオーナの強力が不可欠です。しっかりとしたロードマップを書いて、開発者から早めに見積もりをもらい、プロジェクトオーナが企画会議に先立って意思決定できるようにする必要があります。こうすることはプロジェクトの仕組みから遅延を排除することに他なりません。こうすることでひとつの作業から別の作業へスムーズに移行できるようになります。また、作業の始まりと終わりを把握しておいて、その間に遅延があるかどうか特定することには価値があります。

同じようにWouter Baars氏ITプロジェクトでのよくある遅延について下記のように述べている。

  • 金メッキ–顧客から要求されていない機能の実装に多くの時間を費やしてしまう。
  • 品質管理の無視–時間的余裕がないとプログラマやチームはテストを省こうとしがちだが、テストを省くと結局、テスト行ったとき場合よりも遅延がひどくなる。
  • 同時に数多くのプロジェクトで働く–作業をスイッチすることは利点よりも問題点の方が多い
  • ‘すべて同じ方法で解決できる’シンドローム–新しい問題にも従来の解決策を適用しようとしてしまう。
  • 未熟な人々–技術力の不足や不十分なプロジェクト管理能力は様々な水準で遅延を生み出す。
  • 顧客との取り決めが履行されない–顧客が関係しなければならない作業のときに、適切なタイミングで反応を返さない場合、プロジェクトは停止してしまう。
  • 顧客と開発者との間の緊張–プロジェクトが十分な手続きを経ていないと、顧客と開発者の間の緊張関係が更なる遅延を生み出す。そして、互いの信頼関係や作業の雰囲気が悪くなる。

遅延の理由については、他にもRobert Neri氏がエンタープライズ分野へのアジャイルの適用の難しさも遅延を生み出すことがある、と指摘している。曰く、

よく出くわすのはプロジェクトを支援する組織がスプリントと同じ速度で動くことができずに、アジャイルプロジェクトが遅れがちになるという事態です。同じようにアジャイルでないプロジェクトをアジャイルプロジェクトに統合するのも時間がかかります。

あなたのアジャイルプロジェクトで遅延が発生したら、その原因を上述したような一般的な遅延の原因とつきあわせてみてはどうだろうか。原因が特定できたら、すぐに解決にむかった方がいいだろう。そうすればプロジェクトでの最大の無駄を削減できるはずだ。

特集コンテンツ一覧

GAE開発の落とし穴

Googleのクラウド環境をつかったGoogle App Engineによる開発するにあたり、初めての試みで苦悩する開発者達の経験をもとに、各開発フェーズにあわせて問題点やどう解決したかをご紹介します

イベントレポート:「Coqチュートリアル#1」

去る1月12日、定理証明支援系ツールCoqの初心者向けチュートリアルが開催さ れた(http://kokucheese.com/event/index/23667/)。今後も2月2日 (http://kokucheese.com/event/index/23744/)、2月9日、2月16日と引き続き開 催されていく予定である。本記事では、開催の様子をレポートする。

Javaの未来についてのNeal Gafter氏とのディスカッション

Choosing Options

Neal Gafter氏はOracleによるJava買収の影響に関する議論、Javaにセグメンテッドスタックやメタオブジェクトプロトコルを追加することについての主張、そしてJavaとC#との比較について話をしてくれた。

Google Dartのエッセンス:アプリケーションの構築、スナップショット、Isolate

GoogleはVMをともなう新しい言語であり、JSコンパイラでもあるDartをプレビューした。 InfoQはDartのアプリの構築に貢献する文法の裏側を探った:スナップショット、Isolate、モジュール方式

CSPベースのモデル検査ツール「Process Analysis Toolkit」

本記事ではCSPベースの「マルチドメイン・モデル検査ツール」である、PAT(Process Analysis Toolkit)について紹介する。モデル検査は、形式手法(Formal Method)という方法論を基礎とする技術であり、複雑さが増大しながらも安全性を求められる、現在のソフトウェア開発の状況に対する処方箋の1つとして注目されている手法である。

Jenkinsによる継続的インテグレーションのススメ(4) ~CloudBeesでJenkinsをサービスとして使う~

前回まで、Jenkinsの幾つかの側面に注目して解説をしてきました。シリーズ最後の今回は、Jenkinsをサービスとして使う方法を紹介します。

書籍『抽象によるソフトウェア設計-Alloyではじめる形式手法-』の紹介

Alloyは、MITにて開発された仕様記述言語であり、ツールによる自動解析を使い、インクリメンタルに形式仕様が書けることが特長である。筆者らはAlloy開発者による、Alloyを使った形式手法入門書を翻訳、今夏にオーム社より刊行した。本記事では、Alloyの簡単な概要と、翻訳書『抽象によるソフトウェア設計』(「Alloy本」)を紹介する。

Windows デバイスで開発するタッチユーザーインターフェイス

スマートフォンを中心としたマルチデバイスにおけるタッチユーザーインターフェイスへの対応は、既に必須の項目となりつつある。本記事では、Windows デバイスにおける UX のベースとなっている「メトロ」というデザイン言語を掘り下げながら、既存環境を意識しつつもどのようにタッチユーザーインターフェイス開発に取り組んでいくべきであるかについて解説していく。