私の会社は、スクラムの方法論を採用しようとしましたが、成功はまちまちでした。論文は、私たちが問題を抱えているいくつかの分野です。これらをどのように処理しますか？
私のテイクが何かを追加するかどうか見てみましょう（決して確実ではありません...）
「それぞれにリリースを割り当てる」ことについてはよくわかりません。アイデアは、各ストーリー/機能ポイント/開発単位に「価格」を付けて、現在のスプリントに何が入るかを選択することだと思いました. それ以外はすべてバックログです - 残りの労力を示すことはできます ( FogBugz のエビデンスに基づいたスケジューリングを参照)。一つには、あなたはそこに着きます。あなたが知っているのは、それが変化するということだけです。なぜ時間を無駄にするのですか？
指定されたユーザー代表者が必要です。または、ドメインの知識を 1 人の個人に集中できない場合は、複数。しかし、ビジネスドメインの誰かが、スプリントに何を入れるかを決定する全体を担当する必要があります。もちろん、利用可能な労力に応じて. ビジネス アナリスト タイプの場所がある場合もありますが、彼らはドメイン エキスパートである必要があります。あなたのユーザーがあなたの助けを借りてもストーリーを書くことができない場合 (それは協力的なものであり、そうあるべきです)、あなたは皆助けを必要としています。コーチを 1 つか 2 つのスプリントに参加させることを検討してください。
アジャイル環境で機能仕様を作成することはありません。コードを書くことになります。ユーザーは常に手元にあり (または、すでに重大なリスクにさらされています)、彼らはあなたの仕様です。ストーリーは「何を」伝え、「どのように」をかなり迅速に決定できるように十分に小さな作業単位になるでしょう。そしてリファクタリング。常にリファクタリングします。これはオーバーヘッドではなく、プロセスの一部であり、設計はそれなしでは満足のいくものにはなりません。
そのような質問をする VP (私は VP です。全員が悪いわけではありません!) がいる場合、会社の一部はまだ理解できていません。誰かを選んでください (非技術者に対処するのに最も適している人か、または明らかに練習が必要なため、おそらく最も能力の低い人) を選んで説明してください。構築されたものが彼らにとって重要である場合、おそらく彼らの質問は、誰かが関与すべきほど関与していないことを示しています.
要件を製品バックログに変換する必要があります。このバックログは、スプリントの反復ごとに選択されるスプリントバックログアイテムを決定するために使用するものです。経営陣は製品バックログの内容を決定しますが、チームはスプリントで何を作成できるかについて合意する必要があります（これはすべてのスプリントで行われる交渉です）。
プロダクトオーナー（通常はプロダクトマネージャー）がストーリーの作成を推進します。ストーリーは単純です（システム管理者として、ユーザーを追加できる必要があります）。あなたの製品管理者があなたの製品を理解していない場合、あなたは困っています。
アジャイルとは、必要に応じて設計することです。デザインは決して物語の中にはありません。仕様は、ストーリーごと、または機能ごとにすることができます。複数のストーリーをカバーする1つの仕様内ですべてのCRUDを設計できます。
プロダクトオーナーは、すべてのスプリントの最後に製品デモを入手します。したがって、値はすべてのサイクルで示されます。したがって、VPは毎月レポートを受け取ります（通常、3週間の開発+ 1週間のスプリントデモの準備）。
コードの作成または設計に関して何かを行う場合、常に行うべきことの 1 つは、使用している方法論に関係なく、それがスクラム、XP、アジャイル、または SDLC であるかどうかに関係なく、仕様を作成することです。多くの人々は、仕様書を書くことは非常に機敏ではなく、無駄な官僚的な事務処理の記念碑であると言っています。単純な事実は、コードが仕様であると彼らが言うとき、彼らは間違った方向に導かれているということです。
明確な事実は、仕様によってアイデアや設計を前もって定式化できることです。また、単純な LOB アプリケーションの範囲外で作業している場合は特に、プログラムを変更するよりも仕様を変更する方がはるかに簡単です。仕様は、コーディングを開始するときに何が必要かをより明確に理解できるようにします。
仕様を使用し、より優れたソフトウェアを設計するチームが何度も示されています。私の意見では、コードは仕様であり、ドグマであり、単純明快であり、将来のために巨大な保守性の問題を抱えていると誰かが言うのを聞いた場合.
余談ですが、私はアジャイル マニフェストや、スクラムのような軽い管理プロセス中心の方法に反対するものは何もありません。私は過去数年間に何度もそれを使用してきました。私はまた、アジャイルに焦点を当てていれば救われたであろう優れたソフトウェアが流出するのを見てきました。しかし、それは万能薬でも特効薬でもありません。