パスワードを忘れた？ アカウント作成
Close
12189 story

Waterfall 2006 開催！ 71

ストーリー by mhatta
April is the Craziest Month 部門より

あるAnonymous Coward曰く、"元ネタは XP-jp ML に流れていた投稿。 近頃のアジャイルな開発プロセスに叛旗を翻すべく、Waterfall 2006 というカンファレンスが開催される(日本語版案内)。すべてのセッションに参加できるようにシーケンシャルな形で行われたり（ウォーターフォールの考え方に基づき、テスターはテストのセッションにのみ、プログラマはプログラミングのセッションにのみ参加可能）、ディスカッションを排除してドキュメントによるワークショップが行われたり（当然、履歴は構成管理されるのだろう）と、まさにウォーターフォールによるウォーターフォールのためのカンファレンスである。 最近の流れを踏まえれば、ぜひ『Waterfall 2.0』という名前にしてほしかった... 気がしないでもない。"

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

Waterfall 2006 開催！ More

  • 沈黙の悦び (スコア:5, おもしろおかしい)

    by Anonymous Coward on 2006年04月01日 13時35分 (#913479)
    このハードウェア [waterfall2006.com]が個人的には一番アレゲだと思います。機能的にも申し分ない。

  • 協賛 (スコア:5, おもしろおかしい)

    by kacchan6 (19477) on 2006年04月01日 14時04分 (#913496)
    富士通の協賛です。

    • Re:協賛 (スコア:1, おもしろおかしい)

      by Anonymous Coward on 2006年04月01日 23時42分 (#913662)
      どこに返事するとフリダシに戻るんだろ？　ここかな？

      ウォーターフォールの輪廻
      シェア
      親コメント

    • Re:協賛 (スコア:0)

      by Anonymous Coward
      てぃがう、それは日立

      • Re:協賛 (スコア:0)

        by Anonymous Coward
        豆蔵も。

        • Re:協賛 (スコア:0)

          by Anonymous Coward
          NEC＠お約束

          • Re:協賛 (スコア:0)

            by Anonymous Coward
            この後戻りも分岐も無い流れ・・・・・・
            正にウォーターフォール・・・・・・！

            ＃オレたちはようやくおちはじめたばかりだからな
            ＃このはてしなく長いウォーターフォールをよ・・・

  • プログラム一覧（超訳） (スコア:5, 参考になる)

    by Anonymous Coward on 2006年04月01日 14時35分 (#913504)

    プログラム一覧を日本語にすると、こんな感じ？

    • 現場の決定権を取り返せ ～ マネージャの復権 ～
    • 「柔軟」なプロセスの落とし穴
    • ペアマネージメント - 開発者１人に２人のマネージャを！
    • ２相ウォーターフォールプロセス有害論
    • 理想の操作性：開発の労苦をユーザーにも！
    • テスト：できるならやる、でなければよい
    • 静寂の喜び：会話レスなキューブデザイン
    • WordUnit - ドキュメントユニットテストのススメ
    • 特攻の楽しみ：業務システムを２度書き直す
    • 巨大プロジェクト：終わらなければ失敗なし
    • 単独プロジェクト：コラボレーションからの開放
    • 過去の復権 ～ 古代への回帰 ～
    • 古代メソッド実践：データ中心ソフトウェア開発
    • 俺様プログラミングへのいざない
    • パターンによるデリファクタリング：隠蔽による給与確保法
    • 社内評価プロセスの真髄 ～ 社員間競争の先鋭化 ～
    • 理想のアウトソーシング：メンバ数＝大陸数
    • Ruby On Snails: 新フレームワークによるスローコーディング
    • 瑕疵性ソフトウェア：補修費ビジネスモデル
    • 製品テストの原則：真打は最後まで
    • 実践プロジェクト：いかにすべてを何度も何度も行うか
    • 成熟のプロセス管理：弁護士による弁護士のためのプロセス
    • 開発ライフサイクル：開発のための開発、テストのためのテスト
    • ２４時間戦えますか？－ 知能より期間
    • 認証制度 ～ シールが生む経済価値 ～
    • 悲観的情報伝達プロセス
    後は疲れたので誰かよろしく。

    発表者もミソなんだけど、その辺は原文で噛み締めて下さいな

  • 笑いとしてはイマイチなような (スコア:2, 興味深い)

    by kayama (22142) on 2006年04月01日 17時02分 (#913559) 日記
    双方とも適材適所で、規模や状況に応じて使い分けるものなのに、
    片方がもう片方の相手を一方的にあげつらうと、
    「必死だな」感が醸し出されてしまうというか…

    私が読み方を間違えてるのかなあ。

    • Re:笑いとしてはイマイチなような (スコア:2, すばらしい洞察)

      by Anonymous Coward on 2006年04月01日 18時50分 (#913584)
      > 双方とも適材適所で、規模や状況に応じて使い分けるものなのに、

      ウォーターフォールでうまくいったためしがないです。
      品質ぼろぼろ、コスト上げ上げ、納期りぎりぎ。

      どういった規模や状況だと、ウォーターフォールが有効なんだろうなぁ?

      シェア
      親コメント

      • Re:笑いとしてはイマイチなような (スコア:5, 興味深い)

        by oku (4610) on 2006年04月01日 21時31分 (#913625) 日記
        どういった規模や状況だと、ウォーターフォールが有効なんだろうなぁ?

        マジレスすると、例えば、政治的・経済的に利害の異なる N (N > 1) 個の法人が、徒党を組んで発注又は受注している状況が該当します。

        このような状況下では、何かを後から変えようとすると喧々囂々侃侃諤諤のフレームウォーが発生し、下手をすると裁判沙汰になりかねません。 また、往々にして開発者の数は数百〜千人以上になりますので、開発者間の意志の疎通などハナから不可能です。

        # そもそもそういう体制にするなってのは同意。
        # 政治的に無理なことも多いけど。

        シェア
        親コメント

      • Re:笑いとしてはイマイチなような (スコア:4, すばらしい洞察)

        by Anonymous Coward on 2006年04月01日 19時21分 (#913594)
        >どういった規模や状況だと、ウォーターフォールが有効なんだろうなぁ?
        技術力のない人が下請けに○投げする時。
        たとえどんな酷いデスマでも、丸○げした相手を脅迫すれば
        最後までやり遂げさせられます。最後までやり遂げれば失敗とは
        呼びません。

        故にウォーターフォールの辞書に、失敗という文字はありません。
        シェア
        親コメント

      • ウォーターフォールの適用対象 (スコア:3, おもしろおかしい)

        by Anonymous Coward on 2006年04月01日 19時12分 (#913590)
        必要事項が発注者によって正確に詳細に指示されていて、
        あらかじめ確保した妥当な日程、予算どおりに執行されており、
        予定からの逸脱はないと説明したい人にとっては大変有効な方法です。

        シェア
        親コメント

      • Re:笑いとしてはイマイチなような (スコア:2, 興味深い)

        by kayama (22142) on 2006年04月01日 22時33分 (#913640) 日記
        > どういった規模や状況だと、ウォーターフォールが有効なんだろうなぁ?
        私も知らないのですが、数百人を越える大規模開発では有効なのでは。
        大規模開発案件自体が、開発プロセスの選択に関係なく失敗率の高いものだと思いますが、
        少なくとも、XPやアジャイルで銀行のオンラインシステムを作ったというような事例は
        まだないですよね。

        アジャイル自体がイテレーションを単位とするウォーターフォールだ、という
        解釈も散見しますし、尊敬しつつも乗り越えるべき「親」的存在とでもいえばいいでしょうか。
        アジャイルの立場からウォーターフォールを「笑う」というのは、
        私にはどうもしっくりこないのです。
        シェア
        親コメント
        • というか、「ウォーターフォール」の対になるのは、「スパイラル」だった記憶が・・・

          XPでもアジャイルでもなく？　それら以前の時代とウォーターフォールの後の時代にあるそれ。
          • ウォーターフォールは当初からサイクリックなもの
            あったと聞いた気が・・・。

            問題は契約なんですよ。
            イテレーション毎の契約（見直し）なんて現実的に
            可能なんですかね？
            全体予算の決まった中でのアジャイルなら変更対応が
            そのままコストとして積み上がるだけだし・・・。
            みんなどうしてるんだろ？
            --

            --- （´-`）｡oO(平和な日常は私を鈍くする) ---
            シェア
            親コメント

      • Re:笑いとしてはイマイチなような (スコア:2, 興味深い)

        by Anonymous Coward on 2006年04月01日 23時31分 (#913656)
        >どういった規模や状況だと、ウォーターフォールが有効なんだろうなぁ?

        とりあえず、こういうのだと上手くいきましたね。
        ・全て自社内で作り、売る担当も自社。
        ・担当者規模が50名程度まで。(企画～テストの範囲内)
        ・各担当の仲はそれなりに悪くない。(良いとまでは言わないが(笑))

        規模がでかい話については知りませぬ。
        シェア
        親コメント
      • デザインパターンが定型的に押し込められるシステムなら
        結構waterfallって有効だと思ってますけど
        ＃社内的にはwaterfallなPJ95%ですし... 本来は否定的な立場なのですけど
        --
        みんつ
        シェア
        親コメント

      • Re:笑いとしてはイマイチなような (スコア:2, 興味深い)

        by t-wata (10969) on 2006年04月03日 14時40分 (#914293) 日記
        >ウォーターフォールでうまくいったためしがないです。
        >品質ぼろぼろ、コスト上げ上げ、納期りぎりぎ。

        まず、「納期」の変更ができない場合は、ウォーターフォールの開発はまずいです。agileな開発手法では、「優先度の高いものだけ終わらして納品」ということが可能ですが、ウォーターフォールでは、全工程がシーケンシャルに実施され、最終工程が終わらない限り、物自体が何も無い状態となります。 また、各工程の終わりに、次の工程に進むかどうかの判断が行われ、十分でないと判断された場合はその工程の成果物の修正、最レビューを実施する必要があります。もし、最初からぎっしり線表を引き、納期の変更ができない状況では後ろの工程にしわ寄せが行き破綻します。 そのため、納期は状況に応じ、いくらでも延ばせる必要があります。もちろんコストについても納期の遅れに伴い上乗せできる必要があります。

        次に、ウォーターフォールでは、要求を理解し、仕様書から実際のプログラムを予見でき、ユーザーの要求とのギャップを指摘できる頭のいい人物がレビューアとして（特に上工程に）必要です。agileな開発手法では、プログラム自体を動かしてレビューすればよいため、一般的なユーザーのレベルの人物でも十分ですが（実際に想定ユーザーと同レベルの方がより良いフィードバックを期待できる）、ウォーターフォールでは、実際のプログラムができるのはずっと先、受け入れの段階であり、その前までは紙の上での議論に始終します。そして、紙の上の話は、完全に固めてから次の工程に進む必要があります。そのため、実際の想定ユーザーを熟知し、紙の上の話と現実に要求される事項とのギャップを指摘できる人物が必要です。

        最後に、各工程において、レビューに参加、工程移行の承認をし、万が一仕様と要求とのギャップを見抜けなかった場合や、前工程で欠陥を見抜けなかった場合には全ての責任を取ってくれる（納期延長、予算拡大する）ユーザー（ステークホルダ）が必要です。また、この人物は、プロジェクトの途中で部署異動。退職などが絶対に発生しない人物であることが求められます。

        以上の３つの条件
        • 柔軟な納期
        • 頭の良い人物
        • 責任を取るユーザー
        が全て揃っているならば、かなりの確率で成功すると考えます。恐らく失敗したプロジェクトは上記のうち、少なくとも1つ以上欠けていたのではないでしょうか？
        次回は、全条件を満たしてから再チャレンジしてみてください。
        シェア
        親コメント

      • それでもシステムが動いたのがウォーターフォールの良いところでしょう. 同じシステムをRADなんかでやったら, 多分カットオーバーまで行きませんよ.

        ただ経験的にはウォーターフォールが有効なシステムでまともな設計ができるところはほとんど無いですね. 未だにフローチャートとレコード/画面仕様書「だけ」で設計しているので, 業務とシステムの整合性, サブシステム間の整合性, 運用要件の明確化などが全てグズグズな状態です. 結局, 業務分析・システム設計といった上流工程の技術力が無いので, 下流工程ではどうしようもないってだけの話です.

        シェア
        親コメント
      • > どういった規模や状況だと、ウォーターフォールが有効

        やっぱ規模や状況ではなく、CIOがいない会社ですよ。　WaterFall Modelが有効なのは。　まちがいない。

        て、それが状況か？　でも、ほら、最近CIOをとって付けて済ませた某Stop Exchangeとかね。　当たってるでしょ？
    • Kent BeckのDDDは、日頃ドキュメント書きや内容チェックに追われる身には結構ニヤリとできる話ではあります。

      Robert Martinの話は、日頃下請けにシステム開発させている大手システムインテグレータには耳の痛い話でしょうし。

      ちょっとまじめに。XP/Agileは小規模向きでWaterfallが大規模向き、みたいな通説がありますが、大規模におけるXP/Agileの検証が序盤についただけ、という程度でしょう。大規模に限らず、Waterfall適用の問題点については、失敗事例が多いので検証が進んでいますよね。
      --
      ---- 末は社長か懲戒免職 なかむらまさよし
      シェア
      親コメント

      • Re:笑いとしてはイマイチなような (スコア:1, すばらしい洞察)

        by Anonymous Coward on 2006年04月02日 3時02分 (#913706)
        >XP/Agileは小規模向きでWaterfallが大規模向き、みたいな通説がありますが、
        大規模なアジャイルは普通はないけれど、
        大規模案件にアジャイルが向かないってのは嘘臭い。

        いくら大規模でも完全にモノリシックな開発をやるわけではない
        ので、機能単位とかで分割すればいい。分割された単位ごとに
        見れば、それぞれは中小規模なのでアジャイルが利用できる。

        ウォーターフォール屋さんって、何故かこういう視点が完璧に
        抜け落ちているんですよね。

        ちなみに完璧にモノリシックで分割不可能だとすると、それ自体が
        設計ミスです。そんな腐った設計だと、ウォーターフォール
        だろうとアジャイルだろうとうまくいかないでしょう。
        シェア
        親コメント

        • Re:笑いとしてはイマイチなような (スコア:3, すばらしい洞察)

          by kayama (22142) on 2006年04月02日 11時24分 (#913773) 日記
          知識も経験もないので想像の話で恐縮ですが、
          大規模案件は、より小規模な問題に分割不能な、大規模案件特有の複雑さを抱えているからこそ、
          成功が困難なのではないでしょうか?

          それが設計ミスだということなら確かにその通りですが、
          そうするとアジャイルとかウォーターフォールとか以前に、
          「大規模案件を分割可能にする設計手法」の獲得こそが成功の鍵を握るということになると思います。
          シェア
          親コメント

        • Re:笑いとしてはイマイチなような (スコア:2, 興味深い)

          by Anonymous Coward on 2006年04月02日 14時32分 (#913812)
          その分割がアジャイルの苦手なところでは。
          正確にいえば分割をアイソレートするのが難しい。

          アジャイルだとどんな(モジュールを「またいだ」)変更でも、
          向こう三軒両隣が井戸端会議ですりあわせりゃいいじゃん
          ということになりますね。

          でも大規模で分割「しないとならない」ってのは
          その奥に「いったん行った分割を後から変更しにくい」
          という毒が潜んでいます。

          長屋の一棟(5世帯？)くらいじゃやっていけない「から」
          分割するのであって、
          隣の棟まで巻き込むと、隣の棟との間のコミュニケーションは
          どうしても大味になっちゃう。
          だから棟(ごとに担当してるモジュール分割)を跨いだソース変更は、
          どうしてもやりにくくなる。

          どちらかというと根本的解決は、
          ソフトをいかに大規模化「せずにすます」か
          を模索する方向に有るような気がしています。
          作り方が下手なほど大規模という名の肥大化をしがちですから。
          規模を出来るだけ最適化(最小化)したうえで、
          チーム分割(=非アジャイル化)が出来るだけ起きないようにする、
          というのが狙うべき線かと。

          ただ、規模の最適化自体が、高度な技術(情報科学的にも、政治的＆文化的にも)
          を必要とするタスクである、ってのが悩みの種ですが。
          シェア
          親コメント
        • でもプロジェクトの初期で、えいや！っとサブプロジェクトに分割するっていうのも無茶な話です。かといって、じっくりと考えてから分割するというのはWaterfallになっちゃって、Agileの機動性がでてこない。

          どうやらそのあたりはDistributed ScrumとかScrum of Scrumsとか呼ばれる分野で事例もあるようなのですが、そもそものScrumにすら拒絶反応を示す人達がいる会社には説明のしようがない...

          Distibuted Scrumの論文(PDF) [scrumalliance.org]
          --
          ---- 末は社長か懲戒免職 なかむらまさよし
          シェア
          親コメント

  • April Fool ネタ? (スコア:2, おもしろおかしい)

    by Anonymous Coward on 2006年04月02日 1時20分 (#913690)
    これって、April foolネタなんじゃないでしょうか?

  • 要するに (スコア:1)

    by s-tomo (2841) on 2006年04月01日 13時58分 (#913494) ホームページ 日記
    > Location: Niagara Falls, NY

    滝かよ！！

    • Re:要するに (スコア:0)

      by Anonymous Coward
      ウォーターフォール＝waterfall＝滝

      ってわかった上でのツッコミですか？

  • typo？　最近の流れ？ (スコア:0)

    by Anonymous Coward on 2006年04月01日 13時37分 (#913481)
    ぜひ『Warterfall 2.0』という名前にしてほしかった
    Warterfall 2.0？

  • 百聞は一見にしかず (スコア:0)

    by Anonymous Coward on 2006年04月01日 16時27分 (#913543)
    開催期間を1ヶ月にし、初日に来た開発者をピックアップ
    中から外を覗けないマジックミラーの部屋で実際に何か作ってもらったらいい。

    表には「あるぷろじぇくとの一生」とか掲げておけば、集客効果抜群!!
    • >開催期間を1ヶ月にし、初日に来た開発者をピックアップ
      「初日に来た『参加者』を『ランダムに』ピックアップ。
      それぞれを夜か昼かも分からない外部から隔絶された独房に
      監禁し、独房間のコミュニケーションは手書きの書類のみ
      可とする。通信する場合は事前に参加本部に対して、許可申請を
      書面にて提出しておくこと。一日の睡眠時間は合計で2時間以下。
      食事はコンビニ弁当、おにぎり、菓子パン等のみ許可。ただし
      インスタントコーヒーとドリンク剤のみは大量投与して良い。」
      こうすればデスマーチがリアルに再現できます。
    • >表には「あるぷろじぇくとの一生」とか掲げておけば、集客効果抜群!!
      「あるプログラマーの一生」の間違いでは？(;_;)
typodupeerror

最初のバージョンは常に打ち捨てられる。