初めに
今年からスクラム体制で開発を行っており、イベントの意義や全体像を理解したいと思い、この本を読んでみました。将来的にはスクラムマスターも目指したいと思っています。
本の紹介
こちらはスクラム初学者向けの本で、初めてスクラムを学ぶ際には非常におすすめです。スクラム開発の体系的な知識がわかりやすく説明されており、ところどころで漫画形式の説明もあるため、非常に理解しやすい内容となっています。前回紹介した「アジャイルサムライ」と比べても、個人的にはこちらの方がわかりやすかったです。
この記事を書いている人
私は社会人2年目のエンジニアで、主にUnityを利用したARグラスサービスの開発に従事しています。社会人1年目は企画側を担当しており、エンジニアとしての業務は行っていませんでしたが、2年目からエンジニアとしての業務を本格的に担当するようになりました。そのため、エンジニアとしての経験は実質半年ほどです。
大事/参考にしたい箇所
スクラムにおけるロールはただの目印
スクラムには「プロダクトオーナー」「開発チーム」「スクラムマスター」の3つのロールがあります。
| ロール | 役割 |
|---|---|
| プロダクトオーナー | 何のために何をどういう順番で作るかを決める人 |
| 開発チーム | 実際に作る人 |
| スクラムマスター | プロダクトオーナーと開発チームが上手くスラムを進められるようにする人 |
ロールは肩書や役職とは異なり、誰がどの責任を持つかを明確にするためのものです。ロールは兼任することも可能ですが、プロダクトオーナーとスクラムマスターの兼任は避けるべきです。プロダクトオーナーはプロダクトの改善に注力しがちで、開発メンバーにプレッシャーをかけることがあります。一方、スクラムマスターは円滑なスクラムの進行が目的であり、両者の役割が相反するためです。
あてずっぽうな見積もりにベストを尽くす
開発前の見積もりは正確にはできないため、ある程度の推測で行います。そのため、時間をかけずに素早く見積もりを行うことが重要です。見積もりは、実際に作業を行う開発メンバーが担当するのが良いでしょう。なぜなら、現状で最も多くの知識と情報を持っており、最も正確な見積もりができるからです。
見積もりを担当するのは（実際に作業をする）開発メンバーがよい。理由は、多くの知識と情報を持っているため現状、一番正確な見積もりをすることができる。
実際の見積もり方法
多くのスクラムチームでは、ポーカーを使った見積もりが行われています。方法は以下の通りです。
- フィボナッチ数が書かれたカードを開発者に配る
- タスクごとにかかる日数をカードで示す
- 数字が異なる場合は話し合いを行う
- すべてのタスクについて繰り返す
タイムボックスは譲れない
タイムボックスとは、スクラムイベントの時間枠のことです。
スプリントの期間は１カ月以内
デイリースクラムは15分以内等など
タイムボックスを守ることで、タスクの達成にかかる時間の予測がしやすくなります。1日でも延長すると、他のスプリントとの比較が難しくなり、予測が立てにくくなるため、タイムボックスを厳守することが重要です。
ユーザーストーリの書き方
プロダクトオーナーが開発チームに正確に伝えるためには、以下のフォーマットを使うと良いでしょう。5W1Hを用いることがポイントです。
＜どういったユーザーや顧客＞として
＜どんな機能や性能＞が欲しい
＜どんなことが達成したい＞ためか
スクラムチームの問題は視覚化する
スクラムマスターの役割には、スクラムチームを改善することも含まれます。そのため、問題をタスクボードに視覚化して掲示するのが効果的です。また、その問題には優先順位をつけ、スクラムマスターが解決に向けてリードする必要があります。