アジャイル開発とスクラムをしっかり理解する1.5日セミナーを参加しました。
初めて参加したワークショップ形式のスクラムセミナーは、おそらく2005年の春だったと思いますが、久しぶりのセミナーで温故知新ができました。
[1日目]
・モダンなソフトウェア開発のための原則とその恩恵とは
・スクラムのフレームワークについて
・役割と自己組織的なチーム
・成果物の紹介とその役目
[2日目]
・どのようなミーティングがあり、どうやって問題を避けるか
・ひとつのスプリントを超えてた計画づくりをどうやるのか
・大規模プロジェクトにおけるスクラム
・より理解を深めるための体験学習
メモ（一日目）
・User storyの書き方
I as a
・セミナー自身もScrumタスク化して、左から右へ進行され、上から下まで優先順位を決めていた。
タスクごとにポイント（時間見積もり）を記入して、それをベースにスプリント（一時間）ごとの説明項目を書かれていた
時間が足りない場合は、優先順位の低い項目は飛ばされる
・Scrumの透明性
最近透明性はより強調されるようになった。（2005年の勉強会時になかったかも）
たとえば、Ground Rule（PJやセミナーの勧め方など）を決めるときに、みんなで一緒に提案して一緒に投票して決まること。
・Burndownチャートはセミナーの進行にも活用され、わかり易かった
・Ball point game
自発的な組織を体験するゲーム。
重要なのはKaizenでKaikakuではない（natural throughputはそんなに簡単に上がらないから。いくらinsentive出してもそんなに簡単に革命が起こらない）。
なお、振り返りの重要性も。ようはPJ完了時にではなく、スプリントおきにプロセスに対する振り返りが重要である
・Agile傘の根幹はLEANである
・Scrumのprincipleは12項目もある
アジャイルの12原則
・Scurmのフレームワーク
プロダクトオーナーのミッション：PJのVisionとROI
Scrumマスターのミッション：障害を取り除く。ファシリテーション
Deliver チーム（Scrumチーム、理想構成は５～９人）のミッション：プロダクトの品質
Sprintの期間：2週間。（１～4週でもいい）
・Visionの定義テンプレート(Elevator Pitch)およびFlickrサービスのVision定義例
For
Who want
The
Unlike
Our product provides
・課題-サザエさんの新しい住む町を作ろうPJ。とりあえず一日目はチームごとにVisionを決めたことで終了した
メモ（二日目）
・Collaborative sketching
スケッチを使ったUser Storyを表現する手法。一人6スケッチを作って（5分間）、グループでお互いに説明して（一人2分）検討して評価する。
絵の質より量が重視される。いいものは青い丸をつける。よくない（いらない）ものは赤丸をつける。
皆でたくさんアイデア出して最終的に合意を取る手段（発散ー＞収束）。 この成果物に基づきProduct Backlogを作る。評価のポイントは昨日のVisionの定義。
概要：
・スケッチ作成段階はとにかく先入観を持たせずにどんどん作っていく
・他のチームの方にも見せる
・スケッチ作成と発表は繰り返し行うことで質が向上していく
・User Interview（「ゲリラリサーチ手法 (Guerilla Research Methods)」）してペルソナを作る
"正規軍（調査の専門家）"でなくても調査――例えば、あなた自身の人脈をたぐってユーザを見つけて、街角のカフェでインタビューして、結果は口頭でチームに伝える――はできます。
ゴールやコンテキストはメモしておく。ユーザの一日の流れやGood dayやworst dayなどを聞いていく
ポイント：ユーザを常に意識すること。早い段階でユーザニーズを気づく。一般的ではなく特定したユーザを対象。design consideration
対象者は一般者。プロではないしデザイナーでもない。しかしユーザの希望を知ることが大事。もちろん対象者が言ってることはすべて正しいとは限らない。
最終的に作成したペルソナはこれ。
・インタビュー結果に基づき大きなスケッチを作る。design considerationを意識すること！
チーム毎に作成して発表する。最終的に全員投票でひとつの案を決める。
・Product Backlog
悪い例：１．粒度が大きすぎて大きなBlockしかない（中身がない）。２．細かすぎで管理しきれない。４．あまり将来過ぎても意味がない。Steve Jobsに怒られるパタン。
いい例：３．直近のタスク。粒度が適切。3スプリント分。優先順位見える。メンテナンスされている。
・Product Backlogの作り方
まずuser storyをカテゴライズする。 ここの例だと、Born,Sleep,Eat,Power, Learn, Earnなどになります。以下の作業は常にお客さん（船さん）に確認しながら進めていく。バリューずれてないかなど確認。
High level featureからuser storyを作る。 各カテゴリの下に並べてみる
user storyに対して優先順位をつける（上は高いほう。S1、S2、E1、E2など。Sはカテゴリ名のInitial文字）
user storyに制約事項を記入（個数や部品など。要は細かい開発要件）
MVP(最小存続可能個体数、minimum viable product) 理論に基づき必要最低限機能に絞る。リスクの高いものを先にテストしていく意味。いらないものは捨てる（たとえば道路は既にあるので不要に）。
各User storyに対して大雑把な工数見積もりする。ボリュームグループは服サイズのXSからXXLまで使うので分かりやすい。とりあえず各グループの下にタスクの紙を移動して張ってみる。
更に、各タスクのサイズ（ポイント制）に基づき、再度各タスクを分類する。ボリュームグループはXS、S、M、L、XL、XXLに細かく分割。ポイントのグループは1,2,3,5,8...足し算で分けていく。
工数精算したら、紙に各User Storyのポイントも記入しておく。
最後にUser Storyを最初のカテゴリの場所にプライオリティ順で戻す。工数が分かったのでリソースを基づく 今スプリントの線（milestone）を引く。
重いタスクがあれば分割してく。これで作業内容（Backlog）は決まり
・Sprint reviewについてはDemoを行うこと。ただ重要なのはProduct ownerに見せることではない！
個々の機能はできたタイミングでオーナーにチェックしてもらいましょうとのこと。多数の失敗例は最後のレビュー会の時に見せたこと。ここは要注意
・振り返り
Scrum masterがよかった点、悪かった点を整理。
Learning Matrixを作る。記入方法は左上：よかった点。右上：悪かった点。左下：次のスプリントでプロセス改善施策。ひとつだけにすること。右下：感謝すること
・Doneの定義について、チェックリストを用意すること！
・あとは、3スプリント（45分間）を分けてLegoの町作り。忙しすぎてメモ取る暇がない。
覚えてるのは、 銀行を作るとして、先にSprint1が壁と屋根を作ってからSprint2で内装を作るを言ったら怒られた。
「これはWaterfallだ。Agileじゃない。Agileはまず小さい銀行を作ってから大きな銀行を作ることだ」。納得。
あとは小さな成果物でも常にProduct Ownerに確認していって合意とフィードバックを取ること。
練習の目的の一つは、大きいPJを小さいスクラムチームで分けて遂行可能を理解することが、全体を仕切るPOがいない、もしくは仕切ることができないととうまく行かない。大PJはUMのスキル次第でうまく行く・行かないで決めるでしょ。Agileやスクラムなどの手法を学ぶのは簡単だが、実際PJの中に活用できるかは別問題だ。スキル足りない人はWaterfallでもうまく行かないでしょ。
・Sprint MTGの例
10時 Demo
10時半 Retro
12時 ランチ
13時～15時もしくは17時 Plan
Planには時間がかかるケースがあるので事前にGrooming MTGをやること。1.5時間、3-7 days before Demoとのこと。
Comments