ブログ@kaorun55

HoloLensやKinectなどのDepthセンサーを中心に書いています。

読了・アジャイルな見積りと計画づくり

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

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

最近すっかり scrum のトリコとなったワタクシですが、やっと読んだ。
そして借りものの本だったので自分用にちゃんと買った。


最初の感想としては、最近いろいろな人から教えてもらってる scrum についての知識がなかったら、まず理解できなかった。
フィーチャーとは?バックログとは?ベロシティとは?


今、社内で布教活動するときに一番困るのは、それら最初の一歩を踏み始める言葉をどうやって理解してもらえるか。
そのときに紹介してるのが、7月の勉強会での ebacky さんの発表資料
多分これが概要をつかむのに一番いいと思う。
#さすが認定スクラムマスター:)

中身

scrum でのプロジェクト開発の流れが見えてきた半面、また疑問もたくさん出てきた。
ただ疑問が出てくるということは内容を読み取れていると好意的に解釈してる。

理解したこと
  • 顧客が最終成果物を完全に理解していないものとする
  • フィーチャーはユーザーに提供する機能で作成する(おそらく MVC の Model 部分に相当する部分?)
  • 見積もりでは「規模の見積り」と「期間の見積り」を混同しない
  • フィーチャーに優先度を決め、優先度の高いものから進める
  • 優先度が決まらない場合、開発リスクが高いものから進める
  • 困った時は狩野モデルによる優先度付け
  • バーンダウンチャートとバーンダウン棒グラフ(棒グラフは初めて知った)
疑問点
  • ストーリーポイントの設定方法
    • ストーリーポイントをどうやって相対的な規模に置き換えるのか。ベースを1として見積もればよい?
  • ベロシティで個人生産性を計らない
    • 20日のセミナーで PSP(Personal Software Prosess)を使ってる某メーカーさんが質問していた。PSP の場合、自分の生産性を把握し、レビューで欠陥を検出する完全なウォーターフォールなので、scrum とは相容れないと思うけど導入できるものなのか興味がある

まとめ

scrum ってビジネス価値だったり、顧客満足だったり、技術者の視点より少し上から俯瞰して見る感じだと思った。
見積もりがタスクではなく、フィーチャーであることも含めて。
このパラダイムシフトを受け入れられるかどうかが難しいところだと思った。


もう一周読んで実践することと、わからないことを洗い出そうかな。
とにかく すくすくTrac に出てなければこの本は確実に理解できてなかったので、本当にありがたい。


現場に少しずつ入れられそうではあるが、やっぱり一度自分で経験してみたいなぁ。。。