Waterfall 2006 開催！ 71
ストーリー by mhatta
April is the Craziest Month 部門より
April is the Craziest Month 部門より
あるAnonymous Coward曰く、"元ネタは XP-jp ML に流れていた投稿。 近頃のアジャイルな開発プロセスに叛旗を翻すべく、Waterfall 2006 というカンファレンスが開催される(日本語版案内)。すべてのセッションに参加できるようにシーケンシャルな形で行われたり（ウォーターフォールの考え方に基づき、テスターはテストのセッションにのみ、プログラマはプログラミングのセッションにのみ参加可能）、ディスカッションを排除してドキュメントによるワークショップが行われたり（当然、履歴は構成管理されるのだろう）と、まさにウォーターフォールによるウォーターフォールのためのカンファレンスである。 最近の流れを踏まえれば、ぜひ『Waterfall 2.0』という名前にしてほしかった... 気がしないでもない。"
沈黙の悦び (スコア:5, おもしろおかしい)
協賛 (スコア:5, おもしろおかしい)
Re:協賛 (スコア:1, おもしろおかしい)
ウォーターフォールの輪廻
Re:協賛 (スコア:0)
Re:協賛 (スコア:0)
Re:協賛 (スコア:0)
Re:協賛 (スコア:0)
正にウォーターフォール・・・・・・！
＃オレたちはようやくおちはじめたばかりだからな
＃このはてしなく長いウォーターフォールをよ・・・
プログラム一覧（超訳） (スコア:5, 参考になる)
プログラム一覧を日本語にすると、こんな感じ？
- 現場の決定権を取り返せ ～ マネージャの復権 ～
- 「柔軟」なプロセスの落とし穴
- ペアマネージメント - 開発者１人に２人のマネージャを！
- ２相ウォーターフォールプロセス有害論
- 理想の操作性：開発の労苦をユーザーにも！
- テスト：できるならやる、でなければよい
- 静寂の喜び：会話レスなキューブデザイン
- WordUnit - ドキュメントユニットテストのススメ
- 特攻の楽しみ：業務システムを２度書き直す
- 巨大プロジェクト：終わらなければ失敗なし
- 単独プロジェクト：コラボレーションからの開放
- 過去の復権 ～ 古代への回帰 ～
- 古代メソッド実践：データ中心ソフトウェア開発
- 俺様プログラミングへのいざない
- パターンによるデリファクタリング：隠蔽による給与確保法
- 社内評価プロセスの真髄 ～ 社員間競争の先鋭化 ～
- 理想のアウトソーシング：メンバ数＝大陸数
- Ruby On Snails: 新フレームワークによるスローコーディング
- 瑕疵性ソフトウェア：補修費ビジネスモデル
- 製品テストの原則：真打は最後まで
- 実践プロジェクト：いかにすべてを何度も何度も行うか
- 成熟のプロセス管理：弁護士による弁護士のためのプロセス
- 開発ライフサイクル：開発のための開発、テストのためのテスト
- ２４時間戦えますか？－ 知能より期間
- 認証制度 ～ シールが生む経済価値 ～
- 悲観的情報伝達プロセス
後は疲れたので誰かよろしく。発表者もミソなんだけど、その辺は原文で噛み締めて下さいな
Re:プログラム一覧（超訳） (スコア:4, 参考になる)
Re:プログラム一覧（超訳） (スコア:0)
とりあえずRailsネタ [so-net.ne.jp]
Re:プログラム一覧（超訳） (スコア:3, 興味深い)
笑いとしてはイマイチなような (スコア:2, 興味深い)
片方がもう片方の相手を一方的にあげつらうと、
「必死だな」感が醸し出されてしまうというか…
私が読み方を間違えてるのかなあ。
Re:笑いとしてはイマイチなような (スコア:2, すばらしい洞察)
ウォーターフォールでうまくいったためしがないです。
品質ぼろぼろ、コスト上げ上げ、納期りぎりぎ。
どういった規模や状況だと、ウォーターフォールが有効なんだろうなぁ?
Re:笑いとしてはイマイチなような (スコア:5, 興味深い)
マジレスすると、例えば、政治的・経済的に利害の異なる N (N > 1) 個の法人が、徒党を組んで発注又は受注している状況が該当します。
このような状況下では、何かを後から変えようとすると喧々囂々侃侃諤諤のフレームウォーが発生し、下手をすると裁判沙汰になりかねません。 また、往々にして開発者の数は数百〜千人以上になりますので、開発者間の意志の疎通などハナから不可能です。
# そもそもそういう体制にするなってのは同意。
# 政治的に無理なことも多いけど。
Re:笑いとしてはイマイチなような (スコア:0)
Re:笑いとしてはイマイチなような (スコア:3, すばらしい洞察)
微妙に違うと思います。
「護送船団」も「ノアの箱舟」も中の人を守ってくれますが、ウォーターフォールは必ずしも中の人を守ってくれるとは限りません。 ウォーターフォールは発注元や受注先にとって重要な、納期や予算を守るためのものです。
戦死・殉教しても、神社に祭られたり殉教者に列されることはありませんのでくれぐれもご注意ください。 家族がご心配な方は、事前に生命保険に加入されることをお勧めします。 また、勤務先が太っ腹であれば、労災が下りるかも知れません。
Re:笑いとしてはイマイチなような (スコア:0)
大船に乗ったつもりでいたまえ。 (スコア:0)
>納期や予算を守るためのものです。
保険がたっぷりかけられたタイタニック号のようなものですね。
Re:笑いとしてはイマイチなような (スコア:1)
Re:笑いとしてはイマイチなような (スコア:4, すばらしい洞察)
技術力のない人が下請けに○投げする時。
たとえどんな酷いデスマでも、丸○げした相手を脅迫すれば
最後までやり遂げさせられます。最後までやり遂げれば失敗とは
呼びません。
故にウォーターフォールの辞書に、失敗という文字はありません。
Re:笑いとしてはイマイチなような (スコア:3, おもしろおかしい)
伏字になってませんよ…
Re:笑いとしてはイマイチなような (スコア:0)
貴様だったのか…
ウォーターフォールの適用対象 (スコア:3, おもしろおかしい)
あらかじめ確保した妥当な日程、予算どおりに執行されており、
予定からの逸脱はないと説明したい人にとっては大変有効な方法です。
Re:ウォーターフォールの適用対象 (スコア:1)
その逸脱の可能性の大きさが、土方と IT 土方の差でもあるのだな。
Re:笑いとしてはイマイチなような (スコア:2, 興味深い)
私も知らないのですが、数百人を越える大規模開発では有効なのでは。
大規模開発案件自体が、開発プロセスの選択に関係なく失敗率の高いものだと思いますが、
少なくとも、XPやアジャイルで銀行のオンラインシステムを作ったというような事例は
まだないですよね。
アジャイル自体がイテレーションを単位とするウォーターフォールだ、という
解釈も散見しますし、尊敬しつつも乗り越えるべき「親」的存在とでもいえばいいでしょうか。
アジャイルの立場からウォーターフォールを「笑う」というのは、
私にはどうもしっくりこないのです。
Re:笑いとしてはイマイチなような (スコア:0)
XPでもアジャイルでもなく？ それら以前の時代とウォーターフォールの後の時代にあるそれ。
Re:笑いとしてはイマイチなような (スコア:1)
あったと聞いた気が・・・。
問題は契約なんですよ。
イテレーション毎の契約（見直し）なんて現実的に
可能なんですかね？
全体予算の決まった中でのアジャイルなら変更対応が
そのままコストとして積み上がるだけだし・・・。
みんなどうしてるんだろ？
--- （´-`）｡oO(平和な日常は私を鈍くする) ---
Re:笑いとしてはイマイチなような (スコア:2, 興味深い)
とりあえず、こういうのだと上手くいきましたね。
・全て自社内で作り、売る担当も自社。
・担当者規模が50名程度まで。(企画～テストの範囲内)
・各担当の仲はそれなりに悪くない。(良いとまでは言わないが(笑))
規模がでかい話については知りませぬ。
Re:笑いとしてはイマイチなような (スコア:2, 興味深い)
結構waterfallって有効だと思ってますけど
＃社内的にはwaterfallなPJ95%ですし... 本来は否定的な立場なのですけど
みんつ
Re:笑いとしてはイマイチなような (スコア:2, 興味深い)
>品質ぼろぼろ、コスト上げ上げ、納期りぎりぎ。
まず、「納期」の変更ができない場合は、ウォーターフォールの開発はまずいです。agileな開発手法では、「優先度の高いものだけ終わらして納品」ということが可能ですが、ウォーターフォールでは、全工程がシーケンシャルに実施され、最終工程が終わらない限り、物自体が何も無い状態となります。 また、各工程の終わりに、次の工程に進むかどうかの判断が行われ、十分でないと判断された場合はその工程の成果物の修正、最レビューを実施する必要があります。もし、最初からぎっしり線表を引き、納期の変更ができない状況では後ろの工程にしわ寄せが行き破綻します。 そのため、納期は状況に応じ、いくらでも延ばせる必要があります。もちろんコストについても納期の遅れに伴い上乗せできる必要があります。
次に、ウォーターフォールでは、要求を理解し、仕様書から実際のプログラムを予見でき、ユーザーの要求とのギャップを指摘できる頭のいい人物がレビューアとして（特に上工程に）必要です。agileな開発手法では、プログラム自体を動かしてレビューすればよいため、一般的なユーザーのレベルの人物でも十分ですが（実際に想定ユーザーと同レベルの方がより良いフィードバックを期待できる）、ウォーターフォールでは、実際のプログラムができるのはずっと先、受け入れの段階であり、その前までは紙の上での議論に始終します。そして、紙の上の話は、完全に固めてから次の工程に進む必要があります。そのため、実際の想定ユーザーを熟知し、紙の上の話と現実に要求される事項とのギャップを指摘できる人物が必要です。
最後に、各工程において、レビューに参加、工程移行の承認をし、万が一仕様と要求とのギャップを見抜けなかった場合や、前工程で欠陥を見抜けなかった場合には全ての責任を取ってくれる（納期延長、予算拡大する）ユーザー（ステークホルダ）が必要です。また、この人物は、プロジェクトの途中で部署異動。退職などが絶対に発生しない人物であることが求められます。
以上の３つの条件- 柔軟な納期
- 頭の良い人物
- 責任を取るユーザー
が全て揃っているならば、かなりの確率で成功すると考えます。恐らく失敗したプロジェクトは上記のうち、少なくとも1つ以上欠けていたのではないでしょうか？次回は、全条件を満たしてから再チャレンジしてみてください。
Re:笑いとしてはイマイチなような (スコア:1)
それでもシステムが動いたのがウォーターフォールの良いところでしょう. 同じシステムをRADなんかでやったら, 多分カットオーバーまで行きませんよ.
ただ経験的にはウォーターフォールが有効なシステムでまともな設計ができるところはほとんど無いですね. 未だにフローチャートとレコード/画面仕様書「だけ」で設計しているので, 業務とシステムの整合性, サブシステム間の整合性, 運用要件の明確化などが全てグズグズな状態です. 結局, 業務分析・システム設計といった上流工程の技術力が無いので, 下流工程ではどうしようもないってだけの話です.
Re:笑いとしてはイマイチなような (スコア:1, すばらしい洞察)
そんなわけでITは「土方」と評されるわけだが、本物の土方は工法ってのが確立されてるだけましだよね。
Re:笑いとしてはイマイチなような (スコア:1)
Re:笑いとしてはイマイチなような (スコア:0)
やっぱ規模や状況ではなく、CIOがいない会社ですよ。 WaterFall Modelが有効なのは。 まちがいない。
て、それが状況か？ でも、ほら、最近CIOをとって付けて済ませた某Stop Exchangeとかね。 当たってるでしょ？
Re:笑いとしてはイマイチなような (スコア:1)
Robert Martinの話は、日頃下請けにシステム開発させている大手システムインテグレータには耳の痛い話でしょうし。
ちょっとまじめに。XP/Agileは小規模向きでWaterfallが大規模向き、みたいな通説がありますが、大規模におけるXP/Agileの検証が序盤についただけ、という程度でしょう。大規模に限らず、Waterfall適用の問題点については、失敗事例が多いので検証が進んでいますよね。
---- 末は社長か懲戒免職 なかむらまさよし
Re:笑いとしてはイマイチなような (スコア:1, すばらしい洞察)
大規模なアジャイルは普通はないけれど、
大規模案件にアジャイルが向かないってのは嘘臭い。
いくら大規模でも完全にモノリシックな開発をやるわけではない
ので、機能単位とかで分割すればいい。分割された単位ごとに
見れば、それぞれは中小規模なのでアジャイルが利用できる。
ウォーターフォール屋さんって、何故かこういう視点が完璧に
抜け落ちているんですよね。
ちなみに完璧にモノリシックで分割不可能だとすると、それ自体が
設計ミスです。そんな腐った設計だと、ウォーターフォール
だろうとアジャイルだろうとうまくいかないでしょう。
Re:笑いとしてはイマイチなような (スコア:3, すばらしい洞察)
大規模案件は、より小規模な問題に分割不能な、大規模案件特有の複雑さを抱えているからこそ、
成功が困難なのではないでしょうか?
それが設計ミスだということなら確かにその通りですが、
そうするとアジャイルとかウォーターフォールとか以前に、
「大規模案件を分割可能にする設計手法」の獲得こそが成功の鍵を握るということになると思います。
Re:笑いとしてはイマイチなような (スコア:2, 興味深い)
正確にいえば分割をアイソレートするのが難しい。
アジャイルだとどんな(モジュールを「またいだ」)変更でも、
向こう三軒両隣が井戸端会議ですりあわせりゃいいじゃん
ということになりますね。
でも大規模で分割「しないとならない」ってのは
その奥に「いったん行った分割を後から変更しにくい」
という毒が潜んでいます。
長屋の一棟(5世帯？)くらいじゃやっていけない「から」
分割するのであって、
隣の棟まで巻き込むと、隣の棟との間のコミュニケーションは
どうしても大味になっちゃう。
だから棟(ごとに担当してるモジュール分割)を跨いだソース変更は、
どうしてもやりにくくなる。
どちらかというと根本的解決は、
ソフトをいかに大規模化「せずにすます」か
を模索する方向に有るような気がしています。
作り方が下手なほど大規模という名の肥大化をしがちですから。
規模を出来るだけ最適化(最小化)したうえで、
チーム分割(=非アジャイル化)が出来るだけ起きないようにする、
というのが狙うべき線かと。
ただ、規模の最適化自体が、高度な技術(情報科学的にも、政治的＆文化的にも)
を必要とするタスクである、ってのが悩みの種ですが。
Re:笑いとしてはイマイチなような (スコア:1)
どうやらそのあたりはDistributed ScrumとかScrum of Scrumsとか呼ばれる分野で事例もあるようなのですが、そもそものScrumにすら拒絶反応を示す人達がいる会社には説明のしようがない...
Distibuted Scrumの論文(PDF) [scrumalliance.org]
---- 末は社長か懲戒免職 なかむらまさよし
April Fool ネタ? (スコア:2, おもしろおかしい)
Re:April Fool ネタ? (スコア:2, おもしろおかしい)
要するに (スコア:1)
滝かよ！！
Re:要するに (スコア:0)
ってわかった上でのツッコミですか？
typo？ 最近の流れ？ (スコア:0)
Re:typo？ 最近の流れ？ (スコア:2, すばらしい洞察)
すべてのプログラマやＳＥの幸福と反映を願って
welfare 2006
きぼんぬ
Re:typo？ 最近の流れ？ (スコア:1)
現実にはよじ登ってでも戻らされるケースが多いですから(＾＾；
Re:typo？ 最近の流れ？ (スコア:1)
mhatta was here
百聞は一見にしかず (スコア:0)
中から外を覗けないマジックミラーの部屋で実際に何か作ってもらったらいい。
表には「あるぷろじぇくとの一生」とか掲げておけば、集客効果抜群!!
実録！デスマーチ！ (スコア:0)
「初日に来た『参加者』を『ランダムに』ピックアップ。
それぞれを夜か昼かも分からない外部から隔絶された独房に
監禁し、独房間のコミュニケーションは手書きの書類のみ
可とする。通信する場合は事前に参加本部に対して、許可申請を
書面にて提出しておくこと。一日の睡眠時間は合計で2時間以下。
食事はコンビニ弁当、おにぎり、菓子パン等のみ許可。ただし
インスタントコーヒーとドリンク剤のみは大量投与して良い。」
こうすればデスマーチがリアルに再現できます。
Re:百聞は一見にしかず (スコア:0)
「あるプログラマーの一生」の間違いでは？(;_;)