ウォーターフォール・モデル - Wikipediaなんてやったことないなー。Yes! Agile!!
なんてわけもない。開発モデルなんてものがあった記憶がないのだ。スクラムってなんだ！？
そう。implementation→implementation→releaseが本質だった。
仕様とはバグのaliasであり、品管とはネゴシエーションでごにょってリリース。とまぁ。
Requirementsが語られることもなく、語ることもない。明確な要求など来ないので「どうぞよろしく」と言われ、我々もまたパートナーに「どうぞよろしく。なにをあれしていい感じにしちゃってください！」というわけであった。かくして「Requirements」は想定通りにスキップされる。
Design。それは、.psd という拡張子のファイルの伝達を意味する。ペラの絵をどうぞよろしくというフェーズだ。え？「設計」ですって？私の辞書にはそんな単語はありません。
implementation, Yes! implementation!!とくに叩き台も何もないが、ふわっと「int main(void)」してみよう。気の赴くままにタイピングするとさぁβの日がくるぞ！もうGMの日だからリリースするっきゃないっしょ！！うにょー、もといウンヨーでカバーーー
・要件を変更したときの見積もりや契約の方法が確立されていない
→ 要件定義をできるスキルを持ったもんがおらん。要件(案).xlsx 要件(仮).ppt
・各工程の頻繁なリリースによるバージョン管理が難しい
→ svn checkout && makeだっ！！(tag打ちってなんれすか？(^ρ^))
・テストの自動化に関するノウハウが蓄積されていない
→ テストってなんっすかー？CppUnitなんて知らないよ～
製品製造過程のように開発をいくつかの工程に分け、各工程の終了を意味する文書を作成することで進捗を管理し、早いうちから品質の作りこみをしよう
工程はimplementationとreleaseのみデス。文書は書きません(キリッ) ソースコードが仕様書です(キリッ)
「ウォーターフォールモデルは間違っており有害である。私たちはこのモデルから脱却しなければならない」
すいません。まずは「ウォーターフォールモデル」くらいやってみたいれす(^ρ^)
「秩序正しく、予測が可能で、説明が付きやすく、測定可能なプロセスであり、文書を中心とした単純なマイルストーンが存在するという幻想をウォーターフォールがあたえた」
量子力学を基盤とした、ソフトAを書いているコーダーとソフトBを書いているコーダーが同時に共存している状態があり、深夜に蓋をあけた瞬間に妖精さんが要請に応えている状態に収束するという、測定に不確定性を伴うプロセスであり、ソースコードという文書を中心とした単純な負の時間軸に存在していたマイルストーン(線引きするとαは昨日！)という幻聴を聞く(そんなばかなーそんなばかなー)。
前工程に間違いがない
どころかそんな確認をしないので不明。よって間違いがあるという帰無仮説は棄却できないので次の工程に進んでよしっ！
とまぁ、ほぼそんなことを10年以上続けてしまったし、誰も文句言わないし、残業しとけば「頑張っとる！」って感じだし、Agileなんて単語を口にする者もいたことないし、いまやAgileとは都市伝説である。
きっと引退するまで開発モデルというものを味わうこともなく終えるんだろうなとほぼ確信中。振り返っても程度の低い開発(？)しかしたことない
