web-dev-qa-db-ja.com

アジャイルは、プロジェクトの完了間近（90％シンドローム）にプロジェクトが停止するのをどのように回避しますか？

私は過去数週間、90％症候群と呼ばれるものについてたくさん読んだ。

基本的に、このシンドロームは、スケジュールどおりに約90％の完了に達したプロジェクトを表し、その後ストールし、最終的には当初予測された期間の約2倍で終了します。

この問題に関する古い記事を見つけて、その根本的な原因を理解しようとしました。

しかし、この問題がアジャイル手法でどのように処理されるかについての新しい記事や情報源は見つかりませんでした。アジャイル方法論、具体的には極端なプログラミングとスクラムは、ウォーターフォールプロジェクトで行われているものとは異なる方法でこの問題を処理しますか？

短いサイクルは、この症候群の損傷と確率を減らすプラスの影響を与えることができると私は信じています。特にXPでは、TDDなど、やり直しを回避して本当にやり遂げるのに役立ついくつかの方法があります。

agileproject-managementscrumextreme-programmingtracking
7
Belgi

アジャイルは、最後の10％をまったく行わないことでこれに対処します。私たちは最初に最も重要な（価値のある）作業を行うので、最初の90％まで作業を終えたときには、最後の10％が開発に投資する価値のない種類のものを持っているのは素晴らしいことです最後に少し。スケジュールではなく、アジャイルプロジェクトでscopeを変更する傾向があります。

13
RubberDuck

Alistair Cockburnには 良い記事はこちら があり、引っ越しのために家を荷造りするのと同じようにこれについて説明しています。

基本的に、あなたが説明している問題は、チームに「達成率」を報告してから、何らかの数式を使用してそれをプロジェクト全体の達成率の値に集計することだと思います。

アジャイルプロジェクト管理の最も重要な側面の1つは、成果物の完全性の状態がバイナリであるという概念です。ヨーダイズムを盗むには：doneまたはnot doneのいずれかです。部分的に行われるようなものはありません。

これは他のいくつかの重要な概念につながり、何よりもまずdoneの意味です。私は「夕食のように」の基準に不満です。つまり、夕食は実際に消費する準備ができたときにのみ行われたと見なされます。ここでのもう1つの重要な点は、独立した成果物を小さくすることで、進捗状況をより正確に把握できることです。

これを実行すると、より大きな努力で達成率について話すことが可能になります。ほぼ同じサイズの10の成果物（労力の観点から）があり、そのうちの5つ完了がある場合、おおよその成果であると言えます。 50％完了。さらに重要なのは、これら5つのことを実行するのにかかった時間と、どのようなバリエーションを見たのかに関するデータを取得し、それを予測モデルで使用して、残りの作業がいつ完了するかを予測できることです。

11
JimmyJames

アジャイルはそれを非常に簡単な方法で扱います。「スケジュール」はありません。

私が説明したように この答えで ; 90/90は、「ハッピーパス」に基づいてスケジュールを構築しようとしているときに発生します。実装が必要な他のすべてのEdgeケースを最後の瞬間に見つけ出すためだけです。

適切なアジャイル環境では、ソフトウェアが常に「解放可能な」状態にあることに焦点を当て、短い反復と小さな機能のチャンクにより、この種の計画を回避できます。ただし、大きな機能が適切に完成する時期をスケジュールするのは非常に難しくなります。

簡単に言えば、アジャイル方法論は、スケジュールの量に基づいたプロジェクトの基本的な「完全性」ではなく、これを回避しようとします。すでに実装されている機能に基づいています。

7
Euphoric

その質問を理解するには、2つの方法があります。

  1. 100の機能のうち90が完了しました。ただし、最初に簡単な機能を実行すると、残りの10は以前の90と同じくらいの時間がかかります。
  2. すべての機能は「90％完了」しています。ただし、機能の簡単な部分を最初に実行すると、残りの「10％」には、以前の「90％」と同じくらいの時間がかかります。

どちらの場合も、労力の見積もりは非常に不十分でした。最悪の場合、あなたの努力を示すために機能するものは何もありません。

スクラムはこれを次のように解決します。

  1. 何ヶ月もかかるスケジュールを立てず、正確であると信じている。スクラムにあるのはバーンダウンであり、残りの部分可能性があるにかかる時間を推定できます。しかし、スクラムはこれが推測であるということについて非常にオープンです。
  2. 一度に1つの機能を使用して、成果物のバージョンが完成するまで仕上げます。各作業項目を強制的に実行、終了、テスト、磨き、ワックスをかけることで、ハッピーパスを推定し、「ええ、出荷する前に先延ばしにするだけ」という傾向を排除できます。 」部品。
  3. 製品に付加する価値によって機能に優先順位を付ける。そうすることで、時間/お金が足りなくなったときに、おそらくその時間に組み込むことができた最も価値のある製品を手に入れることができます。
  4. 反復を短く保つ。各イテレーションの最後に、コースを変更し、開発を継続し、最小限の無駄な労力でプロジェクトを放棄し、従来の意味で行われたときの期待を再調整するオプションがあります。
0
Kempeth