-
Notifications
You must be signed in to change notification settings - Fork 47
Readingagilesamuraiindwango20110824
akitsukada edited this page Aug 24, 2011
·
8 revisions
参加者：@erukiti @futoase @kwappa @akitsukada @lchin @tlync + 美人天気の中の人
#「第III部：アジャイルな計画づくり」/ "(原文タイトル?)"
原文タイトル：
原文タイトル：
- ソフトウェア見積り、いい本だったよ。いろんな見積方法がかいてある。
- 見積もりやってる？
- まぁ、やってる。
- 何をもって見積というんだろうね
- ガントチャートとか、一つ形にできて、基準にできる状態になれば。
- ここでは、ウォーターフォール的な感覚の見積もりを意識して書かれているね
- 管理者的には、契約も絡んでくるだろうから当てずっぽうじゃなくて確定スケジュールがほしい
- 規模が大きいとまた精度が低くなるよね
- 経験にもよるね
- ケツが決まってるのは別にいいと思う、その分スコープが調節できれば。
原文タイトル：
- ポイントは「意味のないもの」にしようというか「日数とかそういう相対的な意識をせずにすむもの」にしようという感じだよね
- 「ピンチをチャンスに」って訳はちょっと違う気もするかな。。
- ちなみに原文のタイトルは「レモンをレモネードに変える方法」みたいな意味だよ
- デール・カーネギーの『道は開ける』に出てくる言葉＞「運命がレモンをくれたら、それでレモネードを造る努力をしよう。」
- ここではレモンは酸っぱくて食えないもの、レモネードはそこをうまくやって変えたいいもの という比喩
- 前、こういうアジャイルな見積もり導入しようとしたけど、ポイントと理想日と結び付けたい意識がどうしても抜けなくてうまくいかなかったな
- ハックが必要。やっぱりポイントだけじゃなくて「うちのチームではこういう日を１ポイントにしましょう」みたいな尺を共有する。
- それも、途中で、実績と突き合せてベロシティ計測して変えていけばいい、尺を。
- 何回かイテレーション回すとベロシティわかるから、そこから変えていく
- この本でも、最初は「理想日」と言っといて途中から「ポイント」にするみたいなハックが書いてあるわけだよね
- 以前、二人で1理想日1ポイントで見積もり始めても、実績は二週間で5～8ポイントだったりした。
- それは、「計測」はできたよね
- ポイントの理想数ってあるの
- たとえば開発者的には「10ポイント」と見積もりつつ「5ポイント」の実績だったら、目標下げちゃうことになるよね
- ポイントを評価に使ってはいけない
- チームとして何ポイント消費したかは共有すべきだけど、「誰が何ポイント」までは追求しちゃうと引け目を感じちゃいやすいところもあるからうまくやらないと
- 「ポイント」は最初に立てた目標とやってみた結果であって、評価材料じゃなくて次の見積もりの精度をあげる経験値とすべき
- ちなみにどうやってポイント管理してたの？
- Trac使って、ポイントの記録をして、グラフとかも出るようにしたりした。
- どのくらいの規模感・工数感だとこの手法がいいと思う？
- リリースまで2ヶ月で1週間イテレーションくらいとか、3ヶ月で1,2週間イテレーションとかかな。
- サイクルが短いプロジェクトでも現実的に「いつまでにできますか」みたいなことはある、どう対処していけばいい
- メンバーが受け入れてくれないと導入できないだろうし
- いやできるんじゃね 普通に全体では時間で見積もっといても、超ちっちゃい範囲ではポイント化できるんじゃない
- まぁ残業してでもやらなきゃという場面もあるよね
- それはブーストした後の反動（スピードダウン）まで踏まえて見積もれてればいいんじゃない
- ある程度進めてからポイントを見直し、修正することはあるのか？
- ある、やっていいと思う。
- でもポイント総量変わるし、見積もり結果変わる。
- 「精度をあげるための再見積」はいくない、スコープを再検討する材料にするために見積もりなおすのはありと思う
原文タイトル：
- 三角測量！
- さっき話しが出た「再見積」について書いてあるね
- これは相対的に分類するものだね
- 絶対的に「このタスクは8ポイント こっちは9」とかじゃなくて、これはこいつより大きいね みたいな。
- 続けてると途中で基準が変わっていったりしない？
- そういうもんだよね、同じメンバーでチームを長く続けていくと精度上がっていく
- プランニングポーカー
- 人によってポイントが違ったりするよね
- 要件の理解度、足並みを揃える意味が大きいね
- 新人と一緒に見積もりすると大きく意識や理解が違うことがわかったりとか。
- この本的には、コンサル・受託開発を想定というか、そんな感じで書かれてる
- うちらてきには、イテレーション単位で見積もったりする、タスクの割り込みがあるから。「ここまでのバックログをだそう」とか
- 個人個人の作業が頭にあって、チームとしての見積もりに持っていけなかったことがある
- 個人のスキルによって一つのタスクに対するポイント違ったりして。
- じゃあ、見積もりポイントの種類を減らす、「大中小」だけで分類するとか。
- 見積もりを正確にするために時間を書けるんじゃなくて、未来の見積もりの精度を上げるための見積もりと実績
- 「スケジュールコミットメントのための見積もり」という意識でいたからうまくいかなかったかも
- 締切ドリブンよりは「この日までに何ができる」ドリブンでいければいいね
- 弊社の場合、イベント日が決まってそれによってタスクが生じることが多いから、実質的にここで書かれているチームの見積もりは現場では求められていない場合が多いな
- スケジュールを立てるための見積もりは、開発内の基準とは別で開発外の基準があって、「開発外の基準」で見積もるものかな
- 対外的には「良い線いってる当てずっぽうだよ」と出すしかないよね
- まぁそれには「顧客を巻き込んで」おかないとね
- 「アジャイル」は目的じゃなくてツールだけど、マーケティングの道具にされがち。
- 目的は「開発をうまく成功されること」だ
- ウォーターフォールは「ビジネス要件」としてスケジュールを決めて、それを実現方法に変換せずに作業をすすめる
- そりゃあリリースまでは（99%までは）ウォーターフォール最高ですよね、「進んでる」んだから
- ほんとはウォーターフォールももともとの論文では「ちゃんと見なおそうね」と主張してるのにね
- システム屋が作るシステムで、「◯◯パッケージを使ってATMシステムを9ヶ月の超スピード開発」とかを見ると我々の仕事とは違うと思う
- 「失敗できる余裕のあるときにやりましょう」ということだ
- やばいときには挑戦しちゃだめ、一番自分たちが成果を出せる方法でやるもの
- 逆に「専門家」的には、やばいときがセールスチャンスだったりする
- 「火消し役」はいないほうが幸せ
- 周りの人の巻き込み方
- やっぱ同志がいるといいよね
- TDDは一人でもできるな、とは思う
- 新人巻き込んじゃうとか
- なんかアジャイルな感じの体験談おしえて
- KPT：触れる時間がふえる、人となりがわかる、コミュニケーション効率あがる
- 朝会：状況、問題把握できる
- ↑その２つは導入しやすいよね
- 軽い情報交換として毎日やれるけど、意外と大事な情報が出てきたりとかね
- 問題点は何でもあげてほしい、知っておきたい
- 同じ報告を毎日してないか、とか。けっこう把握すべき事態。
- コードレビュー毎日やるようにしてた。
- 毎日だと若干時間は使うけど、結果的にとっても成果があった。
- 情報共有、二人以上でチェック、コミュニケーション。どういうコミットしたのか、という意図を共有する。 * diffレビューしてた。コミット粒度とか、メッセージとか、コード中身とか。ツッコミいれて、ちゃんと答えられるかとか。説明できるかとか。
- ポイントは守破離
- 開発は武道、ケンカとにてる
次回は「第8章 アジャイルな計画づくり」からやります。