プログラム開発手法とプロジェクト管理手法はちがうわな - Identity Not Found
前回のエントリで、開発手法がどうという話じゃないのになんでそんな絡みかたになったかというと、まったくの別件で買ったとある開発系の本が「アジャイルマンセー!ウォーターフォールは前時代の遺物!」な主張が端々に現れてて、読んでてノれなかったのがまざってるんだ。 的を射ない要望に対して、ぐだぐだ説明するより動くもん見せちまった方が早いぜ、っていうのは開発者じゃなくても普通にある状況で、事実だと思うんすよね。 けれど、そもそも顧客側(発注側というべきかも)の社内調整ってのは企画立案>承認>>予算提出>承認>>っていうウォーターフォールで進んでる。ぐたぐたいわんと予算よこせってのは当然通用しないし、企画も納期もそうそう手戻りできないんすよ。 なのに、いざ制作段階に入った途端「あじゃいる」とかいわれてもね。開発・実装段階でやるならともかく、設計段階いきなりすっ飛ばしたあげく「手戻り上等ですが予算も納期
アジャイルだウォーターフォールだいう前にさぁ - Identity Not Found
もうさあ。 アジャイルだかウォーターフォールだかどうでもいいよ。 どっちでもいいから、ともかくまずは顧客の要望をきちんとほじくりだして並べてみせてくれよ。 通り一遍のヒアリングでいきなり開発し始めておいて、そうじゃなくてこんなのがいいって指摘したら、仕様変更です直せるけど納期に影響が出ますって。それがアジャイルとかいう手法なのかい? 顧客の出した要望は開発側でまとめてくれよ。顧客が自分でまとめた要望なんて穴だらけなんだよ。 この要望でどんなものが出来上がるのか、開発側は頭ん中にすぐに組み立てられるだろうさ。けど顧客側にはわかんないんだよ? どんなものが出来上がるのか想像もつかないのに、最初から満足な量の要望なんて出し切れないんだよ? 要望を仕様書としてまとめる代わりに、いわゆる「最低限を満たして動くもの」をもってきたとしよう。それに誘引されて顧客側の頭のなかに「どんなものを作るべきなの
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
