エクストリームプログラミングの実践により、アプリケーションはエラーが発生しやすくなりますか？
私はエクストリームプログラミングのトピックと、その実践がアプリケーションのエラーやバグのためのスペースの作成につながるかどうかについて学術研究を行っています。
多くの人から集めた経験から、双方に当てはまるコメントがあります。多くの人がそれをサポートし、変化するプロジェクト要件を容易にすることができるダイナミクスでそれを毎日の必要性と見なしています。他の多くの人はそれが次のような多くの問題につながると主張します：
プロセスへの顧客の過度の関与は、ニーズではなく顧客の希望の表現につながります
多くの製品には複数の顧客がいて、ニーズと意見の対立を引き起こし、不要な封鎖を引き起こしています。
多くの製品には外部顧客がなく、製品は内部使用または将来販売される予定です。このような場合、チーム自体が開発者だけでなくユーザーもプレイしているため、プロセスの有効性が失われます。
正式なドキュメントには多くのものは存在しません。この非公式性は漠然としたビジョンを導き、これが私たちが求めたものではないなどと顧客が言う可能性がある問題を引き起こす可能性があります。
質問は、なぜそのような矛盾する意見がXPに関して存在するのかということです。それはさまざまなシナリオの問題ですか？他に何かありますか？ （タイトルに書かれているように）主張はどの程度真実ですか？
XPここで働いている、または一緒に働いたことのある人に、彼らの学習と現実世界の経験に貢献してもらいたいです。あなたが答えるのを裏付ける事実や参考文献があれば理想的です。
その過程で顧客との過度の関わりは、ニーズではなく顧客の希望の表現につながります。
これは、顧客がシステムの要件に対してある種の完璧なOracleであることを前提としています。 XPの基本原則の1つは、顧客はnot完璧なOracleであり、実際の出荷ソフトウェアに基づく絶え間ないフィードバックが、市場、顧客、そして最終的には利害関係者。
多くの製品には複数の顧客がいて、ニーズと意見の対立を引き起こし、不要な封鎖を引き起こしています。
はい、そうした顧客からの定期的な関与は、これらの矛盾を明確にし、時間をかけて解決するのに役立ちます。問題を非表示にしても問題は解消されません。
多くの製品には外部顧客がなく、製品は内部使用または将来販売される予定です。このような場合、チーム自体が開発者だけでなくユーザーもプレイしているため、プロセスの有効性が失われます。
内部の利害関係者は、外部の利害関係者と基本的に違いはありません。 XP以外の方法論がこの問題にどのように対処するかについては説明していません。
正式なドキュメントには多くのものは存在しません。この非公式性は漠然としたビジョンを導き、これが私たちが求めたものではないなどと顧客が言う可能性がある問題を引き起こす可能性があります。
XPには、利害関係者と開発者の間で頻繁に段階的なフィードバックが含まれます。これらの通信障害が存在する場合は、初期の反復中に発見でき、後の反復に大きな影響を与える前に修正できます。別の方法として、これらの通信障害は、製品の出荷直前まで検出されません。
基本的な誤解は、XPはこれらの問題を引き起こしていないということだと思います。それはただ公開問題です。問題を早期に公開して修正するプロセスは、一般的にエラーが発生しにくいです、それ以上ではありません。
いくつかの考え：
- プロセスへの顧客の関与が多すぎると、ソフトウェアに対するニーズではなく、希望を表明し始める
詳細で安定した仕様を持つことと顧客に対応することの間には常にバランスがあります。極端とは、顧客への応答性を高めることを意味し、もちろん、その方向に行き過ぎることも可能です。したがって、これは正当な懸念事項です（特にプロジェクトの請求方法によって異なります。固定価格契約の場合は、明確に指定する必要があります）。
ただし、私の経験では、仕様がどれほど優れていても、「顧客が望んでいること」を行うために仕様を変更する必要があることがよくあります。 Extremeは、後で仕様に合わせて巨大で複雑なプログラムを構築したのではなく、できるだけ早くそれらの変更を行うのに役立ちます。
- 多くの製品には複数の顧客がいるため、ニーズや意見が相反し、不必要な封鎖が発生します。
もちろん、そのような状況で相反するニーズを解決することは常に問題であり、それに対処するための適切なプロセスが必要です。顧客からのフィードバックを得るプロセスに時間がかかり、複雑になると、Extreme Programmingの効果が低下するため、これは正当な懸念事項だと思います。
- 多くの製品には外部顧客がいません（それらのために作られた、または将来販売される製品組織）。この場合、チーム自体が開発者だけでなくユーザーも演じているため、プロセスの効果が失われます。
これはまったく正当なことではないと思います。 Extremeの背後にある考え方は、実際に作り始めるまで顧客は何を望んでいるのかを理解しないということです。これは、外部の顧客と同様に内部の「顧客」にも当てはまります。
また、まだ顧客がいないもの（まだリリースされていない製品など）を開発している場合は、架空の顧客として行動し、人々が何を望むかを決定する誰か（またはグループ）が必要です。エクストリームは、顧客として行動する彼らと同様に機能します。
私はこのような製品に取り組んできましたが、これは外部の顧客を対象としたもので、まだリリースされていません。 「エクストリームプログラミング」というラベルは付けていませんが、広範な正式な仕様がなく、頻繁にビルドされる、同様の反復型開発プロセスを使用しました。かなり効果的だと思いました。
- 正式なドキュメントには多くのものが存在しません。この非公式性は漠然としたビジョンにつながり、これが私たちが求めたものではないなどと顧客が言う可能性がある問題を引き起こす可能性があります。
はい、文書化されていないものは問題です。 Extremeは、正式な仕様に基づいていないため、文書化しない方が簡単な場合があります。しかし、Extremeは自動的に「物事が文書化されていない」という意味ではありません。ドキュメントを作成する必要がありますが、事前にではなくプログラムと一緒に作成されます。また、場合によっては、実装後に動作を文書化することになります。これ自体は問題ではありません。
課金に関しては、作業を開始する前に、何が提供されるかを正確に文書化した文書が必要になることがよくあります。これは、エクストリームプログラミングではさらに難しい場合があります。
結論：Extremeは、他の方法と同様に、長所と短所がある方法論です。それを使用する（または教える）ときは、両方を覚えておく必要があります。
あなたの質問は、2つの主要なXPトピック：「直接の顧客コミュニケーション」と「あまり正式なドキュメントではない」）のみを扱っています。したがって、私の見解では、これは実際には「XP」の質問ではありません。 、これらは私が知っている他のアジャイル開発プロセスの一部であるトピックです。
これが私の考えです：
プロセスへの顧客の関与が多すぎると、顧客はソフトウェアに対するニーズではなく、希望を表明し始めます。
さて、ウォーターフォールのようなプロセスがあり、事前に完全に詳細な仕様があり、多くの要件がある場合、これらの要件のうちどれが単なる希望であり、どれが実際のニーズであるかで問題が発生する可能性があります。これを明確にする最も簡単な方法は、お客様と話し、さまざまな代替案を示すIMHOです-明確にする必要がある場合はいつでも。つまり、まったく逆のことが当てはまります。「アジャイル開発」は、「ニーズとウィッシュ」にうまく対処するのに役立ちます。
多くの製品には複数の顧客がいるため、ニーズや意見が相反し、不必要な封鎖が発生します。
はい、完全に詳細な仕様により、これらの競合は事前に解決されている可能性がありますbefore開発が始まります（運が良ければ）。アジャイルプロセスでのこの問題の解決策は、顧客側の少数の人だけが開発者と直接話し合うことであり、競合が発生した場合に最終決定を下せる顧客のために1人責任者がいます。
多くの製品には外部顧客がいません（それらのために作られた、または将来販売される製品組織）。この場合、チーム自体が開発者だけでなくユーザーも演じているため、プロセスの効果が失われます。
いいえ、不正解です。開発者と同じ会社に所属する内部ユーザーのみがいる場合、「顧客オンサイト」は外部顧客しかいない場合よりもはるかに簡単にインストールできます。 no直接ユーザーが手元にある場合、それは問題になる可能性がありますが、それはアジャイル固有の問題ではありません-代わりに、潜在的なユーザーの役割を果たす誰かを見つける必要があります（そしてこの人は通常、開発者チームの出身ではありません）。
正式なドキュメントには多くのものが存在しません。この非公式性は漠然としたビジョンにつながり、これが私たちが求めたものではないなどと顧客が言う可能性がある問題を引き起こす可能性があります。
私の経験では、顧客との絶え間ないコミュニケーションなしに正式な仕様に従って開発する場合、顧客が「これは私が求めたものではない」と言うものを開発する可能性は、毎日顧客と話すときよりも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およびAgileの原則に対する厳格さは、「デイリーグラインド」に組み込まれたときに、それがソフトウェア開発を成功させるかどうかを決定するように見えます。私がインターンしたところ、顧客相互作用がすべてを駆り立て、顧客が最初にそれを行うべきだと述べない限り何も行われませんでした。このショップの運営方法は、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
乾杯とあなたの研究の幸運を祈ります。