第2回スクラムプロダクトオーナー勉強会に参加してきた #postudy

勉強会 Scrum Agile 


本勉強会では、
　　「現場でスクラムを実践するためにはどうすればよいか」
という命題に対して、スクラムで定義されている
3つの役割（チーム、スクラムマスター、プロダクトオーナー）のうち、特に
　　・プロダクトオーナー
にフォーカスを当てて、CSPO研修で扱われた内容や
スクラムギャザリング東京2011で扱う予定の内容を軸に、
過去の導入事例やワークショップなどを通じて参加者同士で議論を行い、
情報交換をすることで互いに有益な場を作っていきたいと考えています。

タイトル及び概要が示す通り『プロダクトオーナー』によりフォーカスを当てたこちらの勉強会。当日は同じくスクラムのイベントで『すくすくスクラム』も開催されていたのですが、個人的に『アジャイルサムライ読書会 DevLOVE道場』で現在参加エントリ〜チーム作業中(且つ当日のテーマに現状の作業状況も合致)であったため、こちらのスクラムイベントに参加する事にしました。

開催場所はあの『海岸沿いのSIer』で知られるTIS株式会社。現場から意外と近いものの交通手段的に時間が掛かりそうだったので、思い切って現場からタクシーで直行しちゃいました。15分・1500円位で到着。


開始時間は18:45〜と若干早目。ある程度の参加者到着状況を把握後、和やかな雰囲気で勉強会が始まりました。(何か陽気なBGMが4〜5分位流れてた(笑))

イベントの進行及びセッション資料発表は主催者/主謀者であるfullvirtue(TwitterID:@fullvirtue) さんが行われました。

まずは自己紹介やこのイベントを開催するにあたっての流れなどを軽めに。

  • 今回の参加者の1/3ぐらいが前回参加者で、残りの方々は今回からの参加。
  • 参加者の顔ぶれ(人数的に)
    • 認定資格所有者：3〜4人
    • スクラム関連イベントに参加している：全体の8割
    • 業務でスクラムを実践している：6人程
    • 現場で開発していない：全体の半分位。
  • POって開発やってない人が多かったりする。
  • 業務に近い・考えが受け入れやすい？
  • スクラム開発者は別として、開発者は結構馴染みにくい？
  • このイベントは2週に1回、各週で開催を予定しています。以下は全体の予定。
第1回：2011/09/16（金）18:45〜20:30
第2回：2011/09/30（金）18:45〜20:30
第3回：2011/10/14（金）18:45〜20:30
第4回：2011/10/28（金）18:45〜20:30
第5回：2011/11/11（金）18:45〜20:30
第6回：2011/11/25（金）18:45〜20:30
  • スクラムプロダクトオーナー勉強会について
    • PM、マネージャー視点での勉強会を自分でやろうか、で作った。
    • 現場でPO実践中。
    • どうぞお付き合いください。
    • 金曜なので打ち上げの飲みにも是非参加を！

なお、今回は認定スクラムマスターとして以下の方々もご参加されておりました。適宜コメントやアドバイス等を各チームでされていた模様です。ありがとうございました！

第1回目の復習(プロダクトバックログ〜出荷可能)

  • アジャイル開発とは何？
    • 4つの価値/12の原則について事例を説明していった。30分位かかった。
  • スクラムにおける役割
    • @kawagutiさんや認定マスターの方々による説明があった。
    • ここにも時間を割いた。

プロダクトバックログ 解説

  • プロダクトバックログ
    • PO(プロダクトオーナー)、お客さんからすれば概要だけ出来てればOK
    • でもチームにとっては『これじゃ開発出来ない』→スプリントバックログを作成、
      • どのくらいの工数で出来るのか。
      • SP：ストーリーポイント。時間で見積もる場合もある。
    • POに対して作成し、提出。
    • POは過去の実績から(実行出来そうなものを選んで)見通しを立てる。『じゃあこれで開発してください。』
  • スプリント計画
    • スプリント計画第1部では、チームの到達範囲を予測。
    • 例)チームベロシティ＝6(時間)だとする。
      • 以下の様な内容で作業が存在していた場合、イテレーション1ではA/B/C、イテレーション2ではD/Eを行う…という計画を立てる事が出来る。
        • A(2時間)
        • B(1時間)
        • C(3時間)
        • D(5時間)
        • E(1時間)
    • 始めたら、中身に対する割り込みを許さない（という合意をチームで得る）
    • 急にやらないといけなくなる(割り込みを許さざるを得なくなる)場合、その計画を全部捨てて（作ってたものも捨てて）一から計画を作り直す。
    • やり直すのならその位破壊的な行為をしないと。リスタート。
      • この辺のやりくりもチーム、お客様との間で合意しとく必要がある。
  • チームが成長するとベロシティも増える。
    • 上記の例でチームのベロシティ＝8となった場合
      • 半端となるような見積もりはしない。8に増えたのでDも行けそうだが、Dの作業を全て行うにはポイントが足りない･･･
        • →期間を増やす、残業で増やすとかして対応したりする。
        • →もしくはDをバラす、EとDを順番変える、等。

    • この段階で分割出来る･･･最初の段階でDを分割出来るのでは？
      • チームでルールを作る場合がある。
        • 4以上の工数になるようなものは再度バラす/小さい粒度のものを増やす、等。
  • タスクボード
    • 何の項目要素を置くかはチームで決める。
  • バーンダウンチャート
    • 最近は飛行機事故もありましたねぇ。

ユーザーストーリーマッピング 解説

  • 要求仕様を自然言語で簡潔に記述したもの。
    • ＜役割＞として＜結果＞が欲しい。それは＜理由＞のためだ。
    • ＜役割＞として＜機能や性能＞が欲しい。それは＜ビジネス価値＞のためだ。

  • 顧客との会話に役立つ
    • (@kawagutiさんによる補足コメント)
      • システムは色々な利用者が居る。かき分ける。そこを洗い出すまでが勝負。→『＊＊＊の担当は〜』
      • ユースケースモデリングを出すところが肝。
        • この辺りはブロードバンドでお客様から収集した方が良い。
        • お客さんもプロではない。お客様の言うとおりに作ると大抵(ry
        • お客さんの提案したストーリーを分析し、解決の為のストーリーを書き出す。
        • 調査結果はPOが握っている必要がある。
        • 常にPOはストーリーの内容・背景・優先度・ゴールが説明出来ないとダメ。なのでPO業も大変なのです。
        • 聞かれた時に『あ、これなんだっけ…』ってなるとチームの信頼を失う。
        • POがスムーズに動ける必要はある。
  • 計画作りに役立つ
  • 無駄な詳細化から解放される
    • 人的、物理的、仕様的距離を
  • 要件（機能）のスケジュールが可能なユニット
    • スケジュールは他に依存していない
  • ユーザーがどう使うかという目線に立って表現
    • 他に依存せずにスケジュール可能な特徴を表現
  • Ron Jeffriesの『3C』
    • Card
      • ストーリーはカードに書き、見積もりやメモなども一緒に書く
    • Conversation
      • ストーリーの背後にある詳細事項はPOの会話から引き出される
        • POの気付かない事がチーム、SM、PO間の会話で出てくる事も。
    • Confirmation
      • 受け入れテストによってストーリーが正しく実装されているか確認する
        • チームとしてみせる→POの判断にユーザーストーリーを使う場合も。
        • 受け入れ手段のツールとして使える場合も。
        • (@kawagutiさんによる補足コメント)
          • 『裏書き』このストーリーを受け入れる為には何を必要とするか。ブレインストーミングして書き出す。
          • 網羅的、必要最低限があるかどうかは改めて見直す。
  • 分割の方向
    • 技術的レイヤー単位で分割しない
      • このやり方だと、全てが揃わないとリリース出来ないタスクがある。
  • 動作する機能単位で分割する
    • エンドツーエンドで動作する単位で分割
    • リリース可能な単位が小さくなる
    • 早くリリース出来る事はビジネス価値に繋がる





ユーザーストーリーマッピング ワークショップ 〜 振り返り＆ディスカッション

前述の通り、ここでのワークショップは過去Scrum Boot Campで行われた川口さん作の資料を用いて行う『ユーザーストーリーマッピング』実践です。

ある架空のストーリー背景にある『飲み会支援システム』の構築について、スクラムの手法でストーリーを洗い出して行くなどの諸々の作業を行う、というものです。『ユーザーストーリーマッピング』については以下の特集や川口さんのBlogエントリを参考にしてみてください。

時間としては正味30分無い位の超スピード作業だったのですが、それぞれ3〜5分程度でワークを行いました。

  • 1.資料や説明の情報を元にユーザーストーリーを洗い出し、付箋に書き出す
  • 2.チーム毎に洗い出したストーリーをまとめる
  • 3.最低限リリース目標(ここまで出来ればみんなに使ってもらえるだろう)を定める




タイムボックスを切って作業をする有効性・効果は高いですが、もうちっと(各10分位？)は時間が欲しかったかな〜、とは思いました。(^_^;) なお、これらの作業終了後に各チームで『ふりかえり』を行い、情報をまとめて提出(A3紙に書き出し)。ワークショップ資料(付箋紙)も次回以降活用可能な形でまとめてます。短時間ながらも色々気付きも得られたので次回以降に活かして行きたいですね。

懇親会

懇親会会場へは開催会場から10〜15分程歩いて移動。


移動の道中、Yasunobu Kawaguchi(TwitterID:@kawaguti)さんにお話を伺う機会がありDevLOVE道場作業の中で疑問に思っていたことについて聞いてみたところ、明快且つ腑に落ちる答えを頂き『そういうスタンス、考え方で良かったんだ...！』とモヤモヤが一気に晴れました。

※疑問点については以下の参戦レポート(ふりかえり：ユーザーストーリー見積もりに際しての疑問)をご参照ください。

内容自体は昨日聞いたばかりで自分の中でも充分に消化・理解を深め切れていない部分もあるので詳細は後述...という形にしたいと思いますが、この時間・機会を持てた事だけでも今回の勉強会に参加した甲斐があったのでは、と思います。川口さん、本当にありがとうございました！


また懇親会本編でもYasunobu Kawaguchi(TwitterID:@kawaguti) さん、KIMURA Takao(TwitterID:@tw_takubon) さん、ayaya(TwitterID:@ayaya1024)さんを中心としたアジャイルと『アレ』を絡めた話など(ネタ的に面白かったし内容的にも符合する点が多く非常に興味深い内容でした。いずれ何らかの形になることを期待。)があったり、XP祭りで始めてお姿をお見かけしたSAITO Ryota (TwitterID:@ryotasaito)さんとXP祭り開催に関するお話を聞くことが出来たりと充実の数時間でした。


主催者であるfullvirtue(TwitterID:@fullvirtue)さん、及びイベントに関わる全ての皆さん、ありがとうございました！

※当イベントのハッシュタグは『#postudy』となる模様です。興味があるという方は今後このハッシュタグを要チェックですね。

…という訳で、今回の勉強会参加(レポート)が記念すべき(？)、区切りの50回目となりました!!(パチパチ〜)

第1回目の参加が2010/10/21なので、ざっくり1年(正確には11ヶ月位)で50回。週1回位は参加していたことになりますね。まぁ良く続いたもんだ…。軽くふりかえりエントリなども書いてみようかな。50回の節目を迎えたのでこれで一区切り…ではなく、あくまでも通過点としてこれからも可能な限り続けて行ければなぁ、と思います。目指せ100回！(笑)