クライアントの関与なしにアジャイルを達成できますか？

アジャイルに関する本を書くことができませんでした。私は彼らのプロセスをアジャイルと呼ぶいくつかの店で働いてきました。アジャイル開発の主なポイントの1つは、定期的なクライアントの関与です。スプリントの後、フィードバックを得るためにクライアントに作業をデモすることができます。すすぎ、繰り返します。

私が出くわす問題は、多くのクライアントがそのようになりたくないということです。彼らは、ウォーターフォールアプローチを好むでしょう。要件を事前に収集し、完了したら戻ってください。私の経験では、滝は機能しません。クライアントは、それを見るまで何が欲しいかを知りません。ウォーターフォールのジレンマは、すべての要件を事前に取得したい開発者の大規模なコミュニティによってさらに広まります。このようにして、彼らは自分が何を構築しているのかを知り、それに応じて設計することができます。そして、クライアントは、前述の要件に「サインオフ」したので責任があります。

私は間違っていますか？クライアントの関与なしにアジャイルは機能しますか？もしそうなら、私が議論した問題をどのように、どのように克服しますか？

どうして？技術の性質そのものが、顧客と開発者の間の何らかのフィードバックループを決定します。

ただし、チームの一部は「代理」顧客（「自分のドッグフードを食べる」と同様のプロセス）として機能できるため、実際の顧客を獲得するほど満足のいくものではありませんが、機敏に「ふり」をすることができます。フィードバック。

好むと好まざるとにかかわらず、顧客は設計プロセスに関与します。やり直しにどれだけの費用がかかるかだけです（遅延が長くなるほど、費用がかかります）。

顧客は「前もって大きな設計」を望んでいるので、最初に設計を正しくするためには、より多くの時間と労力が前もってかかることを理解するのに役立ちます。

あなたの質問に対する短い答えは「いいえ」です。ここにあなたの質問のいくつかの部分に関するコメントがあります。正確であるために、答えのほとんどは私の個人的な経験と観察に基づいています。

私の経験では、滝は機能しません。

ウォーターフォールは、さまざまな複雑さのシステムを提供するための適切な方法論です。残念ながら、十分に提示または理解されていません。その理由の1つは、ポップアップし続けるその日の方法論と競合する十分なお金を稼げないことです。銀行、保険、および製造システムの多くがウォーターフォールアプローチのみを使用して構築され、それらの多くが現在も生産されていることを知って驚くかもしれません。ソフトウェア業界が科学よりも誇大宣伝に基づいているのは悲しいことです。

クライアントは、それを見るまで何が欲しいかを知りません。

これは神話です。大きなものも。これはWebページの設計/レイアウトの場合かもしれませんが、ビジネスデータ処理では、ほとんどのユーザーが機能するものを求めています。これらのユーザーの一部は、AS / 400画面とRGBを備えた3270 CICSモニターを引き続き使用しており、これらのツールを使用してビジネスを遂行できます。また、これらの同じユーザーは、インターフェースの設計（および機能の一部）について何も言うことなく、SAPおよびORACLE ERPシステムを受け入れます。ほとんどのビジネスユーザーは、システムが適切な機能を提供している場合、仕事の習慣や流れさえ調整します。ここでのストレスは外見ではなく機能にあります。ビジネスの人々は、自分の仕事のやり方を90％の時間で非常によく理解しています。

ウォーターフォールのジレンマは、すべての要件を事前に取得したい開発者の大規模なコミュニティによってさらに広まります。このようにして、彼らは自分が何を構築しているのかを知り、それに応じて設計することができます。そして、クライアントは、前述の要件に「サインオフ」したので責任があります。

開発者が自分が何を構築しているのか知りたがっているのは、開発者を非難することはできません。それは彼らの現在のスキルセットを置き換えるでしょう！非難のゲームは誰も勝者になりません。各当事者の役割と責任の観点から考えると、状況は非常に明確になります。

結論として、プロジェクトマネージャー、プログラマー、およびWebデザイナーは、方法論に関係なくエンドユーザーから要件を収集する方法を知っている必要があるビジネスアナリストに代わるものではありません。

彼らは時間を使いたくありませんし、選択肢が与えられれば、ソフトウェアを無料で手に入れたいのですが、あなたはまだそれらを請求するつもりですよね？会社のソフトウェアを社内で開発している場合、これはぼやけます。彼らは、IT部門が（給与のかかった従業員）を購入して支払いをしたと考えているので、できるだけ多くの仕事をあなたから得られるかもしれません。

あなたは潜在的に機敏になることができます。すべての仕様を取得し、コーディングを開始します。クライアントが何かを考えただけで作業を中断し、変更とリワークを行う必要があると、もう少し機敏になりました。チーム内で承認を行うこともできます。チームの1人にスーツを着せ、ネクタイをして顧客になりすます。

前もって大きな時間を費やすことは、彼らを恐れさせるかもしれません。スプリントを試してみてください。次に、オプトアウトする機会を与えます。プロジェクトの残りの部分は、いつでもウォーターフォールに移行できます。また、チェックを書く人にとって時間が制約である場合、チームのさまざまな人々がレビューを行い、承認できることを提案します。

ある時点で、滝が機能するとは思わないと伝えなければなりません。彼らにこのアプローチに満足しているかどうか尋ね、もしそうなら、最後の人にこのプロジェクトをしてもらいませんか？

クライアントの関与なしに機能する方法論はありません。私が参加したプロジェクトで目撃したように、要件にサインオフしても意味がありません。あなたの問題はアジャイルを行うことができることを超えており、クライアントを教育し、彼らが参加することの重要性を彼らが理解していることを確認する必要があります。

アジャイルの主な利点の1つは、各機能全体のより詳細な要件を取得できることだと思います。クライアントがすべての要件を事前に提供すると、各機能は曖昧なアイデアになりがちで、機能が少し定義されます。アジャイルは、クライアントに各機能を再検討させ、彼らが望むものとその機能がどのように全体像に適合するかを正確に集中させます。この同じ量の詳細（機能を実装するのに十分な詳細）を仕様に取り込むには、ウォーターフォールでは実際に次の2つのいずれかを行う必要があります。

1. 推測。あいまいなものに遭遇するまで実装し、その機能がどのように実装されるのが最適かを判断します。これは明らかに理想的ではありません。「待って、それは私が求めたものではない！」につながるからです。シナリオ。

2. 事前に設計をさらに重視します。基本的に、クライアントが初日にあなたに中途半端な仕様を投げたとき、何かを実装する前に毎分詳細を調べることを計画します。クライアントに、プロジェクト全体のすべての実装の詳細を知っている点まで、すべての吐き気を明確にするように依頼します。完璧ではありませんが、これはオプション1よりも優れています。まだ予想していなかった詳細に遭遇する可能性があり、丘を走るクライアントを送信することもありますが、開発中とサイキックではありません、これは必要です。これは基本的に滝であり、適切に実行するのが非常に難しいことなど、関連するすべての欠点があります。

3. 中途半端な仕様を取りますが、とにかく行くときに説明を求めます。仕様の曖昧な部分に達するまで作業し、クライアントに明確にするよう依頼します。もちろん、これはクライアントが求めたものではありませんが、仕様と同じくらい曖昧なアプリケーションを望んでおらず、仕様を前もって定義することを拒否する場合、これは残りのオプションです。アジャイルのすべての利点（全員が同じページにいることを確認するための定期的なクライアント承認など）はありませんが、開発に必要な情報を取得することはできます。オプション1はおそらくサブパープロダクトを提供するため、オプション2は無駄であり、クライアントにイライラさせられます（完全に前もって行う場合、設計と仕様の収集に少なくとも2倍の時間を費やす必要があります）。これは本当に悪いオプションではありません。ここで重要なのは、変更が発生するたびにタイムラインと価格を変更することです。正しく行うと、クライアントがそれを知らなくても、アジャイルプラクティスの大部分がこのアレンジメントと互換性があることがわかります。私見、これはアジャイルの精神に沿ったもので、特定のアレンジメントに方法論を適応させることになっています。

クライアントがこれらの3つのオプションのいずれか、または本格的なアジャイルの結果で本当に生きられない場合、このクライアントが本当にあなたの価値があるのか​​想像するのに苦労します。

難しいとは思いますが、それでも可能です。ロバートのプロキシのアイデアは機能すると思いますが、プロキシが「本物の」クライアントとできるだけ多くの時間を費やして、彼らの観点から物事を見ることができるようにする必要があります。こうすることで、プロキシはどの機能が本当に重要であるかを確認し、クライアントが期待/望んでいるユーザーエクスペリエンスを体感できます。

しかし、ある時点で、ソフトウェアを「実際の」クライアントに見せなければなりません...

実際の顧客を回避することは可能ですが、実際には規制に必要な場合があります。通常、医療ソフトウェアの顧客は関与しません。そのような場合、他のエンティティが顧客の役割を代用する場合があります。たとえば、マーケティングチームを顧客と見なすことができます。

アジャイルは、ハードである大きな先行設計を置き換えるためにタイトなループを必要とします-かなりハードですが、実際には実行できますが、アジャイルが唯一の方法ではありません。

アジャイルの修正版の1つを見つけることをお勧めします。多くの場合、この特定の問題に対処する可能性がありますが、可能な場合は独自の修正を行います。

これらのプロセスはすべて、賢い人々によって構成されていました。そして、賢い人々はあらゆるプロセスを機能させることができます。滝は誰のためにも機能しなかったので発明されたとは思わないのですか？一部の人々はそれを機能させることができたので進化し、他の人はそれを見て、「それを改善し、効果的に生産できないように見えるMYチームにそれを供給しなければならない」と述べました。しかし、すべてのプログラマーがすべての問題を解決できるわけではないことを認識していない場合、同じプロセスを使用する2つのチームが異なる結果を得る理由を本当に困惑させる可能性があります。

問題は、多くのプロセスがそれらを実装するために才能を必要とすることです-私たちは、これまでスポーツをしたことがあるすべての人のプールからプロスポーツ選手のようにまれな才能を話している-私たちのほとんどは作ることができる誰かに会ったことがないウォーターフォールのような安っぽいプロセスは、それが非常に多くの人々がそれが成功できないと思う理由です-彼らはそれを見たことがありません。

アジャイルを機能させるのに必要な才能ははるかに少なくなりますが、エラーが広がらないように顧客が常に何をしているのかを顧客に見てもらうなど、非常に具体的な投資が必要です。チームが数ヶ月先に解くことができない技術的負債。

顧客を定義します。

別の会社ですか？もう一人？

社内の別のチームですか？

社内の製品チャンピオンですか？

あなたですか？

上記のすべてが可能であり、状況に応じて非常に合理的です。アジャイルであるということについて、トンネルを1つの視点で見たくないので、決定的なNOは間違っていると言えます。一方、「はい」には少し横方向の思考が必要です。

アジャイルという言葉について少し考えてみてください。この用語を生み出した人々の非常に賢いグループは、彼らが説明しようとしている概念のより良い比metaを選ぶことはできなかったでしょう。Agilityと言うとき、何が思い浮かびますか？艦隊ですか？おそらく反応が速い？適応が速い？

次に、一般に受け入れられているアジャイルの慣行すべてについて考え、アジャイルと見なされるソフトウェア開発方法に実際にもたらすものを考えてみてください。

私は、ソロプロジェクトのすべての意図と目的の顧客です。顧客の役割に独特の精神的な変化を本当にしたいとき、私は時々本当の帽子をかぶっています。これにより、仕事中にいるときよりもアジャイルになります。私が気にするすべてのために、私の猫はマネージャーになることができます。彼は私が時々休憩を取ることを確認し、1つのタスクに夢中になりすぎないように思い出させます。派手な「ポマドーロテクニック」を使用することを好むかもしれませんが、「ラスカル」タイマーが好きです!! 問題は、自分でコードを書くときは常にアジャイルプロセスで作業することです。私は、ハッカー・カム・カウボーイ型ではなく、無限の開発スパイクの人生を生き、何も達成しません。私はソフトウェアを作成し、仕事と私生活の周りで開発をスケジュールし、実際の顧客のために働いている場合に期待する方法でそれを完了するのが好きです。物事がスケジュールを中断するとき、それに応じてプロジェクト作業を調整し、優先順位を付けます。ソロを適用できる標準のアジャイルのプラクティスとテクニックをすべて使用し、「配信」します できる限り頻繁に自分自身（またはテストする友人や同僚）にコードを実行します。このすべてがアジャイルでない場合、私はあなたに何を尋ねますか？

ですから、私の答えはYesです。あなたはアジャイルソフトウェア開発者になれますし、アジャイル方法論を適用できます。あなたは必ずしも顧客もマネージャーも必要としないでしょう。自分でプロジェクトに取り組み、複数の帽子をかぶることができます。ただし、目標を達成するために他の人と協力することは非常に役立つため、これらの他の役割を廃止することは必ずしも理想的ではありません。彼らはあなたのアイデアの響き板として機能し、あなた自身で賢明に生成するのが難しいと感じるかもしれない要件を満たします。顧客とマネージャーが満足するもう1つの非常に重要な役割は、機能を際限なく追加したり、厳密に必要なものを超えてコードを洗練したりすることなく、目標に集中できるようにすることです。

それでも、あなたが選択した方法論に厳守し、アジャイルプラクティスを適用し、規律のある方法で作業し、サイドトラックを取得したとき、または顧客の帽子をかぶったとき）製品のデザインや方向を変える場合スケジュールを調整し、顧客が期待するとおりに優先順位を調整できる場合は、順番を取り、アジャイルになります。