社内のスクラム研修受けてきた

社内のスクラム研修受けてきた

カイゼン・ジャーニーも読んだし、現場で「これアジャイルならどうすんだ?」ってことも出てきたので、
社内のアジャイル研修受けてきました(こういう研修がしれっとあるのでIBMはエラい)

スクラムについて

以下は研修内容そのままではなく僕の頭を経由した内容です。

  • 複雑さに対して透明性と検査と適応で対応するフレームワーク
  • と言っても「頑張ります」ではなく、開発を1~2週間程度のスプリントに分け、スプリント内に改善のための会議体を設置して構造的に狙っていく。
  • (機能を小分けにしているとはいえ)2週間程度でリリースできる理由は...
    1. プロダクトバックログがタスクに落ちる(=ready定義を満たす)よう、プロダクトオーナーが次のスプリントまでに要件定義~外部設計に相当することをやる。
    2. スプリントの中で開発チームがやることはWFで言うとこの詳細設計以降くらいな感じ
  • アジャイル=適当なイメージがあったけど、むしろ相当かっちりしている印象。
  • スクラム=小人数なイメージがあったけど、2~3人ならスクラムすべきではなさそう。役割分担できてこそのスクラム
  • 初めてスクラムを導入したチームはだいたいカオスなことになるので2回くらいは素振りスプリントを設ける。

※ちなみにアジャイルマニフェスト。いくつかあるやり方の一つがスクラム(とはいえ60%以上はこれらしい)

実習してみた

座学だけじゃなくて2日間を2スプリントに見立ててスクラムやってみる。いい研修だわ。

ビジョンとバックログの作成

バックログに関わる作業は二つあって、作成と見積もり。
作成するのがディスカバリーチーム(お客様にあたることが多そう)、見積もりがデリバリーチーム(開発チームにあたる)

見積もりはプランニングポーカーを使った。これで初めて思ったんだけど、工数って概念はなんかおかしいよな〜。
作業量 / 単位時間あたりのメンバーのVelocityがいわゆる工数になると思うんだけど、そのVelocityの単位が不在で会話しちゃってることがある気がする。

詳細設計とコーディングみたいに作業量の単位を揃えて語れないものの見積もりをする上で相対見積もりは優秀だな〜と思いました。

スプリント

Prottでモック作成した。グループワークだけど周りの受講者もみんなプロなので進めるのがうまい...
そこまで大変なことはなかったけど、本当は1日あたりのタスクが積んでくると大変&デイリースクラムの有り難味もわかるんだろうな。
(25分を1日に見立てて作業した)

まとめ

アジャイルスクラムって出たこと勝負なのかな?みたいな誤解は解けた感じがある。
一方で、短期間の実習だとタスクの複雑さに限度があるので、そこまで透明性が必要になる切実さがわからん...明日もあるので、その辺意識したいなーと思いました。