アカウント名:
パスワード:
そもそもアジャイル型というのが本当に普及しないといけないんですかね?
それはCOBOLerが「本当にXXX言語を使わなければダメなんですか?COBOLじゃダメなんですか?」と言ってるに等しい。
いつまでも古くて非効率で失敗だらけの方式を使い続けると、遅かれ早かれ性能的金額的品質的に他国との競争に敗北する。
>ウォーターフォールがダメでなのは確定事項でしょうか?>COBOL がダメなのは確定事項でしょうか?どちらもYES。
>ダメなことが確定だとして、アジャイルがウォーターフォール>よりも良いのは確定事項でしょうか?アジャイルが『銀の弾丸』にはならないけれど、ほぼYES。
>きっと、ケースバイケースなのではないでしょうか?違いが分かってない人ほど、こういうことを言うなあ。
ウォーターフォールの方が良い場合。・外注に丸投げする無責任開発・SIビジネスで多重下請け構造・車輪の再発明的なリスクの少ない開発であること・低スキルプログラマを百人単位、時には千人単位で投入できる。・サービス残業させられる・お金に糸目をつけない。スケジュールがどれだけ遅延しても構わない。
まあウォーターフォールでも良いような開発って、組織として腐ってるし終わってるよね。
>ウォーターフォールがダメでなのは確定事項でしょうか? >COBOL がダメなのは確定事項でしょうか? どちらもYES。
なぜ?
>ダメなことが確定だとして、アジャイルがウォーターフォール >よりも良いのは確定事項でしょうか? アジャイルが『銀の弾丸』にはならないけれど、ほぼYES。
どこがどう優れているんでしょう? ウォーターフォールかアジャイルのどちらかしか選択肢はないんですかね・・・。
別ACだけど、なぜウォーターフォールではなくアジャイルにすべきなのか?は、この報告書の最初の方にちゃんと書いてあるよ。
アジャイル型開発を中心とする非ウォーターフォール型開発は、従来のウォーターフォール型開発の課題を解決し、ビジネス環境の変化に俊敏に対応できるソフトウェア開発手法として期待されている。近年は、ソフトウェアの開発着手から市場投入までに要する期間を短縮する手法として注目され、競争の激しい分野におけるソフトウェア開発の現場を中心に普及してきている。
もっと詳しい説明についてはリンクされてるWikipediaやら巷のその手の本やらを参照で。記事本文にもあるとおり、アジャイルが適用しづらいケースはあれど、一般的にはこんな感じにアジャイルの方がより効率的な開発手法とみなされている。 (かつ、こうやって欧米がどんどん移行してる以上、実際それで成果が上がっている考えるのが妥当だろう。書籍なんかを読む限りその手法や考え方も納得できるものだし・・・仕事でちゃんと実践してるの目にしたことないけどorz)
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲは一日にしてならず -- アレゲ見習い
すべき論。 (スコア:0)
そもそもアジャイル型というのが本当に普及しないといけないんですかね?
Re: (スコア:0)
それはCOBOLerが
「本当にXXX言語を使わなければダメなんですか?COBOLじゃダメなんですか?」
と言ってるに等しい。
いつまでも古くて非効率で失敗だらけの方式を使い続けると、
遅かれ早かれ性能的金額的品質的に他国との競争に敗北する。
Re: (スコア:3)
COBOL がダメなのは確定事項でしょうか?
ダメなことが確定だとして、アジャイルがウォーターフォール
よりも良いのは確定事項でしょうか?
どうせダメなんだから、良いか悪いかに関わらず手法を変える
というのも悪い方策では無いかもしれませんが、"非効率で失敗だらけ"
(古いこと自体は悪いことではない;-) であることを説明できなければ
"競争に敗北する。" という結論は前提が崩れますね。
きっと、ケースバイケースなのではないでしょうか?
# まぁ、アジャイルとウォーターフォールの違いも分かってないですし
# プログラミング言語の "良さ" を理解できるほどの知識もないのですが。。。
Re: (スコア:2, すばらしい洞察)
>ウォーターフォールがダメでなのは確定事項でしょうか?
>COBOL がダメなのは確定事項でしょうか?
どちらもYES。
>ダメなことが確定だとして、アジャイルがウォーターフォール
>よりも良いのは確定事項でしょうか?
アジャイルが『銀の弾丸』にはならないけれど、ほぼYES。
>きっと、ケースバイケースなのではないでしょうか?
違いが分かってない人ほど、こういうことを言うなあ。
ウォーターフォールの方が良い場合。
・外注に丸投げする無責任開発
・SIビジネスで多重下請け構造
・車輪の再発明的なリスクの少ない開発であること
・低スキルプログラマを百人単位、時には千人単位で投入できる。
・サービス残業させられる
・お金に糸目をつけない。スケジュールがどれだけ遅延しても構わない。
まあウォーターフォールでも良いような開発って、組織として腐ってるし終わってるよね。
Re: (スコア:0)
>ウォーターフォールがダメでなのは確定事項でしょうか?
>COBOL がダメなのは確定事項でしょうか?
どちらもYES。
なぜ?
>ダメなことが確定だとして、アジャイルがウォーターフォール
>よりも良いのは確定事項でしょうか?
アジャイルが『銀の弾丸』にはならないけれど、ほぼYES。
どこがどう優れているんでしょう?
ウォーターフォールかアジャイルのどちらかしか選択肢はないんですかね・・・。
Re:すべき論。 (スコア:0)
別ACだけど、なぜウォーターフォールではなくアジャイルにすべきなのか?は、この報告書の最初の方にちゃんと書いてあるよ。
もっと詳しい説明についてはリンクされてるWikipediaやら巷のその手の本やらを参照で。記事本文にもあるとおり、アジャイルが適用しづらいケースはあれど、一般的にはこんな感じにアジャイルの方がより効率的な開発手法とみなされている。
(かつ、こうやって欧米がどんどん移行してる以上、実際それで成果が上がっている考えるのが妥当だろう。書籍なんかを読む限りその手法や考え方も納得できるものだし・・・仕事でちゃんと実践してるの目にしたことないけどorz)