-
Notifications
You must be signed in to change notification settings - Fork 47
Readingagilesamuraiinhiroshima20120515
isabisi1484 edited this page May 17, 2012
·
4 revisions
今回は、二名の新しい方が参加されました。今回の二名の方も別ルートからお知りになられたとのこと、お一人は実践されておられるとのことでうらやましい限りです。全体では１０名（祝二桁！）となり、段々減っていくだろうなと勝手に想像していたのですが、予想に反して増加中ですｗ。にも関わらず、場所タリーズ３階の場所取りに失敗してしまいまして、参加者の方にはご迷惑をお掛けしました。
次回、２９日は既に予約入れましたので、あとは参加者が５人を割らないことを期待しております。
第７章は、いよいよ？見積の章で18ｐしかないのですが、盛り上がることが予測されたので、次の章には進めずにじっくりと深めることができたのではと思います。（違った印象ならwikiで書いてください^_^;）
-
ふりかえり（約10分）
五回目の記録を元に、説明を行いました。
-
Reading Time（約20分）今回は18Pと短いので２０分にしました。
- プロジェクトのターゲットがコントロールによって達成可能な程度に現実的なものかどうかを判断
実際にこの段階で判断できるのか？ 自分のストーリーでは可能だと思っている（でないと出せない） 見積する際に「前提条件」を沢山書いてしまうが、言い分けにしかならないと思っている。 - 実際に行っている見積手法について
圧倒的にＦＰが多い、または正式なＦＰでは無いかも知れないが、機能数ＤＢ数などを規準に見積もりしている。 ＰＦではなく、過去の類似プロジェクト実績ベースで見積もりしている。新規の場合でも何とか当てはめる。 - 当てずっぽうな見積に対しての考え方について
ここでは、営業や客先との直接的な見積と考えないほうが良いのではないか、内部での見積もりとして捉える
- Nutsという単位で見積することについて
日数や金額で見積すると、どうしても膨らんでしまうのでポイントを使用しているのではないか？ 見積もりする人と、金額を顧客に提示する人、スケジュールする人は異なる場合があるためにポイントにしている 開発する担当者によって、消化可能ポイントが変わってくるために共通単位のポイントにする必要がある しかし結局、金額や日数にするのだから、気持ちの問題だけということもある - ＷＢＳとユーザーストーリーの比較について
ＷＦではＷＢＳを作成し、まず担当に振り分けてから担当に見積をさせるという手法の場合もあるｗ 自分の担当部分が終了しているので、帰ってしまったりする（ダメプロジェクトの例） 寄せ集めプロジェクトの場合、会社が異なる場合があり、その時はさらに難しい
- 三角測量について
楽観値、最頻値、悲観値で見積もるのだが、普通は最頻値を加重平均すると思うがしないのか？ 再見積に対して「答えはイエスだ」、再見積すると信頼関係が崩れる。（顧客との関係は重要！特に担当者） 納得してもらう為には、説明、演出、効果が必要となる、「大変だー」の演出や根回しなど - プランニングーポーカー
参加する人の経験地は近いほうが良い、でないと高経験なひとの説明ばかりでそちらに流れてしまう １００とかのカードもあるが、１から８位までのカードで行うほうが良い（本にも書いてある）
- ウォーターフォールではフェーズ毎に作業が見積もられる、各フェーズの全体比率を比較確認することで確かさ確認 アジャイルだとユーザーストーリー単位なので確かさをセルフチェック出来ない→どうしたらいいのだ 心理的な傾向として、最小ポイントと最大ポイントの二極化するのではないかと思われる →プランニングポーカーすることで、確からしさはすでに確立済みと考えるしかないよね（納得）