Readingagilesamuraiinshimane20120126
← Readingagilesamuraiinshimane
sousk3さんが第5回読書会についてまとめて下さいました！ こちらから
第4回読書会 の藩のまとめをプロジェクターに写しながら、発起人の考えを述べさせて頂きました。
- 疑問に感じたポイント
- 捉えどころのないものって具体的に何をさしているのか
- 要求と要求の行間
- 前提お客様は当然だと思っていて開発が認識してないもの
- お客様の漠然とした想い
- 『○○を20%削減！』は一見具体的なようだけど、どうやって実現するのまで落とし込めていない
- 『捉えどころのない』存在をお互い認識することが大事
- 役割としての顧客をしっかりとやれる人はいるのだろうか。つまりプロジェクトに充分時間を割ける人。
- これまでの経験で、ひとつのプロジェクトに付きっきりになってくれる顧客を見たことない。とにかく説明するのみなのか。
- トレードオフスライダーの使い方
- 優先順位があるということをお互い認識すること
- それをお客様自ら動かせる状態にあること
- 捉えどころのないものって具体的に何をさしているのか
- 質問）一つのプロジェクトにつきっきりになれる顧客に出会ったことがないということだが、経験があれば教えて下さい。
- 付きっきりになるとどんないいことがあるだろう…？
- どれくらい時間を割いたら充分だろうか？
- 回答）
- 開発とのやり取りの時間もあるが、それ以上に利用者との調整や例えば端末の手配などの準備とかにも時間を取られると思う。半分ぐらいは入ってもらった方がいいのではないか？
- 私が顧客として経験したプロジェクトでは顔を合わせる時間は週に１回、まる一日でした。それ以外に自分の業務の半分ぐらいをそのプロジェクトの為にささげました。適切だったかの検証はできてないが、足りないぐらいに感じた。
- フィーチャーとストーリーの関係
- 大分類がフィーチャー、小分類がストーリー
- 参考）[システム開発][Agile開発]特徴(Feature)、粗筋(Story)、脚本(Scenario)
- 前提（経験）として、言語を問わず、文章化の難しさ、テキストで伝えることの限界を感じている。
- どうしたら誤解を生まずに理解してもらえるんだろうか？
- Face to Face 顔を見て話をすることと、図（絵）を交えて話をすると理解度が高まるだろう
- それで全て理解できるわけではないが、会話をした感覚と図が残って入れば思い出せるよね。
- どうしたら誤解を生まずに理解してもらえるんだろうか？
- ユーザーストーリーは誰が書くの？
- どちらでもいいよね。誰が書くかより何を書くかが重要！
- ビジネスの観点からユーザーストーリーを評価できないといけない。
- 「第４章：フィーチャーと効能」に繋がる
- プロジェクト期間と見積もりについて
- 皆さんどう見積もってますか？
- 自分の直感した日数×3で見積もっている。実感として事実。信頼できる数字だけど人に説明できないよね w
- 顧客に納得してもらうにはというのはひとつのテーマだろうな。
- トレードオフスライダーについて
- 調整すべきはスコープだが、それが出来る顧客をどうやって確保するのか？が疑問。ここが全て。
- 皆さんどう見積もってますか？
- 質問タイム）
- 顧客の確保がネックということがだったが、個人的なイメージでは、決断できる人を顧客にするのではなく、顧客に据えた人を決断できるようにするんだろうな。
- 顧客の中でも能動的にそのプロジェクトを推進したいという意欲を持った人が以外といないんです。だれも引いていない馬車が勝手に走っている状態のプロジェクトが世の中にはある。だれが一番馬車に近いのか…。営業的な話に繋がる。
- 請負側でスコープの調整、切り捨ての判断はできないので悩ましい。
- 直感×3の見積もりについて
- 最終的にはこうなるだろうけど、見積もりでこれを提示するとびっくりする。
- 社内でやっていると長期間の開発はあまりない。こんな機能欲しいんだけどと上司に言われるぐらい。その時に一週間って言っといて一週間を超えちゃうと立場的に良くないので、大目に言ってます。長めにとって速く終わる分には喜ばれるという事実。
- 安全係数の見積もり基準が世の中にはないし、プロジェクトによっても違うと思う。
- 経験した２０年前の開発では自分が設定した2倍で提出して、1.5倍でおさめろという根性開発をやっていた。直感×3、なるほどな。前倒して喜ばれることに価値を置いている。
- 大雑把に決めて、フィードバックを得ながら調整するという実測駆動は難しい。最初に決めた期間でステークホルダーは動きだしてしまう。例えば市場へのアピールとか。
- 期間は大雑把に見積もる。だけど詰め込む機能は可変、それがスコープの定義だと思います。しかし、最終的に
作りたいものやりたいことが見えていないとスコープの定義も難しい。ゴールを決めた上で見極めるのが顧客の役割ですね。
- 期間は大雑把に見積もる。だけど詰め込む機能は可変、それがスコープの定義だと思います。しかし、最終的に
- 文章のダメな点
- うまく要件定義ができれば開発できるけど、それがうまくいっていないよね。うまい要件定義ってなに？
- 要件定義通りに作っても価値が低いものが出来上がることもあるし。
- それをなくすためのユーザーストーリーなんだ。
- ユーザーストーリーなんだ！ について
- 価値の本質を表現することが重要。価値は普遍だから。それを元に開発すれば、いいものができる。
- 逆に価値に繋がらないところは削ればいい。その判断ができる。
- 何の目的かを意識しながら開発ができる。
- なぜ要件定義ではなくユーザーストーリーを使うのかを意識しながらユーザーストーリーを作るべし。
- 顧客の視点で見れる。歩み寄ることができる。つまり、この機能を作るよりこの困ったを解決するということ。
- 質問タイム）
-
ユーザーストーリーを作った経験があるが、なれるまでは難しかった。慣れるまでは、ついつい、このボタンが欲しいとか、この機能が欲しいという伝え方をしちゃいがち。開発者の経験があるから。ユーザーストーリーを作る人はソフトウェアに精通していない人の方が、本質という点で的を射た伝え方をしてくれるのかなと思いました。
-
ユーザーストーリーをそのまま受け入れることの危険。分析して正しい形に落として実装するべき。
- ユーザーストーリーは簡素な記述である。対話を促進する為ののもの。
- 顧客と開発者のレベルが離れていれば離れているほど会話が生まれにくい。
- されど、会話のきっかけにはなる。開発者側からの支援や提案する活動も必要。
- 粒度も重要。タイムボックスに入りきるのか。
-
何も無い状態ではプロジェクトは進まない。私の印象は、こんな簡単な要件で開発がスタートできるんだという手軽さと、それを変更できるんだという安心感を感じた。
-
- 時間を機械的に設定した。
- 黙読は1ページ1分
- 討論は1ページ1.5分
- 発表は2分、質疑応答は3分
- 時間の箱に収めることができた。
- 藩の発表に対して自分の意見を伝えることができた。
- 他の道場のまとめを紹介することができた。
- なんと初参加者が二人も！！
- 時間を過剰に意識しすぎたかな。
- 実証事業の経験談ばかり話してしまい、深さ？広さ？が無い。
- もっと自然に参加者を時間に乗せるような感覚で進行する。できるかな…。
- 自社で取り組んでいるAgileな活動についても紹介する。
- 時間の箱を守ることができた。
- ユーザーとのやり取りが多い立場の方の体験談を聞くことができた。
- 顧客の要求に対して、分析して本質を突いた提案をするという、本に書いてある以上の提言が出た！
- ストーリーの考え方について理解が深まった。
- 参加し続ける
- 時間配分を意識できた
- 狭く深くの発表を意識できた
- 興味があるところを重点的にやる
- 予習しておいて良かったぜ。
- 積極性を大事にする
- 経験談を伝える
- 没頭！
- しっかりと時間を仕切ってあってやりやすかった
- Face to face
- JR遅れた
- 皆さんの意見に聞き入ってしまって自分の意見を言わなかった
- 発表内容をまとめられず、締めが弱い
- 自分が話してばかりはイマイチ…。
- 電子版＆PCは読みづらい
- ファシリテーション、つまり、意味を引き出す努力！Wtat do you mean?
- 発表時間が短い
- 読み切れなかった
- 予習不足
- 過去分の理解が不足。用語の慣れとか。
- 書記がいると発表を聞く側にも分かりやすいかも。ホワイトボードのまとめを工夫する。
- JRの情報を早めに入手する！
- プロダクトの本質を見落とさない
- 技術者視点の押しつけを避ける
- 自分なりの考えをまとめ意見を言う
- 発表する時は起承転結っぽく！人を惹き付ける発表をする。
- 討論の時、もっと話を引き出すまとめ役になりたい。
- チョコレート以外の甘いもの。
- 紙本を持ってくる
- まとめることを意識して討論する
- 発表の仕方を工夫する（ポイントを絞るなど）
- （討論の時）話を聞きながらボードに書く
- 理解しながら本を最初から読む。
12.2 → 第5回読書会 → 14.1
Readingagilesamuraiinshimane20120112 ← → Readingagilesamuraiinshimane20120209