2020-07-29

SCRUM BOOT CAMP THE BOOK【増補改訂版】を読んだ

tech book

スクラムを基本から学びなおしたいので、スクラムガイド(2017)読んだ - $shibayu36->blog;に続いて、SCRUM BOOT CAMP THE BOOK【増補改訂版】を読んだ。

SCRUM BOOT CAMP THE BOOK【増補改訂版】スクラムチームではじめるアジャイル開発

作者:西村直人,永瀬美穂,吉羽龍太郎
翔泳社

Amazon

個人的に印象に残ったのは

インセプションデッキは単なる話し合いの機会を提供しているにすぎない。みんなで一緒にスライドを作り、認識合わせをすることが一番
- 確かに成果物よりも過程に意味があるフレームワークは多い
プロダクトバックログの順序をつけるときは、直近の数スプリント分くらいに注力する。早く実現したいものが漏れていなければ問題ない
- 今の自分のチームの優先度付をどうするかについて悩んでいたので参考になった

読書ログ

* スプリントプラニングを開始する前にプロダクトバックログリファインメントと呼ぶ事前準備が必要。プロダクトバックログの上位項目について準備する 338
    * 項目の中身を具体的にする、項目の疑問点を解決する、受け入れ基準を明らかにする、項目を自分たちが扱えるサイズに分割する、項目を見積もる、など
* デイリースクラムは問題解決の場ではない。問題が報告されたらデイリースクラム終了後に改めて必要な人を集めた別の会議を設定する。デイリースクラムはタイムボックスを守る 386
* スプリントレトロスペクティブで出たアクションアイテムのうち最低1つは次のスプリントのスプリントバックログに含める 426
* スクラムの流れの図 474 ※
* プロダクトオーナーとスクラムマスターを兼任するのは絶対にだめ 615
    * POは作るものをより良くすることに注力する必要があるので、開発チームにもっとたくさん作って欲しいなどのプレッシャーを無意識のうちにかけてしまうかもしれない
* インセプションデッキは単なる話し合いの機会を提供しているにすぎない 711
    * 自分たちの向かう先についてみんなで知るためのツール
    * 1時間半くらいでみんなでスライド一枚を作り上げるくらいの気持ちで
    * 出来る限り一緒にスライドを作る時間を確保する
* 優先順位は分類ごとに一列に並べる 808
    * 超重要、重要、ふつう、あればうれしいとか
    * 感想) 分類ごとで良い、というのは面白い
* エレベーターピッチを作る時は、メンバーごとに書く時間を取り、全員がかけたら共有しあう 1028
    * 認識のずれなどが見える化される
* プロダクトバックログの順序をつけるときは、直近の数スプリント分くらいに注力する。早く実現したいものが漏れていなければ問題ない 1614 ※
* 9人以上の人数で開発する場合、複数の開発チームで協力しながら開発を進めるアプローチを取る 2665
    * プロダクトオーナーは一人、プロダクトバックログも1つ
    * それぞれの開発チームにスクラムマスターがいる
    * プロダクトバックログが大きくなるとプロダクトオーナーの負担が大きくなる。プロダクトオーナーを支えたり横断的に問題解決したりするために、スクラムオブスクラムを行う
        * デイリースクラムの後にリーダーだけが集まって検査を行う

2020-07-28

開発チーム運営では問題発見・改善だけでなく、良かったことの共有も大事にする

tech

　開発チームをスクラムなどを使って運営している時、改善がどんどん行われることは良いことである。しかし、その時によく起こりがちなのが、問題発見と改善にフォーカスしすぎた結果、チームの悪いところばかり見すぎてしまうことだ。過剰に悪いところばかり見てしまうと、徐々にチームが疲弊してしまうといったことが起こる。改善が捗ることは良いことだが、それでチームが疲弊してしまわないように注意しなければならない。

　ちなみにスクラムガイドを参照してみると、スプリントレトロスペクティブの目的には「うまくいった項目や今後の改善が必要な項目を特定・整理する」と書かれている。つまり、デイリースクラムやふりかえり会などでは、問題発見と解決だけでなく、良かったことを言語化し再生産可能にすることも重視されているのである。

　以上から、開発チーム運営では問題発見・改善だけでなく、良かったことの言語化・共有を大事にし、その2つをうまくバランスさせる必要があると考えている。

　しかしながら、これまでの経験では、かなり意識的に良かったことを取り上げるようにしないと、結局問題発見・改善ばかりに目がいってしまうことが多かった。そのため、良かったことの共有を行いやすいように具体的に工夫したことを紹介してみる。

デイリースクラムに、良かったこと・自画自賛コーナーを設ける

　良かったことを日常的に取り上げる場がないと、中々良かったことは共有されない。そこでデイリースクラムに「良かったこと・自画自賛」というコーナーを用意し、小さい良かったことや自慢を取り上げやすいように工夫したことがある。

　ちなみに、次のようにいくつか失敗パターンもあった。

口頭でいうコーナーを作るだけだとなかなか出てこない
良かったことを自分の日記に書くみたいな形式だとなかなか出てこない

　今まで試した中で良かったことが一番出てくるのは、デイリースクラムの会場をみんなで同時に書き込みできるツール（例: scrapbox、google docs）を使って用意し、ワイワイ書けるようにしておくことである。このようにすると、書きやすいだけでなく、誰かが書いた良かったことに対しさらにコメントが付くなどの連鎖反応が生まれることもあった。

　他にも提案した自分が真っ先に書きまくるというのも普通に大事なので、そこは頑張りましょう。

KPTにGoodを追加してGKPTにする

　KPTを使ってふりかえり会を行うのは定番である。しかし、Keepと言われると結構ハードルが高いようで、あまり良かったことが共有されないことが多かった。

　そこでKPT会にGoodという項目を混ぜてGKPT（参考: http://c16e.com/1510132118/ ）にするという工夫をしたことがある。2チームほどでGoodを追加したGKPT会を経験したが、やはりKeepと比べてGoodは書きやすいようで、良かったことが出てくる割合が増えたように感じた。

　また、Goodを増やして良かったことを書きやすくしたとしても、議論しやすいのはProblemなので、結局ふりかえり会の時間の大半はProblemについて話しているとなることも多い。そうならないように、GoodやKeepの時間を明示的に取るというのも有効だと思う。

　あとは出てきたGoodやKeepを再生産可能な形に言語化するのはスクラムマスターやファシリテーターの腕の見せどころなので頑張りましょう。

まとめ

　今回は、開発チーム運営では問題発見・改善だけでなく良かったこと共有を大事にすると良い理由と、そのために自分が具体的にした工夫を書いてみた。ただこのような工夫をしても、気を抜くと問題ばかりにフォーカスしてしまうことが多々あるので、より良い方法を模索していきたいと思う。

参考

2020-07-27

締め切りが厳しいプロジェクトで、プロジェクト初期にまずやっておきたいこと

tech

　これまで僕は締切がかなり厳しいプロジェクトを数回経験してきた。その経験から、締切が厳しいという特性を持ったプロジェクトの初期にまずこれだけはやったほうが良いということがいくつか見つかったので、今回はそれらを紹介していこうと思う。

前提となるプロジェクト

　今回紹介する方法は、次のような特性を持ったプロジェクトを前提とする。

細かい仕様は決まっていないが、作るものの要件はある程度明確である
アジャイルの定義におけるスコープ・コスト・品質・スケジュールの中で、スケジュールを特に優先したい(スケジュールを変えられないなど)
数ヶ月以上のプロジェクトである

短いスパンでリリースしてユーザーの様子を見てその後のプロダクトバックログの優先度を変えるような性質のプロジェクトでは、別のやり方を取る必要があると思う。そこは注意してほしい。

プロジェクト初期にやっておきたいことは何か

　上記のようなプロジェクトの場合、とにかく最速出す必要がある（どんなプロジェクトでも開発速度の最大化は目指すと思うが締め切りが固定だと特にその傾向は強まる）。そのため、いかに全員が同じ目標に向かえるか、いかに全員が自律的に動けるか、いかに刻一刻と変わる状況でも全員の認識があっているか、いかにトラブルを即座に解消できるかにかかっている。

　また、このようなプロジェクトの場合、まだコントロールしやすいのは「スコープ」である。そのため、いかにやらないタスクを判断するかも重要である。

　これらを考慮して、次のことをプロジェクト初期にやったほうが良いと感じている。

全員とゴールイメージを共有し、何が終わればリリースが出来るかの認識を合わせる
プロダクトバックログをスプリントで終わる単位に分解
全員で集まってタスクの見積もりをする
ベロシティ測定とバーンアップチャートの作成
タスクの追加/分割/やらない判断フローの作成
短いスパンの改善フローの用意

　ある程度教科書どおりのスクラムをするというリストにはなってしまったけど、それぞれのセクションで経験に基づいた工夫を書いたつもりだ。

全員とゴールイメージを共有し、何が終わればリリースが出来るかの認識を合わせる

　まず前提として、全員のゴールイメージが一致していなければならない。そうでないと、同じ目標に向かって全員で協力することも出来ないし、メンバーが各々自律的に動いても効率的に目標に向かえない。そのため、全員とゴールイメージを共有し、何が終わればリリースが出来るかの認識を合わせることが非常に大切である。

　ゴールイメージを一致させるための手法は様々なものがあるのでどれを使っても良い。ただし最低でも、なぜ作るのか、いつまでに何を作るのかについては全員が把握している状態を目指す。これまでの経験からは、インセプションデッキはなぜ作るのか、誰が関係者かなどがパッと判断しやすいので使いやすいと思っている。

　「いつまでに何を作るか」について、Webサービスやアプリを作る時は以下のようなものがあると認識合わせがやりやすかった。

全画面の画面イメージ
- やはり絵があると、圧倒的に全員の認識を一致させやすい
- 絵があることが大事なので、手書きでもAdobe XDのようなツールでも何でも良い。ただし、プロジェクトが進行した時に仕様はどんどん変わるので、画面イメージを修正しやすいツールを使えるとベターである
タスク管理ツールで管理された全ユーザーストーリーが入ったプロダクトバックログ
- 全ユーザーストーリーがタスク管理ツールに入っていると、これを全て実装したら終わりということが見える化されるので、認識を一致させやすい
- プロダクトオーナーが「その時点」で思いつく全ユーザーストーリーを洗い出しタスク管理ツールに登録しておく
- タスク管理ツールは自分たちが使いやすいなら何でも良い

プロダクトバックログをスプリントで終わる単位に分解

　ここまでで現時点で思いつくユーザーストーリーが入ったプロダクトバックログが完成しているはずである。そこで次にプロダクトバックログに登録されたタスクを、ある程度1スプリントで終わる単位にしておくと良い。1スプリントで終わらない単位のまま進めてしまうと、ベロシティが参考にならないものになったり、今起こっている問題が巨大タスクに埋もれてぼやけてしまったりということが起こるためである。

　この段階での分解はある程度ざっくりで良い。また、この段階では全員ではなく、必要最低限の人だけ集めて分解するくらいで良いと思う。

　具体的な手順としては

分解に必要な人を集める
- 最低限だとプロダクトオーナー、スクラムマスター、エンジニア1人、デザイナ1人くらい
ユーザーストーリーを一つずつ見ながら、1スプリントで終わらなそうなら1つずつ分解していく
- 分解単位はユーザーストーリー単位にこだわらず、タスク単位になっても良いだろう

全員で集まってタスクの見積もりをする

　現時点で網羅的なプロダクトバックログが出来たので、続いて全員で集まってそれぞれのタスクの見積もりをする。それぞれのタスクの見積もりの流れとしては、1タスク(1プロダクトバックログアイテム)ごとに以下のような流れが良い。

見積もりできるように、どうなったらタスクが完了かを明確にする。分からないことがあればみんなでどんどん質問しながら完了条件を詰めていく
全員で見積もりを出す。見積もりの単位は、ストーリーポイントでも理想日でも何でも良い
- 参考: 見積もりの基礎知識と「ストーリーポイント vs 理想日」の考察 - yigarashiのブログ
見積もった結果、1スプリントで終わらなそうな規模だということが分かったら、さらに分解しておく

　ここでポイントなのは、時間をかけてでも全員でやるということである。1~2日かけてでも行う価値があるパートだと思っている。なぜ全員で時間をかけてでもやると良いかというと

見積もり時にわからないことはみんなで質問していくことで、よりタスク内容が明確になる。プロダクトオーナーが見落としていたことを発見できたり、簡単だと思っていたことが実は難しいということが発見できたりする
全員で全タスクを一度でもいいから見ておくと、全員がより鮮明にゴールイメージを意識できるようになり、自律的に動きやすくなる

ベロシティ測定とバーンアップチャートの作成

　最終ゴールに対して、間に合いそうかを見える化し続けるには速度を測るしか無い。そして状況の図を作っておくことで、スケジュールに対する温度感を全員で一致させやすくなる。

　そこで、お手本通りスプリントごとのベロシティを測定し、毎スプリントごとにみんなで状況を即座に確認できるようにバーンアップチャートなどの図を作る。図に関してはバーンアップチャートでもバーンダウンチャートでも好きなものを使って良い。

　個人的にはバーンアップチャートの方が好みである。なぜなら、タスクの消化具合だけでなく新規タスクが増えている状況も可視化できるため、遅れている原因が新規タスクが増えているためなのか、速度に問題があるからなのかがひと目で切り分けられるからだ。

　ここまでで現時点でのタスク一覧とスプリントごとの速度を出せたので、間に合いそうかの温度感を全員で一致させやすくなった。

タスクの追加/分割/やらない判断フローの作成

　これまでで、「現時点」でやるべきタスク一覧は作れている。しかし、プロジェクトが進むにつれて新しくタスクを発見したり、タスクに取り組んでみると巨大タスクだったり、リリースまでに必須でなさそうな部分を見つけたり、スケジュールを考えるとやむなく落とす判断をしたり、といったことをしたい場合が必ず出てくる。

　そのため、タスクの追加/分割/やらない判断フローを先んじて作成しておくと良い。特に「やらないものを決める」フローをきちっと決めておくのが大事だと思っている。

　それぞれのフローの例は次のようなものが考えられるだろう。

タスクの追加フロー: 新しいタスクを見つけた人がタスク管理ツールに登録する -> 数人で集まって見積もりしておく -> 次の日の朝会でリリースまでにやるかやらないかを判断する
タスクの分割フロー:
- 1スプリント内で終わらなそうな規模だと発見したら or リリースまでに必須ではない部分を発見したら分割する
- 発見した人が分割し、タスク管理ツールに登録する -> 分割したタスクを数人で見積もりする -> 次の日の朝会で分割したそれぞれのタスクについて、リリースまでにやるかやらないかを判断する
やらない判断フロー:
- タスク追加/分割時は朝会でやるかやらないか判断する
- タスク追加/分割時以外でリリース必須でなさそうなタスクを見つけたら、見つけた人が朝会で提案する。朝会に「やらないタスク提案コーナー」を作っておくと提案しやすくなる

　ちなみに「やらない判断が出来ず、結局やるものが増えてしまう」ということはプロジェクトあるあるなのだが、これまで紹介していることを実践しておけばやらない判断はしやすい状態になっている。なぜなら、

ゴールイメージが揃っており、必須で残したいものは判断しやすくなっている
バーンアップチャートで間に合うかどうかがひと目で分かる
プロダクトバックログでリリースまでにやらなければならないものが全てリストアップされている

という3点が揃っているため、タスクを落とす必要性を全員で理解できる状態になっているからである。

　これで、速度はバーンアップチャートでひと目で分かるようになり、かつやらない判断フローも決まったので、スコープをよりコントロールしやすくなった。

短いスパンの改善フローの用意

　最後に改善フローを用意しておく。締切が厳しいプロジェクトの場合、出来る限り素早く問題発見・改善を回したいので、短いスパンで改善フローを用意しておくと良いだろう。また、問題のキャッチを素早く行えるように、問題に気づいた人が相談しやすい状況を維持することも大事である。

　これまでだと下のような工夫をしたことがある。

スプリント会を短いスパン(1週間とか)で取り、KPT会を行う頻度を増やす
- Good + KPT(GKPT)にすると書きやすくなり、Goodからチームに知見を溜めやすいということもあった
- 参考: KPTにGを足して、スクラムで最強のチームを作る!! - 株式会社クラフトマンソフトウェア
朝会に相談コーナーを用意する
- 気づいた時に即座にメモできるように、scrapboxやgoogle docsなど複数人で編集できる会場を用意しておき、朝会以外の時間でも書けるようにしておくとベター

まとめ

　今回は、自分が締切がかなり厳しいプロジェクトを経験して、その経験からこういう特性のプロジェクトの初期にまずこれだけはやったほうが良いということを紹介してみた。ある程度教科書的なスクラムにはなったと思うけど、それぞれのセクションで経験に基づいた工夫も書けたかなと思う。参考になると嬉しい。