エクストリームプログラミングの実践により、アプリケーションはエラーが発生しやすくなりますか？[閉まっている]

私は、エクストリームプログラミングのトピックと、その実践がアプリケーションのエラーやバグのためのスペースを作ることにつながるかどうかについて、学術的な研究を行っています。

多くの人から集めた経験から、双方に当てはまるコメントがあります。多くの人がそれをサポートし、変化するプロジェクト要件を容易にすることができるダイナミクスでそれを毎日の必要性と見なしています。他の多くの人はそれが次のような多くの問題につながると主張します：

• プロセスでの顧客との過度の関わりは、ニーズではなく顧客の希望の表現につながります

• 多くの製品には複数の顧客がいて、ニーズと意見の対立を引き起こし、不要な封鎖を引き起こしています。

• 多くの製品には外部の顧客がなく、製品は内部で使用するため、または将来的に販売するために作られています。これらのケースでは、チーム自体が開発者だけでなくユーザーも演じているため、プロセスの有効性が失われています。

• 正式なドキュメントには多くのものが存在しません。この非公式性は曖昧なビジョンにつながり、これが私たちが求めたものではないなどと顧客が言う可能性がある問題を引き起こす可能性があります。

問題は、XPに関してこのような相反する意見が存在する理由です。異なるシナリオの問題ですか？他に何かありますか？（タイトルに書かれている）主張はどの程度真実ですか？

ここでXPを使用している、または使用した経験のある人に、学習と実際の経験を提供してほしい。回答を裏付ける事実や参照がある場合は理想的です。

その過程で顧客との過度の関わりは、ニーズではなく顧客の希望の表現につながります。

これは、顧客がシステムの要件に対してある種の完全なオラクルであると想定しています。XPの基本原則の1つは、顧客は完全なオラクルではなく、市場、顧客、そして最終的には利害関係者の真のニーズを判断するには、実際の出荷ソフトウェアに基づく継続的なフィードバックが必要であるということです。

多くの製品には複数の顧客がいて、ニーズと意見の対立につながり、不要な封鎖を引き起こしています。

はい、そうした顧客からの定期的な関与は、これらの矛盾を明確にし、時間をかけて解決するのに役立ちます。問題を非表示にしても問題は解消されません。

多くの製品には外部の顧客がなく、製品は内部で使用するため、または将来的に販売するために作られています。これらのケースでは、チーム自体が開発者だけでなくユーザーも演じているため、プロセスの有効性が失われています。

内部の利害関係者は、外部の利害関係者と根本的に異なるわけではありません。XP以外の方法でこの問題を処理する方法については説明していません。

正式なドキュメントには多くのものが存在しません。この非公式性は曖昧なビジョンにつながり、これが私たちが求めたものではないなどと顧客が言う可能性がある問題を引き起こす可能性があります。

XPは、利害関係者と開発者の間の頻繁な増分フィードバックを伴います。これらの通信障害が存在する場合は、初期の反復中に発見でき、その後の反復に大きな影響を与える前に修正できます。代替策は、これらの通信障害が製品の出荷直前まで検出されないことです。

基本的な誤解は、XPがこれらの問題を引き起こしていないということです。それらを公開するだけです。問題を早期に発見して修正するプロセスは、多くの場合、エラーが発生しにくい傾向にあります。

いくつかの考え：

• プロセスへの顧客の関与が多すぎると、ソフトウェアに対するニーズではなく、希望を表明し始める

詳細で安定した仕様を持つことと顧客に対応することの間には常にバランスがあります。極端とは、顧客への対応力を高めることを意味し、もちろん、その方向に行き過ぎることも可能です。したがって、これは正当な懸念事項です（特にプロジェクトの請求方法によって異なります。固定価格契約の場合は、明確に指定する必要があります）。

ただし、私の経験では、仕様がどれほど優れていても、「顧客が望むこと」を行うために仕様を変更する必要があることがよくあります。Extremeは、仕様に合わせて巨大で複雑なプログラムを作成した後ではなく、できるだけ早くそれらの変更を行うのに役立ちます。

• 多くの製品は複数の顧客を抱えており、ニーズの対立や不要な封鎖を招く意見につながります。

もちろん、そのような状況で相反するニーズを解決することは、常に、対処するための適切なプロセスが必要な問題です。顧客からのフィードバックを得るためのプロセスに時間がかかり、複雑になると、Extreme Programmingの効果が低下するため、これは正当な問題だと思います。

• 多くの製品には外部顧客がありません（それらのために作成された、または将来的に販売される製品組織）。この場合、チーム自体が開発者だけでなくユーザーも演じているため、プロセスの効果が失われています。

これはまったく正当なことではないと思います。Extremeの背後にある考え方は、実際に作り始めるまで顧客は何を望んでいるのかを理解しないということです。これは、外部の顧客と同様に内部の「顧客」にも当てはまります。

まだ顧客がいないもの（まだリリースされていない製品など）を開発している場合は、架空の顧客として行動し、人々が何を望むかを決定している誰か（または何らかのグループ）が必要です。Extremeは、顧客として行動する彼らと同様に機能します。

私はこのような製品に取り組んできましたが、これは外部の顧客を対象としたもので、まだリリースされていません。「Extreme Programming」というラベルは付けていませんが、広範な正式な仕様がなく、頻繁にビルドされる、同様の反復的な開発プロセスを使用しました。かなり効果的だと思いました。

• 正式なドキュメントには多くのものが存在しません。この非公式性は曖昧なビジョンにつながり、これが私たちが求めたものではないなどと顧客が言う可能性がある問題を引き起こす可能性があります。

はい、文書化されていないものは問題です。Extremeは、正式な仕様に基づいていないため、物事を文書化しない方が簡単な場合があります。ただし、Extremeが「文書化されていない」という意味ではありません。ドキュメントを作成する必要がありますが、事前にではなくプログラムと一緒に作成されます。また、場合によっては、実装後に動作を文書化することになります。これ自体は問題ではありません。

課金に関しては、作業を開始する前に、何が提供されるかを正確に文書化した文書が必要になることがよくあります。これは、Extreme Programmingではさらに困難になる可能性があります。

結論：Extremeは、他の方法と同様に、長所と短所がある方法論です。それを使用する（または教える）ときは、両方を覚えておく必要があります。

あなたの質問は、「顧客との直接のコミュニケーション」と「形式的なドキュメントが多すぎない」という2つの主要なXPトピックのみを扱っています。したがって、私の見解では、これは実際には「XP」の質問ではありません。これらは、私が知っている他のアジャイル開発プロセスの一部であるトピックです。

これが私の考えです。

プロセスへの顧客の関与が多すぎると、ソフトウェアに対するニーズではなく、希望を表明し始めます。

まあ、ウォーターフォールのようなプロセスがあり、事前に完全に詳細な仕様があり、多くの要件がある場合、これらの要件のうちどれが単なる希望であり、どれが実際のニーズであるかで問題が発生する可能性があります。これを明確にする最も簡単な方法は、お客様と話し、さまざまな代替案を示すIMHOです-明確にする必要がある場合はいつでも。したがって、まったく逆のことが当てはまります。「アジャイル開発」は、「ニーズvsウィッシュ」をより適切に処理するのに役立ちます。

多くの製品は複数の顧客を抱えており、ニーズの対立や不要な封鎖を招く意見につながります。

はい、事前に完全に詳細な仕様があれば、開発が始まる前にこれらの競合が解決されている可能性があります（運が良ければ）。アジャイルプロセスでのこの問題の解決策は、顧客側の少数の人だけが開発者と直接話をするようにし、競合が発生した場合に最終決定を下すことができる顧客の責任者が1人になることです。

多くの製品には外部顧客がありません（それらのために作成された、または将来的に販売される製品組織）。この場合、チーム自体が開発者だけでなくユーザーも演じているため、プロセスの効果が失われています。

いいえ、不正解です。開発者と同じ会社に所属する内部ユーザーのみがいる場合、「顧客オンサイト」は外部顧客しかいない場合よりもはるかに簡単にインストールできます。あなたが持っていない場合は何も手で直接ユーザーを、それが問題かもしれないが、それはアジャイル特有の問題ではありません-あなたは、代わりに潜在的なユーザの役割を取る誰かを見つける必要があります（この人は、典型的ではありません開発者チーム）。

正式なドキュメントには多くのものが存在しません。この非公式性は曖昧なビジョンにつながり、これが私たちが求めたものではないなどと顧客が言う可能性がある問題を引き起こす可能性があります。

私の経験では、顧客との継続的なコミュニケーションなしに正式な仕様に従って開発する場合、顧客が「私が尋ねたものではない」と顧客が言う何かを開発する可能性は、毎日顧客と話すときよりも100倍高くなります。それでもこの問題が発生する場合は、簡単な解決策があります。各カスタマーセッションの後に、同意した内容を短いメモに書いてください。必要に応じて、そのメモをお客様に送信し、修正する機会を提供します。これは、アジャイルプロセスだけでなく、他の種類のプロジェクトでも機能します。

Too much involvements of the customer in the process make him start expressing his wishes rather than his needs to the software

顧客のニーズに基づいてソフトウェアを開発していますか？顧客が望む場合はどうなりますか？「顧客よ、私は必要性に基づいてソフトウェアを構築するだけです！??」という理由で顧客を否定しますか？

私は極端なプログラミングとアジャイルショップでインターンしました。毎週、QAと開発者の頭を悩ませている直接の顧客との対話を目にしました。しかし、彼らは、顧客が望んだときに、顧客が望んでいたものを正確に提供しました。「ショーアンドテル」の間、顧客が何をし、何をしなかったのか、何を望んでいるのかは明確でした。

Many products have multiple customers which lead to conflicting needs and opinions leading unnecessary blockades

極端でアジャイルなショップが実装の目的と製品に組み込まれるものと組み込まれないものを明確にすれば、不必要な封鎖はありません。同じ製品の異なるバージョンも可能であり、交渉内容によって異なります。これは、生産性を停止したり、不必要な封鎖を招いたりする論点である必要はありません。

Many products don’t have any external customers (products organization made for them or to be selling in future). In this case the team itself is playing the user as well as the developer hence killing the effectiveness of the process.

必ずしも。特定のデバイス用のインターフェースが彼らにとって興味深く見えるであろうものを決定するために人が路上でランダムに人にインタビューしている外部ユーザーインターフェースでさえ、可能性があります。

Not many things exists in formal documentation, this informality leads to vague vision and can create problems where the customer might say that this is not what we asked etc. etc.

次に、正式な文書を使用する必要があります。正式な文書は顧客の足を火に近づけ、「これはあなたが私たちが望んでいたと私たちが言ったものです」1行のパンチカードは文書と顧客のやり取りと一致するため、言い訳はありません。私がこれを極端で機敏な店のインターンとして見る機会があったので、顧客は毎週ドキュメントを承認しました。また、顧客は変更を実装する機会があり、変更も承認する必要がありました。ドキュメントが不足している場合、災害への招待があります。

The questions is why such conflicting opinions exists regarding XP, is it the matter of different scenarios or is there something else and till what extent the claim (as written in the title) is true.

それはお店の知性にかかっていると思います。XPとアジャイルはガイドラインであり、指示ではありません。XPとアジャイルで正常に動作するには、それを運用慣行に組み込み、組織全体で利用する必要があります。走行距離は常に変動し、間違いなく悪いと主張する人もいれば、良いと言う人もいます。私がインターンしたところ、それは間違いなく良かったし、多くの成功があった。

私の経験から、XPとアジャイルの原則にどれだけ厳格であるかが、「毎日のグラインド」に組み込まれたときに、ソフトウェア開発がどれほど成功するかを決定するように見えます。私がインターンしたところ、顧客とのやり取りはすべてを動かし、顧客が最初にそれを行うべきであると述べなかった場合は何も行われませんでした。このショップの運営方法は、XPとアジャイルフレームワークの一部としてしっかりと統合された開発の健全な原則を使用して、優れた測定可能な成功をもたらしました。

の元の質問に固執する場合

私は、エクストリームプログラミングのトピックと、その実践がアプリケーションのエラーやバグのためのスペースを作ることにつながるかどうかについて、学術的な研究を行っています。

表明された懸念が質問に関連しているかどうかはわかりません。

顧客の関与が必要ではなく希望につながる恐れがある場合は、チームがアイテムをシンプルなデザインの小さなリリースに適切に分解していることを確認します。その後、チームが持続可能なペースで作業できるように、これらの項目に優先順位を付けます。

取り組みに、ニーズや意見に同意できない複数の顧客がいる場合、ソフトウェアが顧客のニーズを満たしているかどうかをテストできることには、どんな希望がありますか。SDLCの後半ではなく、早い段階でそれらの問題を解決する方が適切です。

チームがXPのユーザーである必要がある場合、これはXPプロセスを強制終了しません。実際、顧客はチームのメンバーであると明確に述べられています。時々、このチームメンバーは「真の顧客」ではなく内部の従業員であり、個人が顧客のニーズを表す権限を与えられていることが重要です。これがどのように懸念されるかは、アジャイルであろうと従来のものであろうと、他のアプローチと比較してXPに関連しているとは思いません。

正式なドキュメントには多くのものが存在しませんか？適切に行うと、XPチームは従来のチームよりも計画に多くの時間を費やします。さらに、仕様は各反復の開始時にビジネスチームと技術チームのメンバーの間で共同で記述されるため、事前に大きな設計と比較すると、仕様はより正確になる傾向があります。

XPは、プロジェクトの開発（エンジニアリング）側面に焦点を当てています。XPを検討する際に検討すべき事項は次のとおりです。

• テスト駆動開発の学習曲線は、高品質な製品の開発を妨げますか？
• 品質の高いコードを生成する品質のテストを作成するのは、どれほど難しいことですか。
• 開発者がテスト駆動開発サイクルを「だまして」最初にコードを記述し、次にテストを実行する可能性はどのくらいありますか。それは重要ですか？
• ペアで作業する開発者は、従来の開発（関数のコードを1人で書く）と比べてどれほど効果的ですか。
• 反復/緊急設計は、事前に設計されたシステムよりも安定したスケーラブルなシステムにつながりますか？
• ソフトウェアの欠陥を予防的に予防するための継続的な統合は、どれほど効果的ですか。

私にとってそれらはXPで考慮すべき質問です。上記で提起された懸念は、スクラム（非常に一般的にXPとペアになっている）の議論により適しているようです。

参考のために私は見るでしょう：

http://xprogramming.com/index.php

または

http://www.objectmentor.com/resources/omi_reports_index.html

乾杯とあなたの研究の幸運を祈ります。