問題タブ [waterfall]

ウォーターフォール モデルの欠点を軽減するための方法論を教えてください。

私のチームは昨年かそこらで1から5にかなり急速に成長し、開発スタイルをウォーターフォールからスクラムのようなより反復的なアプローチに変更することに非常に興味を持っています。私たちは大学で働いており、常に要件を変更している社内顧客向けのCRUDWebアプリを専門としています。

だから、私の質問は...スクラム技術をどのように最適に実装するのですか？

補足的な懸念事項：移行を容易にするためにウォーターフォールの「コールドターキー」を終了することをお勧めしますか、それともプログレッシブアプローチの方が効果的だと思いますか？言い換えれば、今実装するスクラム手法をいくつか選んで選択し、さらに先に他の手法を追加しますか？

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

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

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

提案をお願いします。

Microsoft Project とウォーターフォール

Microsoft Project を使用すると、ウォーターフォール モデルを強制されますか? (d) MS Project をサポート ツールとして使用して成功した反復 (アジャイルなど) プロジェクトの例を誰か教えてもらえますか?

明らかに、2つのアプローチを適用することによるチーム、顧客、ROIなどへの影響の違いは非常に大きく、多くの本や終わりのない議論や会議の主題となっています。

しかし、それについてもっと考えると、リリースの頻度である単一のルートの違いに最終的にマッピングされない2つの違いを見つけるのに苦労しています。

Waterfallは、設計、コードの記述、テスト、そして最後にリリースに時間を費やしています。しかし、アジャイルはまったく同じ一連のステップを実行します。つまり、それぞれが小さいというだけです。

アジャイルアプローチの重要な部分は、各リリースから学習し、それを使用して、最初に予測しようとするのではなく、より大きなデザインを出現させることです。

しかし、Waterfallもこれを行います。ウォーターフォールチームは、3週間または4週間ごとに学習するのではなく、6か月または9か月ごとにしか学習しません。しかし、ウォーターフォールのデザインはまだ現れています。つまり、ウォーターフォールリリース2は、リリース1で学習した内容を反映します。したがって、プロセスに違いはなく、実行速度が異なるだけです。

アジャイルは、顧客との緊密なコラボレーションに重点を置いています。しかし、Waterfallもこれを行います。ウォーターフォールの反復時間が長いため、長期間にわたって全員を同じページに維持するには、契約の形式で要件の列挙リストがより必要になります。しかし、繰り返しになりますが、これは単なる周波数のアーティファクトです。配達の頻度が高いほど、契約の必要性は低くなります。

私が見逃している他の原始的な違いはありますか？それとも本当に周波数だけですか？

SDLC とソフトウェア プロセスという用語について、いくつか混乱があります。これらの (多かれ少なかれ類似した) 用語に関して、いくつか質問があります。

1. SDLC とソフトウェア プロセスの違いは何ですか? （SDLCはウォーターフォールだけではないことを理解しています）。
2. SDLC を Unified Process にマッピングできますか?
3. アクティビティについて- 伝統的なウォーターフォール モデルでの分析, 統一プロセスで分析を行いますか (任意の統一プロセス- アジャイルまたは合理的) ?

まず、そんなことは考えていません。

iPhone でいくつかの砂丘に滝の簡単なシミュレーションを作成する方法を考えていました。

何人かの人々が水を動かす問題に取り組んだことが判明し、GameDev はこのアイデアに何度かアプローチしました。ただし、これらのソリューションはすべて計算量が多いようです (そして、水が流体であり、流体力学が複雑であることを考えると、それは理にかなっています)。シミュレーションが正確であることは重要ではなく、正確に見えることだけが重要なので、ショートカットに興味があります。

1500 個の粒子を使用して DirectXで (Navier-) Stokes をシミュレートすることについて誰かが尋ねました。彼は自分の結果がぎざぎざであると述べています。もちろん、iPhone では、そのようなことの OpenGL ES 実装になります。

別の善良な魂がChipmunk の物理エンジンを使用しようとしましたが、私には戦車を使用して蚊を殺すように聞こえますが、それでも非常に多くの粒子の問題が発生します。したがって、全体の計算を最小限に抑えるために、流体のマクロ状態を管理し、粒子でエッジを管理するために、この圧力管理手法と同様の手法を使用することが合理的であるかどうか疑問に思ってい ます。

素晴らしいアイデアがある場合は、テストすることを提案してください。

2015 年 8 月 6 日編集: Thimbleweed Parkのブログで、Joseph Huckabyが HTML5 で行った非常に古い手法の素晴らしい例を見つけました。これは状況に応じてのみ関係があります。外観がすべてであり、物理がまったく重要ではないためです。しかし、流体を大まかにシミュレートして、「液体ゾーン」にパレット サイクリング エフェクトを重ねてみませんか? もちろん、この技法は芸術的要素に大きく依存しているため、芸術家の領域の難しさを動かしています。ただし、レンダリング コードはブレンド時に少し負荷がかかります。

ウォーターフォールスタイルのプロットにプロットしたい一連のスペクトルデータがあります。細い線は各スペクトルであまりにも多くの違いがあるため、滝自体はそれほど有用ではありません。それはあまり有用ではありません。

したがって、ドキュメント で有望に見えるリボン関数を試してみたいと思います。

しかし、結果は完全に異なり、役に立たない！

編集：

私は今、私が望んでいたものに近い手動の滝のプロットを作成しました：

それにもかかわらず、私はまだ元の問題の解決策に興味があります。

編集2：

これは、ウォーターフォール、リボン、およびカスタムコードで同じデータを使用した例です。私のコードだけがデータを視覚化するのに役立ちます。リボンと滝をまともなプロットのように見せるための方法を知りたいです...

このコードは現在、いくつかのデータを作成するために使用されています

こちらはリボンを使用した結果です

そしてここに滝があります

比較のために、私自身が書いたコードを使用したプロット。これは滝に似ていますが、深さ軸がありません。しかし、それはまともなように見え、各曲線間の変化が見えるようにデータ曲線を表示する唯一のものです。

私はアジャイルとウォーターフォールに関する多くの情報を読みましたが、今日誰かがウォーターフォールをやるべき理由が思いつきません。私は特にテストプロセスについて心配しています。私が見落としている明確な利点はありますか?