アカウント名:
パスワード:
そもそもアジャイル型というのが本当に普及しないといけないんですかね？
それはCOBOLerが「本当にXXX言語を使わなければダメなんですか？COBOLじゃダメなんですか？」と言ってるに等しい。
いつまでも古くて非効率で失敗だらけの方式を使い続けると、遅かれ早かれ性能的金額的品質的に他国との競争に敗北する。
＞ウォーターフォールがダメでなのは確定事項でしょうか?＞COBOL がダメなのは確定事項でしょうか?どちらもＹＥＳ。
＞ダメなことが確定だとして、アジャイルがウォーターフォール＞よりも良いのは確定事項でしょうか?アジャイルが『銀の弾丸』にはならないけれど、ほぼＹＥＳ。
＞きっと、ケースバイケースなのではないでしょうか?違いが分かってない人ほど、こういうことを言うなあ。
ウォーターフォールの方が良い場合。・外注に丸投げする無責任開発・ＳＩビジネスで多重下請け構造・車輪の再発明的なリスクの少ない開発であること・低スキルプログラマを百人単位、時には千人単位で投入できる。・サービス残業させられる・お金に糸目をつけない。スケジュールがどれだけ遅延しても構わない。
まあウォーターフォールでも良いような開発って、組織として腐ってるし終わってるよね。
ウォーターフォールが問題点の多い開発手法であることは事実だけど、アジャイルがその問題点を解決しているわけではない。
アジャイルは大規模開発には向かないし、製造をオフショアに出すのも難しい。複数の会社が入っている場合も、責任分解点が曖昧になるので向かないでしょう。その代わり、小規模で、客と直結していて、その関係をコントロールしやすい案件ならそのメリットを十分に享受することが出来る。結果として、アジャイルに強いのは小規模な会社に多くなってしまうし、そこにいる人たちが、大手SIerを見下す材料としては非常に使いやすい。
だからといって、既存のウォータフォールを置き換える手法ではないため、大手やそこにぶら下がる側からすると、ドヤ顔されてもなあ、となってしまう。
ということで、手法として対立しているというより、立場が対立させてるだけなんですね。
ウォーターホールの欠点だけ列挙してアジャイルの欠点に言及しないのは公平性にかけるのでは？というか、実際にアジャイルをバリバリつかている人の意見じゃないよね。アジャイルに幻想見過ぎ。高スキルプログラマを望みどおり集められる会社ってどこ？
アジャイルの方が良い場合。・客の協力が得られる【重要】・仕様がよく変わる・プロジェクトが小規模～中規模・プロジェクトに関わるプログラマの半数以上が高スキル・開発者が客から直接ニーズを聞くことができる
日本ではこれに合っていないプロジェクトや体制が多いのがアジャイルが使われることが少ない要因だと思う。アジャイルの方がドキュメントが減るはずなのに、結局納品物としてドキュメントが必要だったりするし。
アジャイルに合っていないプロジェクトや体制が多いのが良いか悪いかはまた別の話。多段請負は弊害が多いけど、やらないとうちみたいな零細はやっていけないしね。
#今やっているプロジェクトなんて、毎月動く形にしてリリースしてるのに#元請けも客も全く触った形跡がない。#どうにかしてくれ。
＞アジャイルの方がドキュメントが減るはずこれ自体が”アジャイルの間違った神格化幻想”の最たるものだと思う。
メンテナンスを考えた場合、ドキュメントは必ず必要です。
何を目的にどういう方法論でどういう結果を出す。
最低限これだけはドキュメントにないとメンテナンスなんかできません。最初に開発にかかわった人間が残っていればいいですが。
ソースを見ろ？ソースからだけでは対外”何を目的に”の部分が出てきません。
目的とゴール違いだけど似たような経路を通るなんていくらでもあるんですから。
日本式SIerのビジネスモデル(奴隷商売)≠ウォーターフォールモデル
SIerのビジネスモデルがウォータフォールによって支えられているだけですね一回で使いつぶす奴隷に継続的開発はむりですからね
＞ウォーターフォールがダメでなのは確定事項でしょうか? ＞COBOL がダメなのは確定事項でしょうか? どちらもＹＥＳ。
なぜ？
＞ダメなことが確定だとして、アジャイルがウォーターフォール ＞よりも良いのは確定事項でしょうか? アジャイルが『銀の弾丸』にはならないけれど、ほぼＹＥＳ。
どこがどう優れているんでしょう？ ウォーターフォールかアジャイルのどちらかしか選択肢はないんですかね・・・。
別ACだけど、なぜウォーターフォールではなくアジャイルにすべきなのか？は、この報告書の最初の方にちゃんと書いてあるよ。
アジャイル型開発を中心とする非ウォーターフォール型開発は、従来のウォーターフォール型開発の課題を解決し、ビジネス環境の変化に俊敏に対応できるソフトウェア開発手法として期待されている。近年は、ソフトウェアの開発着手から市場投入までに要する期間を短縮する手法として注目され、競争の激しい分野におけるソフトウェア開発の現場を中心に普及してきている。
も
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
犯人は巨人ファンでA型で眼鏡をかけている -- あるハッカー
すべき論。 (スコア:0)
そもそもアジャイル型というのが本当に普及しないといけないんですかね？
Re: (スコア:0)
それはCOBOLerが
「本当にXXX言語を使わなければダメなんですか？COBOLじゃダメなんですか？」
と言ってるに等しい。
いつまでも古くて非効率で失敗だらけの方式を使い続けると、
遅かれ早かれ性能的金額的品質的に他国との競争に敗北する。
Re:すべき論。 (スコア:3)
COBOL がダメなのは確定事項でしょうか?
ダメなことが確定だとして、アジャイルがウォーターフォール
よりも良いのは確定事項でしょうか?
どうせダメなんだから、良いか悪いかに関わらず手法を変える
というのも悪い方策では無いかもしれませんが、"非効率で失敗だらけ"
(古いこと自体は悪いことではない;-) であることを説明できなければ
"競争に敗北する。" という結論は前提が崩れますね。
きっと、ケースバイケースなのではないでしょうか?
# まぁ、アジャイルとウォーターフォールの違いも分かってないですし
# プログラミング言語の "良さ" を理解できるほどの知識もないのですが。。。
Re:すべき論。 (スコア:2, すばらしい洞察)
＞ウォーターフォールがダメでなのは確定事項でしょうか?
＞COBOL がダメなのは確定事項でしょうか?
どちらもＹＥＳ。
＞ダメなことが確定だとして、アジャイルがウォーターフォール
＞よりも良いのは確定事項でしょうか?
アジャイルが『銀の弾丸』にはならないけれど、ほぼＹＥＳ。
＞きっと、ケースバイケースなのではないでしょうか?
違いが分かってない人ほど、こういうことを言うなあ。
ウォーターフォールの方が良い場合。
・外注に丸投げする無責任開発
・ＳＩビジネスで多重下請け構造
・車輪の再発明的なリスクの少ない開発であること
・低スキルプログラマを百人単位、時には千人単位で投入できる。
・サービス残業させられる
・お金に糸目をつけない。スケジュールがどれだけ遅延しても構わない。
まあウォーターフォールでも良いような開発って、組織として腐ってるし終わってるよね。
Re:すべき論。 (スコア:2)
違いが分かっていなくて申し訳ないです．
元々の問いは，”アジャイルが普及しなきゃいけないのか？” なわけで
なぜアジャイルを普及させることが当然正しいという流れになっているのか？
っていう疑問だと思うのですが，その答えを ”YES” で返しているように
思えるんですよね．．．
それじゃ，議論になっていないですよね？って言うのが元のコメントの意図
なんですが．．．
# なぜ と YES じゃ，噛み合っていないですよね？
好きな物を好きだと言うのはとっても良いと思うのですが，なぜ好きかと
聞かれたら，なぜかを答えてほしいなと思います．
ところで，開発と組織，腐ってたり終わってたりするのはどちらですか？
まぁ，開発が終わってたりしたら，お家に帰ってオヤスミナサイですかね ;-p
また，場合について書いてありますが，この条件は and か or のどちらでしょうか？
そういった疑問はいくつかあるのですが，気分は分かった気がします．
# フレームの元ですね．．．m(._.)m
> ・外注に丸投げする無責任開発
> ・ＳＩビジネスで多重下請け構造
wikipedia で見た程度の知識で考えると，工程管理をしない or 出来ない，
っぽいのを想定されてそうなので，失敗する条件に見えますね．どちらの手法でも
後半は失敗を許容するという条件でしょうか．．
そんな時なら，どんな手法でも良いので，ウォーターフォールである必要もなさそうです．
むしろ，管理者の名前が表に出てしまって，うやむやに出来ない気がします．
Re:すべき論。 (スコア:1)
ウォーターフォールが問題点の多い開発手法であることは事実だけど、
アジャイルがその問題点を解決しているわけではない。
アジャイルは大規模開発には向かないし、製造をオフショアに出すのも難しい。
複数の会社が入っている場合も、責任分解点が曖昧になるので向かないでしょう。
その代わり、小規模で、客と直結していて、その関係をコントロールしやすい案件なら
そのメリットを十分に享受することが出来る。
結果として、アジャイルに強いのは小規模な会社に多くなってしまうし、
そこにいる人たちが、大手SIerを見下す材料としては非常に使いやすい。
だからといって、既存のウォータフォールを置き換える手法ではないため、
大手やそこにぶら下がる側からすると、ドヤ顔されてもなあ、となってしまう。
ということで、手法として対立しているというより、立場が対立させてるだけなんですね。
＞製造をオフショアに出すのも難しい (スコア:0)
実際、この報告書では米国→ブラジルのオフショアではアジャイルが普及していることが述べられており、「製造だけを」オフショアできないことをもってアジャイルの欠点というのはちと違うのではないかと。
（もちろん、時差がある地域間のオフショアには向かないだろうが。）
Re:すべき論。 (スコア:1)
ウォーターホールの欠点だけ列挙して
アジャイルの欠点に言及しないのは公平性にかけるのでは？
というか、実際にアジャイルをバリバリつかている人の意見じゃないよね。
アジャイルに幻想見過ぎ。
高スキルプログラマを望みどおり集められる会社ってどこ？
アジャイルの方が良い場合。
・客の協力が得られる【重要】
・仕様がよく変わる
・プロジェクトが小規模～中規模
・プロジェクトに関わるプログラマの半数以上が高スキル
・開発者が客から直接ニーズを聞くことができる
日本ではこれに合っていないプロジェクトや体制が多いのが
アジャイルが使われることが少ない要因だと思う。
アジャイルの方がドキュメントが減るはずなのに、
結局納品物としてドキュメントが必要だったりするし。
アジャイルに合っていないプロジェクトや体制が多いのが
良いか悪いかはまた別の話。
多段請負は弊害が多いけど、やらないと
うちみたいな零細はやっていけないしね。
#今やっているプロジェクトなんて、毎月動く形にしてリリースしてるのに
#元請けも客も全く触った形跡がない。
#どうにかしてくれ。
Re: (スコア:0)
＞アジャイルの方がドキュメントが減るはず
これ自体が”アジャイルの間違った神格化幻想”の最たるものだと思う。
メンテナンスを考えた場合、ドキュメントは必ず必要です。
何を目的にどういう方法論でどういう結果を出す。
最低限これだけはドキュメントにないとメンテナンスなんかできません。
最初に開発にかかわった人間が残っていればいいですが。
ソースを見ろ？
ソースからだけでは対外”何を目的に”の部分が出てきません。
目的とゴール違いだけど似たような経路を通るなんていくらでもあるんですから。
Re: (スコア:0)
日本式SIerのビジネスモデル(奴隷商売)≠ウォーターフォールモデル
Re: (スコア:0)
SIerのビジネスモデルがウォータフォールによって支えられているだけですね
一回で使いつぶす奴隷に継続的開発はむりですからね
Re: (スコア:0)
＞ウォーターフォールがダメでなのは確定事項でしょうか?
＞COBOL がダメなのは確定事項でしょうか?
どちらもＹＥＳ。
なぜ？
＞ダメなことが確定だとして、アジャイルがウォーターフォール
＞よりも良いのは確定事項でしょうか?
アジャイルが『銀の弾丸』にはならないけれど、ほぼＹＥＳ。
どこがどう優れているんでしょう？
ウォーターフォールかアジャイルのどちらかしか選択肢はないんですかね・・・。
Re: (スコア:0)
別ACだけど、なぜウォーターフォールではなくアジャイルにすべきなのか？は、この報告書の最初の方にちゃんと書いてあるよ。
も
Re:すべき論。 (スコア:1)
ケースバイケースなのも間違いないでしょう。
しかしそもそもウォーターフォールの元といわれている提唱者は早くプロトタイプを作れと言っていたり、前工程に戻ることも別に禁止していなかった。今ウォーターフォールといわれてる開発形態は単に（大した根拠の無い）見積もりがしやすいので採用されやすかった。
また、過去私がいたところではトヨタ式のなんの言うのも聞こえてましたが、最近じゃトヨタのリーン開発も逆輸入されて「本当はそういう事じゃないんだ」っていうのを他の国から教わる始末。
そういうところがダメだと思います。
アジャイルもそれぞれのプラクティスの理由を踏まえなければ上手くいかないと思いますね。
# yes, fly. no, fry.