はてなブックマーク - アジャイル開発のボトルネック

アジャイル開発のボトルネック - Social Change!

kuranuki.sonicgarden.jp

タグ : agile アジャイル開発システム開発 development *あとで読むあとで読む management sier マネジメント

コンピュータ・IT 150 users

"Work is Life"なカンパニー長の日記：社内ベンチャー立ち上げで学んだことや、社内SNSがもたらす可能性について書いています。「お金なら出しますから、４ヶ月のところを２ヶ月で作ってくれませんか？」システム開発で、顧客からこう言われた時、どうするか？ SIerの経営者や管理職であれば、飛びついてしまうんじゃないだろうか。私だって飛びつきたい。確かにエンジニアがいるなら、もしくは、集める目処が立つなら、ありがたい話かもしれない。XPでも、「リソース・スコープ・品質・時間」のパラメータで、品質以... > このページを見る

最終更新時間: 2009年10月19日07時46分

▼ブログで紹介する

みんなのブックマーク人気（0）新着

hokorobi agile
アジャイルには憧れるけど、関係各位に仕様の確認を行うことを考えると十分な速度を保てない気がする。一人だとユーザへの説明資料作りだけで手一杯だし、人員を増やせば情報過多でユーザがパンクすると思う。 2012/03/29
kireifish アジャイル開発
客「あ。やっぱ仕様変えてー」「え。マジっすか(・∀・;)」客「うーん。なんか違うなー」「どっちなんだ・・・（＾ω＾）」というお話。 2011/10/08
noky アジャイル
提案という考えがないのかね「ボトルネックはあんたら客です」って、何でもかんでも客のせいにしたいみたいだアジャイラーの印象がどんどん悪くなっていく 2011/08/21
gallu
一方で「エンジニアのスキルで上がる速度」もあるだけに、一概に"こう"とは言いにくいあたりがなんとも微妙。 2011/07/14
tmtms
"発注側のかけるコスト（工数）の限界が、ソフトウェア開発における速度の限界点なのだ" "ソフトウエア開発においては、開発側が必要とする工数と、発注側が必要する工数を同等にするべきである" 2011/07/14
nakimura 開発, アジャイル
ボトルネックは発注側 2011/07/04
nozom
こういう感覚は確かにあるな。 / "発注側のかけるコスト（工数）の限界が、ソフトウェア開発における速度の限界点なのだ。" アジャイル開発のボトルネック - Social Change! 2011/06/04
so1nakamura job, ★★★, プロジェクト運営
発注側が仕様調整にどれだけ時間をかけられるかも、工数に大きく関わってくる。ボトルネックは開発工程だけではない。 2010/05/19
takuno ラベルなし
『ソフトウエア開発においては、開発側が必要とする工数と、発注側が必要する工数を同等にするべきである』こんな法則があるのではないだろうか。そして、『発注側は、自社がかけれる工数（コスト）以上の、発注をし 2010/03/02
nekora
継続的リリースなどされた日には、納品される度に受け入れテストと夜間のAP置換とその接続テストでお客は連日徹夜を強いられるという…。 2009/11/19
kanz-labs マネジメント, アジャイル, 読み物
http://forza.cocolog-nifty.com/blog/2009/11/post-f662.htmlの元ネタ 2009/11/03
PoohKid アジャイル, システム開発
『発注側のかけるコスト（工数）の限界が、ソフトウェア開発における速度の限界点』仕様の確定こそがボトルネックは経験上たしかにそのとおり「仕様さえ決まってればすぐ作れますよ（口癖）」 2009/10/23
int128
実に興味深い。仕様承認者がボトルネックになるのは元請けと下請けの関係でも同じ。 2009/10/21
koumiya
確かに、請け負う側がいくら頑張ろうと発注側が本気にならなければどうしようもないというモヤモヤ感はある。 2009/10/21
haishi
つまり、発注側のかけるコスト（工数）の限界が、ソフトウェア開発における速度の限界点なのだ。プロジェクトが成功するかどうかの分水嶺と言える。これは実はアジャイル開発に限らず、一般的なウォーターフォール 2009/10/20
Nagise システム開発, アジャイル
実際、仕様策定が何よりネックなので、まず優先してそれを片付ける。２週間で仕様策定、１週間でプログラミング、１週間でテストで１か月ごとのリリースとか日常茶飯事。 2009/10/20
kmachu agile, development
「発注側のかけるコスト（工数）の限界が、ソフトウェア開発における速度の限界点なのだ。プロジェクトが成功するかどうかの分水嶺と言える。」 2009/10/20
t_yano システム開発, 開発, programming
『発注側のかけるコスト（工数）の限界が、ソフトウェア開発における速度の限界点』結構納得できる。すくなくとも、発注側（客側）の判断速度が開発速度に直結しているという実感はある。 2009/10/20
tarchan agile, development
コストがかけられない発注側は検収を放棄した 2009/10/20
imai78 development, management, agile, programming, sier, 紹介用, business
「数字による見える化」の弊害だよね。並列稼働が可能かどうか、別々に数値化するだけでもずいぶん違う。というお話。 2009/10/20