パットン・ジェフ。 ユーザーストーリー。 アジャイル ソフトウェア開発の技術

アブストラクト

この本は、アジャイル技術を使用してアイデアから実装までの開発プロセスを実行するためのアルゴリズムを解説しています。プロセスは段階的に配置されており、各ステップでプロセス ステップの方法が示されています。著者は、オリジナルであると主張することなく、ほとんどの手法がオリジナルではないと指摘しています。しかし、優れた文体とプロセスのある程度の整合性により、この本は非常に有用なものになっています。

ユーザー ストーリー マッピングの重要なテクニックは、ユーザーがプロセスを進めるにつれてアイデアとパフォーマンスを構造化することです。

同時に、プロセスはさまざまな方法で説明できます。主要な値を達成するにつれてステップを構築することも、単にシステムを使用して行われるユーザーの勤務日を単純に想像することもできます。著者は、プロセスの概要をプロセス マップ上でユーザー ストーリーの形式で表現する必要があるという事実に焦点を当てており、これがユーザー ストーリー マップという名前の由来です。

誰がそれを必要とします

IT アナリストとプロジェクト マネージャー向け。必読です。読みやすくて楽しい本で、中くらいの大きさです。

レビュー

最も単純な形では、これがどのように機能するかです。

訪問者はカフェに来て、料理を選び、注文し、食べ物を受け取り、食べ、支払います。

各段階でシステムに求めるものについての要件を記述することができます。

システムは料理のリストを表示し、各料理には構成、重量、価格が表示され、カートに追加できる必要があります。なぜ私たちはこれらの要件に自信を持っているのでしょうか?これは要件の「標準的な」説明には記載されていないため、リスクが生じます。

なぜこれが必要なのかを理解していない出演者は、たいてい間違ったことをします。アイデアを生み出すプロセスに関与しない出演者は、結果に関与しません。アジャイルは、システムではなく、人、消費者、そのタスクと目標に主に焦点を当てましょう、と言っています。

私たちはペルソナを作成し、共感を得るために詳細を与え、ペルソナの側からストーリーを語り始めます。

会社員のザカールさんは昼食に行き、簡単な軽食を食べたいと考えています。彼には何が必要なのでしょうか？おそらく彼はビジネスランチを希望しているのではないかという考えです。もう 1 つのアイデアは、彼はダイエット中であるため、システムに彼の好みを記憶してもらいたいというものです。もう一つのアイデア。彼は昼食前にコーヒーを飲むことに慣れているので、すぐにコーヒーを持ってきてほしいと思っています。

そしてビジネスもあります（組織キャラクターとは組織の利益を代表するキャラクターです）。企業は、平均小切手を増やし、購入頻度を増やし、利益を増やしたいと考えています。アイデアは、いくつかの料理の珍しい料理を提供しましょうということです。別のアイデア - 朝食を紹介しましょう。

アイデアはユーザー ストーリーの形で具体化し、変換し、提示することができますし、そうすべきです。ザカール ビジネス センターの従業員として、私の好みに基づいたメニューを受け取ることができるように、システムに私を認識してもらいたいと考えています。ウェイターとして、クライアントが迅速なサービスに満足できるように、テーブルに近づくタイミングをシステムに通知してもらいたいと考えています。等々。

何十もの物語。次は優先順位とバックログでしょうか？ Jeff 氏は、細かい点に行き詰まり、概念的な理解を失い、さらに機能を優先することで、目標との矛盾が生じてぼろぼろな状況が生じてしまうという、発生する問題を指摘しています。

著者の軌跡: 機能ではなく、結果、つまりユーザーが最終的に得られるものを優先します。

明白ではない点: 優先順位付けセッションは効果がないため、チーム全体ではなく 3 人で実行されます。 1 人目はビジネスを担当し、2 人目はユーザー エクスペリエンスを担当し、3 人目は実装を担当します。

1 つのユーザーの問題を解決するための最小値 (実行可能な最小限の解決策) を選択してみましょう。

ユーザー ストーリー マップ上のユーザー ストーリー、デザイン スケッチ、制約、ビジネス ルールを使用して、プロセスの各段階で人々や関係者が何を必要としているかをチームに伝え、話し合うことで、最優先のアイデアを詳細に説明します。残りのアイデアは未検討のまま機会の未処理のままにしておきます。

プロセスはカードに左から右に書かれており、プロセスのステップの下のカードにアイデアが書かれています。相互理解を確実にするために、ストーリー全体の流れについてチームメンバーと一緒に話し合うことが不可欠です。

このように精緻化することで、プロセスに準拠した整合性が生まれます。

受け取ったアイデアはテストする必要があります。チームメンバーではない人がその人の帽子をかぶって、その人の一日を頭の中で生き、その人の問題を解決します。彼が展開を見ていない可能性があり、再びカードを作成し、チームが独自に代替案を発見します。

次に、評価のための詳細設定があります。これなら3人いれば十分です。ユーザー エクスペリエンス、開発者、テスターの責任者であり、「もしも...」という質問が大好きです。

各段階で、ユーザーの履歴のプロセス マップに従ってディスカッションが行われるため、ユーザーのタスクを念頭に置き、一貫した理解を得ることができます。

著者の意見では文書は必要ですか?はい、必要です。ただし、合意内容を覚えておくためのメモとして。再び部外者を巻き込むには議論が必要だ。

著者は文書の十分性については深く掘り下げず、議論の必要性に焦点を当てています。 (はい、アジャイルを深く理解していない人がどのように主張しても、ドキュメントは必要です)。また、機能の一部のみを詳しく説明すると、システム全体の完全な作り直しが必要になる場合があります。著者は、考え方が間違っている場合の過剰な詳述の危険性を指摘する。

リスクを排除するには、作成中の製品に対するフィードバックを迅速に受け取り、「間違った」製品を作成する被害を最小限に抑える必要があります。私たちはアイデアのスケッチを作成し、ユーザーと検証し、インターフェイスのプロトタイプをスケッチし、ユーザーと検証しました。 (これとは別に、プログラム プロトタイプを検証する方法について少し説明があります)。ソフトウェア作成の目標は、特に初期段階では、迅速なフィードバックを受けて学習することであるため、最初に作成される製品は、仮説を証明または反証できるスケッチになります。 (著者は、Eric Ries の著書「リーン手法を使用したスタートアップ」を参考にしています)。

ストーリー マップは、実装が複数のチームにまたがって実行される場合のコミュニケーションを改善するのに役立ちます。地図上には何が表示されるべきですか?会話を続けるために必要なもの。ユーザーストーリー (誰が、何を、なぜ) だけでなく、アイデア、事実、インターフェイスのスケッチなど...

履歴マップ上のカードをいくつかの水平線に分割することで、作業をリリースごとに分割することができます。つまり、最低限の機能と弓のレイヤーを強調表示することができます。

私たちはプロセスマップ上でストーリーを伝えます。

従業員が昼食に来ました。

あいつ何がしたいんだろ？サービス速度。そのため、彼のランチはすでにテーブル、または少なくともトレイの上で彼を待っています。おっと、ステップを間違えました。従業員は食事をしたかったのです。彼はログインし、ビジネス ランチのオプションを選択しました。彼は、カロリー量と栄養成分量を見て、太らないようにダイエットするのに役立ちました。彼はその料理の写真を見て、その店で食事をするかどうか決めました。

次に、彼は昼食と夕食を食べに行きますか？それとも昼食が彼のオフィスに配達されるのでしょうか？次に、プロセスのステップは、食事をする場所を選択することです。彼は、それがいつ配達されるのか、どれくらいの費用がかかるのかを知り、階下に行くか仕事に行くか、自分の時間とエネルギーをどこに費やすかを選択できるようにしたいと考えています。彼は、行列にならないように、カフェがどれくらい混雑しているかを確認したいと考えています。

すると店員さんがカフェにやって来ました。彼はトレイを見て、それを持って夕食に直行できるようにしたいと考えています。カフェはサービスでお金を稼ぐためにお金を受け取りたいと考えています。従業員は、貴重な時間を無駄に浪費しないように、カフェとの決済にかかる時間を最小限に抑えたいと考えています。どうやってするの？リモートでサービス後に前払いまたはその逆の支払いが可能です。または、キオスクを使用してその場で支払います。これについて最も重要なことは何ですか?ランチの代金を銀行カードで支払える人は何人いるでしょうか?繰り返しの支払いに備えてこの食堂にカード番号を保存してくれると信頼できる人がどれだけいるでしょうか?実地調査がなければそれは不明であり、テストが必要です。

プロセスの各ステップで、何らかの方法で機能を提供する必要があります。そのためには、ある人を基準として、その人にとってより重要なもの (同じ 3 つのセレクター) を選択する必要があります。ストーリーを最後までフォローした = 実行可能な解決策を作成した。

次に細部の仕上げです。クライアントは、行列にならないように、カフェの混雑状況を知りたいと考えています。彼は一体何を望んでいるのでしょう？

彼がそこに着くとき、15 分以内に何人の人がそこにいるかという予測を見てください

カフェでの平均サービス時間とその推移を 30 分前に表示する

状況とテーブルの占有状況を確認する

予測システムの不明確な結果が得られたり、機能が停止した場合はどうなりますか?

カフェの行列やテーブルの占有状況をビデオでご覧ください。うーん、まずそれをやってみませんか?!

著者は、実践すべき小さな練習法を指摘しています。それは、朝起きた後に何をしているかを想像してみてください。 1 枚のカード = 1 つのアクション。カードを拡大して (コーヒーを挽く代わりに、爽快な飲み物を飲みます)、個々の詳細を削除し、実装方法ではなく目標に焦点を当てます。

この本の対象者: IT アナリストとプロジェクト マネージャー。必読です。

アプリ

議論や意思決定は3～5人のグループで行うのが効果的です。

最初のカードには開発する必要があることを書き、2 番目のカードには最初に行ったことを修正し、3 番目のカードには 1 番目と 2 番目に行ったことを修正します。

ケーキのようなストーリーを準備します。レシピを書き留めるのではなく、ケーキが誰に、どのような機会に、何人に向けて作られるかを調べます。売上を内訳すると、ケーキやクリームなどの製造ではなく、小さな既製ケーキの製造になります。

ソフトウェア開発は映画の制作に似ており、撮影を開始する前に、慎重に脚本を開発して磨き上げ、シーンや俳優などを整理する必要があります。

資源は常に不足します。

努力の 20% は目に見える結果をもたらし、60% は理解できない結果をもたらし、努力の 20% は有害です。だからこそ、学習に集中し、否定的な結果が生じても絶望しないことが重要です。

ユーザーと直接コミュニケーションをとり、ユーザーの立場になって感じてください。いくつかの問題に焦点を当てます。

評価のためのストーリーを詳細に説明し展開することは、スクラムの最も面倒な部分であり、水族館モードで議論を立って行います (理事会で 3 ～ 4 人が議論し、誰かが参加したい場合は誰かを交代します)。

出所： habr.com