Readingagilesamuraiinshimane20120209
← Readingagilesamuraiinshimane
第5回読書会 の藩のまとめをプロジェクターに写しながら、発起人の考えを述べさせて頂きました。
- ユーザーストーリーと要件定義書の間にどんな差があるのか。
- 要求工学的な正統派な要件定義書とユーザーストーリーは一緒な気がする。
- スピード間が違うね。
- 変更可能という点が違うね。
- Q.ストーリー間の依存関係や矛盾をどうやって取り除くのか。
- A.ユーザーストーリーを列挙するだけでは依存関係は見えにくいですよね。
- ユーザーストーリーを挙げる時、依存しないように注意した。
- ユーザーストーリーマッピングの紹介
- 横軸を業務フロー、縦軸を優先順位にして、ユーザーストーリーを貼っていくと、ユーザーストーリー間の依存関係や矛盾、リリースまでのスコープが見えやすくなった。また、プロダクトを俯瞰して、開発者が今どのあたりの開発をやっているかを知ることができた。
- 何を軸に依存関係や矛盾を見える化するか。業務の視点で切るということがとても有効です。結合が互いに疎になりやすい単位で切り分けるということ。
- マッピングした後、リストを磨きあげることにコストがかかると思う。でもそれは、夢を描くことなので一番面白く楽しいフェーズかも。
- ベロシティは計測しないと算出できない。新規案件ではどうやって見積もっていく知りたい。
- 例えばプロタイプを作ってみて計測するにしても、その費用をどこが出すのか。
- 実測する前に正確な見積もりを出すにはどうしたらよいか？
- 日本の契約では走り出してからの見積もりは難しい。走り出してからのリスク管理が重要だろう。
- 実測駆動における安全係数の考え方について議論に挙がったが、いつ、どうやって設定して良いのか答えが出なかった。
- Q.何に対する安全係数ですか？
- A.ストーリーポイントに対する。
- なぜ安全係数が必要なのか？議論に挙がったバックグラウンドを説明して貰わないと回答に困る。この本では安全係数は出てこない。何から必要だと思ったかの説明がいると思います。おそらくこの本では安全係数の概念は出てこないだろう。なぜなら、トレードオフスライダーに基づいて、何かを削るという調整をするから。恐らくスコープを調整することになる。アジャイルでは。
- 安全係数もだが、お金の話も載ってない。切り離して考えた方がいい。ここで言う見積もりは作業見積もりのこと。その先に、金額のことを考えた方がいい。ここでは、人月商売の話を置いておいて、やり方の話をしている。
- 議論が意味が無いわけではない。日常のビジネスで使う為の議論なので。ただし、バックボーンの話を説明しないと議論に入れない。内製、発注側、受注側、それぞれのバックボーン、違いを話して、から議論に入るとよい。
- 客の代わりにストーリーを書いても構わない
- アジャイル開発を実践しようと思ってもお客さんの理解を得られなかったり、時間を確保して貰えなったりというのが現実問題起こりうるので開発者がストーリーを書くことは必要になってくると思う。
- 顧客が積極的に要求収集の場に参加し意見を言うこと、開発者は言われたことを表面的に捉えるのではなくて実際お客様が何を望んでいるのか潜在的ニーズを引き出すことが重要。
- 制約について
- 自由すぎると逆に作り憎い。制約があることで帰って作りやすくなる。
- ストーリーと制約の色分けはいいね。
- 質疑応答
- 要求工学でいうと制約は非機能要件。とても挙げにくいもの。それを制約という言葉の定義で意識することが大事。それは、ストーリーに依存しない、ストーリーを横断している、まさに制約。作りたいものだけをヒアリングしていると、機能ばかりが挙がってしまいそう。制約という言葉を定義することで、非機能要件を意識することが大事かなと思います。
- 相対的にポイントで見積もること
- 日数見積もりになった時点で、いつまでに？といったような色々な責任に縛られてしまう。まず進めるために相対的に作業ボリュームをざっくり、すばやくだすのはいい。日数だと残業をどう考慮するのってなっちゃいそうだし。作業の大きさで見積もる事に賛成という意見がでました。
- 質疑応答
- Q.人月前提ならばポイントを最終的に日数に変えないといけないと思うがその議論は出たか。
- A.その話は本にありました。相対的に全体を見積もって、その中で小さいものを実際に手を動かして作ってみて、日数に落とし込み、それを基準とする。大きいものはスパイクを使って、調査をして、見積もれるレベルまで落とし込む。うちがやっている見積もりと同じです。
- Q.プランニングポーカーについて、新人とベテランで意見をすり合わせることができるものなのでしょうか？
- A.うちでは、お客様にも入ってもらってプランニングポーカーをしています。色んな視点での対話が生まれて、気付かないリスクに気付けたり、お客様も考えていなかったようなストーリーが出てきたりします。
- なんと初参加者が二人も！！
- 今週のTRYが実践された。討論に入る時、全ての付箋をホワイトボードに貼って共有した後、テーマ毎にグループピングし、議論を深堀するというやり方。
- 読書会が終わっても会場に残る方多数！読書会を通じて読書会以上の何かを得ようという意欲を感じました。
- 5分ぐらい時間オーバー。これだけは絶対避けねばならぬ。時間は制約ですぞ。
- 別の藩や他の道場、Agileに興味を持っている全ての人達に向かって、我々の意見を理解してもらいやすいようなまとめ方を追求し続ける！ｷﾘｯ
- 読書会以上の価値を探求する。
- ↑ 二つとも曖昧すぎる…。
- 読書会まとめのフィードバックが欲しい…。誰となく。
- 発言できた。
- 付箋出しできた。
- 皆勤賞（^_^）
- 野坂さんの声、カッコいいッス。
- 侃々諤々 四字熟語図書館
- たくさん討論できた。
- 新参者、弐名。
- 現場でやっている方の視点、本質を見る目、に触れることができた。
- 議論の中であいまいな部分について突っ込んで話すことができた。
- ポイント毎にまとめて最初に付箋を貼っていくやり方。
- 時間を守るように促せた！ I'm timekeeper!!
- 他業種の意見が聞けた。
- まとめ方が参考になった。
- 「伝える」ことを意識できていなかった。
- 本を持ってない orz
- 本の内容のダメ出しっぽい話になってしまった。
- 時間内に読み切れなかった。
- 予習いまだに出来ず…。
- 読書会参加回数が藩によって偏ってしまった。
- 仕事を完了させて読書会に参加することができなかった。 ×2
- 経験値の必要性を感じた。（経験値の交換が羨ましかった）
- ホワイトボードのまとめ方はあまり変わらなかったかも…。カルタ藩の2回目は良かった。
- 話を脱線させてしまった。
- 質問、意見する時に笑顔が無い。
- 受け身になっている事が多かった。
- 進め方に戸惑った。
- 本を買う
- これからも参加する
- もっと「アジャイルの理想」をつかんでいきたい。
- 現実の日本式開発にどうアジャイル開発手法をマージするか、追求したい。
- 思ったことは言う。
- 自らのバックグラウンドをさらけ出そう。（大きな金槌に通ず）
- 予習して来るぜ！
- 次回はもう少し発表向けのまとめ方を意識したい
- 私、参加しない方がスムーズに進むかも…。（ウソ♪）
- Keep the smile!!
- 分かりやすいまとめ方
- 意見が出やすい進め方
19.2 → 第6回読書会 → 22.3
Readingagilesamuraiinshimane20120126 ← → Readingagilesamuraiinshimane20120223