こういうやつほど「アジャイルよりのウォーターフォールになっちゃってます」とか言うんだな・・・
アジャイル原則のウォーターフォール型開発への適用｜アイネット
前回、アジャイルマニフェストの４つの中核的価値（個人とその相互作用、動くソフトウェアの提供、顧客とのコラボレーション、変化への対応）が、ウォーターフォール型開発においても、実践上価値があり、ウォーターフォール型開発の改善や今後のアジャイル開発への移行のうえで参考になると考え、アジャイルマニフェストのウォーターフォール型開発へ適用について述べた。今回は４つの中核的価値を支えるアジャイルの１２の原則のウォーターフォール型開発への適用について考察する。
おもしろい・・・きかせてもらおうじゃないか。
１）我々の最優先事項は早期に連続的に価値のあるソフトウェアを提供することを通じて顧客を満足させることである。
ウォーターフォール型開発では、価値のあるソフトウェアを提供するためにスコープ（品質）、スケジュール、コストの計画を守ることが求められるが、最終的に価値のあるソフトウェアを提供することが、顧客を満足させる。
そうだよね！！じゃあアジャイル必要ないね！これからもウォーターフォールでいこうね！！
２）要求事項に対する変更は、開発局面の後半でも歓迎する。アジャイル開発プロセスでは、顧客の競争優位のための変更は容易に対応できる。
ウォーターフォール型開発では、スコープの変更は後半にはできるだけ発生しないように変更をコントロールするが、顧客とのコラボレーションを強化する方法や仕組み（変更管理システム）を導入するにより、価値の向上する変更に対応することが望まれる。
どうやってスコープの変更に対応するのかな？？変更管理システムとやらでできるのかな？？
３）動くソフトウェアをより短い期間を優先し、数週間から数カ月でたびたび出荷する。
短い時間で顧客に動くソフトウェアを見せることで、顧客からのフィードバックを得ることにより、顧客の期待した価値のあるソフトウェア作ることができる。ウォーターフォール型開発においては原則的に最終にしか動くソフトウェアを顧客は見ることはできないが、重要な部分は開発途中でプロトタイプ手法などを使ってできるだけ顧客がイメージできるような方法を採用することが望まれる。
プロトタイプをどうやって作るんだっつーの！！無理がありすぎるだろ・・・
４）プロジェクト期間をとおして、ビジネスユーザーと開発者は共同して作業する必要がある。
ビジネスユーザー（顧客）は、ビジネスニーズを出す役割を持っているが、それをうまくシステム開発者に伝えることができない場合や、システムを実際に見るまではビジネスユーザー自身が必ずしもニーズをイメージできない場合がある。ビジネスユーザーと開発者が共同して作業することによって、ビジネスニーズにあった製品を開発できる。ウォーターフォール型開発においても、ビジネスユーザーとのコミュニケーションを強化し、コラボレーションする方法や仕組みを導入することにより、ビジネスニーズにあった製品を開発できる。
前提として動くシステムを見ないとニーズがイメージできないんだからコミュニケーションを強化してもビジネスニーズにあった製品なんか開発できるわけねーだろうが！！
そう自分で言ってるじゃねーか！
つーかよー、おまえらの顧客っていうのはいったいなにものなんだよ。
どうせ、自分たちがすべきことをロクにわかってないただいわれたままにシステム部門を任されてるようなボンクラなんだろ？
そんなやつが顧客だったら開発者がいくらがんばってもできるものはゴミなんだよ！！
５）やる気のある人を集めてプロジェクトを組織し、彼らが必要とする環境と支援をし、仕事を達成することを信頼する。
アジャイル開発では、チームの自主性を重視し、チームコラボレーションによって高い成果を目指すが、ウォーターフォール型開発においても、プロジェクトマネジャーが指示管理型のマネジメントスタイルではなく、チームの自主性を尊重し、チームがより効果的に生産的な活動できるよう障害を取り除いたり、コーチングやメンタリングなどの支援型行動をするコラボレーション型リーダーシップ（サーバントリーダーシップ）（３）を発揮することにより、高い成果をあげることができる。
できねーーーよ！！！
っていうかまた教科書にかいてあることのまるパクりじゃねーか！
ウォーターフォールで指示管理しなきゃ誰もなにおｍしねーぞ！？！？
ちゃんと各工程をマネジメントしねーと！！
建築現場で各個人の自主性を尊重したりするか？しねーだろ！
っていうかそもそもやる気のある人を集めてとかいうけど、おまえのまわりに一人でもそんな人間がいるのかよ！！！いないだろうが！
６）チーム内のコミュニケーションで最も効率的かつ効果的な方法は、フェイスツーフェイスの会話である。
アジャイル開発のコミュニケーションは、ドキュメントも重要であるがチーム内の対話によるコミュニケーションがもっと重要である。これはウォーターフォール型開発においても同様である。
吹いたｗｗｗｗ
アジャイルとかウォーターフォールとか関係ねーよｗｗ
おまえは社会人として微妙だよｗｗ
７）動くソフトウェアが進捗の基本的な評価である。
アジャイル開発では、実際に動いたソフトウェア本数によって進捗を測っている（バーンダウンチャート）。
ウォーターフォールはどうしたｗｗｗｗｗｗ
８）アジャイル開発プロセスは持続的な開発を促進する。スポンサー、開発者、ユーザーはずっと一定のペースで仕事ができるようにすべきである。
アジャイル開発において持続的に一定のペースで働ける（オーバーワークにならない）ことはプロジェクト関係者全員のクオリティオブライフ（生活の質）に重要である。持続的に一定のペースで働けることは、ウォーターフォール型開発においても同様に重要である。
で？
ちなみに納期直前になったらキミタチはどうするのかな！？！？
ウォーターフォールでも「一定のペースで」とかいえるのかな〜〜？
９）技術的な優位性や良い設計に継続的に注目することにより、俊敏性を増すことができる。
新しい技術や方法を取り入れることにより、開発の生産性を向上することができ、迅速な開発が可能となる。これはウォーターフォール型開発においても同様である。
関係ねーよ馬鹿！！まだ技術に頼ってんのか！厨房かどあほ！！
俊敏性や生産性、ビジネスにおける価値を高めてきたのは技術じゃねぇ！勉強しなおせ！！
１０）簡素が重要
チームは顧客の望むものを開発するもので、望まないものや使わないものを開発することは無駄である。これはウォーターフォール型開発においても同様である。
シンプルであることと簡素であることは違うんだけどそのへんの思想が備わってるわけはないか・・・
顧客が望むか望まないかをウォーターフォールで主張したり判断したりできるのかね？
最初の計画の段階で「それはいらない機能です」ってか？
ちったあ想像力を働かせて考えてみりゃわかるだろ・・・・
っていうかこいつは仕事もしないでこんあことばっかかいてないで、ちったあ仕事しろ！！
１１）最良の構想、要求事項、設計は自己組織型チームから出現する。
チームの自主性を重視し、チームコラボレーションによって、すばらしい創造的なアイデアがより出てくる。これはウォーターフォール型開発においても同様である。
これはウォーターフォール型開発においても同様である。(キリッ)
だってぉｗｗｗｗｗｗｗｗ
いままでそんなことが一度でもあったのかよーー！！！
１２）定期的に行動の振り返りを行い、継続的改善を追求する。
アジャイル開発では反復期間やリーリース期間のそれぞれの最後に作業の振り返りを行う。無駄はないか、もっと改善できないかを振り返り、その後の行動に反映する。ウォーターフォール型開発においてもプロジェクト進捗会議やフェーズ終了毎に作業を振り返り、教訓として次の活動に反映しプロセスを継続的に改善していくことが求められる。
まずおまえの人生を振り返れ。まずはそれからだ。
「無駄はないか、もっと改善できないかを振り返」られたら真っ先におまえのクビが飛ぶｗｗｗｗ
あとおまえらに次のフェーズはない。
プロジェクトが終了したら、顧客はおまえらの仕事に辟易して他の会社へ案件を発注するからだ！
以上から多くの教科書からまるコピペ文章は漫然とウォーターフォール型開発を行ってる惰性エンジニアをdisるのに参考になるものと考えられる。
