プログラマーはMSF /アジャイルメソッド）に従って顧客/ユーザーと対話する必要がありますか？
非常に異なっているように見える2つのステートメントを読みました。
Des Weiteren ist mangelnde Kommunikation zwischen Programmierern und Nutzern einenichtzuvernachlässigendeQuellevonunzureichendenProdukten。
翻訳：
プログラマーとユーザーの間のコミュニケーションの欠如は、貧弱な[ソフトウェア]製品の原因です。
出典： de.wikipedia.org
StandishGroupのCHAOSレポートで似たようなものを読んだと思います。
そして
Insbesondere bei der Rolle Development ist Kontakt zum Kunden oder zu Den Benutzern nach Meinung des MSF geradezu zu unterbinden。
翻訳：
MSFによると、特に「開発」の役割は、顧客やユーザーと連絡を取るべきではありません。
ソース： msdn.Microsoft.com
これも理にかなっています。プログラマーとして、私はエンドユーザーに満足してもらいたいからです。そのため、ユーザーは新しい機能を好むので、それを実装してみます。これは feature creep につながる可能性があります。
私が正しく理解していれば、MSF（Microsoft Solution Framework）は、顧客と連絡をとる役割（これは製品マネージャー、ユーザーエクスペリエンスの役割、そしておそらくテスト）によってこの問題を回避しようとします。役割、そうではありませんか？）そして、開発の役割（プログラムマネージャー）に接触する役割は1つだけです。
質問1：アジャイルメソッドは、機能クリープの問題にどのように対処しますか？開発者はアジャイルな方法で顧客と非常に強力に接触する必要があり、スクラムを使用する際の主な問題の1つは、プロセスに参加するように顧客を説得することであると読みました。
SCRUMでは、プロダクトオーナーのみがユーザー/顧客と連絡を取りますか？プログラマーはプロダクトオーナーとは異なる問題を目にする可能性があるため、これは問題ではありませんか？
質問2：アジャイルメソッドとMSFの要件エンジニアリングは誰ですか？
質問3：製品が顧客の希望とユーザーのニーズを満たしているかどうかをMSF /アジャイルメソッドで検証しますか発送する前に？どうやってやるの？
- 顧客は製品を製造するチームの一員であるため、彼らは確かに願いごとに願いを積み重ねることができます。しかし、それらはまた、どのストーリーがどのスプリントに含まれるかについての計画プロセスの一部でもあるので、彼らは、どの願望を実装するのにどれだけ時間がかかり、他のどんな願望がそれのために延期されるかについて、即座にフィードバックを得ます。これにより、自然なカウンターウェイトが作成されます。 （昔ながらの厳密に分離された要件エンジニアリングと開発では、このようなフィードバックは事実上決して発生せず、顧客はどの機能にどれだけの時間がかかるかわからない。時には顧客が積極的にそれについて嘘をつくことさえある。）
- 方法によって異なりますが、一般的には、マネージャ、調達部門、または営業担当者からではなく、最終製品の実際のユーザーに近い人から要件を取得することに焦点が当てられます。
- （1）とほぼ同じ配置の一部です。機能が計画、実装、試用、およびテストされるときに、顧客が立ち会う必要があります。それらのすべてのステップの間に、彼らが実際にそれを望んでいないことに気付かない場合は、まあ...本当に満足できない人もいれば、アジャイルな方法でさえそれに対して無力です。
アジャイルメソッドはフィーチャークリープの問題にどのように対処しますか
主な方法は、アジャイルメソッドは通常、バックログおよびリリース計画。のアイデアに基づいているということです。ユーザーが望むものはすべてバックログに入れることができます。定期的に、ユーザーはバックログに優先順位を付けて、チームが取り組む機能を設定することが期待されています。
ユーザーはnotですが、現在のイテレーションの新しい機能をリクエストできます。ただし、「機能」の定義はやや曖昧です。反復の開始時に、プログラマーは時間の概算を与えるための要件について十分に知っています。反復中、開発者はユーザーと協力して要件を調整します。これが発生すると、合意された機能が当初の予想よりも複雑になる可能性があります。完璧な世界では、ユーザーと開発者は「十分に良い」と判断し、バックログの拡張を延期します。
現実の世界では、ユーザーと開発者が合理的な範囲について合意できないため、スプリントが失敗することがあります（何も生成されません）。いくつかの失敗の後、チーム（ユーザーを含む）は彼らの機能不全に直面し、それを回避する方法を見つけなければなりません。
アジャイル手法で要件エンジニアリングを行うのは誰ですか
開発者とユーザーを含むチーム。アジャイル手法の背後にある考え方は、ユーザーが本番品質のソフトウェアを実装するために必要な詳細レベルで何が必要かをほとんど知らないということです。常にコーナーケースがあり、開発者が機能を分析するときにそれらが出てくるはずです。
大きな問題は、これらの要件をどのように取り込むかです。アジャイル手法の一部として正式な要件ドキュメントを作成できなかった理由はありませんが、ほとんどのチームはそれを反アジャイルと見なしています。一部のチームは要件としてテストケースを使用しており、統合テストの適切に作成されたスイートは、入手可能な最良の正式な要件ドキュメントの1つです。ユーザーと開発者の間の議論を捉えたwikiページも合理的です。
残念なことに、多くのチームはアジャイルを「私たちは臭いのある文書を必要としない」と見ています。その特定の会社で時々「アジャイル」の終わりを綴ります。
製品が出荷前に顧客が望んでいることとユーザーが必要としていることを製品が実行するかどうかをMSF /アジャイルメソッドで検証しますか？どのように行いますか？
ユーザーは「これは私のニーズを満たしています」と言います。これは、すべての反復の終わりに、プロジェクトのリリースで十分なニーズが満たされたときに発生します。次に、機能強化が始まります。
これらの2つの哲学は互いに矛盾しているように見えますが、共存することはできます。開発者がユーザーに直接連絡を持っていないからといって、それらの間にコミュニケーションがないという意味ではありません。
コミュニケーションは、顧客に要件を尋ね、開発チームの言語に翻訳し、開発者が従うことができる明確な指示を与える顧客関係担当者を通じて行われます。次に、プロトタイプを顧客に提示し、フィードバックを集約して、開発チームに報告します。そうすれば、開発者は開発に完全に集中できます。
マイクロソフトの哲学は、プログラマーと顧客関係がまったく異なる2つの専門分野であり、まったく異なるトレーニングを受けているという前提に基づいています。プログラマーは機械と話すための訓練を受けており、CRの人々は人間と話すための訓練を受けています。一人一人が彼らが訓練された仕事をするべきです。
一方、アジャイル哲学は、エレガントなコードを記述でき、ユーザーに対応する社会的能力を備えた雄弁なソフトウェア開発者を前提としています。社会的スキルと技術的スキルの両方で優れていることは、私たち全員が取り組むべき理想ですが、正直に言うと、ほとんどの人はどちらか一方に傾倒していますまたはもう一方。両方を行うことができる人は珍しい（そして非常に貴重な！）エリートです。
これはアジャイルの観点からです
1。フィーチャークリープフィーチャークリープ自体は問題ではなく、実際にはアジャイルで推奨されています。お客様は、新しい機能が発生したときにそれをリクエストできる必要があります。スコープは変更できる必要があり、その変更に対処することがアジャイルの主要なテナントです。
どこが問題になるのかは、チームが一連の作業（つまり、スクラムスプリント）に取り組んでいて、要件が変更されている場合です。うまくいけば、計画会議が終了するまでに、機能は明確に定義され、コミットすることができ、うまくいけば、次の2週間で変更されません。計画会議の前に、機能を必要なだけ変更できるようにする必要があります。
私の見解では、チームは、イテレーション中に少しの変化を吸収できるはずです。機能に加えて追加の作業である場合は、バックログに追加します。機能を実行する意味がなくなった場合は、機能を組み込むか、機能をすべて一緒に削除します。機能がすでに完了している場合は、バックログに変更を追加します。何をするにしても、不要になった機能を実装しないでください。いずれにせよ、プロダクトオーナーは、機能が完了したときに機能を「受け入れる」必要があるため、関与する必要があります。
スコープの変更を制限する方法は、適切なユーザーストーリーを記述することです。優れたユーザーストーリーは、機能が何であるかを明確に示しています。また、サイズも小さい（つまり、2日未満の作業）ので、影響を与えるには大幅に変更する必要があります。
2。要件収集アジャイルは、誰が要件収集を行うかについてかなり静かになる傾向があります。プロダクトオーナー、開発者、BA、またはエンドユーザーである可能性があります。 is重要なのは、単一のバックログ（作業プログラム）があり、それが1人の人（製品所有者）によって優先されることです。製品の所有者は、他の人から意見を聞き、好きな方法で整理することができますが、お金は彼/彼女と一緒にやめる必要があります。
。検証反復法（スクラムなど）を使用している場合、検証は通常、反復表示の最後に行われます。継続的な方法（かんばんなど）を使用している場合、検証は継続的に行われます。タスクは、検証されるまで実行されません。私は通常、チームに定期的に適切な人を引き付け、彼らと一緒に機能を試してもらいます。
別の方法は、機能を出荷し、フィードバックに基づいて調整することです。これは、ソフトウェアを頻繁に（毎日->隔週）出荷する場合にのみ実行できます。
私たちは、クライアントがクライアントサービス部門で、プロダクトオーナーがその部門の責任者である大企業で働いています。彼女には、すべてを支援する「頭の下」が1つあります。
開発者がクライアントと話しているという質問に答えるには：スクラム/アジャイルでは、「クライアント」はプロダクトオーナー（PO）になります。クライアントが製品に取り組んでいる開発者と連絡を取ることは非常に重要です。それはクライアントのそれと同等の開発者の理解を得るためにスプリント計画とバックロググルーミングに役立ちます。そのため、私たちが構築するものは、クライアントが期待するものに近づきます。しかし、クライアントの性質や関係の環境によっては、2つの当事者が互いに話し合うべきではない場合があります。このような場合、両側と通信できるプロキシPOを取得します。開発者に「クライアント」への個人的な接続を提供しながら、クライアントに製品で何が起こっているかを最新の状態に保つことができる人。
フィーチャークリープに対処するというサブ質問に、どのように対処するかを説明することで答えようとします：バックロググルーミングを使用すると、クライアントがバックログに追加したものとその優先順位を知ることができます。ここで彼らは何を追加することができます。なぜなら、企業環境では、私たちが取り組んでいる1つの製品は長期的だからです。しかし、スプリント中に（X量のストーリー/エフォートポイントをコミットした後）彼らが追加を開始した場合は、単に新しい作品のサイズを設定し、「計画外」とラベル付けします。予定外の作業をスプリントに追加できますが、最初のリストから同じ量のポイントを削除するか、それを負のポイントとしてスプリントグラフに追加します。これにより、クライアントは、スプリントに必要なものに対する決定の影響を確認できます。彼らがすべての元の機能を取得していない場合、またはスプリントの最後に元のコミットメントが満たされていない場合、それは彼らの責任であることが明らかになります。
これは起こりますが、1回か2回、それから彼らはそれをやめます。 :)しかし、それは開発者チームが彼らの銃に固執し、計画外の作業が「亀裂を通り抜けて」とにかく行われないようにすることを要求します。