アジャイルプロジェクトで顧客/開発者文化の不一致に対処する

アジャイルの教義の一つは...

契約交渉を介した顧客コラボレーション

...もう1つは...

プロセスとツールを介した個人と相互作用

しかし、少なくとも顧客とのやり取りに関しては、根本的な問題があります。

顧客の考え方は、ソフトウェアエンジニアの考え方とは異なります

はい、それは少し一般化するかもしれません。間違いなく、そこにあるこれは必ずしも真実ではないところの事業領域は---これらは少数とはるかにかかわらず、間にあります。ただし、多くのドメインでは、典型的な顧客は次のとおりです。

1. 日常の運用上の懸念に関心がある-短距離戦術...必ずしも戦略ではない;
2. 当然のことながら、当面の解決策のみに関係します。
3. 抽象的思想家ではなく、実践的思想家。
4. ソリューションが将来の懸念をどのようにサポートするかを検討するよりも、「仕事をやり遂げる」ことにずっと興味があります。

一方、理想的には、アジャイルを実践するソフトウェアエンジニアは次のとおりです。

1. 品質についてよく考える人。
2. 少し前もって作業することで、後の労力を大幅に節約できることに感謝する個人。
3. 経験豊富な分析的思想家。

そのため、「顧客コラボレーション」を阻害する傾向がある文化の不一致があるようです。

これに対処する最良の方法は何ですか？

ただし、多くのドメインでは、典型的な顧客は次のとおりです。

• 日常の運用上の懸念に興味がある-短距離戦術...戦略ではなく、
• 即時の解決策のみに関心があります。
• 一般に、一次元の抽象的なない思想家。
• 永続的で質の高いソリューションを思い付くのではなく、主に「仕事を終わらせる」ことに関心がある。

そして、率直に言って、彼らは通常、このように考える十分な理由があります。まず第一に、彼らはビジネスを運営しており、それは遠い将来ではなく、今日と明日に収益を生み出すはずです。第二に、彼らは技術の専門家ではありません-何が可能で何ができないのか、そして特定のアーキテクチャ/設計/実装の選択の結果が何であるかを知りません。これは私たちが知っていることです。

したがって、答えは-驚くことではない- コミュニケーションです。

お互いを教育し、お互いに少なくとも基本的なレベルまで相手の視点を理解させるために、あなたはたくさんのコミュニケーションをとる必要があります。あなたは彼らに可能な選択肢の短期的および長期的な結果を説明する必要があります。そして、あなたは彼らが理解する言語を使用する必要があります。

• あなたが言うならば、「これは、コードが読みにくくかつ拡張可能ハック、だろう」、彼らは言う、「ええ、何でも」。
• あなたが言うならば、「これは長期的な開発と保守をより高価にすると、バグを導入するリスクを増加させる短期修正、だろう」、彼らは言う、「HAは、のは、考えてみましょう」。
• そして、「このソリューションは現在100ドルかかりますが、遅かれ早かれ利子付きで返済しなければならない500ドルの技術的負債を導入します。欲しい」、彼らは「今、私たちは話している！」と言います。。

OTOHは、ビジネスの観点について1つまたは2つ教えてくれます。ビジネスは使いやすく、十分な -ほとんど完璧ではない-ソリューションを求めている。そして、彼らはおそらく「完璧は善の敵」であることを誰よりもよく知っています。したがって、技術的に完璧なソフトウェアを作成するのではなく、クライアントの問題の解決策を提供することが私たちの仕事であることを忘れないでください。時々、これら2つは同じに収束しますが、より頻繁には収束しません。これは多くの人に悲しいと思われるかもしれませんが、ビジネスの現実です。私にとっては、なんとか顧客の問題を解決でき、それが彼らの生活を目に見えて楽にしたと思うなら、私は彼らと同じくらい幸せです。OTOH私が思い描いていた完璧なデザインを実装できたのに、翌週に会社が倒産した場合、それは誰にとってもほとんど勝利ではないでしょうか？

賢明なビジネスオーナーは、あなたが彼ら自身の言語を使って説明するなら、なぜソフトウェアをきれいに保ち、ユニットテストを書き、リファクタリングすることが重要なのか理解します。長期メンテナンスには不可欠です。そして、賢明な顧客はビジネスの長期的な保守性を気にしているので、投資が生み出す価値を見たとき、彼らは確かにそれに投資することをいとわないでしょう。ただし、リソースと時間の両方が限られているため、最も重要なことに優先順位を付けて集中する必要があります。しかし、それはあなたとあなたの両方にとって重要である場合にのみ重要です。

モジュールAのリファクタリングが必要な場合があります。そこにあるコードはひどく、読んだばかりのデザインパターンを使用して、簡潔でエレガントでクリーンなコードにリファクタリングする方法が驚くべきアイデアです。ただし、そのモジュールが何年も触れられておらず、確実に機能する場合は、モジュールBに焦点を当てたほうがよいでしょう。モジュールBは来週、非常に重要な新機能で拡張され、多数のバグが含まれます既に。

顧客が自分をどのように見ているか：

• 私はできるだけ早く完了する必要があるプロジェクトを持っています
• ビジネスニーズを知っている
• 現在のビジネス慣行を混乱させない方法で問題を解決する必要がある
• これを実現するための予算は限られています。

一方、彼らはあなたのグループを次のように見ています。

• 私の予算からお金を吸い取っていることを理解していない人。
• 私たちのビジネスのニーズを理解しないでください
• ビジネスでの実装が難しくなる場合でも、すべてを再設計したい。
• 機能的かつ効果的な予算がある場合に、巧妙で洗練されたソリューションが必要です。

あなたの主な問題は、どちらも相手から必要なものを理解していないことのようです。

まあ、何よりもまず、アジャイルはプロジェクトにあるすべての問題の解決策ではありません。

顧客の考え方は、ソフトウェアエンジニアの考え方とは根本的に異なります

はい。時々それは本当です。顧客が何をどのように望んでいるかわからない場合もあります（つまり、要件が明確ではありません）。これまでのところ、アジャイルであれば、各スプリント（2週間など）の後に結果が得られ、顧客からのフィードバックを得て、すべてが同じページにあることを確認する機会が得られます。これは、問題を早期に特定して修正するのに役立ち、内部的に信頼を構築するのに役立ちます。

また、ユーザーは狂った子供のようであるため、銃を求めているときに安全ではないことがわかっている場合は、おもちゃの銃を与えて落ち着かせることができます。

これに対処する最良の方法は何ですか？

私がすでに言ったように、これらすべての問題を解決できる魔法の杖はありません。お互いが何をしているのかをよく理解するために、顧客ともっと関わり合う必要があります。サイト訪問、オープンフィードバックなどを促進します。

製品所有者と利害関係者がスプリントデモに参加し、製品を改善するための貴重な提案を行っていることを確認してください。

顧客からの同意がない場合、アジャイルはほとんど不可能です。

バイインとは、1週間または1か月あたりの顧客担当者の時間の一部を保証するという意味です。この割合はプロジェクトによって異なります。

明らかに彼らは彼らの日常の仕事を持っているので、それは彼ら自身の顧客担当者だけではなく、彼らのために時間を作ることは彼らの管理者にかかっています。

したがって、顧客側の経営陣から同意を得ることがこの問題の鍵です

アジャイルとは、顧客が毎日のスタンドアップやアジャイルの他の日々の側面に関与していることを意味するものではないことを忘れないでください。顧客の観点から見ると、アジャイルはコミュニケーションに関するものです。それは彼らが実装の詳細についてエンジニアと通信しているという意味ではありません。

顧客は製品所有者と協力して、絶え間ないフィードバックを取得および提供します。トピックは機能ですが、実装方法ではありません。適切な機能を提供していますか？スケジュールどおりですか？順応する必要のある要件が変化していますか？

アジャイルは、あなたとあなたの顧客がこれらの質問に答えるのを助けます。