スクラム開発してみた①～イテレーション・ゼロからスプリントプランニングまで～
はじめに
最近よく聞くスクラム開発について、セミナーや書籍でインプットはしたものの、結局何をどうすればいいの？やってみたいけど本当にうまくいくのか・・・ウォーターフォールが染みつきすぎてイメージができない・・・
ということで、社内で実験的にスクラム開発をしてみました。
全体の流れから、スクラムにおける各イベントで行っていたことや気を付けていたことを、4回に分けて（！）書き起こしていこうと思います(^.^)b
第一弾はプロジェクトの発足からスプリントプランニングまでをご紹介します！
▼ 目次
スプリントを始める前に-イテレーション・ゼロ-
スプリントを始める前に、「イテレーション・ゼロ」を実施します。
プロジェクトの最初のイテレーションで、このスクラムを進めるにあたってのルール決めや、決められた役割についての全員の認識合わせを行いました。実際にここで話し合った内容は以下の通りです。
ルール
| スクラムマスター交代のサイクル | 1スプリントごとに交代 |
| スプリントの期間 | 2週間 |
| 使用するツール等 | ビルドはモブプロで行う。 スクラムボードはJamBoardで作成する。 |
メンバー構成
- プロダクトオーナー（以下PO）…2名
- スクラムマスター…1名（交代制）
- デベロッパー…3名
それぞれの役割によって責任のあるイベントやタスクが異なること、全員が自分の役割を理解し、適切なタイミングで能動的に動く必要があることを共通認識としました。
「足りない情報や欲しい情報は自分から取りに行く」というマインドセットも行いました。
メンバー内に認定スクラムマスター資格を取ったメンバーが3名いたため、スクラムマスターに関してはスプリントごとに交代して実施しました。
成果物
社内で既に作られていたアプリの改修を行いました。
今回の目的は、良いサービスを生み出すことよりも「スクラムを成功させる」ことが優先だったため、技術面でモチベーションが低下しないようタスク自体は簡単なものに設定されています。
完了の定義
完了の定義についてもメンバーの共通認識として確認しました。
スクラムにおける完了とは、計画・構築・テスト・デプロイまですべて終えた状態のことを指します。
実装が終わっているだけでは完了とは言えません。
テストとデプロイを終わらせ、顧客に見てもらえる状態に持っていくまでを1スプリント内で行います。
1スプリントを2週間と決めていた場合は、2週間で完了できるようタスクを細分化することが必然となってきます。
・・・・・・・・・・・全然時間足りません( ;∀;)
タスクを洗い出して気づくのですが、スクラムにおける各イベントをすべてこなし、そのための準備や各方面との調整を行おうとすると、1スプリント2週間というのは結構ハードです。
全員が自主的に動いていかないと何も終わりません。
つまり、スクラムを成功させようと全員が思っているチームは自然と自己組織化されたチームになっていきます。
今回は実案件ではなく、社内活動という名目だったため使える時間に上限がありました。
そうでなくとも、メンバーそれぞれが案件を抱えていますので、それと掛け持ちでのこのスクラム開発。
「時間が無い」は言い訳とはよく言いますが、いやいや、時間、ありません。
このプロジェクトに使える時間は月10時間で、2週間ごとにスプリントを回すとなると…1スプリントの時間の使い方は、こうなりました。
- スプリントプランニング…0.25h
- ビルド…4h
- スプリントレビュー…0.25h
- スプリントレトロスペクティブ…0.5h
計5hを月に2回行うため、月10hとなります。
それぞれの内訳は変動するとして、まずこれでやってみようという結論に至りました。
スクラムボードの作成
イテレーション・ゼロが終わったら、スクラムボードを作成しました。できあがったボードがこちら↓
①プロダクトバックログ（以下PBR）と全体の進捗を管理するシート
②スプリントのタスク・ゴールを管理するシート（スプリントごとに作成）
③スプリントレトロスペクティブに使用するシート（スプリントごとに作成）
オンラインとオフラインを併用しての活動だったため、Slackのチャンネルに固定しておき、いつでもだれでも見れるようにしました。
ここで大事なことは、使っているうちに愛着が湧いてくるようなスクラムボードを作成することです。
要件を満たしたシンプルなシートを作成するのでもよいのですが、チームの士気を上げ、何よりも楽しくスクラムを進められるようシートをカラフルにしたり、写真や画像を貼り付けてデコレーションをしました。
せっかくチームで共有して追記していくボードですので、どんどんデコってオリジナリティーを出していきましょう (@^-^@)v
スプリントプランニング
作成したボードを元に、スプリントプランニングを行います。
ここでの主人公はデベロッパーです。
今スプリントでどのタスクに着手するか、どこまで完了させるのかを、デベロッパー中心に決めていきます。
実際に作業をする人たちが、自分たちで疑問点や準備物について、確認を取っていきます。
工数の算出
タスクをある程度洗い出すと、それぞれに工数の見積もりを行います。
今回私たちは、時間を出すのではなく、サイズでタスクの見積もりを行うことにしました。
プロジェクト全体の規模に対して、相対的なタスクのサイズをS・M・L・XLに分けていくやり方です。
1スプリントで大体どこまで進められるのか？サイズごとにどのくらい時間がかかるのか？
不明確なところは多かったですが、これに関しては実践してみるまでわかりません。
変化を受け入れるのがスクラム💪( ‘ω’💪) ということで、こちらもまずやってみようということで初回は概算でサイズを見積もりました。
とはいえ、工数の見積もりっていつになっても難しい・・・(@_@)
認識を合わせる
スプリントプランニングは、完了させるタスクを決めて工数を見積もり、作業についての疑問点をつぶすだけでは不十分です。
議題としてあげておかないと忘れがちなのですが、完了させるタスクについての共通認識を再確認して下さい。
意外とメンバーそれぞれで認識の粒度にバラつきがあると思います。
私たちのチームは初期でここの共通認識の確認をサボってしまい、タイムロスを発生させてしまいました・・・。
例えばですが、PBRに「ヘッダー・フッターを設定ファイルで参照する」という項目があったとします。
Aさん：Webページ内にあるヘッダーメニュー・フッターメニューのHTMLを共通化するんだな・・・
Bさん：ページ内にある<header>タグと<footer>タグで囲まれたコードの部分を共通化するんだな・・・
という2通りの認識でスプリントプランニングを進めました。
それぞれ疑問に思うことなかったため、プランニング中にこの確認について話題に上がることもありませんでした。
このままビルドは始まってしまい、そこで初めて自分たちの認識がバラバラであることに気づきます。
貴重なビルドの時間が始まっているのに、POと再度成果物についての認識が合っているか確認する時間が増えてしまいました。
このような認識のズレによる手戻りを防ぐためには、どうすればよかったのでしょうか？
今回の原因としては、以下のようなことがあげられました。
・デベロッパー自身が、「大体想像はついた」「何となくイメージが付いた、理解した」と、曖昧な認識のままスプリントプランニングを終えていたこと。
・「スクラムマスターか他の誰かは完全に理解しているだろう、後で聞けばいいだろう」と考えており、メンバーの当事者意識が低かったこと。
これを受けてチームで考えた対策は、以下3点です。
①自分の疑問点だけでなく、成果物（スプリントゴール、各タスクの作業内容）についての認識が合っているか全員で確認する。
②理解の粒度を「自分ひとりで説明できるかどうか」を基準にする。不十分ならスプリントプランニングの時点で聞いておく。
③Slackのリマインダーを使用し、日々問題が無いか、考える時間を設けて問題意識を持てるよう癖づけする。
作業に対する考え方、事前に認識を合わせていないとどうなるのか、アンチパターンが学べたので良い経験になりました。
スクラムでなくとも、プロジェクトを進める際に認識を合わせるという部分は必ずテーマに上げられることかと思いますので、サボらずに積極的にコミュニケーションを取りに行こうと思えるきっかけになりました。
最後に
スプリントプランニングを終えたら、次は実際の開発作業（ビルド）に入ります。
次回はこのビルドと、そこで行ったデイリースクラムについて紹介していきたいと思います（＾ｕ＾）
最後までお読みいただきありがとうございました♪
ウィズテクノロジーで一緒に働きませんか？
分野を限定せず幅広い事業を展開。新しい技術の導入にも積極的に取り組んでおり、チャレンジや成長する機会が沢山。
あなたの経験・知識を活かしながら一緒にIT業界を盛り上げて行きましょう！
採用情報詳細はコチラ
