今日は、柔軟なプロジェクト管理の重要な側面についてお話したいと思いますが、純粋なアジャイルについてではなく、プロジェクトの計画と反復についてお話したいと思います。 それは「ユーザーストーリー」のジャンルについてであり、それはマーティン・ファウラーによる序文でジェフ・パットンによる西部で非常に成功した本に捧げられます：
この記事では、テキストがあなたを待っていますが、「ユーザーストーリーマッピング」を「機能の視覚化」と翻訳しました。 このオプションは、出版社でも出版されているBoris Wolfsonの非常に興味深い本「 柔軟なプロジェクトと製品管理 」から取ったものです。
そのため、この記事の著者はパットンの研究を読み、誰もがこれを行うべきだと判断しました。 彼が与えた説得力のある例は、あなたが判断することです。
プロジェクト計画の重要な目標の1つは、要件をまとめて収集することです。 しかし、どこから始めて何に焦点を合わせるかを決めるのは難しいことがよくあります。 機能の視覚化（ストーリーマッピング）は、すべてのチームメンバーが要件リスト（バックログ）の形成に参加する魅力的な作業です。壁にカードを貼り付け、退屈な100ページの仕様を作成しません。
この機能を視覚化する方法は、 Jeff Pattonによって考案されました。ShiragDoshiがそれについて私に話しました。 これは、プロジェクトを通じて考える段階で要件を修正する非常に効果的で便利な方法だと思います。
機能的な地図を描く
機能の視覚化は、ツリー形式で提示される要件を収集するトップダウンの方法です。 視覚化を開始する前に、プロジェクト全体の概要を説明する必要があります。 これを行うには、目標を設定します。 目標を達成するには、特定のアクションを実行する必要があります。 そして、アクションを完了するには、ユーザーは問題を解決する必要があります。 ソフトウェアを開発するとき、特定のタスクをユーザーストーリーとして定式化できます。
マップ構造： 目標-アクション-タスク-ストーリー
たとえば、オンラインストアを操作するためのアプリケーションを考えてみましょう。このフレームワーク内で、特定の目標を特定します：「製品を見つける。 プロセス全体をよりよく理解するために、この機能を地図上に視覚化します。
「製品を見つける」という目標を達成する方法はいくつかあります。たとえば、「製品カタログでツリーをブラウズする」、「テキスト検索を使用する」、「プロモーションアイテムを見る」などです。 2番目のオプションである「商品のカタログでツリーを調べて」、そのような機能を視覚化します。 ''
さらに、目的の製品に到達するために、ユーザーは特定のタスクを実行する必要があります。
そして今、これらのタスクをユーザーストーリーとして定式化し、プログラム開発に進むことができます。
そのため、目標から始めて不可欠なマップを構築しながら、各機能ブランチについて詳細に説明を続けます。 私の経験では、機能の完全な視覚化には、プロジェクトの規模と複雑さに応じて、3日から2週間かかる場合があります。
参考のために：ここに、実際のプロジェクトから取得した1つの機能的な視覚化の「ブランチ」を示します。
そして、これが5日間の作業後のマップ全体です。
それで、機能的な視覚化を理解したので、このアプローチの利点を説明しましょう。
機能可視化の利点
- バックログの視覚的表現（全体像）により、関心のあるすべての人が同じ平面で作業し、一緒に作業の量と複雑さを評価できます。 さらに、この作業はプロジェクトの範囲を間接的に理解するのに役立ちます。
- 紙に要件を修正すると、相互作用が改善され、作業に対する共通の理解が形成されます。
- 通常、プロジェクトを開発する時間は限られているため、機能を視覚化することで、プロジェクトを深く掘り下げ、アプリケーションの重要な側面に集中することができます。 「望ましい」機能を「セカンダリ」としてマークすると、チーム全体が開発時間を節約します。
- 興味深いことに、すべての「ストーリー」を壁に貼り付けると、チームがそれぞれのサイズを関連付けやすくなります。
- プロジェクトをマップの形式で構造化すると、タスクの優先順位付けとリリースのバックログのセグメント化が容易になり、各リリースの実行可能な最小バージョンが指定されます。 セグメンテーションは水平または垂直にできます。たとえば、限られた数の機能を選択するか、多くの機能を選択しますが、それぞれで最小の実行可能性のレベルを示します。
- ビジュアルマップは、 Mingleなどのアジャイル開発用の特別なツールを使用してバックログに変換できます。
結果のカードに追加情報を追加します
プロジェクトマップ上の比較的多くの情報を修正することが必要になる場合があります。たとえば、作業中に生じた質問や代替アプローチをマークするために...これらはすべて視覚化にも当てはまります。 実用的な例を次に示します。
- 異なる色は、マップの異なるレベルを示します。 たとえば、目標はオレンジ、特徴は青、ストーリーは緑、ストーリーは黄色になります。
- マップの対応する領域の隣には、ワイヤフレームモデルがあります。
- 特別なステッカーを使用して、たとえば、ドットや星の形で特別な表記を整理します。
- 誰もがプロジェクトの一般的な考えを持つように、二次機能にフラグを立てることが重要です
- UXが飽和状態になり、非コアソリューションが高すぎないように、代替オプションを強調することが重要です
小さなステッカーにメモを書き、仮定、予備的な結論、質問を書き留めます。
代替の機能可視化方法
機能を視覚化する場合、最初に構造を決定し、次に必要に応じて構造を改良することが重要です。 作業の最初に、プロジェクトの構造を想像し、それに基づいて構築する必要があります。 全体的な構造は、2〜3回の反復後にのみ取得される場合があります。
1つの代替構造は、カスタムトラベルと呼ばれます。 このアプローチは、買い手、売り手、管理者など、ユーザーの観点から要件を決定するのに役立ちます。 この場合、視覚化はUser-Goals-Travel-Actions-Storiesの形式を取ります。
特にNFR（非機能要件）を開発する場合の別の選択肢は、次のとおりです。
NFR-デマンド-履歴 。
大規模プロジェクトの完全なマップには、最大6つのレベルを含めることができます。 ただし、典型的なプロジェクトでは、通常3つのレベルで十分です。
機能可視化の準備
そのため、機能を視覚化して次のプロジェクトを開始することに決めました。 これに必要なものは次のとおりです。
- 自由な壁のある大きな会議室。プロジェクトの全期間にわたって自由に利用できます。
- カラフルなステッカー、各レベルに1枚のステッカー。
- ステッカーのラベルを遠くから簡単に読み取れるように、太字のマーカー。
- 特別なステッカー（ドットまたは星）-地図上の追加情報を修正します。
- 一部の場所で壁のステッカーを接着するのが不便な場合のマーカーボード。
- 地図全体の写真を撮るのに適したカメラ。
私の経験を共有します
機能の視覚化に従事していると、私はしばしば問題にぶつかり、それらを克服しました。 さらに、一般的な間違いを回避し、視覚化にうまく対処する方法に関するいくつかのヒント。
- 機能の視覚化の段階で、製品の要件を把握します。したがって、無限の議論を避けるために、すべての可能性を代替案とともに修正するようにしてください。
- 詳細に入ると、重要でないトピックに時間を浪費しないように優先順位を定期的に設定します。
- 不要なステッカーを定期的に取り外して、巨大な無限の山にならないようにします。 壁に沿って快適な通路を残しています。
- ステッカーで作業する場合、プロジェクト全体でステッカーが曲がったり、くっついたりしないようにします。そうしないと、写真でステッカーを見ることは困難になります。
おわりに
機能的な視覚化は、プロジェクトの要件を非常に明確に考えるための効果的なメカニズムです。 このようなアプローチは、問題の一般的な理解に役立ち、バックログの既存のギャップを強調し、相互依存関係をキャッチし、より正確にプロジェクトの段階の相対的なサイズを評価するのに役立ちます。 将来的には、このような視覚化は、プロジェクトを正しくセグメント化し、すべてのリリースを準備する時間を適切に計画するのに役立ちます。