Re: SmartHR 社内でスクラム勉強会を開催した話
練習問題が面白そうだったので自分のブログに回答を載せてみます。
第二回：経験主義と透明性・検査・適応について
Q: 経験的プロセス制御の実現において、なぜ透明性が重要なのでしょうか？ また、透明性がある状態の具体例を教えてください。
A : 「進捗どうですか?」→「順調です、進捗80%です」→「問題が発生してスケジュール遅延しそうです」というよくあるダメな進め方をしないため。 チームの外から見て見える形で状況がわかるように保つ。
透明性がある状態の具体例とは・・・
- チーム外のメンバーがカンバンなど見える化された何かを見て、作業状況・進捗・リリース日の目安などがわかる。
- チーム外のメンバーがチームに進捗に関する質問をして、誰に聞いてもすぐに同じ答えが返ってくる。
- 開発中のものを部分的にではあるが動かして、できている状況を確認することができる。
Q : 経験的プロセス制御の実現において、なぜ検査が重要なのでしょうか？ また、検査できている状態の具体例を教えてください。
A : 定期的に検査を挟まないと、自分たちが進んでいる方向性・スピードが十分なのか判断がつかないため。
検査できている状態の具体例とは・・・
- 開発中のもの・開発が完了したものを実際に動かして、受入条件を満足しているかどうかデモで確認してもらうことができる。
Q : 経験的プロセス制御の実現において、なぜ適応が重要なのでしょうか？ また、適応できている状態の具体例を教えてください。
A : 新しく得た情報・変化した状況に追従し、計画を見直していくため。週間天気予報を毎日更新するのと同じ。
適応できている状態の具体例とは・・・
- 開発過程で受入条件の抜け・漏れが見つかったので項目が見直され、リリース日が見直された。
第三回：プロダクトオーナー / 開発チーム / スクラムマスター
Q : プロダクトオーナー / 開発チーム / スクラムマスターをそれぞれ何かに喩えてください。また、それに喩えた理由を教えてください。
A :
- プロダクトオーナー：J.Y.Park 音楽プロデューサー、ビジョン・ゴールを示し皆を導く。
- 開発チーム : NiziU メンバー、歌唱力・ダンスを磨き、ファンを魅了する音楽を提供する。
- スクラムマスター : 歌唱コーチ・振り付けコーチ、メンバーに基本を教え、訓練によって苦手を共に乗り換え、プロダクトオーナーが描くゴールへ伴走する。
Nizi ProjectのJ.Y.Park氏に学ぶことが多いなと最近感じているので(※番組は未視聴)
Q : なぜプロダクトオーナーは「一人の人間」でなければならないのでしょうか？
A : 利益が相反する事象の決定は誰かが決めるしかなく、複数人いるとその判断基準や責任がぼやけてしまう。
Q : 自己組織化チームとは一言で表すとどんなチームでしょうか？ また、なぜ自己組織化チームである必要があるのでしょうか？
A : 自分たちの管理を自分たちでできるチーム。マネージャーがマイクロマネジメントで進めるのであればマネージャーの能力を超える成果は生み出せない。 何かしら見落としや対処遅れが発生し、チームが成果を出す阻害要因になってしまう。
第四回：スプリント / スプリントプランニング
Q : スプリントの長さを固定するのはなぜでしょうか?
A : 開発にリズムを持たせるため、一定間隔で経常的にアウトプットを出していくため、うまくいかない時に比較しやすくするため。
Q : 直近の 3 スプリントをすべてバーンダウンできなかったチームの中で、スプリントを 1 週間から 2 週間に伸ばした方がいいのではないかと議論になっています。あなたがスクラムマスターなら、どのように振る舞いますか？ その理由も教えて下さい。
A : スプリントの期間を延ばすのは簡単だけど今うまく行ってないなら振り返りをして短く改善していった方がよいし、もう少し1週間で続けてみたらどうかな? 3スプリント続けて終わらなかったなら、次のスプリントは思いきってやることぐっと減らしてみたら? もし全部終わったならバックログからおかわりしたっていいんだし。
理由：スプリントを長くするのは最後の手段。立ち上げ当初は振り返りを数多くこなして改善サイクルを作った方が良い。
Q : あるチームがスプリントプランニングに丸 2 日かかってしまいました（スプリントは 1 週間）。残りの期間で計画したタスクは全て Done し、PBI は PO に受け入れられました。あなたがスクラムマスターなら、どのように振る舞いますか？ その理由も教えて下さい。
A : 開発を始めて見落としが見つかったらリスキーじゃない? 今回はラッキーだったけど、いつも全てを見通してから開発に着手できるわけじゃないからある程度のところでプランニングは打ち切って手を動かすのは大事だと思うよ。1週間の開発なら2時間ぐらいが上限じゃないかな? 少し開発してみて改めて計画を見直すならそれでもいいからさ。
理由：設計は十分に行った方が良いが、手を動かさないと何も経験できない。経験できなければ開発を進めるリスクはちっとも下がっていないことになるため。
第七回：インクリメント / 完了の定義
Q : とあるスクラムチームの PO から、スクラムマスターであるあなたに以下のような相談がきました。「1ヶ月前に完了の定義を作ったのはいいものの、リリース後に完了の定義が満たされていないことがたびたび発覚します。また、完了の定義を満たした PBI であっても、リリースするまでにいくつかの調整を私が行なっています。どうしたらよいでしょうか？」。あなたがスクラムマスターならどのように振舞いますか？ また、その理由も教えてください。
A : 完了の定義が満たせていないのは開発チームと私の責任です。リリース調整までお願いしてしまって申し訳ないです。開発チームと話し合いをして改善を検討します。 ・・・と伝えて完了の定義をチームが確実にできるレベルにまでいったん落とす。その上で少しずつ完了の定義のレベルを再度上げていくようにする。
理由：守れない崇高なルールを掲げるよりも、自分たちのレベルに見合ったルールを守り、スキルアップしていく方が良いと考えます。
Q : とあるスクラムチームはレシピ検索サービスの Android アプリを製作しています。そのアプリは同じ会社の別チームが開発する Web API に依存しています。スクラムチームは毎スプリント Android アプリをインクリメントとして作成していますが、アプリは実際に Web API に繋いでいるわけではなく、スプリント終了時点ではモック API に繋いでいます。Android アプリの開発が Web API の開発に先行しており、モック API が返すサンプルレスポンスを使用するしかないためです。そのような状況で、あなたがスクラムマスターならどのように振舞いますか？ また、その理由も教えてください。
A : Web APIを開発しているチームのところへ行き、「バックエンドと繋いでの開発・検証を回していきたいので開発を手伝わせてください。お作法にはきちんと従いますのでmm」という話をして、コードを触っても良い了解を取る。
理由：チームは価値提供に必要な上(Androidアプリ)から下(Web API)まで触れるべき。そうでないとデリバリーが他依存になってしまい、安定したデリバリーができなくなる。
