アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~

制作 : 安井 力  角谷 信太郎 
  • 毎日コミュニケーションズ
4.22
  • (74)
  • (55)
  • (30)
  • (4)
  • (0)
本棚登録 : 855
レビュー : 62
  • Amazon.co.jp ・本 (336ページ)
  • / ISBN・EAN: 9784839924027

感想・レビュー・書評

並び替え
表示形式
表示件数
  • しばらくチーム開発から離れていたのでとても為になりました。(PivotalTrackerを導入する前にその方法論を学ばねばと慌てて読みました。)

    規模の見積りと期間の見積りを明確に分けるのは目から鱗。

    ただ、受託開発の時にどういった契約書(請求書)出すのかがイメージ出来なかった。他にも参考になりそうな書籍を当たってみたい。

  • アジャイルな見積。計画→見直を行いながら、詳細化していく。
    ゴールドラット氏のクリティカルチェーン的な内容が含まれています。
    開発を行う方法としては、理想的です。

    一方で、顧客は「要件」に匹敵する、「予算」を用意して(もしくは、確保して)いるが、発注されるためには、「要件」をクリアにする必要があり、また、「予算」は枠で確保されるのが現実である。
    また、会社の内部に対しても、ソフト開発=会社からカネを持ち出すということであるから、開発を開始するとき(=お金を借りるとき)、「総額は1000万~2000万の間になると思いますが、ボンヤリとしたこういう機能を実現するのにお金を使いますので貸してください。段々詳細化していきますから」とは行かないであろう。
    お金がからむと急にシビアになり、その予算に見合う機能としてもっと具体的に表現せよ・・・、といった羽目になる。

    つまり、開発を進めるやり方の理想型と、事業を行うやり方の理想型にはギャップがあるということであり、このあたりのギャップに日々苦しめられています。

  • 具体的なやり方をなぜそうするのか含めて説明してくれているのでとても参考になった。

    本に書いてあったからこうするのではなく、現場のフォースを見極めた上で適宜学んだ知識を適用していくよう心がけたい。

  • 従来の計画は作業完了を基準にしているが、顧客からすると価値の単位はフィーチャーである
    (バリューストリームマッピングは意味がある)

    作業基準の計画はパーキンソンの法則により、フルで使うようになってしまう。(という暗黙の了解を得る)
    計画は確率であってコミットメントではない

    ユーザーストーリー→プロダクトバックログ→スプリントバックログ

    リリースプランニング→つぎのリリースのテーマやユーザーストーリーを検討
    イテレーションプランニング→スプリント計画

    プランニングポーカーのゴールは精緻な見積りを出すことではなく、低コストで価値のある見積りを出すこと(労力、正確性曲線の左上)
    プランニングポーカーの議論を長引かせすぎると曲線の右に追いやられ、労力に見合った正確性がでなくなる

    ベロシティは補正装置である
    再見積りすべきときは相対サイズが変わったときのみ

    ベロシティを計測するときのポイントの乗せ方はオールオアナッシングが原則

    チームが熟練してストーリーポイントが変わることはない(サイズが変化するのは例えばフレームワークを導入したとか)

    目標の不確実性(なにを作るか)はいきなりなくせないことは前提にありながらも、早めに(優先的に)減らしていくべき

    スプリントレビューは誰でも参加可能

    優先順位づけ(スプリント始まる前)
    スプリントレビュー(1つ前)
    スプリントプランニング(レビューと同日)
    スプリント(次のやつ)


    開発はヨットで海を航海するようなもの
    (風向きや波によって進むべき進路が変わる)

    個人のベロシティは測るべきでない


  • アジャイルプロセスでの見積に必要な方法論が書かれている。2011年現在では、これが最も合理的で詳細なやり方に見える。

  • 年初に購入してあったのにやっといま読み終わり。なんとか年内に読めた:-)

    会社でこの本の読書会をやるというので読み始めたんだけど、前評判どおりのいい本でした。特に第一部はグッとくる。

    読了したけど、読書会は年明けからが佳境になりそうで、それもふくめてまだまだ楽しめそうな一冊。

  • 定評のある書籍だけど未読だった。

    Agile開発の本でよくある「肝心なところがぼかしてあり、Agileであればなんでもバラ色」的な居心地悪さがない。
    Agile開発は「アバウト」なのではなく、基準点として開発者の経験値を重んじ、数値を重要視するのが良く分かる。

    総量としての見積もり数の制度を上げるのではなく、精度を高めていくという事がよく分かる。

    実際には、経営資料や投資効率指数を駆使して、優先度を決定するなど、かなりハードコアな内容だ。

    実際、びっしり文字なので、読んでいて、細部に入りすぎると感じすぎていたが、最初のチャプタのケーススタディーで、それまでの細部の情報がなぜ必要だったか分かる。

    開発プロセスの本のケーススタディーも、読んでいていまいち居心地悪い感覚があったが、これはケーススタディーが秀悦だ。


    システム開発の現場だけでなく、デザイン、設計、いろんな環境の職場に応用できる。

    評判が高いだけあって素晴らしい内容だった。

  • アジャイルサムライ参考資料

  • ウォーターフォールは、ほぼ死んだ。そもそも、建築プロセスを見本にしたこのやり方がここまで命を永らえたのは、ソフトウエアに対する人類の知見がいかに未熟かを示す良い例だろう。 そのアンチテーゼとして、アジャイルが存在する。アジャイル・マニフェストから垣間見るその精神は高く評価されるも、HowToの決定打と思える本が無いのも事実だったのだが、この本は決定打だと確信できる。この本が2年も前に出版されていたのだから、浅学を恥じるのみである。

  • 図書館
    アジャイル
    ソフトウェア開発
    プログラミング
    見積り
    プロジェクトマネジメント
    コンピュータ
    マネジメント
    IT
    開発

全62件中 1 - 10件を表示

アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~のその他の作品

Mike Cohnの作品

この本を読んでいる人は、こんな本も本棚に登録しています。

有効な左矢印 無効な左矢印
メアリー・ポッペ...
ケント・ベック
スティーブ マコ...
Travis S...
濱野 純(Jun...
有効な右矢印 無効な右矢印

アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~を本棚に登録しているひと

ツイートする