Readingagilesamuraiinshimane20120126

← Readingagilesamuraiinshimane

sousk3さんの参加まとめ

sousk3さんが第5回読書会についてまとめて下さいました！　こちらから

第4回読書会ふりかえり

第4回読書会 の藩のまとめをプロジェクターに写しながら、発起人の考えを述べさせて頂きました。

各藩　討論の内容

タイムキーパー藩

第5章 5.4 - 5.5

• 疑問に感じたポイント
  • 捉えどころのないものって具体的に何をさしているのか
    • 要求と要求の行間
    • 前提お客様は当然だと思っていて開発が認識してないもの
    • お客様の漠然とした想い
    • 『○○を20%削減！』は一見具体的なようだけど、どうやって実現するのまで落とし込めていない
    • 『捉えどころのない』存在をお互い認識することが大事
  • 役割としての顧客をしっかりとやれる人はいるのだろうか。つまりプロジェクトに充分時間を割ける人。
    • これまでの経験で、ひとつのプロジェクトに付きっきりになってくれる顧客を見たことない。とにかく説明するのみなのか。
  • トレードオフスライダーの使い方
    • 優先順位があるということをお互い認識すること
    • それをお客様自ら動かせる状態にあること
• 質問）一つのプロジェクトにつきっきりになれる顧客に出会ったことがないということだが、経験があれば教えて下さい。
  • 付きっきりになるとどんないいことがあるだろう…？
  • どれくらい時間を割いたら充分だろうか？
• 回答）
  • 開発とのやり取りの時間もあるが、それ以上に利用者との調整や例えば端末の手配などの準備とかにも時間を取られると思う。半分ぐらいは入ってもらった方がいいのではないか？
  • 私が顧客として経験したプロジェクトでは顔を合わせる時間は週に１回、まる一日でした。それ以外に自分の業務の半分ぐらいをそのプロジェクトの為にささげました。適切だったかの検証はできてないが、足りないぐらいに感じた。

第6章 6.1 - p.112

• フィーチャーとストーリーの関係
  • 大分類がフィーチャー、小分類がストーリー
• 前提（経験）として、言語を問わず、文章化の難しさ、テキストで伝えることの限界を感じている。
  • どうしたら誤解を生まずに理解してもらえるんだろうか？
    • Face to Face 顔を見て話をすることと、図（絵）を交えて話をすると理解度が高まるだろう
    • それで全て理解できるわけではないが、会話をした感覚と図が残って入れば思い出せるよね。
• ユーザーストーリーは誰が書くの？ * どちらでもいいよね。誰が書くかより何を書くかが重要！ * ビジネスの観点からユーザーストーリーを評価できないといけない。 * 「第４章：フィーチャーと効能」に繋がる

オワリ藩

第5章 5.4 - 5.5

• プロジェクト期間と見積もりについて
  • 皆さんどう見積もってますか？
    • 自分の直感した日数×3で見積もっている。実感として事実。信頼できる数字だけど人に説明できないよね w
    • 顧客に納得してもらうにはというのはひとつのテーマだろうな。
  • トレードオフスライダーについて
    • 調整すべきはスコープだが、それが出来る顧客をどうやって確保するのか？が疑問。ここが全て。
• 質問タイム）
  • 顧客の確保がネックということがだったが、個人的なイメージでは、決断できる人を顧客にするのではなく、顧客に据えた人を決断できるようにするんだろうな。
  • 顧客の中でも能動的にそのプロジェクトを推進したいという意欲を持った人が以外といないんです。だれも引いていない馬車が勝手に走っている状態のプロジェクトが世の中にはある。だれが一番馬車に近いのか…。営業的な話に繋がる。
  • 請負側でスコープの調整、切り捨ての判断はできないので悩ましい。
  • 直感×3の見積もりについて
    • 最終的にはこうなるだろうけど、見積もりでこれを提示するとびっくりする。
    • 社内でやっていると長期間の開発はあまりない。こんな機能欲しいんだけどと上司に言われるぐらい。その時に一週間って言っといて一週間を超えちゃうと立場的に良くないので、大目に言ってます。長めにとって速く終わる分には喜ばれるという事実。
    • 安全係数の見積もり基準が世の中にはないし、プロジェクトによっても違うと思う。
    • 経験した２０年前の開発では自分が設定した2倍で提出して、1.5倍でおさめろという根性開発をやっていた。直感×3、なるほどな。前倒して喜ばれることに価値を置いている。
  • 大雑把に決めて、フィードバックを得ながら調整するという実測駆動は難しい。最初に決めた期間でステークホルダーは動きだしてしまう。例えば市場へのアピールとか。
    • 期間は大雑把に見積もるが詰め込む機能は可変、それがスコープの定義だと思います。しかし、最終的に作りたいものやりたいことが見えていないとスコープの定義も難しい。ゴールを決めた上で見極めるのが顧客の役割。ですね。

第6章 6.1 - p.112

発起人ふりかえり

Keep

• 時間を機械的に設定した。
  • 黙読は1ページ1分
  • 討論は1ページ1.5分
  • 発表は2分、質疑応答は3分
• 発表に対してアドバイスすることができた。
• 時間の箱に収めることができた。
• 藩の発表に対して自分の意見を伝えることができた。

Problem

• 討論の時間

Try

• 時間を機械的に設定する

参加者ふりかえり

Keep

• 人が集まる！！

Problem

• すべて読むことができなかった

Try

• 予習しようぜ

SAPA ~ ShimaneAgilityPointAverage ~

xx.x → 第5回読書会 → xx.x

Readingagilesamuraiinshimane20120112 ← → Readingagilesamuraiinshimane20120209