ソフト開発をステップ数で見積っていることに疑問を持たなくてはならない - レベルエンター山本大のブログ
ステップ数を見積もり根拠にする会社さんは、いまだに多い。嘘じゃない。 お世話になってる会社さんもそういう仕組みをとってるところがあって、いいにくい部分もなきにもあらずだが、お世話になってるからこそいいたい。 そんなことやってちゃだめだと。 １キロステップの生産性指数をだして、今回の開発は10キロだから１０００万円とか。 汎用機時代ならまだ百歩譲ってわからんでもないけど、オープン系という言葉すら死語になりつつあるこのご時世において、ステップ数が１キロ（１０００行）だったら１人月とかどうこうという話は、もはや見積もりでもなんでもなく、こじつけだ。 フレームワークのコアのコードも、 ビジネスロジックの肝のコードも、 ネットワークの通信コードも、 自動生成したコードも同じ１ステップとカウントする。 見積もり時の計画ステップ数と、実際に開発したときの実績ステップ数を比較して 次の開発の値決め（ダンピ
データベースパフォーマンスに関する、僕が知りうる限り最高の教科書 - レベルエンター山本大のブログ
データベースの醍醐味は、パフォーマンスチューニングにあります。 チューニングによっては、同じ処理でも1時間掛かる場合もあれば、 1秒で終わるということもあり得る世界です。 僕はDBの魅力に取り付かれた者の一人です。 DBという技術の奥深さが気に入っています。 DBを極めると、どこの現場に行っても絶対に必要とされます。 また、どこの現場に行っても正解を導く方程式は一緒なので応用が利くのです。 しかし、その基本原理を体系的に学べる手段はあまりありません。 OracleMasterやMCDBAといった資格試験でも学べることは限られていて あとはWebで調べるなりマニュアルを読むなりするしかありませんでした。 とくに肝であるパフォーマンスチューニングについては、 経験則でチューニングしている部分も多いです。 Oracle、SQLServer、MySQLと色々なDBのチューニングをしてきましたが、
なぜ依然としてウォーターフォールが残っているのか？ - レベルエンター山本大のブログ
マネージメントに携わるようになってウォーターフォールにも理があると思うことが多い。（もちろん最適解ではないが。） ウォーターフォール・反復に次ぐ、実践的な開発プロセスを検討したいとずっと思ってる。そんな検討をしていこうと思う。 ということで、語りつくされてはいるが「アジャイルかウォーターフォールか？」から考える。 アジャイルかウォーターフォールか？ アジャイルプロセスが提唱されてから既に数年、業界の多くの著名人がアジャイルを推奨し、多くの書籍が揃う。 アジャイルの考え方は、ウォーターフォールプロセスによる開発で「仕様変更」と「コストオーバー」、「スケジュールオーバー」に苦しめられてきた開発者達の、怨念にも似た声から生み出されたものだ。 エンジニアの視点から考えると理想的な開発の進め方のように思う。 しかしながら、やはり実際の開発現場は依然として、ウォーターフォール式の開発プロセスを採用する
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
