Readingagilesamuraiinshibuya20110810
← Readingagilesamuraiinshibuya
- 読書会終了後に有志で飲み会があると思います。(前回からの繰越金2,300円）前回は一人2,600円でした。
- どんどんWikiになんでも書いてください。（まずいことがあれば消しますので）
カードのサイズはどれくらいの使ってる? →座席表に使ってるポスト・イット(5センチ角くらい)､またはもう一回り大きいやつ
ユーザストーリーをあまり大きくないインデックスカードに書いて詳細を詰め込まない様にするのは、早期の段階で詳細な検討をするコストが将来の過程で無駄になるかもしれないという可能性を避けられる、必要になったときにFace to Faceで詳細確認すればよいと、合理的と思いました
内容が簡潔でなくて見直したときに分からなくなったという体験談 「問題を洗い出す」みたいなストーリーが出てよくわからなくなった →ストーリーカードに書くのはfeature(ユーザの体験の単位)である
[余談] ケーキのメタファ(p.108)は@Akiyahさんが2005年ぐらいの時点で発見している。「アジャイルサムライの108ページのケーキの話は、私の書いた絵を平鍋さん経由でメアリーが引用したアイデアと同じだ！」Tweet
見積もりの段階で設計のプロトタイプの話があるはず
縦切りにすることでやり直しが発生することがあるのでは?
- あります｡
- 事前に設計が必要なことはある
- その設計のプロトタイプを作るというストーリーがあるはず
- Featureではないが｡
- そのストーリーについての見積の段階で設計について話しておく
- プランニングポーカーの時話し合っておく
- 全部きっちりやってから実装するというのはだめ
- しかし概要レベルでの認識のすり合わせはやる
- 設計が大丈夫なのかどうかわからないときはスパイクを実施
- 要件定義書のいいところは?
- ユーザと直接顔合わせること無い下請けなのでストーリの共有難しい
- 上から下にこういうものつくれってときは要件定義書がいい
- 「日本語がすごくきれいな人の要件定義書は最強の武器」
- 審査とか監査とか通らない
- 運用するとき仕様書ないとこまる
- すごく複雑な仕様(例外処理多いとか)の場合､仕様書は書くことがある
- 口頭コミュニケーションすることによって間違えるケース
- p.122
- 品質管理部があるとき、どういう動作が正しいのか分かるようにする
- 別に[ユーザーストーリー] vs [要件定義書]という訳ではない
複雑な条件分岐ケースなどは、一覧表などにしてもらった方が効率的なことがあります。
- 色々なツールもあるようだが、あまりツールにとらわれるのは過ぎない方が良い(ツールにしばられてしまう)
そういえばですが、熱心な弟子が最後に「自分でもよく考えてみます」と締めくくる事が多いけど、そういう姿勢が大事なんだなと感じる
- この本の良い所は「こうしなさい」を示すのではなく、各自の現場でより具体的な最適解を考えてみる事を促している所
- その辺りの思想が伝わってグイグイ読み進めてしまう、という感想もありました
お客さんとユーザーストーリーを共有されている方は、どのように共有されていますか？
P119で取り上げている図以外に独自に編み出したやつ（または、試したもの）があれば、紹介して頂けませんか？
P122でマスターは、アジャイルは文書を作ることを目的としない最後の手段だと仰っていますが、 最終的には仕様書などを作る場合があるということでしょうか。 ＊数年経過して、主な開発メンバーが居なくなり、機能追加する必要が発生した場合文書がないと困ると思います。
- 仕様書などを作る場合もある（というか仕様書をまったく書かないということはないのではないか）と思います。「文書化は最後の手段だ。初手から振りかざすものではない」のくだりとか、ヒーロー物の必殺技と同じで、とても大事、でもやたら使いまくるものではないという意味であると理解しました。ちなみに「アジャイル開発者の習慣」の第4回 「ドキュメントを大切にする」にもそのあたりの説明があるようです。
p.122 「モレなくダブリなくストーリーを集められているだろうか？」という確認はこの時点ではどの程度重要なのだろうか。「次のイテレーションでカバーできるからOK」？それとも「この時点でしっかり押さえておいたほうがよい」？
マジカ！ http://www.magicaland.org/
概算見積もりでは、この期間・リソースであればこのプロジェクトはやり遂げられそうだ、というニュアンスを見定められればいいのか、ポイントが絞れて良いと思いました
- p49 あたりの話とイメージが繋がりました
ストーリーをそのままざっくりと見積もっているが、作業内容をブレークダウンしないのか？「やってみたら思ったよりも簡単だった」という場合よりもハマりポイントが隠れていて泣くことになる場合の方が多くなる気がして不安にならないか？ポイントが小さければブレークダウンする間にやってみようってことなのだろうか？
ポイントで見積もるとは、日数と直接関連がない。つまり、熟練プログラマと不慣れなプログラマとでは必要な時間が異なる (3ptのストーリーで、熟練プログラマなら1日だけど不慣れなプログラマなら3日かかるというような) ということを吸収した考えであるのだと理解しました。
- ベテランとビギナーのptはチームの中間に寄せて測るとよいという体験談
###[感想] hirowatari アジャイル開発の現場ではないが、プランニングポーカーを簡単にやってみた。短時間で終わるのに効果が高い。他人のストーリーについて真剣に考えるようになる。
###[コメント] fukumori プランニングポーカーは、「いっせーのせ」でみんなが同時に札を出すのが重要。順番にひとりずつ札を出したりすると前の人の出した数字に必ず引きずられてしまう。
- ベテランは最後に出す位の感じが良いようです
ストーリー同士の相対的なサイズの定め方がそれなりに適切なんだとしたら、見積もりはそのままにしておいた方がよい(p139)の意味合いが今一つ飲み込めませんでした
- 見積もりではストーリーの相対的なサイズを出し、その値は固定 -> プロジェクト完了までに要する時間は「ベロシティ」を測って予測 -> 期日までに収まらないことが予想される場合にはスコープをコントロールする、ということであると理解しました。
- イケてなかった物だけを見直せばよいというニュアンス
- 経験者の話が面白かった
- 体験談が多く聞けた
- 経験者の「こうした方がいい！」という話はすごくタメになります
- 今回は、発言できた！
- 座席表が前面にあってよかった
- 女子枠++
- 全部の章をまんべんなく話を聞けるのはいいと思う
- wiki (x2)
- wikiで意見に意見を重ねてくれる人、ありがとう
拡大画像：http://a.yfrog.com/img738/2559/lnkrq.jpg
ファシリテータやる！ LTやる！ @jiskanulo