アカウント名:
パスワード:
アジャイルを受け入れてくれる一般企業の発注者、そもそもそんなにいなくない？
素人考えで申し訳ないけど、そもそもどういう開発のやり方をするかなんて、発注側には関係なくない?発注側としては、要求仕様どおりのものを指定期日までに作ってくれればいんだから、問題は要求仕様どおりの物が正しく出来ているかどうかがちゃんと確認できるかだけの問題と思うんだけど。もちろん途中で状況がかわって仕様変更の必要が出てくる事もあるだろうけど、その時は一旦作業を止めて、変更仕様を提示し、納期や追加費用の交渉をするんじゃないのかな。まあ、追加費用が出た場合にその費用調達が行政機関だと難しいのかもしれないが、それは開発手法に関係ないよね。
そもそも要求仕様を定めて動こうとする姿勢自体があまり良くない。運用しながらシステムを改善していくのだ。仕様は結果でしかない。
ほんとそう思う、それ自体建設業界モデルの古い日本の習慣なんじゃないかと思う。
建設業界モデルを古いというのはちょと違うな。ウォーターフォールは、建設のように手戻りのペナルティが極めて大きい業態には良く合った優れた手法。それは今でもそう。その手法を、ソフトウェア開発という手直しが建設より遥かに容易な業態に適用してるから問題なのよ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
開いた括弧は必ず閉じる -- あるプログラマー
自分の体験のみで恐縮だけど (スコア:0)
アジャイルを受け入れてくれる一般企業の発注者、そもそもそんなにいなくない？
Re: (スコア:0)
素人考えで申し訳ないけど、そもそもどういう開発のやり方をするかなんて、発注側には関係なくない?
発注側としては、要求仕様どおりのものを指定期日までに作ってくれればいんだから、問題は要求仕様どおりの物が正しく出来ているかどうかがちゃんと確認できるかだけの問題と思うんだけど。
もちろん途中で状況がかわって仕様変更の必要が出てくる事もあるだろうけど、その時は一旦作業を止めて、変更仕様を提示し、納期や追加費用の交渉をするんじゃないのかな。まあ、追加費用が出た場合にその費用調達が行政機関だと難しいのかもしれないが、それは開発手法に関係ないよね。
Re: (スコア:1)
そもそも要求仕様を定めて動こうとする姿勢自体があまり良くない。
運用しながらシステムを改善していくのだ。
仕様は結果でしかない。
Re: (スコア:0)
ほんとそう思う、それ自体建設業界モデルの古い日本の習慣なんじゃないかと思う。
Re:自分の体験のみで恐縮だけど (スコア:0)
建設業界モデルを古いというのはちょと違うな。
ウォーターフォールは、建設のように手戻りのペナルティが極めて大きい業態には良く合った優れた手法。それは今でもそう。
その手法を、ソフトウェア開発という手直しが建設より遥かに容易な業態に適用してるから問題なのよ。