Skip to content

Readingagilesamuraiinakitam20120111

katsuyoshi edited this page Jan 11, 2012 · 7 revisions

 Home / AgilesamuraiDojo / ReadingAgileSamuraiInAkitam / Readingagilesamuraiinakitam20120111

アジャイルサムライ読書会 in Akita.m 第4回

日時: 2012年1月11日 14:30-16:30
場所: 米カフェ
参加者: 5名

記入者: @gutskun

範囲

  • 第6章 ユーザーストーリーを集める

内容

朗読

  • 全員で回し読み

ユーザーストーリーの書き出し

  • 竿燈位置情報のユーザーストーリーを書き出してみた。

書き出したユーザーストーリー

  • ビューアー
    • 地図表示
    • チーム名一覧
    • チーム毎のページ
    • 画面デザイン
      • ボタンの種類
      • 機能の分類
    • リアルタイム更新
    • 市役所のHPからリンクしてもらう
    • 一発で竿を見つけられる
      • 2〜3クリック程度
    • 近くのトイレの位置
    • トイレの混み具合
    • 写真共有サービス
      • twitterと連携
    • インフォメーション
      • 開催、中止等主催者からの情報
    • 迷子の情報
    • ユーザーの位置情報
      • 視聴率のような統計につかいたい
    • 自分の位置が分かる
    • 出店ランキング
    • サイトのリンクの入手方法
      • 駅やバス降り場などにサンドイッチマン
    • 駐車場情報
  • サーバー
    • アカウント管理
    • お祭り作成
    • 今年の分のみ考える
    • 位置情報管理
      • フィルター処理
        • 時間等
    • 市役所からのお知らせ管理
    • スケール
  • アップローダー
    • ログイン
    • 町内一覧
    • 町内選択
    • 位置情報アップロード
    • 送信リトライ
    • ログ表示
    • 端末の配布、回収
    • 端末を紛失した場合は?
  • 全体
    • 運用テスト
    • 失敗した時は…
    • 合宿

フリーディスカッション

  • 文章の曖昧さの再認識
    • 打合せや電話の後に文章化して確認している。
      • それでも個々の認識が異なっていたりする。
        • 最大いくらと決めた
          • 限界値と捉えた
          • 本当はもっと大きいが現段階ではこれでいい
    • 話すのが苦手なので文章でやっている
      • 記録が残るのは良いが、正確に伝わっているかどうか?
    • デザインや音楽(雰囲気)はさらに伝わり難い
      • 個々のバックグラウンドが異なる
  • 認識の違い
    • その業種では常識であって言わなくてもやってもらえると思ってる事がある。
      • 後になって火種に
      • うまく聞き出せていなかった
        • ユーザーストーリーが活用出来るのではないか?
  • 客が納得してくれない
    • サイトの変更(例えばメニューの追加)
      • テンプレート使用
        • 簡単に変更出来る
      • テンプレート未使用(他業者作成)
        • ベージ一つ一つの作業が必要
        • 200ページもあったら?
      • 客から見たらどちらも同じ変更
        • 説明は何となく分かってもらえるが腑に落ちない
          • git等で作業量を視覚化すればどうか?
          • 作業量をユーザーストーリーで視覚化?
            それでも納得してもらえるか?
  • コスト
    • 元々要件定義や仕様作成しなくてもいい規模の仕事でやっている事が多い。
      (本来はしなくちゃいけないのかもしれない)
    • 第II部、III部の作業を客が費用として捉えてもらえないのではないか。
    • 個人的見解(@gutskun)
      • 一人作業なので下手な推測や誤った前提を招き寄せる事が多々ある。
        • 読書会で他の人の意見を聞くと、自分が広げすぎている事を感じる箇所があった。
          • 必要以上の機能が含まれていたりしてないか?
        • スコープを狭める(狭められる)事で第II部、III部の作業に回せるのではないか。
      • やり方が違うので考え方を変える必要があるのではないか
        • 「これをやるにはこれだけかかります」から「予算に合わせてスコープを絞るやり方」
        • 顧客にも覚悟が必要
          • ユーザーストーリーを作成してもらう事で出来る事を納得してもらう。(スコープの調整含む)
          • 今までだとやりたい事を全部やってもらいたいだったのでは?
            結果、後になって「こうなってるはずなのになってない」とクレームになる。

雑感(@gutskun)

  • ユーザーストーリーを出す時に最初どこから手を出せば良いか迷った
    • サーバー、ビューアー、アップローダーと区切りを作ったら出し易くなった。
  • 項目を書き出す事ばかり考えてしまいINVESTなストーリーの基準を満たしているかの確認を忘れてしまった。
  • ストーリー収集で幅広く集めようとした時に、広げようと思えば際限なく広げてしまう事もできるが、広げすぎてしまっても良い物かどうか?
    • やらない事リストから明らかに逸脱する内容は除いた方が良いのか?
    • 全体像を見るために出すだけ出した方が良いのか?
  • 粗い粒度ということで位置情報管理と一項目にまとめてしまったが、もうちょっと粒度を細かくしたほうが良かったのか?
  • その他もろもろは頭の片隅にあって、作業量として把握していな(目をつぶってる)かったりするので、カードに書き出すのは重要と思った。
  • 時間の関係もあり項目の洗い出しだけだったが、図を書いたりすると1日かけてやるつもりで行う作業と感じた。
  • デイブが小さい事に今日気付いた(今まで全く気に留めてなかった orz)

次回

  • 範囲
    • 第7章 見積り:当てずっぽうの奥義
      • 今回出た項目に対してワークショップ形式でやります。
Clone this wiki locally