アジャイル方法論を使用する場合、どのように長期的なリソースと予算を計画できますか?


8

アジャイルは多くの先行設計を奨励しません。これは、要件管理とソフトウェア開発の観点からは適切であり、プロジェクトを変化するビジネスニーズに適応させることができます。

しかし、開始時に何を構築するのか本当にわからない場合、リソースの長期計画をどのように行うのでしょうか。確かに、何を構築するかについての概念モデルはありますが、プロジェクトを完了するために必要なリソースの数や、それにかかるコストを測定するための測定可能な詳細はありません。

誰かがアジャイル環境で長期計画を行う方法について何か提案はありますか?


1
「資源の長期計画」に関してあなたは何を探していますか?アジャイルプロジェクトでは、特別なリソースは必要ありません(または、私はそういう人たちと呼んでいます):)
Marcie

1
マジ?あなたはソフトウェアを書くために人々を必要としないと言っていますか?
Erik Funkenbusch 2010

@MystereMan:マーシーは、特定のタスクのために専門家を必要としないことを意味すると思います。アジャイル手法は、人々が互いに引き継ぐことができるはずであることを強調しているからです。
2011年

回答:


2

私は、組織にプロジェクトの1つでアジャイルアプローチをパイロットするようにプッシュしました。彼らがプロジェクトに資金を提供する前に、予測される予算とタイムラインが必要であるため、これは上級管理職にとっての課題でした(大企業であるy社です)。

だから、私はその状況でいつもしていることをし、知識に基づいた推測をしました。私は、プロジェクトが必要と想定している範囲を調べ、それらの項目の開発時に推測し、ビジネスアナリスト、DBA、プロジェクトマネージャーなどのために追加の時間を追加し、いくつかのパディングを追加し、推定予算と呼びました。この種の「大まかな順序」の見積もりは、すべてのウォーターフォールプロジェクトの前にも私の会社で行われるため、違いはありませんでした。

次に、アジャイルプロジェクトを開始して速度を把握すると、速度と残りのストーリーポイントに基づいてプロジェクトのエンドポイントを予測したところ、元の高レベルよりも先に進んでいることがわかりました。見積り。しかし、それは大丈夫です(そして私たちはそれを期待していました)。

答えを一般化すると思いますが、それはあなたが「長距離」とはどういう意味か、そしてこれらの推定値がいつ必要かによって異なります。プロジェクトの開始前にそれらが必要な場合は、私の方法を使用できます。プロジェクトの実行中にそれらが必要な場合は、Matthew Kubicinaが述べているリリース計画の概念を使用できます。

また、この種の問題に対処するのに役立つマイクコーンの「アジャイルの見積もりと計画」の本を強くお勧めします。


7

アジャイルには「リリース計画」という概念があります。チーム全体が集まり、次のリリースを計画します。事前に2〜3か月間行ってきました。これは通常、製品の所有者が「実行可能な最低限の製品」を決定し、製品をリリースするために何を行う必要があるかを正確に把握した後に行われます。

チームは、既知の物語または壮大な物語をとることができます。エピックとは、まだ完全に定義されていない大きなストーリーまたは機能です。「国際支払いを許可する」のようなものかもしれません。この物語または叙事詩は非常に一般的であるため、見積もりは大きくなり、それを説明します。チームは「Tシャツ」サイズと呼ばれるものを実行し、各エピックに「小」、「中」、または「大」を与えることができます。これにより、製品の所有者は問題のストーリーのサイズについてある程度の感覚が得られ、スクラムマスターは実際のリリース日を予測することができます。

重要なのは、いくつかの場所から始めて、より多くの情報がわかったときに、ストーリーポイントまたは見積もりを洗練し続けることです。

リリース計画に関するリンクをいくつか紹介します。


チームがいて、製品の開発にかかる時間を知りたい場合は、これで問題ありません。チームがない場合は機能しません。また、x時間で製品を構築するために必要なチームの規模を把握する必要があります。
Erik Funkenbusch 2010

5
OK。それは違います。チームがなければ、アジャイル方法論に必ずしも参加しているとは限りません。アジャイルは、仕事をする人だけが仕事を完了するのにかかる時間を見積もるべきだと述べています。私が提案するのは、何人かの上級エンジニアまたは建築家を集めて、製品のニーズに基づいてタイムラインの大まかな感覚を得ることです。どこかから始めなければなりません。
Matthew Kubicina 2010

0

David AllenによるGet Things Done方法論を試してください。私は彼の本(GTDに関する最初/主要な本)の一節を思い出した。

GTDは実用的な用語で考えるのに役立ちます。そのため、実行可能な実際のタスクをプログラミングしたり、独自のシステムで実行するようにプログラミングしたりできます。これは一言で言えばGTDです:http : //lifedev.net/gtd-cheatsheet/

GTDは人生と仕事の両方で機能します。あなたやチームが心配することだけでなく、行動を考え続ける限り、最短期間から最長期間まで機能します。本を読む時間があまりない場合は、オーディオブックを入手してください。

スクラムを試すこともできます(GTDと組み合わせることもできます)...機能のリストを作成し、開発の1か月でボックス化して、製品の作業バージョンを作成します。

最後に、Jason FriedによるReworkを読むことをお勧めします。ここでは、優先順位付けと、非常に役立ついくつかの非公式なプロジェクト計画の概念について多くのことを語っています。


0

アジャイルでは、これは検査と適応と呼ばれます。履歴をガイドとして使用します。

目標にどのくらい早く到達できるかについて想定を始める前に、速度を知る必要があります。言い換えれば、あなたが実行しているどのくらいの速見とする反復のカップルを介して実行、その後の計画を作るためにその情報を使用しています。

あなたの質問に対する答えは、長期計画を行う前に、最初にデータを収集する必要があるということです。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.