53

私はアジャイル環境で作業していますが、現在のアジャイルシナリオの失敗（それが彼らの考えです）のために、クライアントがウォーターフォールを好むとクライアントが感じる状態になりました。私たち（開発者）が指定した時間内に完了できなかったスプリントの最終段階で発生した膨大な量の設計レベルの変更が、彼らにこのように思わせた理由です。

いつものように、私たちはお互いを非難していました。私たちの観点からすると、最後に言った変更が多すぎて、設計/コードの変更が多すぎました。一方、クライアントの観点からは、私たち（開発者）が要件を完全に理解しておらず、要件で意図したものではないソリューションを考え出していると不満を漏らしています。（彼らが私たちに虎を描くように頼んだように、そして私たちは猫を描きました）。

そのため、クライアントは（私たちではなく）アジャイルプロセスが正しくないと感じ、IMHOが悲惨なウォーターフォールモードに切り替えたいと考えています。アジャイルモード自体の満足度が十分ではなかったという単純な理由では、ウォーターフォール開発の設計段階で多くの時間を費やした後、どのように出力を許容するのでしょうか。

提案をお願いします。

4

16 に答える 16

53

まず最初に-あなたは本当にアジャイルをやっているのか自問してみてください。もしそうなら、以前のスプリントでの要件を満たした使用可能な機能の大部分をクライアントにすでに提供しているはずです。理論的には、「損傷」は、大幅な設計変更が必要であることがわかった最終スプリントに限定する必要があります。その場合、提供する能力を証明する必要があり、現在必要な変更を計画するためにクライアントとの対話が必要になります。

しかし、あなたの説明を考えると、毎回実際に本番環境に配信することなく、2週間のサイクルで開発するという罠に陥り、最初の適切なリリースの終了日が決まっていると思います。これが事実である場合、あなたは実際に要件分析/設計を前もって行わずに反復的なウォーターフォールを行っています-通常は悪い場所です。

完全なウォーターフォールは必ずしも答えではありませんが（問題が何であるかを示すのに十分な証拠があります）、実際には、緊急アーキテクチャの「純粋な」アジャイルエトス（実際にはリーンアプローチ）。大きなプロジェクトは、コードをハッキングし始めて、それがすべてうまくいくことを望んでいるだけでは、賢明で安定したアーキテクチャの基盤を実現することを望んでいません。

上記に加えて、「純粋な」アジャイルに関するもう1つの一般的な問題は、クライアントの期待の管理です。アジャイルはこの素晴らしいものとして販売されています。つまり、クライアントは決定を延期し、考えを変え、適切と思われる新しい要件を追加することができます。ただし、それは必要な終了日/予算/労力が固定されていることを意味するわけではありませんが、人々は常にその部分を見逃しているようです。

于 2010-07-12T08:15:02.617 に答える
28

アジャイル開発手法は、要件が不明確な場合や、プロジェクトの後の段階で設計を変更する必要がある場合に特に適しています。この場合、ウォーターフォールはあまり適切ではありません。ウォーターフォールアプローチは、よく理解されているプロジェクトや、プロジェクトの存続期間中に要件が変更される可能性が低い場合に適しています。ここではそうではないようです。

あなたのスプリントはどのくらいですか？別のアプローチは、少なくともプロジェクトの開始時に、スプリントの長さを短くすることです。新しいバージョンをより頻繁に顧客に提供し、変更について顧客と話し合います。彼らが望んでいることをしていなければ、これはより早く明らかになるので、顧客の要件を満たさないソリューションの実装に費やされる時間が少なくなります。

于 2010-07-12T08:03:49.267 に答える
26

どんなお店を経営しているのかわからないので、いいアドバイスを出すのは難しいです。しかし、私は2つの指針を提供することができます。

  1. 顧客とのコミュニケーションが悪い場合、開発方法論はあなたを救うことはできません。
  2. 食事がおいしい限り、シェフがキッチンを整理するのはダイナーの仕事ではありません。
于 2010-07-12T08:05:34.387 に答える
10

プロジェクト管理とアーキテクチャ/設計に深刻な問題があるようです。また、コミュニケーションも途絶えているようです。基本的に、開発方法論を変更してもそれが修正されるとは思わないため、間違ったことを行うことはできません（ただし、クライアントの信頼が回復する可能性があります）。

入力の容量がなく、基本的に要件を1回だけ（問題があることがわかっています）キャプチャすることを選択しているため、ウォーターフォールへの移行について特に懸念します。その剛性は柔軟性のない配信ターゲットには適していますが、常に変化するここでは完全に不適切です-それはアジャイルです！

  • 短期的には、一歩下がって、この段階で要件を再確認します。それらに関連してあなたの現在の状態を再交渉し、確認してください。

  • 中期的には、クライアントとのコミュニケーションをさらに広げたいと思います。しばらくの間、クライアントを毎日のスクラムに参加させてみてください（自信が回復するまで、より柔軟に対応できます）。

  • 長期的には、PMと上級開発者がどのようにしてこのポジションにあなたを導くことができたかについて心配する必要があります。クライアントが不合理である場合、それは1つのことです（しかし、それを管理するのはPM次第なので、あなたは免除されません）。変更が多すぎることについて不平を言うのは合理的ではありません。つまり、要件（モノローグではなく対話）を決定するのに失敗したこと、またはより多くの、しかしおそらくより短いスプリントが必要であることを意味します。

何より、滝に向かって移動するのが正しいとは思えません。それは直接何も修正せず、あなたがすでに強調した問題を悪化させるのを見ることができるだけです。

警告：滝が効果的に機能するのを見たことがなく、エンタープライズプロジェクトでは完全に時代遅れになっているため、滝をバランスよく見ることはできません。

于 2010-07-12T08:14:25.153 に答える
7

アジャイル開発は、あなたと顧客の両方が同じように理解する設計を実際に考え出す負担からあなたを救うことはありません。アジャイルは、一度にすべてではなく、小さな増分で設計を考え出すことを可能にするだけです。そして、難しいお客様の場合、適切なデザインを考え出すのに時間がかかります。

ですから、私は顧客と一緒にホワイトボードを持って座って、彼らが実際に何を望んでいるのかを検討することにもっと力を注ぐでしょう。この場合、開発プロセスがアジャイルであるかウォーターフォールであるかは、それほど重要ではないと思います。

于 2010-07-12T08:20:52.793 に答える
7

アジャイルまたはウォーターフォールは単なる言葉です。うまくいくものとうまくいかないものだけがあります。ソフトウェア開発は多くの人にとって仮想的であるように思われ、彼らは彼らが要求する小さなものを変更することが難しい理由を理解していません。

ソフトウェアの構築は家の構築と同じであることを顧客は理解する必要があります。すべての基礎と壁を構築した後、家の最終計画と部屋の設計をすべて変更することは困難です。

データモデリング、データディクショナリ、データフロー図など、この種の問題を回避するのに役立つプラクティスがいくつかあります。目標は、すべての要件を完全に詳細に知ることです。製品を多くの独立したブロックに分割すると、最終製品の他の部分の設計または指定を続けながら、コーディングを開始するのに役立ちます。

動作するすべてのプラクティスについては、Steve McConnellの本：「RapidSoftware Development：TamingWildSoftwareSchedule」を参照してください。

于 2010-07-12T10:01:43.320 に答える
4

私たち（開発者）が指定した時間内に完了できなかったスプリントの最終段階で発生した膨大な量の設計レベルの変更が、彼らにこのように思わせた理由です。

スクラムはある意味「短い滝」であり、スプリント期間の要件の変更から隔離する必要があります。これは起こっていないようです！したがって、従来のウォーターフォールに切り替えることで何も得られないように見えますが、スプリント期間中は凍結要件に固執する必要があります。多分あなたの反復は長すぎますか？（スプリントについて言及しているので、スクラムに従うと思います）。

クライアントと話し合い、次のことに同意します。

- Shorter iterations, up to 3 weeks max.
- No changes in requirements during the iteration. 
- Features are planned at the beginning of the iteration 
- Every iteration ends with deliverable: fully functional software with all features that are fully operational
- Iteration length does not change. Unfinished features are left for the next iteration (or maybe discarded if client changes his mind).
- Number of "feature points" you can deliver in a single iteration should be based on the team metric, not client insistence. This is your "capacity".
- Client decides what features (but not how many of them) are planned for the iteration

自問すべきもう1つのことは、アプリケーションに「設計レベルの変更」が非常に多い理由です。これで、基本的なアーキテクチャと設計が整ったはずです。たぶん、実際の設計を確認し、いくつかの設計ガイドラインを課して、いくつかのパターンを実装するようにしてください。たとえば、一般的なエンタープライズWebアプリでは、おそらくDAOのようなものを使用することになります。新しい機能を追加すると、新しいDAOが作成されますが、基本的なアーキテクチャと設計は変更されません。

ただし、クライアントが望んでいるものを提供していないようです。その場合、クライアントに実用的な製品を提供することが最も重要であるため、クライアントは次の反復のために賢明なフィードバックを提供できます。

それにかんする

「私たち（開発者）は、指定した時間内に完了できませんでした。」

クライアントは、反復の時間枠を指定するクライアントであってはなりません。反復の長さは常に同じである必要があります。イテレーションに入る要件は、クライアントの優先順位付けの結果として取得する必要がありますが、イテレーションで計画される要件の量は、チームが実行する見積もりと、イテレーション中に提供できる「ポイント」の数に基づく必要があります。 。

于 2010-07-12T17:44:33.300 に答える
3

クライアントは、ソフトウェアを開発する方法や、ソフトウェア開発プロセスを管理する方法を知りません。クライアントがこれらの問題について意味のある指示を提供することを期待しないでください。特別な場合として、クライアントは「ウォーターフォール」や「アジャイル」などの用語が何を意味するのかを実際には知りません。彼らがあなたの開発方法論に意味のあるインプットを提供することを期待しないでください。さらに、合意された予算と時間枠内で要件が満たされている限り、クライアントはこれらの詳細を実際に気にすることはありません。彼らが気にかけることを期待しないでください。また、内部プロセスに関する多くの不適切なビルドや無関係な情報と混同しないでください。

クライアントが気にかけていること、そしてあなたに話しかけようとしていることは次のとおりです（部分的にあなた自身の専門用語を使用して）：彼らの要件、彼らの失望した期待、そしてあなたが彼らとコミュニケーションする方法。これらの問題に関しては、クライアントが絶対的な権威です。彼らが言っていることを、内部プロセスについての有用な解説としてではなく、あなたの関係と製品についてのものとして解釈してください。内部の期限とプロセスで水を曇らせないでください。進捗状況と期待、および関係について話し合ってください。（彼らが内部について話すことを主張する場合、あなたは用語を再マップすることができます：例えば、彼らが「次のリリース」であると理解するものは、内部的に「次のメジャーリリース」などとして知られているかもしれません）。

クライアントがフィードバックを求められたり、悪いビルドで遊んだりする前に、より高いしきい値を望んでいるように思えます。これが本当かどうかを確認する価値があります。もしそうなら、あなたはそれを尊重するべきです-そしてそれがあなたのチームが最善であると感じるなら、それでも内部的にアジャイルメソッドを使用するべきです。彼らが「ウォーターフォール」と言った場合、それを内部的に「要件の期限を設定し、しばらくの間、これ以上の機能を追加することを許可しない」という意味であると解釈できる場合があります。要件の期限に続いてこの種のフリーズを設定することがクライアントに適しているかどうかについて、クライアントと話し合います。

あなたのチームの誰かがクライアントの擁護者であり、クライアントの問題の上に座り、彼らのために戦う必要があります。この支持者は傍観されてはならず、またクライアントに対してチームの側に立つこともできません。彼らは代理ボスでなければなりません。次に、内部プロセス通信（チームからアドボケイト）を外部コミュニケーション（アドボケイトからクライアント）から分離できます。アドボケイトは、内部プロセスに特定の種類の管理やスケジューリングを人為的に課すことなく、クライアントをおしゃべりや彼らが評価しないビルドからある程度隔離することができます。

明確にするために、私はあなたがクライアントと秘密にしたり遠ざけたりするべきだとはまったく思いませんが、（A）クライアントが関係について言っていることとあなたがどのようにコミュニケーションしているのかを聞いてそれを尊重する必要があります（B）それを維持する内部開発プロセスとは別に、最終的にクライアントの期待に応える方法で管理する必要があります。

于 2010-07-14T19:24:15.060 に答える
3

私にとっては、アジャイルプロジェクトに「BigPlan[TM]」がなかったかのように聞こえます。アジャイルプロセスを使用することは、長期的な計画がないことを意味するのではなく、遠い将来に増大する不確実性に対処しようとしています。たとえば、今後2か月以内にすべてのリリースで計画された機能を備えたリリース計画（およびその後のリリースの機能を備えたより詳細でない計画）が必要であるため、機能をいつ、いつ期待するかが顧客に明確になります。要件を変更する可能性があります。

また、私には、プロセスに（十分な）顧客の関与がなかったようです。これは非常に問題のある点であることを私は知っていますが、各反復の終わりに現在の進捗状況について顧客と話し合うことができれば、非常に役立ちます。@Mark Byersがすでに書いているように、顧客から得られるフィードバックが多ければ多いほど、あなたはより良くなります。

また、非難を割り当てないようにしてください。これにより、人々はブロックされ続けます。代わりに、検査と採用のアプローチを使用して、より良いプロセスを取得してみてください。

于 2010-07-12T08:23:11.780 に答える
3

どのようなデザイン変更を意味するのかは明確ではありません。グラフィックデザイン？ユーザーエクスペリエンスデザイン？コードデザイン？

いずれにせよ、最善の解決策は、クライアントとのより多くの、そしてより早い段階での話し合いです。クライアントの要件を満たす明確で具体的な例を共同で開発します。これらの例を回帰テストに変換して、引き続き満足できることを確認できます。

また、進行しながら議論を続けてください。利用可能な出力を表示します。スプリントの終わり近くまで待たないでください。そして、最初に問題を引き起こす可能性が最も高い部分に取り組みます。また、頻繁に変更されるものを簡単に変更できるようにする方法も検討してください。

重要なのは、設計の反復であっても、クライアントをより関与させることです。おそらく、デザインだけに焦点を当てた議論が必要になるでしょう。

于 2010-07-12T09:34:03.360 に答える
2

クライアントを起動します。それらが何を意味するのかを理解していないのはあなたのせいですが、滝は各スプリントの終わりのチャンスではなく、あなたにフィードバックを与えるチャンスを1つ与えます。一部の人々/クライアントは文字通り非常に愚かなので、働く価値がありません。それらを起動するか、実際に切り替えることなくウォーターフォールを使用していることを伝えます。

于 2010-07-13T20:54:01.770 に答える
2

ここでの明らかな問題は、顧客とのコミュニケーションです。本当にアジャイルをやりたいのなら、日常の基本について顧客とコミュニケーションをとる必要があります。顧客だけが決定を下すことができるはずです。春の半ばとスプリントの終わりにのみ顧客とコミュニケーションをとる場合、後でアプリケーションに問題が発生するのは当然です。また、スプリントに実装されている機能は、お客様が受け入れてテストする必要があります。その機能が完了するまで。

私は現在のプロジェクトで同様の問題を抱えているのでこれを書いていますが、どこで失敗したかはわかっています。

于 2010-08-21T22:32:05.950 に答える
1

チームと顧客の間のコミュニケーションの問題が修正されていない場合、顧客が製品を完成させて初めて見ると、ウォーターフォールによって状況が悪化する可能性があります（トンネル効果）。

以前のスプリントで達成されたタスクのやり直しを引き起こし始めたスプリント6〜7からの変更についてコメントしました。これらの変更は、スプリントレビュー中に以前に検出されているはずです。

機能の説明に誤解があり、チームがお客様の期待を実装していない場合、これは機能が実装されているスプリントまでに検出され、理想的には現在のスプリントで修正される必要があります。

顧客が気が変わった場合は、他のバックログアイテムと同様に、新しいアイデアが製品バックログに追加され、優先順位が付けられてスプリントに選択されます。これはやり直しと見なされるべきではありません。

各スプリントの後にソフトウェアを顧客に提供しますか、それとも単にデモを行いますか？

誤解の原因はスプリント計画にある可能性があります。チームは、明確に定義されたバックログアイテムにのみコミットする必要があります。アイテムの定義には、受け入れ基準を含める必要があります。顧客はプロダクトオーナーですか、それはプロダクトオーナーですか？

于 2010-07-12T10:59:19.673 に答える
1

開発プロセスのリモートデバッグは十分に難しいので、あなたが何をすべきかについて意見を述べることを躊躇します。あなたのチームの外の誰も、それについて非常に有用な判断を下すのに十分な情報を持っているとは思えません。

結論へのより少ないジャンプは、何が悪かったのかを推測することです。あなたの説明から、あなたが銀行で進歩していると思っていた初期の成果物は、大部分が作り直されたように思えます。

その一般的な原因の1つは、「すべての」要件の発見/作成が遅れていることです。これは、プロジェクトの範囲内のすべてについて真実であると想定されていることです。これらを真剣に受け止めれば、かなり致命的となる可能性があります。たとえば、「すべてのダイアログボックスのサイズを変更できる必要がある」という単純なものは、MicrosoftがWindowsに後付けする機能を明らかに超えています。

この種の失敗の古典的な説明は（アジャイルではないプロジェクトではありますが）ここにあります

「彼らが私たちが書いたコードの製品を見ると、彼らは「ああ、これを変更しなければならない。それは私が意図したことではない」と言うだろう」とSAICのレイノルズは言った。「そして、それは私たちが変更要求の後に変更要求の後に変更要求のログを記録し始めたときです。」

たとえば、SAICのエンジニアによると、8つのチームがVCFの約25％を完了した後、FBIはすべての画面に「ページクラム」機能を追加することを望んでいました。ヘンゼルとグレーテルのおとぎ話にちなんで名付けられた「パンくず」とも呼ばれるこのナビゲーションデバイスは、現在の画面に到達するためにVCFを通過するパスを識別するURLのリストをユーザーに提供します。SAICのエンジニアによると、この新機能により複雑さが増しただけでなく、完成したスレッドに新機能を追加する必要があったため、開発が遅れました。

そこにあるキーワードは「すべての画面」です。その性質の変化に直面して、既存のツールサポートがない限り、スイッチを入れるだけで（すべての背景色を変更するのは本当に簡単なはずです）、問題が発生します。その時点までに達成したと思われる進歩は、遡及的に幻想的であることが判明します。

そのような問題への唯一の既知のアプローチは、それらを最初に正しくすることです。それが失敗した場合は、それらを間違えて生きてください。

于 2010-07-19T22:40:32.263 に答える
1

多くのショップは、アジャイルトリミングを追加して、それを期待する顧客に「アジャイルに見える」ようにしています。たぶん、ウォーターフォールのトリミングをいくつか追加して、2スプリントごとに1回製品を表示する必要があります。

于 2011-04-06T18:01:21.223 に答える
0

あなたのクライアントが滝に移動するのは間違っていると思います。病気ではなく、症状を治します。あなたが説明する問題はコミュニケーションの1つです-クライアントはトラを望んでいます、あなたは彼らに猫を与えています。

ウォーターフォールモデルには、記述された要件が提供されていることを確認するための多くのステップが含まれていますが、記述された要件がビジネスの意図したものであることを保証するものではありません。

コミュニケーションを改善するために、インパクトマッピング、ビヘイビア駆動開発（BDD）、ストーリーマッピングなどの手法を検討します。

于 2016-05-31T09:52:14.547 に答える