トップ «前の日記(2015-03-10) 最新 次の日記(2015-03-12)» 編集

ヨタの日々

2001|08|09|10|11|12|
2002|01|02|03|04|05|06|07|08|09|10|11|12|
2003|01|02|03|04|05|06|07|08|09|10|11|12|
2004|01|02|03|04|05|06|07|08|09|10|11|12|
2005|01|02|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|04|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|04|05|06|07|08|09|10|11|12|
2012|01|02|03|04|05|06|07|08|09|10|11|12|
2013|01|02|03|04|05|06|07|08|09|10|11|12|
2014|01|02|03|04|05|06|07|08|09|10|11|12|
2015|01|02|03|04|05|06|07|08|09|10|11|12|
2016|01|02|03|04|05|06|07|08|09|10|11|12|
2017|01|02|03|04|05|06|07|08|09|10|11|12|
2018|01|02|03|04|05|06|07|08|09|10|11|12|
2019|01|02|03|04|05|06|07|08|09|10|11|12|
2020|01|02|03|04|05|06|07|08|09|10|11|12|
2021|01|02|03|04|05|06|07|08|09|10|11|12|
2022|01|02|03|04|05|06|07|08|09|10|11|12|
2023|01|02|03|04|05|06|07|08|12|
2024|01|02|03|

2015-03-11 :-)

_ 午前

0520 起床

0700 食堂

0830 労働

1100 外出

_ 午後

1200 高田馬場

1230 おひる。ねぎし

1330 すくすくスクラム

DSC_0950.JPG

_

1900 クールダウン

2000 解散

2100 飯

_ [レゴ][スクラム]LEGO(R)ではじめるスクラム入門(レゴスクラム) - ワイクル株式会社

@高田馬場

@kdmsnr@kakutani による研修(?)。ずーっと以前から行こうとしていて全然行ってなかったんだけどようやく行ってきた。

  1. 座学: スクラムとは
  2. 実技: レゴで街づくり

座学: スクラムとは

基本的にはスクラムガイドに全部書いてある( Scrum Guide の日本語訳 )ものの、では実際にはどうやんの ということで知識を詰め込む。

スクラムの定義

Scrum Guide の日本語訳

スクラム(名詞):複雑で変化の激しい問題に対応するためのフレームワークであり、可能な限り価値の高いプロダクトを生産的かつ創造的に届けるためのものである

複雑で変化の激しい問題に対応するためのフレームワーク

大事なことなので二回言いました。

複雑とはなんぞや?というのはステイシーマトリックス(ステイシーグラフ?)という図を参照。こちら

stacey_matrix.gif

( via The Stacey matrix )

縦軸は課題が明確か不明確か( 何を作ればいいか )。下が明確。上が不明確

横軸は技術的な課題があるかどうか( どうやって作ればいいか )。左が課題なし。右が課題あり。

左下は課題が明確 && 技術的な課題なし

右上は課題が不明確 && 技術的な課題あり。超絶ヤバい。

Complex の部分がスクラムを適用すべきという「複雑」な領域。

スクラムは Complex に適用すべきであり、左下や右上には適さないという。

私のいまの勤務先はスクラムぽい( バックログがあり毎週リリースしている。が、それだけだとわかった ) と思ってたんだが、私の業務としては何を作るか明確だし、どうやって作るのかも明確である。もっと上流レベルの製品コンセプトを考えるような人達ならば「複雑」なんだろうけど、私のところに来る頃にはすでに仕様は明確だし、どうやって作るのかも明確になっているので、どうやらスクラムの出番ではないらしい。

2つのフィードバックループ

リーンにも「構築と検証」のループがあるけど、実際にフィードバックって何やんの というのがふんわりしていたんだけど、2 つの言葉を知ることにより腑に落ちた。

  • プロダクトのフィードバック
    • プロダクトオーナーから貰う
    • よいものが作れたか?
  • プロセスのフィードバック
    • 開発者がおこなう ( KPTとかふりかえり )
    • もっとうまく作る方法はないか?

「K P T ! K P T !」と叫ぶのは簡単だけど、結局これなにやってんだっけ?という ふんわりした理解が言葉として定義された。そうですな。開発者の仕事の回し方を改善できないか を検討してるんですな。

実技: レゴで街づくり

3 チームあり、自分たちが顧客であり開発者である。2 役を担う。

ユーザーストーリーを創る

まず自分たちが顧客となり、架空の家族を作り(ペルソナ)、家族が街に棲むときどのような要望があるかを創る。これが要件作り。

「○○として○○が欲しい。それは○○だからだ」のテンプレに当てはめる。

  • 自営業の父として
  • 図書館が欲しい。
  • それは家で仕事ができないからだ。(根本原因)
    • 他にもこだわりがあれば書く (制約条件。受け入れ条件)

(資料より)

見積もり

ユーザーストーリーを開発者チームへ渡し、開発者が見積もる。

見積もるときは絶対値よりも相対値で見積もる。プランニングポーカーが有名。

  1. 1, 2, 3, 5, 8 (フィボナッチ数列) の紙を用意
  2. ユーザーストーリーを 1 つ選択し数値へ当てはめる
  3. これが基準となる
  4. ほかのユーザーストーリーを見積もる。先のユーザーストーリーと比較して相対値を見積もる

プランニングポーカーは知識としては知っていたんだけど、実際に見積もろうとすると、どうしても「工数」(N人日、N人月) として考えてしまい、どうもプランニングポーカーのような見積もりができなかった。何かコツがあるのかと悶々としていた。今回のレゴスクラムにはこのプランニングポーカー見積もりのヒントが得られるのではないかと期待して参加した。参加して正解だった。そう、相対値なのよね。

スプリント

このような感じでレゴでスクラムを実践していった。

  1. バックログを見積もり( ユーザーストーリー全体 )
  2. 見積もりをスプリント数で割る
  3. それが 1 スプリントで実施できるユーザーストーリー予測となる
  4. 1 スプリント実施
  5. スプリントレビュー ( プロダクトフィードバック。プロダクトオーナーが受け入れ可否を判断 )
  6. スプリントレトロスペクティブ( プロセスフィードバック。振り返り )
  7. 1 スプリントで消化できたユーザーストーリーを積算する( ベロシティ計測 )
  8. 次のスプリントを予測する

1 回目のスプリントでは見積もりとベロシティがかけ離れていた。

スプリントを回すことで、ユーザーストーリーの見積もりの精度も上がり、タスク分割も適切になり、予測値とベロシティが近づいていく。

この様子は、スプリントごとに自分たちが成長していっている、うまくやっていっている、改善している、という実感が得られた。

レゴで作った「枯山水」

DSC_0951.JPG

クールダウン

レゴスクラムで脳が沸騰しそうだったので、レゴスクラムが終わったあと同僚たちを誘い一緒にコーヒーを飲みながら振り返った。

現在の業務にスクラムを当てはめると、誰がプロダクトオーナーなのか、スプリントは何をやっているのか。自己組織化が重要なのだ、などなどといったことを話していた。