クライアントの関与なしにアジャイルを実現できますか？
私はアジャイルについて本を書くことができませんでした。私は彼らのプロセスをアジャイルと呼ぶいくつかの店で働いてきました。アジャイル開発の主要なポイントの1つは、定期的なクライアントの関与です。スプリントの後、作品をクライアントにデモして、フィードバックを得ることができます。すすぎ、繰り返します。
私が遭遇する問題は、多くのクライアントがそれに関与したくないことです。彼らは滝のアプローチを好むでしょう。要件を事前に収集し、完了したら戻ってきます。私の経験では、滝は機能しません。クライアントは、それが表示されるまで、何が必要かを知りません。ウォーターフォールのジレンマは、すべての要件を事前に設定したい開発者の大規模なコミュニティによってさらに広がっています。このようにして、彼らは自分たちが何を構築しているのかを理解し、それに応じて設計することができます。クライアントは、これらの要件に「サインオフ」したため、非難されます。
私は間違っていますか？アジャイルはクライアントの関与なしに機能しますか？もしそうなら、私が議論した問題をどのようにそしてどのように克服しますか？
どうして？この手法の性質により、顧客と開発者の間のある種のフィードバックループが決まります。
ただし、チームの一部は「代理」顧客（「自分のドッグフードを食べる」と同様のプロセス）として機能できるため、俊敏であるように「見せかける」ことができます。フィードバック。
好むと好まざるとにかかわらず、お客様は設計プロセスに関与します。それは彼らがリワークにどれだけのコストをかけたいかだけの問題です（それが遅れるほど、それはより高価になります）。
お客様は「Big Design Up Front」を望んでいるため、最初から設計を正しく行うには、事前に多くの時間と労力を費やす必要があることを理解してもらいます。
あなたの質問への短い答えは「いいえ」です。ここにあなたの質問のいくつかの部分についてのコメントがあります。正確に言うと、ほとんどの答えは私の個人的な経験と観察に基づいています。
私の経験では、滝は機能しません。
ウォーターフォールは、さまざまな複雑さのシステムを提供するための適切な方法です。残念ながら、十分に提示または理解されていません。その理由の1つは、ポップアップし続ける今日の方法論と競合して十分なお金を稼ぐことができないことです。銀行、保険、製造システムの多くはウォーターフォールアプローチのみを使用して構築されており、それらの多くは現在も生産されていることに驚かれるかもしれません。ソフトウェア業界が科学よりも誇大宣伝に基づいていることは悲しいことです。
クライアントは、それが表示されるまで、何が必要かを知りません。
これは神話です。大きなものも。これは、Webページのデザイン/レイアウトの場合に当てはまるかもしれませんが、ビジネスデータ処理の場合、ほとんどのユーザーは機能するものを望んでいます。それらのユーザーの一部は、AS/400画面とRGBを備えた3270 CICSモニターをまだ使用しており、それらのツールを使用してビジネスを遂行できます。また、これらの同じユーザーは、SAPとOracleを受け入れますERPシステムは、インターフェースの設計（および場合によっては機能性）で何も言わずに使用します。ほとんどのビジネスユーザーは、作業の習慣とフローを調整します。システムが正しい機能を生成している場合、ここでのストレスは機能の見た目ではなく、ビジネスパーソンは90％の確率で自分の作業を非常によく理解しています。
ウォーターフォールのジレンマは、すべての要件を事前に設定したい開発者の大規模なコミュニティによってさらに広がっています。このようにして、彼らは自分たちが何を構築しているのかを理解し、それに応じて設計することができます。クライアントは、これらの要件に「サインオフ」したので非難されます。
開発者が自分たちが何を作っているのかを知りたいと非難することはできません。なぜなら、開発者は3時間ほどかけて次の技術を習得した後、夕食を家に持ち帰り、シャツに別のドリルを押したいからです。それは彼らの現在のスキルセットを置き換えるでしょう！非難ゲームは誰も勝者にはなりません。各当事者の役割と責任について考えれば、状況は非常に明確になります。
結論として、プロジェクトマネージャー、プログラマー、およびWebデザイナーは、方法論に関係なくエンドユーザーから要件を収集する方法を知っているビジネスアナリストに代わるものではありません。
アジャイルの主な利点の1つは、各機能全体のより詳細な要件を取得できることです。クライアントがすべての要件を事前に提示すると、各機能は曖昧なアイデアになりがちで、少し機能が定義されます。アジャイルは、クライアントに各機能を再訪させ、正確に彼らが何を望んでいるか、そしてどのように機能が全体像に適合するかに焦点を当てます。この同じ量の詳細（機能を実装するのに十分な詳細）を仕様に取り込むには、ウォーターフォールで実際に次の2つのいずれかを実行する必要があります。
推測。曖昧なものに出くわすまで実装し、その機能が最も実装されていると感じる方法を判断してください。これは「待ってください、それは私が求めたものではありません！」につながるため、明らかに理想的ではありません。シナリオ。
事前に設計にはるかに重点を置きます。基本的に、クライアントが初日、中途半端な仕様をあなたに投げかけたら、何かを実装する前に、細部に至るまで検討することを計画します。プロジェクト全体のすべての実装の詳細がわかるところまで、クライアントにすべて悪心を明確にするように依頼します。完璧ではありませんが、これはオプション1よりも優れています。まだ予期していない詳細に遭遇する可能性があり、丘のために実行中のクライアントを送信する可能性もありますが、開発中に通信したくない場合は、精神的ではない、これは必要です。これは基本的にウォーターフォールであり、適切に実行することが非常に難しいことを含め、関連するすべての欠点が伴います。
中途半端な仕様を採用しますが、とにかく進むときに説明を求めます。仕様のあいまいな部分に到達するまで作業し、クライアントに説明を求めます。もちろん、これはクライアントが要求したものではありませんが、仕様ほど曖昧なアプリケーションを望まず、仕様を事前に定義することを拒否したい場合は、これが残りの1つのオプションです。アジャイルのすべての利点（全員が同じページにいることを確認するための定期的なクライアントの承認など）はありませんが、開発に必要な情報を取得できます。オプション1はおそらく標準以下の製品を残すので、オプション2は無駄であり、クライアントにフラストレーションを与えます（完全に前もって行う場合は、設計と仕様収集に少なくとも2倍の時間を費やす必要があるでしょう）。これは本当に悪いオプションではありません。ここで重要なのは、発生する変更ごとにタイムラインと価格を変更することに熱心であることです。これを正しく行うと、クライアントが知らない場合でも、アジャイルプラクティスの大部分がこの配置と互換性があることに気付く場合があります。私見、これは実際にはアジャイルの精神に沿ったものであり、特定の方法に方法論を適合させることになっています。
これらの3つのオプションのいずれか、または本格的なアジャイルの結果にクライアントが本当に耐えられない場合、このクライアントが本当にあなたの価値があるとは想像できません。
彼らは時間をかけたくないし、選択肢が与えられれば無料でソフトウェアを入手したいのですが、あなたはまだ彼らに請求しますよね？会社の内部でソフトウェアを開発している場合、これは不鮮明になります。彼らは、IT部門が（給料を支払われた従業員）のために購入されて支払われていると考えているので、彼らはできる限り多くの仕事をあなたから得るでしょう。
あなたは潜在的に機敏になることができます。すべての仕様を入手してコーディングを開始してください。クライアントが何かを考えて変更を加えてやり直さなければならないためにクライアントが作業を中断すると、少し機敏になります。チーム内で承認を行うこともできます。チームの1人にスーツを着せてもらい、顧客のふりをさせます。
事前に大きな時間を費やすと、彼らを怖がらせる可能性があります。スプリントを試してみてください。次に、彼らにオプトアウトする機会を与えます。プロジェクトの残りの部分では、いつでも滝にシフトできます。また、チームのさまざまな人がレビューを行い、時間が小切手を書く人にとって制約である場合は承認することもできます。
ある時点で、滝が機能するとは思わないことを伝えなければなりません。彼らにこのアプローチに満足しているかどうか尋ね、もしそうであれば、最後の人にこのプロジェクトをやってもらいませんか？
方法論は、クライアントの関与なしには機能しません。参加したプロジェクトで見たように、要件にサインオフしても意味がありません。あなたの問題はアジャイルを実行できることを超えて、あなたはあなたのクライアントを教育し、彼らが参加することがどれほど重要であるかを彼らが理解していることを確認する必要があります。
難しいですが、それでも可能だと思います。ロバートのプロキシのアイデアはうまくいくと思いますが、プロキシが「実際の」クライアントと可能な限り多くの時間を費やして、彼らが自分の視点から物事を見ることができるようにする必要があります。このようにして、プロキシはどの機能が本当に重要であるかを確認し、クライアントが期待する/望むユーザーエクスペリエンスの感触をつかむことができます。
しかし、ある時点で、ソフトウェアを「実際の」クライアントに提示する必要があります...
実際の顧客を回避することは可能であり、実際には規制に必要な場合もあります。通常、医療ソフトウェアの顧客は関与していません。これらの場合、他のエンティティが顧客の役割を代用する可能性があります。たとえば、マーケティングチームは顧客と見なすことができます。
アジャイルは、ハードである大きな事前設計を置き換えるためにタイトなループを必要とします-かなりハードですが、実際にはそれが可能であり、アジャイルが唯一の方法ではありません。
アジャイルの修正の1つを見つけたいと思うかもしれません-たくさんあり、おそらく1つはこの特定の問題に対処しますが、可能であれば自分で修正しないでください。
これらのプロセスはすべてスマートピープルによって構成されており、スマートピープルはあらゆるプロセスを機能させることができます。あなたは滝が誰のためにも働いたことがないので発明されたとは思わないのですか？一部の人々はそれを機能させることができるために進化し、他の人は「私はそれを洗練して、効果的に生産できないように見えるMYチームにフィードする必要がある」と考えて言ったために進化しました。しかし、すべてのプログラマーがすべての問題を解決できるわけではないことを認識していない場合、同じプロセスを使用する2つのチームが異なる結果をもたらす可能性がある理由に本当に困惑する可能性があります。
問題は、多くのプロセスがそれらを実装するために才能を必要とすることです-私たちは、これまでスポーツをしたことのあるすべての人のプールからプロスポーツ選手と同じくらい稀な才能を話します-多くの場合、私たちのほとんどは、作ることができる誰かに会ったことがありません滝のような不安定なプロセスが機能するため、多くの人が成功することはできないと考えています。
アジャイルを機能させるために必要な才能ははるかに少なくなりますが、エラーが伝播しないようにお客様が常に何をしているかを見てもらうなどの非常に具体的な投資が必要です。チームが数か月後には解決できない技術的負債。
顧客を定義します。
別の会社ですか？別の個人？
社内の別のチームですか？
それはあなたの会社内の製品チャンピオンですか？
あなたですか？
上記のすべてが可能であり、状況に応じてかなり合理的です。アジャイルとは何かについて、トンネルを一目見たくないので、決定的な[〜＃〜] no [〜＃〜]は正しくありません。 [〜＃〜] yes [〜＃〜]一方、少し横向きの考え方が必要です。
言葉について考えるアジャイル少しの間。用語を作り出した非常に賢い人々のグループは、彼らが説明しようとしている概念のためのより良い比喩を選ぶことができなかったでしょう。 Agilityと言うと、何が思い浮かびますか？足の艦隊？おそらく反応が速いですか？迅速に適応できますか？
ここで、一般に受け入れられているすべてのアジャイルプラクティスについて考え、それらがAgileと見なされるソフトウェア開発メソッドに本当に何をもたらすかを自問してください。
私はソロプロジェクトのすべての意図と目的の顧客です。 お客様の役割に際立った精神的な変化を加えたいと思っているときは、本物の帽子をかぶることもあります。これにより、私は職場にいるときと同じようにアジャイルになります。私が気にすることはすべて、私の猫はmanagerになります。彼は私が時々休憩をとることを確実にし、単一の仕事に夢中になるのを避けるように私に思い出させます。ファンシーな「ポマドーロテクニック」を好むかもしれませんが、私は「ラスカル」タイマーを好みます！自分でコードを書くときはいつでも、厳密にアジャイルなプロセスで作業します。私は、無限の開発スパイクの生活を送って何も達成しないハッカーカウボーイタイプではありません。私は自分のソフトウェアを作成し、自分の仕事と私生活を中心に開発をスケジュールし、実際の顧客のために働いていた場合に期待する方法でそれを完成させるのが好きです。スケジュールが邪魔されるときは、それに応じてプロジェクトの作業を調整し、優先順位を付けます。私は、ソロで適用できるすべての標準的なアジャイルのプラクティスとテクニックを使用し、自分自身（またはテストする友人や同僚）にできるだけ多くの作業コードを「提供」します。これらすべてがアジャイルでない場合、私はあなたに何を尋ねますか？
だから私の答えははいです。あなたはアジャイルソフトウェア開発者になることができ、アジャイル方法論を適用することができます。そして、必ずしも顧客やマネージャーさえも必要としません。一人でプロジェクトに取り組み、複数の帽子をかぶることができます。目標を達成するために他の人と協力することは非常に役立つので、それらの他の役割を廃止することは必ずしも理想的ではないかもしれません。それらはあなたのアイデアの土台として機能し、他の方法では自分で賢く生成するのが難しいと思われる要件を提供します。顧客とマネージャーが満足するもう1つの非常に重要な役割は、無限に機能を追加したり、厳密に必要なものを超えてコードを改良したりせずに、目標に集中できるようにすることです。
それでも、規律のある方法で作業し、選択した方法論に厳密に従って、アジャイルプラクティスを適用する場合、およびサイドトラックされる場合、または（顧客の帽子をかぶっている場合）気が変わり、製品の設計または方向性が変わった場合あなたがスケジュールを調整し、顧客が期待するように想像するように優先順位を調整できるなら、あなたは順番を取り、あなたはアジャイルです。