スプリントプランニングをうまくやるために意識していること

スクラム

1年ほど専任のスクラムマスターとして活動してきて、スプリントプランニングがうまくいってるケースとうまくいってないケースについてなんとなく見えてきたのでメモとして残す。

スプリントプランニングの目的

自分の理解だとスプリントゴールを達成するための実行可能な作業計画を作るのがプランニングの目的なので、以下の3つが達成できているかを気にしている。

  • チーム全員がスプリントバックログとして分解した全てのタスクについて「何をするタスクか」「完了条件は何か」が理解できている
  • キャパシティに収まる計画になっている（収まらないのであればプロダクトバックログアイテム(PBI)の分割などといった調整が必要）
  • リスク・不確実性のあるタスクがない。もしくはスプリントの早い段階でクリアになる計画となっている

うまくいってないチーム

うまくいってないチームはプランニングで「ゴール達成のための実行可能計画を作る」ことができておらず、行き当たりばったりな計画になっていることが多かった。

そういうチームが作るスプリントバックログの兆候としては

  • 「調査」「設計」のようなタスクがPBI毎に存在する
  • 「バックエンド開発」「画面の実装」など曖昧で、有識者しか具体的に何をするのか理解できないもの
  • 1つ1つのタスクの見積もりが2日などかなり長い
  • そもそも見積もりをしていない（アジャイルだから計画いらないよね？みたいな。。）

あたり。

スプリントプランニングをうまくやるために

現状で意識していること。

プランニングの時間

実行可能な計画を作るのが一番の目的。チームの練度が低い段階だとプランニングにかける時間はあえて気にしない方が良さそう。 スクラムガイドには

スプリントが 1 か月の場合、スプリントプランニングのタイムボックスは最大で 8 時間である。 スプリントの期間が短ければ、スプリントプランニングの時間も短くすることが多い。

とあるが、時間を気にするのはプランニングがうまくできるようになってからが良いと思う。

タスクの粒度

チーム結成直後やチームにJoinしたばかりのメンバーがいる場合は、タスクの粒度を2h以内まで。（場合によっては1hでも良いかも）

理由としては、

  • 各タスクの曖昧さを無くしチーム全員が同じ認識を持つため
  • 予想外のことが発生した場合にデイリースクラムなどで検知しやすくするため

タスクの内容

「設計」のようなタスクは排除。プランニングの中でモブワーク的に設計をしてもらう。

理由としては、

  • 設計が終わっていない状態で分解したタスクは内容が曖昧になってしまうことが多い。→ 設計が終わってみないと本当にスプリント内で完了できるかわからなくなってしまう
  • モブでやることで誰が何を「知っているのか」「知らないのか」が明確になる

進め方のイメージ

  • クラス図などの絵を描きながら認識をすり合わせる
  • 実際のコードを見ながら「このメソッドに処理を追加しよう」「XXXって処理を追加しよう」などの具体的に話しをする
  • コードの実装箇所にコメントを入れておく
  • APIやテーブル設計もこのタイミングでやっておく（あとはドキュメントに起こす、yamlファイル各だけみたいな感じ）

最後に

プランニングがうまくいくとチームとしてゴール達成のイメージを持ちやすくPOも安心感が高まる。 スプリントゴールの達成率が高まれば、チームとして不確実性の高いゴールにもチャレンジできるようになり、成功・失敗を通してチームの学習がより進む。

スクラムを始めたばかりのチームの場合はしっかりとプランニングを行うように促すと良いのではないだろうか。

紙粘土スクラム in 大阪！

スクラム ワークショップ 勉強会

Devlove関西さんにご依頼頂き、ネモトさんと大阪で紙粘土スクラムをやってきました。 f:id:ko_sho:20190721161442j:plain

運営側として紙粘土スクラムのワークショップを行うのはこれで３回目。毎回、新たな発見があり運営する方としても楽しい！

スクラム一枚絵ワーク

最初にスクラム初心者でもざっとスクラムについて理解してもらうため、チームでスクラムガイドを読んでスクラムの一枚絵を作成してもらいました。 それぞれ個性のあるオリジナルな一枚絵が出来上がっていました

成果物

  • Aチーム

スクラムとは森羅万象である！

  • Bチーム

下書きでほぼ出来上がっていた感じだったものさらに清書して非常に綺麗

  • Cチーム

スクラムについて議論に時間を割いていた印象。絵はシンプル。

紙粘土スクラム

本題の紙粘土を使ってのスクラム体験ワークショップです。 今回も自分は顧客役として参加。3チーム全部は見れなかったので、中村洋さんにCチームの顧客役をお願いしました。

顧客役として

意識したのは「自分が本当に何が欲しいのかをわかっていない顧客」ということ。チームには曖昧な要求だけを伝えてインタビューやスプリントレビューでこちらのニーズを引き出してもらおうとしました。

スプリント毎の各チームの成果物

スプリント1

全チームゾウがメイン。

  • Aチーム

  • Bチーム

  • Cチーム

スプリント2

少しずつチームの特色が。

  • Aチーム

  • Bチーム

  • Cチーム

スプリント3

だいぶ紙粘土にも慣れてきました。

  • Aチーム

  • Bチーム

  • Cチーム

スプリント4

総仕上げ！

  • Aチーム

  • Bチーム

  • Cチーム

各自のふるまいについて意見交換

ワーク終了後全体のふりかえり。各自と自分以外のロールのふるまいについて意見交換をしてもらいました。

自分が聞いていた範囲だと、やったことのないロールは思ってた以上に難しかったという話しが多かったですね。 また、チームの他の人から自分の行動についてフィードバックをもらうことで良い学びの場になっていたように思いました。今後、このふりかえりは入れたほうが良さそう！

個人的には、自分がふりかえりに参加したAチームにスクラムコーチの Aki さんがいらっしゃり、各ロールの方々にコメントされてたのは非常に勉強になりました。

全体のふりかえり

全体でFun! Done! Learn!でふりかえり。 時間が押してしまったため、じっくり出来ずごめんなさい。

運営側として

今回は比較的スクラムの経験がある方が多かったこともあり、いろいろとフィードバックを頂くことができました。 紙粘土楽しかったという声も結構聞こえたので、大阪に遊びに来て良かったなー！ Devlove関西さん、本当にお呼び頂いてありがとうございました！

ネモトさんとアイデア出しも出来たので、次にやる時はさらに良いワークショップになるはず！

これからスクラムをやってみたい方、チームの他の人にもスクラムを知ってもらいたい方などいらっしゃいましたらお声がけくださいませ！

アジャイル札幌 | Doorkeeper

TDDBC札幌2019

TDDBC 勉強会

2019/06/15 札幌でTDD Boot Campを開催しました。令和初のTDDBCとなります。

札幌での開催は2011年以来8年ぶり。講師として@t_wadaさん、TAとして仙台から@i_takehiroさんにお越し頂きました。

@t_wada スタンドのスタンドがお出迎え（ @izumii19 ＆ @nemorine による渾身の作品）

基調講演＆ライブコーディング

午前中は@t_wadaさんによる講演＆ライブコーディングです。

過去に自分が参加した時からは内容がかなりアップデートされており、個人的にはTDDに対して新たな気づきや発見を得られる内容でした。

いつもながら@t_wadaさんの講演はとても面白く聞きやすく、2時間を超える内容でしたが参加者の皆さんも最後まで非常に熱心に聞かれていた印象です。

また、sli.doを使った質問コーナーも設けてみましたが、良い質問が多く参加者全員でより深く学べたのでは無いかと思います。

ペアプロ＆コードレビュー

午後は@i_takehiroさん作成のお題を使ってペアプロによるTDDの演習。

今回の言語構成はC#(1), Elixir(1), Go(2), Java(3), JavaScript(3), PHP(2), Python(2), Ruby(1) となかなかの言語数。 それぞれ熱心にコーディングしていました。

コードレビューでは、テストコードの読みやすさやプロダクトコードのメソッドのわかりやすさなど、いろいろな方々の意見を聞くことができ学びが深かったです。 特に@i_takehiroさんの指摘は噂に聞いていた通りの的確さ(マサカリ)で、あの短い時間でよくそこまで気づけるなぁと感嘆しました。

最後に

8年ぶりのTDDBCは自分にとっても新たな発見が多くTDDに対する考え方がアップデートできました。 参加者の皆さんからも「よかった」「楽しかった」などの声も聞け、大成功のイベントになったかと思います。*1

f:id:ko_sho:20190616150621j:plain

テスト駆動開発

テスト駆動開発

*1:これを機に定期的に開催できると良いな

モブプロのイベントを通じて、モブプロの生産性について考えてみた

アジャイル ワークショップ 勉強会 モブプロ

はじめに

2019/03/16に札幌で開催された「Agile Japan 2018 札幌サテライト」に運営側として参加してきました。

agilesapporo.doorkeeper.jp

午前は本会場の基調講演のビデオを鑑賞、午後は基調講演の1つでモブプロが取り上げられたこともあり、モブプロの第一人者である楽天の及部さんを札幌にお招きしてモブプロのワークショップを行いました。

個人的には業務でペアプロやモブプロ（実際には設計をチームでやるモビング）をやっていますが、今後本格的にチームでモブプロをやってみたいと考え、「モブプロで生産性が下がらないのか？」という質問に答えられるように、何らかのヒントをこのイベントで得たいと思っていました。

セッションで心に残ったワード

モブに関するワードでいくつか心に残った、モブを導入する際に他の人に説明したいワードです。

  • 間違った事を早くやるより、正しいことをゆっくりやる方が良い
  • 生産性は本当に正しいことをやっているかは不明。ただアウトプットが出ているだけ
  • 効果的な仕事
  • 仕掛かりと在庫。在庫は作業が終わっていない状態。
  • 仕事を一つずつ終わらせていく。一個流し
  • 没頭している状態 → フロー状態
  • 個人のフローとチームのフローはアンドが取れる
  • Output → Outcome
  • モブプロで暗黙知をチームへ

モブプロで生産性は上がるのか？

答えは「わかりません」でした。

これはWoody氏が説明していた「生産性は本当に正しいことをやっているかは不明。ただアウトプットが出ているだけ」ということを考えると、 そもそも生産性という基準が間違っている可能性があるので、議論のポイントが違うのかも。ということと、

及部さんのセッションの中に、「分担作業を前提とした場合には分担前と分担後に必ず、どうやって分担するかの計画と分担後のレビューや承認作業が発生する」というお話があり、これらの作業も考えると分担する方が早いとは言えなくなります。

自分の実体験でも、新人やチームにジョインして間もない人が作成した成果物をレビューしたとき、1回のやり取りでは終わらず、2回、3回とレビューをやり直した事があります。この時はかなりの時間を費やしてしまったので、さっさとペアプロした方が早いなと感じました。 *1

そして、このようなことがチームのあちこちで起きてしまった場合、途端にチーム全体の作業が滞り生産性はガタ落ちするでしょう。

但し、全員がレビューで指摘が一つもあがらないくらい素晴らしい作業ができる（もしくはレビューを適当にやってしまう）場合は全員が生産性は高いかもしれません。


リソース効率とフロー効率

上記についてイメージできる図が及部さんのスライドにありました。

スライドが見つけられず図を紹介できないのですが *2、3車線の高速道路を隙間なく車が走っている図で、全ての車が一定の速度で走っている場合は問題ないが、どこかで詰まってしまうとたちまち渋滞が発生してしまう。 一方、交通量が少なく車間距離に余裕のある状態であれば、どこかの車が多少ブレーキをしても渋滞が起こることはなく、車は流れていく。

もちもん、すべての車がブレーキをかけず一定の速度で走っていれば、隙間なく車が走っていたほうが絶対数は多くなると思います（リソース効率が良い）

ただ、自分たちの作業に置き換えた場合に滞りなく作業できることのほうが稀で、レビューの問題の他にも

  • 要件の詳細を確認する
  • 他人の作業とコンフリクトを起こしたので修正する
  • 分担した他の作業が終わるのを待つ

など、作業が滞る要素はいくらでもあります。

そんなことを考えていくとモブプロは非常に有効な手段と言えるのではないでしょうか。*3

と、いうことで自分が感じたことは生産性が上がるかどうかはチームの状態や作業内容によるため、ケース・バイ・ケース。 但し、ほとんどの場合モブでチーム一体となって作業をするほうがより高いレベルの仕事ができそうだ。ということです。


ここまでの内容はイベントを通して自分が感じたことです。 お話して頂いた内容と食い違う点があるかもしれませんので、ぜひ及部さんのブログやスライドを見てください。 takaking22.com takaking22.com

モブプロワークショップをやってみて

上であれこれ書いていますが、モブプロやりたい究極の動機は「楽しいから」です。

午後からのセッションで、実演とワークショップの２回モブプロやりましたが、とても楽しかったです。 他のチームのあちこちからも笑い声が聞こえてきて、みなさん楽しみながらプログラミングをしていた印象でした。

これからチームにモブプロ（もしくはペアプロ）を導入していきますが、チームがリモートチームのため、いろいろやってみて知見が溜まったら どこかで紹介したいと思います！

*1:これも結局はレビュアー側が期待したレベルのものが出来ない（期待値の合意が出来ていない）というコミュニケーションの問題だったのだなとイベントを通じて感じました。

*2:モブプロの本に詳しく載っているのでぜひ参考に

*3:このような問題が解消できるほど練度が高いチームがあれば分担作業したほうが早いのかもしれませんが、自分はまだそんな経験をしたことはありません・・・

第1回 エンジニアリング組織論への招待 読書会

読書会 勉強会 エンジニアリング組織論への招待

はじめに

1/25から札幌で「エンジニアリング組織論への招待」の読書会を始めました。

agilesapporo.doorkeeper.jp

読書会を主催したきっかけ

この本は前職の後輩がオススメしてくれていた本で、時間が出来たら読もうと思っていました。しかし並行していくつかの本を読んでおり、中々購入まで至っていませんでした。そんな中、自分の送別会でこの本を紹介してくれていた後輩が「ぜひ読んでください」ということでプレゼントしてくれました。

しかし、転職したばかりで他にやる事も多く、一人で読んでも途中で積読になってしまう可能性が高かったので、どうせなら他の人達と一緒に読み、学びを共有したいと考えました。 *1

読書会の進め方

今回は、読書会中に黙読 → 読んだ内容をディスカッション を繰り返すというスタイルで進めてみました。理由としては、事前に読まない形にした方が皆さんが参加しやすいかな？という考えと、 自分自身も他に並行して読んでいるものも多いので、試しにこの形でまずは初めてみました。

このスタイルで進めてみたところ今回は

  • 1-1 .すべてのバグは 、思考の中にある
  • 1-2 .不確実性とエンジニアリング
  • 1-3 .情報を生み出す考え方

まで進みました。

印象に残ったポイント

読書会でディスカッションした内容で特に印象に残ったのは「情報」というキーワードでした。

本の中では、「情報は不確実性を減らすもの」とあり、では一般的に、情報がありすぎて困る(不確実性を増やす)などの文脈で言われている情報は何になるのか？という疑問に 、「それはノイズではないか」という答えを頂き、とても納得しました。

こういうやり取りは1人で読んでいるだけだとなかなか出来ないので、一緒に読んでくれる人達がいるととても良いですね。

主催者として

社外の読書会を主催するのは初めてでしたが、社内で何度かやっているのでなんとかなると思ってました。が、あまりにも準備不足で参加者の方々に支援してもらいながらの進行となってしまいました。(グダグタでスミマセン)

進め方も2センテンス読んでディスカッションという形をとってみましたが、読書時間もディスカッション時間も盛り上がってきたところで中断してしまい、微妙な感じでした。。。

ただ、参加者の皆さん優しく、いろいろと進め方のアイデアも頂けたので、次回以降は試していこうと思います。 (このあたりもアジャイルに進めていけたら自分としても学びが大きいので)

今回はあまり進めませんでしたが、出来れば今年中にはこの本を読み終えたいと思います。


参加して頂いた方々、ありがとうございました。 今度ともよろしくお願いします！

*1:特にこの本は2019 年ITエンジニアに読んでほしい！技術書部門のベスト10にも選ばれているので、他にも読みたい人はきっといるだろうと思っていました

Reactの開発環境をDockerで構築（その2）

react 入門 環境構築 docker compose docker

はじめに

前回、dockerコマンドを使用してreactの開発環境を構築しました。

ko-sho.hatenablog.com

このままでも使うことはできますが、アプリケーションを作成する都度コマンドを打たなくても良いようにdocker-composeで実行できるようにしてみます。

docker-compose.yml

前回の内容を元に、まずはyamlファイルを作成します。

docker-compose.yml

version: '3'
services:
  react:
    image: node:10.15.0-slim
    working_dir: "/work/app"
    command: bash -c "cd react-app && yarn && yarn start"
    ports:
      - "3000:3000"
    volumes:
     - ./react-app:/work/app/react-app

ポイントは、

の2点です。

create-react-app の実行

次に、docker-compose run コマンドを使って create-react-app を実行します。 http://docs.docker.jp/compose/reference/run.html

$ docker-compose run react npx create-react-app react-app

これでカレントディレクトリ内に react-app が出来上がります。

コンテナの起動

最後に docker-compose up でコンテナを立ち上げます。
http://docs.docker.jp/compose/reference/up.html

$ docker-compose up -d

yamlファイルの command でreactの開発用サーバーの起動まで行っているので、ホスト側のブラウザからlocalhost:3000にアクセスするとデフォルトで用意されたreactの画面が表示できます。


以上で環境構築ができました。出来たものをgithubなどに上げておけば clone して docker-compose up -d で、すぐに新しい環境が手に入ります。

心理的安全性ゲームの参加レポート

勉強会 ワークショップ アジャイル

東京出張中にタイミングよく心理的安全性ゲームが開催されたので参加してみました。

 

このゲームはやっとむさんこと安井力さんが考案され、いろいろなカンファレンスで開催されていました。非常に興味があり是非参加したみたいと思っていたので、出張中に参加できたのはとても幸運でした！

 

 

ゲームのルールや詳細については以下を見てください。

ゲームの解説 - Google スライド

アナログなカードゲームで短い時間でできるものなので、チームビルディングなどではやりやすい感じがします。

f:id:ko_sho:20190117171032j:image

f:id:ko_sho:20190117170959j:image

 

ワークショップを体験して

ワークショップは1チーム4人〜5人で、

ゲーム1回目➡︎話し合い➡︎ゲーム２回目➡︎全チームで気づきの共有

という形で進められました。

 

ゲーム1回目

1回目のゲームはルールに則り普通に進められます。

各自に配られた発言カードはどちらかというと悪い印象を与える発言カードが多かったのか、ゲームが終わった後は「あまりこのチームでは一緒に仕事をしたくないかも？！」という感覚になりました。

 

解説と話し合い

その後、やっとむさんから心理的安全性の解説とその内容を受けてチームで話し合いです。

チーム内の他の方も、自分と同じように安全性が高いとは言えないと思っていたようで、チームの雰囲気はみんなが同じように感じているんだなあと思いました。

また、カードに書いてあることをそのまま表現してしまうと、悪い印象を相手に与えたり、そもそも意味がわからない表現になってしまったりするので、意訳して伝えるのも必要という話しになりました。

 

ゲーム2回目

その後、2回目のゲームをやりました。

チーム内でいい雰囲気で終わりたいねーという事で、できる限り「心理的安全性の高いチームになるように発言してみよう」という合意で初めて見ました。

また、やっとむさんからの提案で「なりきり登場人物」という拡張ルールを取り入れてやってみました。(詳細については先程のゲーム解説のリンクを見てください)

 

上記以外はルールを変えずやってみましたが、チーム全員がチームの心理的安全性を良くしようという事で、みんなカードに書いてあることをそのまま伝えるのではなく、言い方を変えたりしたり、意訳して良い表現にしたりといろいろ工夫していました。言われる側も「みんな良い雰囲気にしたいと思っている」とわかっているので、良い印象で言葉を受け取る事が出来ました。

 

チーム内の合意の大切さに関しては、なんとなくわかっていましたが、ゲームを通じて体感する事で改めて感じる事が出来てとても良かったです。

 

全チームで共有

最後に全チームで気づきの共有をしました。

f:id:ko_sho:20190117180649j:image

この中に「今日の気分を名札に貼る」というのがありましたが、これは非常に納得で、自分の気分や状態(風邪でだるいとか)を周りに伝えている事で、発言がキツかったり上の空だったりでも受け入れてもらえることはあるなぁと思いました。(これも2回目のゲームでなりきり登場人物をやった事で得た学び)

自分だと、デイリースクラム等で自分の気分を周りに伝えてみようかと思いました。

 

最後に

ルールも比較的シンプルで簡単に出来るゲームでしたが、とても学びの多いワークショップでした。やっとむさんからカードを購入することが出来たので実際のチームでも機会があればやってみたいと思います！