私はチームでプロジェクトを開始しており、方法論として SCRUM を使用しています。SCRUMは初めてです。機能をリストし、ストーリーを作成しました（ユーザーストーリーと技術ストーリー、およびそれらのタスク）。
私はあらゆる開発プロジェクトを開始するための厳密な UML アプローチを持っています。すべての機能をリストした後、次のステップはユーザー ケース ダイアグラムを作成して、アプリケーションが何を実行し、誰がそれを操作するのかを誰もが確認できるようにすることです。しかし、私のチームは、SCRUM で UML を使用することに関心がないと言いました。
UML のユーザー図を使用して、SCRUM のユーザー ストーリーを表すことはできますか? SCRUMで使用できる他の図はどれですか? (クラス図やシーケンス図のないアプリケーションは想像できないので、ばかげた質問かもしれませんが、SCRUM の専門家からのアドバイスを本当に知りたいです)
ありがとう。
UML のユーザー図を使用して、SCRUM のユーザー ストーリーを表すことはできますか?
ユースケース図は非常に簡単で、プロジェクトの概要を理解するのに役立ちます。
ただし、スクラムで他の UML ダイアグラムを使用することはお勧めしません。アジャイル プロジェクトではコードが頻繁に変更されるため、ダイアグラムが数日後には時代遅れになるという他の人たちの意見に同意します。この場合、それらを再描画する必要があり、これは無駄です。
たとえば、開発にEclipseを使用している場合、簡単なリファクタリング手順でクラス図が台無しになる可能性があります:-(
SCRUMで使用できる他の図はどれですか?
マインドマップを使用することをお勧めします。最近、大きなマインドマップを描いてオフィスの壁に貼り付けて、独自のユーザー ストーリーを作成し始めました。
真ん中に機能があり、それにサブ ユーザー ストーリーを接続し、サブ サブ ユーザー ストーリーをそれらに接続し、現時点で入手可能なすべての情報を関連付けます。このアプローチにより、ユーザー ストーリー、技術情報、質問など、すべてが 1 か所にまとめられています。
もちろん、マインドマップは日々成長しており、実装しなければならない機能についての知識はますます増えています。
実際には、このアジャイル dzone の記事で説明されているようなことを行っていますが、xp+kanban ではなくスクラムを使用しているため、MMF ではなくユーザー ストーリーについて話しました。
スクラムでは、チームが効果的にコミュニケーションをとるのに役立つものを何でも使用できます。スクラムは、そのチームにとってどのツールが効果的かについて、決定、判断、またはガイダンスを行いません。スプリントの実行に使用されるツールとプラクティスを熟考し、それに応じて調整することのみを求めます。これは検査と適応のループです。
価値を提供するために使用されるツールや手法のメリットについてオープンかつ正直に話し合うには、個々のメンバーが変化に対してオープンになるための多大な努力と意欲が必要です。
しばらくの間スクラムを使用してきた人々から言われたこと (つまり、これは意見です) は、UML ダイアグラムの作成には少し時間がかかる可能性があるということです。なぜなら、開発方法論はアジャイルであるため、要件は非常に簡単に根本的に変化する可能性があるからです。最初のスプリントのショー アンド テルの後で、かなり大きな再設計を行う可能性があります。
もちろん、スプリント バックログで自分のタスクにどのように取り組むかをスクラッチアップしてください。もちろん、作業を進めながら文書化することもできますが、クラス図などの中央リポジトリを維持することは、リソースのわずかな浪費になる可能性があります。
プロジェクトでのあなたの役割はわかりませんが、PO だと思います。その場合、意味がある場合は追加のドキュメントを使用してください。ユーザー ストーリーは、チームがそれについて PO と会話するためのリマインダーと考えてください。
ユーザー ケース図によって、求める機能が明確になると思われる場合は、問題ありません。実際には、スクラムボードとバーンダウン チャートの横の壁に置きます。
私の経験では、ストーリーごとに「テスト方法」のシナリオを指定するだけで十分です。たとえば、Stackoverflow のストーリーがあるとします。
「ユーザーとして、新しい質問を投稿できます」
「テスト方法」のシナリオは次のようになります。
「「質問する」ボタンをクリックすると、質問テキスト用のテキストエリアとタグ用のテキストフィールドを含むフォームが表示されます。ユーザーが両方を入力すると (これらは必須です)、ユーザーは質問リストにリダイレクトされます。ユーザーは見ることができますリスト内の質問のタイトルとタグ"
したがって、ユースケース図は実際には必要ないかもしれません。「テスト方法」を試してみることをお勧めします。機能的な観点から、ストーリーから何を期待しているかをチームが知っているため、チームにとって非常に役立ちます。また、すべてのストーリーのドキュメンテーションを行うわけではありません。
気に入らない場合は、ユース ケース図を使用しますが、ストーリーの説明以上のものをチームに提供することをお勧めします。
さて、あなたが言及した技術的な話について。彼らは何ですか？技術的要件が機能的要件と混在しているのはなぜですか? おそらくそれはプロジェクトの実際の要件ですが、通常はそうではなく、機能的なストーリーとして書き直すことができます。あなたの製品がフレームワークやライブラリのようなものでない限り。
たとえば、「質問を取得する」クエリのインデックスを作成するという技術的な話は、「質問一覧ページを高速化する」と書き直すことができます。
これら 2 つの図は Java コードとライブ同期されるため、スクラムではクラス図とシーケンス図のみを使用します。ユースケースやその他のダイアグラムを作成したり、ダイアグラム (MDD など) からコードを生成しようとしたりすることは絶対にありません。プロジェクトやコードで何かが変更されるとすぐに、ダイアグラムを更新するのが非常に苦痛になるからです。ダイアグラムは、人間の介入なしに自動的に更新される必要があります。私は Omondo EclipseUML で多くのプロジェクトを行いましたが、非常にうまく機能しました。
UML ステート マシン図は、ビジネス ロジックを維持しながら UI を再設計することに重点を置いたプロジェクトのスクラムで役立ちます。
ステート マシン モデリングは動的モデリング手法であり、システム内の動作 (この場合は単一クラスのインスタンスに固有の動作) を特定することに重点を置いています。私のスタイルは、クラスがその状態に応じて異なる動作を示すときに、1 つまたは複数のステート マシン図を描くことです。たとえば、Address クラスは非常に単純で、システムで表示および操作するデータを表します。一方、セミナー オブジェクトはかなり複雑であるため、それらのステート マシン ダイアグラムを作成することは理にかなっています。
参考文献