素早い

従来のプロジェクトマネジメントの方法論では、顧客の関与がなかなか実現しません。 実際、プロジェクトへの顧客の関与が完全に成功したと思われたのは、プロジェクトの最初と最後の２回だけでした。 完全とは言えないまでも、多少の成功を認められた従来のプロジェクト環境では、スコープの変更や変更要求を交渉する時に顧客が関与することもあります。 このような場合、開発側と顧客側のモットーは「勝つか負けるか」です。 ご想像のとおり、このアプローチでは、多く場合スコープの変更と顧客との協調が迷惑なものとして認識されているのです。...

PMPやPrince 2といった従来のプロジェクトマネジメントの方法論では、ステークホルダーを、プロジェクトの影響を受ける人として定義しています。 プロジェクトマネジメントの方法論が異なれば、定義も異なります。 スクラムでは、すべてが異なります。 スクラムの公式の役割は３つです：開発チーム、 スクラムマスター 、 プロダクトオーナー。 プロダクトオーナーは、ステークホルダーが何を必要としているかを理解し、彼らの声を伝える責任があります。 アジャイルプロジェクトでステークホルダーが果たす役割を深く掘り下げる前に、まずは 誰が...

アジャイルプロジェクトには正式なプロジェクトマネジャーのポジションはありませんが、スクラムモデルでは、プロジェクトマネジメントの責任は次の役割を通じて果たされます。 プロダクトオーナー： プロダクトオーナー は、プロダクトについての開発「理由」、「内容」、および「時期」についての責任を持ちます。 理由：プロダクトオーナーは、プロダクトの長期目標と短期目標の両方を設定して、戦略と長期的な方向性を策定します。 プロダクトオーナーを通じて、スクラムチーム全体、特に開発者は、自分たちが構築しているものを、なぜ構築しているのかを理解します。...

動くソフトウェア（および、多くの組織にとっては、実用的な「プロダクト」)の早期提供は、アジャイルアプローチを使用する最大の利点の１つです。 プロジェクトの早い段階で動くプロダクトを提供することで、ROIを高めることができます。 動くプロダクトによって、開発チームは、プロジェクトに長い時間を費やす前に、難しい概念が機能するかどうかを証明することができます。 収益をもたらす動くプロダクトは、プロジェクトの残りの部分に資金を提供することもできます。 アジャイルプロジェクトでは、開発チームは動くプロダクトに焦点を当てます。...

アジャイルソフトウェア開発宣言* 「私たちは、ソフトウェア開発の実践 あるいは実践を手助けをする活動を通じて、 よりよい開発方法を見つけだそうとしている。」 「この活動を通して、私たちは以下の価値に至った。」 プロセスやツールよりも個人と対話を、 包括的なドキュメントよりも動くソフトウェアを、 契約交渉よりも顧客との協調を、 計画に従うことよりも変化への対応を、 つまり、左側の項目には価値がありますが、右側の項目をより重視するということです。...

スクラムフレームワークは５つのイベントで構成されています。 各イベントは、スクラムチームがプロダクトまたはそのプロセスのいずれかに透明性を提供し、定期的な検査と即時の適応を可能にします。 また、スクラムモデルの下でプロジェクトの成功を補完し、向上させるいくつかの一般的なアジャイルプラクティスも見つけました。 それぞれがスクラムフレームワークと共に、価値へのロードマップで概説されています。 段階１ - ビジョン。...

プロジェクトの進捗状況は、可視化され、測定可能でなければ意味がありません。 アジャイルプロジェクトチームは、３つのスクラム作成物（プロダクトバックログ、スプリントバックログ、インクリメント）に加えて、３つの追加の作成物（プロダクトビジョンステートメント、プロダクトロードマップ、リリース計画）を使って効果を高めていきます。 これらの作成物は、チームに戦略的および戦術的な方向性を提供するだけでなく、プロジェクトの進捗状況を組織に伝えます。 プロダクトビジョンステートメント...