タグ

2009年10月19日のブックマーク (3件)

  • 最近もらった本 - アジャイルな見積りと計画づくり - steps to phantasien(2009-10-18)

    (最近はうそです. もらってから半年くらいたってます....) プロジェクト管理のだった. 見積りの話も丁寧に書かれている. プロジェクト管理の二柱(PMBOK による) "計画" と "監視制御" のうち, "計画" に占めるソフトウェア開発固有な部分は見積りくらいだから, 当然といえば当然かも. 前半 2/3 が計画(=見積り), 後半 1/3 が監視制御の話. 顧客に見積りや計画を求められる管理職には読んでおいて欲しい気がしたけれど, 管理職が読むのを期待するよりは自分で読んで見積りができるようにしておく方が たぶん現実的だし, 書の趣旨にもあっていると思う. 書の前半で説明されている見積りについて言えば, 規律にうるさい マコネルの見積り と比べ 実施の敷居は低い気がするので, まずはこのコーン式見積りをやってみるのが良さそう. 私のいるチームも planning poke

    bash0C7
    bash0C7 2009/10/19
    "だからプログラマは安心して <管理> を 管理職にまかせ, 管理職は誤った判断を下し, プロジェクトは失敗し" 本当はプログラマって管理や計画って上手なのよね。
  • アジャイル開発のボトルネック | Social Change!

    お金なら出しますから、4ヶ月のところを2ヶ月で作ってくれませんか?」 システム開発で、顧客からこう言われた時、どうするか? SIerの経営者や管理職であれば、飛びついてしまうんじゃないだろうか。私だって飛びつきたい。確かにエンジニアがいるなら、もしくは、集める目処が立つなら、ありがたい話かもしれない。XPでも、「リソース・スコープ・品質・時間」のパラメータで、品質以外は変動可能としている。 ということは、リソースがなんとかなれば、時間を短くする、もしくは、時間を変えずにスコープを増やすことができるのだろうか。人月という単位で考えれば、計算上は出来るかもしれないが、実際には難しいと言わざるを得ない。それはなぜか。ボトルネックは、プログラムを作る速度か、それとも、仕様を決めて受け入れる速度か。 冒頭の台詞は、開発側にこそボトルネックがあり、コストさえかければスピードアップできると考えているか

    アジャイル開発のボトルネック | Social Change!
    bash0C7
    bash0C7 2009/10/19
    しかもたいてい顧客側タスクが開発スケジュールに明記されていいないので、ずるずると遅れていく。
  • 開発現場で一度は耳にする「何で聞いてくれなかったの!?」なんて台詞は二度と聞きたく無い。 - ぐらめぬ・ぜぷつぇんのはてダ(2007 to 2011)

    異なる二種類以上の開発現場で、ほぼ同様の条件で題名の「何で聞いてくれなかったの!?」という台詞がマネージャ/リーダから発せられるのを確認した。 ソフトウェアの開発現場で受託・内製問わない(両方の開発現場で確認)。ある担当者にアサインしたソフトウェアコンポーネントが(1)完成した後バグが発覚し、マネージャ/リーダが感知していない作りや設計になっていた、(2)〆切に近づいているが仕上がる感じが無く、確認してみたところ実装上の問題に嵌っていたりマネージャ/リーダが予測できないトリッキーなor複雑な設計orコードになっていた。 そのような場合に、「何でもっと早く相談してくれなかったんだ・・・」というマネージャ/リーダの無念の思いが込められ、「何で聞いてくれなかったの!?」という台詞が担当者に降りかかる。 最初に結論、というかリーダ/マネージャに対する「お願い」になってしまうが、離れ小島的にやけに静

    開発現場で一度は耳にする「何で聞いてくれなかったの!?」なんて台詞は二度と聞きたく無い。 - ぐらめぬ・ぜぷつぇんのはてダ(2007 to 2011)
    bash0C7
    bash0C7 2009/10/19
    あるある