Rail なプロジェクトが燃える理由 - 画面がリッチだと燃える?? - ヲトナ.backtrace
まず、まとめ Rails でも View にかかる工数はあまり変わらない。 web 2.0 っぽいリッチな画面は技術リスクが高いので、思ったより高くつく どうも、上記ふたつの点で計画との乖離が大きくて、失敗するケースが多い。 Rails なプロジェクトの場合、俗に言う web 2.0 の文脈からか従来よりリッチな画面を要求されがちである。 確かに、Rails はそういうアプリケーションの作成には、非常に向いていると思う。 しかし、どうして向いているのかを考えてみると、大きな理由として、Rails では従来 Model と Controller に必要だった工数を大幅に削減できるため、その分の工数を View に回せるからだと僕は思っています。 prototype.js や script.aculo.us などの有用なライブラリや Try and Error のしやすい環境で View の開
さて、仕事で Rails を始めたんですが - ヲトナ.backtrace
少し前から RoR な仕事をしているのですが、RoR はハカー御用達みたいなイメージがあったんだけど、案外、普通の SI 屋さんのプログラマでもどうにかなるもんだなぁっと思った。 振り返りも兼ねつつ、良く人に聞かれる事とかまとめていきたいなぁ。
Rails なプロジェクトが燃える理由 - ヲトナ.backtrace
最近、自社のプロジェクトだけでなく、他社の Rails な仕事でも燃えていて、どうにかしてほしいみたいなことを頼まれることが多い。 それらのプロジェクトを見てみると、幾つか共通した燃えてる理由みたいなのがあったのでまとめてみた。 画面がかなりリッチ 要件や仕様が口伝化している 技術スキルが足りない そもそも工数が足らない(ww 結論を先に書いておくと、「いくら Rails だろうとちゃんと見積りとプロジェクト管理しないと燃えるものは燃える」。 当たり前の話なんだけど、これが一番多い理由だと思う。 もう少し詳しく考えてみると、見積りに関しては、現時点で、発注側も受注側も Rails を採用すれば、どの部分の工数は短縮できて、どの部分の工数は短縮できないかを把握できていない気がする。 また、教育コストをきちんと計画に盛り込めていない気がする。 そのため、見積りの工数と実工数の乖離が大きくなり、
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
