私たちは、機能的に複雑な製品を開発している 3 人の開発者 (2 人は経験豊富ですが、この特定のビジネス セクターでは新しい) の小さなチームです。私たちはスクラムを使用しており、各スプリントの終わりにデモを行います。機能チームが多くのアイデアを持っていることは明らかですが、これらは開発チームに十分に伝えられておらず、デモは答えよりも多くの質問を提起しています.
機能的な人々からの入力の質を改善するための推奨事項はありますか?
詳細情報:問題の一部は、仕様やユーザー ストーリー自体がないことだと思います。個人的には、彼らはある種の要件を書き留める必要があると思います。どのようなものを書き留めるべきで、アジャイル プロセスを考えるとどのくらい複雑になるのでしょうか?
受け入れテストを定義/策定するために顧客と協力してみましたか?
Fit のようなものを使用してこれらのテストを考え出すと、より優れた仕様が得られるだけでなく、顧客は本当に必要なものについて考えざるを得なくなります。ケーキのアイシングは、このプロセスの最後に即座にドキュメントを実行できる仕様です。
もちろん、顧客が利用可能で、このアプローチにオープンである場合はそうです。試してみる！
そうでない場合 (それが大多数のようです - 仕事が少ないため) - カレンダーをフラッシュします - カナリアのように歌うまで、毎週ミーティング/テレコンをスケジュールします:) Dana に +1
機能チームの誰かがチームの一員であり、追加する機能に関する質問に答えることができる必要があります。
バックログ項目が十分に詳細化されていない場合、どのように見積もることができますか?
明確な受け入れ基準がないバックログ項目は計画できないというルールを確立できます。
機能チームの誰かがプロダクト オーナー、バックログ アイテムの決定、選択、優先順位付け、および/またはドメイン エキスパートとして機能する方がよい場合。
また、誤解を避けるために、機能チームと開発チームの全員が同じ言語を話すようにしてください。ユビキタス言語を参照してください。
機能チームからの回答を待っている時間と、不要な機能を開発したり、既存の機能を修正して請求書に合うように無駄にした時間を追跡します。
あなたが機能的な人々と呼んでいる人々がプロダクトオーナーとして行動していることを理解していますよね?
問題の一部は、仕様やユーザー ストーリー自体がないことだと思います。個人的には、彼らはある種の要件を書き留める必要があると思います。どのようなことを書き留めるべきで、アジャイル プロセスを考えるとどのくらい複雑になるのでしょうか?
実際、仕様がなければ、おそらくバックログアイテムの受け入れテストもありません. PO にユーザー ストーリーを書くように依頼する必要があります。形。ユーザー ストーリーは、投資 -独立、交渉可能、ユーザーまたは顧客にとって価値あり、評価可能、小規模でテスト可能であることに留意してください。必要なのは、受け入れテストをストーリーと一緒に作成して、ストーリーが完了として設定されるために何ができる必要があるかをチームが理解できるようにすることです。
製品が進化するにつれて、PO は実際に機能する製品を見てアイデアを思いつくことが期待されることを忘れないでください。それは悪いことではありません。実際、これはアジャイルを通じて得られる最高のものの 1 つです。注意しなければならないのは、このアイデアは製品バックログに含める必要があり、PO によって優先順位を付ける必要があるということです。また、それが必要であり、顧客に付加価値を与える場合は、そのアイデアを次のスプリントで構築するように計画する必要があります。
人々からインプットを得る最も簡単な方法は、彼らからそれを強制することである場合があります。私の会社はプロジェクトで SCRUM を使用しましたが、自分が何をしているかを既に知っていると、人々は自分自身を維持する傾向があることがすぐにわかりました。最終的には、チームメンバーがその週に学んだことを発表する必要がある毎週の会議を開催することになりました。強制でしたが、かなりうまくいきました。
私は、ユーザーのアクションに応じたシステムの動作を詳述するユース ケースを大いに信じています。これらをまとめて要件の緩やかなセットを形成することができ、SCRUM 環境では、その特定のスプリントの実装機能を形成するユース ケースに優先順位を付けるのに役立ちます。
たとえば、機能チームと話し合った後、15 の個別のユース ケースを特定したとします。ユースケースに優先順位を付け、5 つのスプリントを計画することにしました。そして、各スプリントの終わりに、スプリント中に実装されたユース ケースを満たす製品のデモを行い、フィードバックに注意してユース ケースを修正します。
何らかの要件 (ユーザー ストーリーなど) が必要であることに同意します。
私ができるアドバイスの 1 つは、機能チームで何らかの視覚補助を使用することです。顧客がたくさんのアイデアを持っている場合 (あなたが言ったように)、彼らは通常、機能がどのように見えるかについての視覚的なアイデアも持っています。機能的に仕事。
お客様と機能について話し合うときは、できるだけ視覚的になるようにしています。ボードにスケッチを描いたり、何かがどのように見えるかを口頭で説明したりします。共通の視覚的イメージを見つけようとしています。その後、スケッチの写真を撮り、ドキュメントの一部として使用できます。
もう 1 つのアドバイスは、スプリントをできるだけ短くして、より頻繁にデモを行うことです。ただし、現在のスプリント期間について言及していないため、すでにこれを行っている可能性があります。
スタンドアップ ミーティングを行っていますか?バーンダウン チャートはありますか? この 2 つの分野は、あなたにとって大きなメリットがあると思います。
彼らはスタンドアップミーティングに参加していますか?
スプリントの終了前に彼らに意見を求めるために、それらのそれぞれ (またはいくつか) に代表者を置くことを提案できます。
「アジャイル開発者の実践」という本をお勧めします。スクラム チームを成功させるためのヒントが満載です。また、製品の所有者/顧客をより関与させる方法と、プロセス全体を進める方法についても、良いヒントを提供します。それは私見のお金の価値があります。