書評 - More Effective Agile - さわらブログ

More Effective Agileを読んで学んだこと・考えたことをまとめました。

TL;DR

スクラム開発は、関係者がプロジェクトを通じてスクラム開発自体に習熟することを織り込んだフレームワークである。
会社としてアジャイル・スクラム開発に舵を切ることは前提として、適切なインプットを与えてチームを高速に学習させるのが良さそうだ。

私が働いているjustInCaseでは、2021年のはじめ頃からスクラム開発を採用しています。それまでは営業（社長）が企画した商品を開発者が期限までに作るのが会社の風景でしたが、最近は変わってきました。

この本は、私が最初のスクラム開発プロジェクトに参加するに当たって読んだ本です。

会社としてアジャイルに取り組んでいる。つまり、プロダクトの営業担当者が営業部門でなく、プロダクト開発チームの中にいる
- フィードバックのループが高速になる。例えば、「この機能がほしいんだけど、3週間後までに出来る？」といえる。
スプリントとスプリントの合間の時間を作っている。
- 開発者が各々、開発環境の整備やリファクタリングに取り組める。
ストーリーポイントを設定している
- 初めは相対的な値というのがよく分からなかったが、要するにチケットのレベル・HPのようなものと納得している。
- やはり基準はほしい。たとえは、「ストーリーポイント1は、往復無しでPullRequestのレビューが終わるレベル」のような。
  - PullRequestのレビューも開発者の熟達に従って簡単になっていくはずなので、これも不適切かも
- だいたい2週間くらい運用していると慣れるが、「何が基準なんですか？」とは新メンバーによく言われる。
本には記載がないが、スクラム開発立ち上げ初期のスプリントは1週間がよい。PDCAを早く回せる。

チケットをバーティカルに分割するのにいまだに慣れない
- プロダクトバックログアイテムの分割方法 | Ryuzee.com良いブログがあった。
開発者がPO/PdMを兼ねない
- ユーザーストーリーを適切なチケットの単位に変換するには、どうしてもデータ構造まで気が配れないと難しいのでは？と思ってしまう。
  - 開発者出身のPO/PdMなら解決する。
- 「POはああ言っているけど、バックログのリファインメントの時に直せばいいか」というのは自分の中に心配事を持ち続けることになるという点でも適切ではない
プロダクトリファインメントの運営
- スプリントプランニングでやってしまっている
- ユーザーストーリーの洗い出しはどこまでで、リファインメントではどこから、という線引が出来ると良さそうだ
  - 多分、エンジニアがデータ構造を鑑みてアドバイスする必要が出てきたらリファインメント。

実践できていないことも多々あるが、チームとして開発方法の共通言語があるのは心強い。スクラム開発に習熟していきたい。