アカウント名:
パスワード:
そもそもアジャイル型というのが本当に普及しないといけないんですかね?
それはCOBOLerが「本当にXXX言語を使わなければダメなんですか?COBOLじゃダメなんですか?」と言ってるに等しい。
いつまでも古くて非効率で失敗だらけの方式を使い続けると、遅かれ早かれ性能的金額的品質的に他国との競争に敗北する。
>ウォーターフォールがダメでなのは確定事項でしょうか?>COBOL がダメなのは確定事項でしょうか?どちらもYES。
>ダメなことが確定だとして、アジャイルがウォーターフォール>よりも良いのは確定事項でしょうか?アジャイルが『銀の弾丸』にはならないけれど、ほぼYES。
>きっと、ケースバイケースなのではないでしょうか?違いが分かってない人ほど、こういうことを言うなあ。
ウォーターフォールの方が良い場合。・外注に丸投げする無責任開発・SIビジネスで多重下請け構造・車輪の再発明的なリスクの少ない開発であること・低スキルプログラマを百人単位、時には千人単位で投入できる。・サービス残業させられる・お金に糸目をつけない。スケジュールがどれだけ遅延しても構わない。
まあウォーターフォールでも良いような開発って、組織として腐ってるし終わってるよね。
ウォーターホールの欠点だけ列挙してアジャイルの欠点に言及しないのは公平性にかけるのでは?というか、実際にアジャイルをバリバリつかている人の意見じゃないよね。アジャイルに幻想見過ぎ。高スキルプログラマを望みどおり集められる会社ってどこ?
アジャイルの方が良い場合。・客の協力が得られる【重要】・仕様がよく変わる・プロジェクトが小規模~中規模・プロジェクトに関わるプログラマの半数以上が高スキル・開発者が客から直接ニーズを聞くことができる
日本ではこれに合っていないプロジェクトや体制が多いのがアジャイルが使われることが少ない要因だと思う。アジャイルの方がドキュメントが減るはずなのに、結局納品物としてドキュメントが必要だったりするし。
アジャイルに合っていないプロジェクトや体制が多いのが良いか悪いかはまた別の話。多段請負は弊害が多いけど、やらないとうちみたいな零細はやっていけないしね。
#今やっているプロジェクトなんて、毎月動く形にしてリリースしてるのに#元請けも客も全く触った形跡がない。#どうにかしてくれ。
>アジャイルの方がドキュメントが減るはずこれ自体が”アジャイルの間違った神格化幻想”の最たるものだと思う。
メンテナンスを考えた場合、ドキュメントは必ず必要です。
何を目的にどういう方法論でどういう結果を出す。
最低限これだけはドキュメントにないとメンテナンスなんかできません。最初に開発にかかわった人間が残っていればいいですが。
ソースを見ろ?ソースからだけでは対外”何を目的に”の部分が出てきません。
目的とゴール違いだけど似たような経路を通るなんていくらでもあるんですから。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
コンピュータは旧約聖書の神に似ている、規則は多く、慈悲は無い -- Joseph Campbell
すべき論。 (スコア:0)
そもそもアジャイル型というのが本当に普及しないといけないんですかね?
Re: (スコア:0)
それはCOBOLerが
「本当にXXX言語を使わなければダメなんですか?COBOLじゃダメなんですか?」
と言ってるに等しい。
いつまでも古くて非効率で失敗だらけの方式を使い続けると、
遅かれ早かれ性能的金額的品質的に他国との競争に敗北する。
Re: (スコア:3)
COBOL がダメなのは確定事項でしょうか?
ダメなことが確定だとして、アジャイルがウォーターフォール
よりも良いのは確定事項でしょうか?
どうせダメなんだから、良いか悪いかに関わらず手法を変える
というのも悪い方策では無いかもしれませんが、"非効率で失敗だらけ"
(古いこと自体は悪いことではない;-) であることを説明できなければ
"競争に敗北する。" という結論は前提が崩れますね。
きっと、ケースバイケースなのではないでしょうか?
# まぁ、アジャイルとウォーターフォールの違いも分かってないですし
# プログラミング言語の "良さ" を理解できるほどの知識もないのですが。。。
Re: (スコア:2, すばらしい洞察)
>ウォーターフォールがダメでなのは確定事項でしょうか?
>COBOL がダメなのは確定事項でしょうか?
どちらもYES。
>ダメなことが確定だとして、アジャイルがウォーターフォール
>よりも良いのは確定事項でしょうか?
アジャイルが『銀の弾丸』にはならないけれど、ほぼYES。
>きっと、ケースバイケースなのではないでしょうか?
違いが分かってない人ほど、こういうことを言うなあ。
ウォーターフォールの方が良い場合。
・外注に丸投げする無責任開発
・SIビジネスで多重下請け構造
・車輪の再発明的なリスクの少ない開発であること
・低スキルプログラマを百人単位、時には千人単位で投入できる。
・サービス残業させられる
・お金に糸目をつけない。スケジュールがどれだけ遅延しても構わない。
まあウォーターフォールでも良いような開発って、組織として腐ってるし終わってるよね。
Re:すべき論。 (スコア:1)
ウォーターホールの欠点だけ列挙して
アジャイルの欠点に言及しないのは公平性にかけるのでは?
というか、実際にアジャイルをバリバリつかている人の意見じゃないよね。
アジャイルに幻想見過ぎ。
高スキルプログラマを望みどおり集められる会社ってどこ?
アジャイルの方が良い場合。
・客の協力が得られる【重要】
・仕様がよく変わる
・プロジェクトが小規模~中規模
・プロジェクトに関わるプログラマの半数以上が高スキル
・開発者が客から直接ニーズを聞くことができる
日本ではこれに合っていないプロジェクトや体制が多いのが
アジャイルが使われることが少ない要因だと思う。
アジャイルの方がドキュメントが減るはずなのに、
結局納品物としてドキュメントが必要だったりするし。
アジャイルに合っていないプロジェクトや体制が多いのが
良いか悪いかはまた別の話。
多段請負は弊害が多いけど、やらないと
うちみたいな零細はやっていけないしね。
#今やっているプロジェクトなんて、毎月動く形にしてリリースしてるのに
#元請けも客も全く触った形跡がない。
#どうにかしてくれ。
Re: (スコア:0)
>アジャイルの方がドキュメントが減るはず
これ自体が”アジャイルの間違った神格化幻想”の最たるものだと思う。
メンテナンスを考えた場合、ドキュメントは必ず必要です。
何を目的にどういう方法論でどういう結果を出す。
最低限これだけはドキュメントにないとメンテナンスなんかできません。
最初に開発にかかわった人間が残っていればいいですが。
ソースを見ろ?
ソースからだけでは対外”何を目的に”の部分が出てきません。
目的とゴール違いだけど似たような経路を通るなんていくらでもあるんですから。