「障害駆動型開発」についてどうすればよいですか？

当店では、アジャイルであるよう努めています。そして、私たちは大きな進歩を遂げていると思います。そうは言っても、私たちの何人かは、「障害駆動型開発」と呼んでいるパターンを発見しました。

障害駆動型開発は基本的に、バグ/機能が受け入れ基準を備えたタスクやストーリーではなく、欠陥追跡ソフトウェアに入力された欠陥によって導かれるアジャイルなリリース/反復サイクルとして記述できます。

私たちのチームには、顧客からの受け入れ基準の取得に努める優れたプロジェクトマネージャーがいますが、常に可能であるとは限りません。私の開発委員長から、これは顧客が自分が望むものを正確に知らないか、顧客の本社の2つの異なる「キャンプ」がストーリーの実装方法と対立するためです。キャンプAは、機能Xがこのように機能することを大まかに指示し、キャンプBはそのように機能しないために失敗します。したがって、「FDD」という用語。プロセスは「失敗」によって駆動されます。

これは私の質問につながります：他の誰かがこれに遭遇しましたか？もしそうなら、それを扱うためのヒント/提案はありますか？

もちろん、キャンプAとBが事前に同意するように試みましたが、これは必ずしもそうではないことを誰もが知っています。

ありがとう

企業の世界では、激しく対立する要件は珍しいことではありません。そして、これがビジネスプロセス自動化プロジェクトが「失敗」する理由です。「ポリシーと手順のマニュアルではXを実行するように指示されている」という単純なこともありますが、実際に作業を行う人はYを実行します。視点。ソフトウェアをXにすることは、実際に仕事を成し遂げる人々が仕事を成し遂げることができないことを意味します。

通常、ほとんどの開発会社は、労働者が何を述べているかについてマネージャーが言うことを選択します。なぜなら、それが請求書の支払い方法だからです。理想的な世界では、書面のポリシーと実際のポリシーの間にインピーダンスの不一致はありません。現実の世界では、多くの事務作業は非公式に分割され、文書化されていません。

キャンプAは機能Xがこのように機能することを誤って指示し、キャンプBはそのように機能しないために失敗します。

CampAとCampBの不一致は政治的な問題であり、ソフトウェアの問題ではありません。問題を解決するには、人と話をして、明確な勝者を1人獲得する必要があります。

反復開発を使用する主な理由の1つは、顧客グループが何を望んでいるかをよく理解していないためです。

これは失敗ではありません。多くのお客様は、何かを手に入れるまで、必要なものを正確に把握していません。これが、顧客が最初にシステムがすべての適合と仕上げが完了した後であってはならないことを理解した理由です。早く、頻繁にそれを見せてください。

言い換えれば、それが唯一の問題であれば、無限に再試行するだけの状況に陥らない限り、パニックする必要はありません。

顧客団体間の意見の不一致の問題は、あなたに漏れてはならないプロダクトマネージャーの問題です。あなたが見るべきほとんどは、バックログ/タスク/何でもです。もちろん、PMは開発の範囲内でしか発散しません。なぜなら、それが彼らができる唯一の場所だからです。しかし、それはあなたに影響を与えるべきではありません。

管理方法は、キャンプAとキャンプBが誰であるかによって大きく異なります。

キャンプAとキャンプBが2つの上位を表す場合、実際にシステムを使用する人を招いて必要なものを教えてください。時々、管理用の土地で希薄な空気を取得し、現実との接続を切断します。実践的な人は、しばしば理想主義を切り抜けて、本当に必要なものを指摘することができます。

一方、AとBがユーザーグループである場合、経営陣から誰かに法律を制定させるという反対のタックを使用します。

すべての場合において、完璧は十分な敵です。

あなたが説明するのは、アジャイルの典型的な間違った実装です。あなたは変化を受け入れません、あなたはその奴隷です。

製品の所有者はいますか？必要に応じて彼らと話せますか？ユーザーとスプリントレビューを行っていますか？ユーザーはスプリント計画のプロセスに（製品所有者を通じて）関与していますか？メインチームにテスターはいますか？

アジャイルコーチを雇うか、チームをトレーニングに送ることを強くお勧めします。

別の解決策は、アジャイルをやめることです。

ピンポン（Aがxを拒否、Bが拒否、Yを通知、Aが拒否してxに戻る）の場合、リード（POまたはあなたが持っているもの）が彼らを打ち負かす必要があります。

最初の行程が彼らのニーズを満たしていない場合は問題ありません（これの要点は、彼らに見せるものを与えることです）が、彼らがそこに座って、後続の反復で前後にスイングする場合、あなたは決して終わらないでしょう。

ここでの問題は、「見ればわかる」ということではないようです。ワイヤフレームは、その特定の問題を（ある程度まで）助けることができます。

ここでの問題は、クライアント内の2つの競合する派factであるように思えます。理想的には、キャンプAとBは、彼らがあなたに提示できる交渉された共有ビジョンを思いつくでしょう。

おそらく、AがBに求めたもの（またはその逆）をもう一度やり直すときに、戦闘中にどれだけのコストがかかるかを説明することによって、彼らはテーブルに追いやられるかもしれません。

ここでは、時間の消費に関する詳細なメモを保存しておくと役立ちます。（私の作品は軽量のタイムトラッキングアプリケーションを作成しました。使いやすく、レポートが簡単で、15分単位で時間をレポートします。「機能Xにn時間を費やした」と言うのは簡単です。）

Bに対して行ったことがAをひっくり返す可能性があるため（または、逆も同様）、クライアントを動揺させたり、見た目が悪くなったりするリスクがあることを意味します。

うまくいけば、あなたはあなたのために内乱の世話をすることができるクライアントでチャンピオンを見つけることができます。

私が見ているように、問題は、顧客側で1か所でしか効果的に解決できませんが、これは困難になるでしょう。

あなたはアジャイルのために努力していると言っているので、スクラムの観点からそれを取り上げます。スクラムは私が最もよく知っているアジャイルプロセスです。

スクラムによると、ユーザーストーリー/バグ/リリースなどの優先順位付けを担当する製品所有者という特定の役割があります。これは理想的には一人である必要があります。同じソフトウェアに対して異なる意見を持つ多くの利害関係者がいる場合、製品がすべての利害関係者を満足させるのは製品所有者の責任です。

プロジェクトマネージャーがこの役割を担っていると思います。しかし、彼はプロダクトオーナーではなくプロジェクトマネージャーと呼ばれているため、他のタスク（従来の、非アジャイル、管理タスク？）にも負担がかかり、それを追求するのに十分な時間がないと信じられます。製品所有者の役割。

そのため、お客様の異なるチーム間でニーズを調整する責任を持つ1人の人物が必要であり、開発者に配信される要件/ユーザーストーリーがお客様の両方のチームによって検証されていることを確認する必要があります。この役割を追求することは、特にあなたがいる顧客にとっては、簡単にフルタイムの仕事になる可能性があります。

本当に理想的なのは、この責任を顧客に移し、顧客の従業員の1人に製品所有者の役割を持たせることです。顧客がこの役割を持たない限り、顧客は自分の内部の不一致を解決することを約束しません。顧客はそれを解決するためにあなたに任せます。そして、それが私が唯一の効果的な解決策が顧客にこの責任を与えることであると信じる理由です。

しかし、既にコラボレーションを開始しているという事実を考えると、その変更を実装するのに苦労すると思います。

顧客にソフトウェアを受け入れてもらうためには、受け入れ基準に従って顧客が設定した要件を満たす必要があります。

ストーリーと受け入れ基準の形でユーザー要件のセットを持っていますが、顧客組織の一部ではユーザーストーリーの解釈が異なるため、あいまいさが生じます。

このような状況から抜け出すには、機能設計と実装されたビジネスルールを説明し、これらを顧客が署名するようにします。これらは、受け入れ時にテストされるものになります。これは、その後すべての文書の意味についての議論を防ぐために、事前に顧客が同意する必要があります。

両方のグループが同意するような方法で、作成しているソフトウェアをグループが記述できない限り、プロジェクトの要件分析フェーズにあります。

プロジェクトマネージャーは、機能要件のあいまいさを解決するために、プロジェクトの一環として有料コンサルタントを提供できる/すべきです。

私たちはすべて、ユーザーから詳細な要件を取得し、それらを実装し、それが実装されると「待ってください、それは私にとってはうまくいきません」とユーザーから聞く場合を見てきました。

役立つことの1つは、予想されるシステムの動作をユーザーに詳細な例を提供することで、要件に関するQAの形式を実行することです。たとえば、「ここに例があります。Xを実装すると、Yが結果になり、Zが結果の1つになります」と言うことができます。そうすれば、後ではなくコードを記述する前に、「待って、うまくいきません」に到達できます。