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