タイトルの通りですが、ウォーターフォール開発しかやったことない私がスクラム開発をやった所感を開発者目線で書いたものです。
スクラム開発はフレームワークで、各スクラムチームでいろいろ違う点もありますので、その点はご承知おきください。
まず、所感を述べる前にスクラム開発について簡単な説明を載せています。
スクラム開発の詳細な内容については以下の参考元をご確認いただければと思います。
参考元:
スクラムガイド
SCRUM BOOT CAMP THE BOOK【増補改訂版】 スクラムチームではじめるアジャイル開発
スクラム開発について
スクラム開発とはアジャイル開発手法の1つで、
わからないことが多いような複雑なプロジェクトを柔軟かつ効率的に進めるのに適しているフレームワークです。
スクラム開発の特徴
- 短い開発サイクルを回す
- 1週間〜4週間ほどの期間でサイクルを決めて計画・開発・レビュー・振り返りを行います。
- 自己組織化されたチーム
- 誰が何を、いつ、どのように行うかをチームメンバーが主体的に判断し、目標に向かって取り組む。
- 透明性
- チーム内で情報を共有し、進捗や問題点を見える化します。
- 透明性によって検査が可能になる。透明性のない検査は、誤解を招き、ムダなものである。
- 検査
- 定期的に進捗や成果物を確認し問題がないか検査します。
- 検査によって適応が可能になる。適応のない検査は意味がないとされる。スクラムのイベントは、変化を引き起こすように設計されている。
- 適応
- やり方などに問題があった場合に、そのやり方を調整し変えます。
スクラムチーム
スクラムチームは以下の3つのロールで分けられる。
通常は10以下でチームを編成されて、チームが大きくなり過ぎる場合は、複数のチームに再編成し適切なサイズを維持する。
開発者はプロダクトを作るために必要なすべての作業ができなければいけません。（機能横断的なチーム）
- 開発者
- プロダクトの開発を行うメンバー。
- プロダクトオーナー （PO）
- プロダクトの価値を最⼤化することの結果に責任を持つ。
- スクラムマスター（SM）
- スクラムの理論とプラクティスを全員に理解してもらえるよう⽀援することで、チームがスクラムを効果的に実践できるように支援する。
イベント
- スプリント
- 開発期間のことです。最大1ヶ月までの同じ期間で区切って繰り返します。
- 1区切りのことをスプリントと呼びます。
- スプリントプランニング
- スプリントの開始時に開催されるイベントで、スプリントゴールの設定と、そのゴールを達成するために必要な作業（スプリントバックログ）の作成を行います。
- デイリースクラム
- 毎日、同じ時間・同じ場所で、短時間で実施されるイベントです。
- 開発チームのメンバーが、進捗状況や問題点などを共有し、スプリントゴール達成に向けて検査し、調整が必要であれば適応させます。
- スプリントレビュー
- スプリントで完成した成果物を、プロダクトオーナーやステークホルダーに共有し、レビューをもらいます。
- スプリントレトロスペクティブ
- 良かった点、悪かった点、改善点などの振り返りを行い、次のアクションプランを決めます。
作成物
- プロダクトバックログ
- プロダクトに必要な機能や改善点をリスト化したもの。
- プロダクトオーナーが優先順位付けや情報の更新を行う。
- スプリントバックログ
- プロダクトバックログから選ばれたストーリーに対して、開発者がそれを達成するために行う作業リストです。
- インクリメント
- スプリントで対応した正常に動作するプロダクトの成果物
スクラム開発をやった所感
良い点
- 短いスプリントでサイクルを回していくため素早く柔軟に対応できる
- 1週間スプリントでやっていたのですが、短いサイクルで各種スクラムのイベントや実装を回していくことで問題点や改善点を発見し対応するまでのスピードが早く、お客さんの要望に対して柔軟に対応できるのは良いと思いました。また、レトロスペクティブで毎週振り返りを行うことで、チームが継続的に改善できるのも良いです。
- レトロスペクティブで毎週振り返りができる
- スプリントの終わりにレトロスペクティブを行って、毎週良かった点、悪かった点、改善点、次のアクションプランについて話し合います。
- 毎週1個はアクションプランを決めるのですが、定期的にアクションプランを振り返って、チーム内で当たり前になっていることや風化してきたものに対しては除外することもできるので、そこは柔軟に対応できます。
- 毎週そんなに振り返ることがあるのかと思ったこともあるのですが、やってみると意外と出てくるものです。
- 工数が見積りやすい
- 設計〜リリースまでの全体の工数を出すウォーターフォール開発と比べて、スクラム開発は短いスプリントごとに対応する内容について工数を見積もるので、より正確に見積もることができます。
- スクラム開発を進めていくとチームとしての成熟度も上がっていくので、開発期間が経つほどより早くより正確に見積もることができるようになります。
- タスク切りのやり方
- これは各スクラムチームでやり方は違う思いますが、私がやっていたスクラム開発では、バックログから今スプリントで対応する課題の詳細なタスク切りを行う際に、切ったタスクにかける作業予定時間は最大1時間というルールでタスクを区切っていました。これは慣れが必要で最初は難しいのですが、具体的な実装方法を検討しながらタスクを切れるので私はとても良いルールだと思いました。タスク切りも開発期間が経つほど知見も深まり、タスク切りもだんだんスムーズに行えるようになります。
- 個人的にはこの1時間というのが長過ぎず短過ぎずの絶妙な時間で良いなと思います。
- ペアプログラミングやモブプログラミングの文化
- ペアプロやモブプロは実際に手を動かして実装する「ドライバー」とドライバーに指示を出す「ナビゲーター」という役割があります。
- ペアプロやモブプロを通じてコミュニケーションを取りながらナレッジシェアできるので、スクラム開発の特徴でもある「自己組織化されたチーム」との相性が良く、スクラム開発では積極的にペアプロやモブプロが取り入れられています。
- ただ個人的に注意した方が良いと思うのが、難しいことや新しいことをやるタスクを、とりあえずペアプロやモブプロでやろうとした際に、ドライバーもナビゲーターもどちらも実装方法について検討があまりついていない状態で始めてしまうとあまり有効的ではありません。そういうタスクをやる場合は事前にチームメンバー間で話し合って検討したり調査タスクを入れてからやるのが良いかと思います。
- 1つの開発に集中できる
- スクラム開発では基本的に複数開発チームの兼任は推奨されていません。理由としては色々あると思いますが、短いスプリントでサイクルを回していくので、単純に複数の開発を掛け持ちできるほどの時間が無いというのが大きのではないかと思います。
- 実際は掛け持ちしている方もいるとは思いますが、基本的には1つの開発に集中して取り組めるので効率的に作業ができます。複数案件を掛け持ちすると各案件ごとに頭を切り替える必要があり苦労する部分もありますが、それが無いのは非常に良いです。
- チーム一丸となって成長できる
- スクラム開発では各種イベントを通してチームでのコミュニケーションが活発で、開発期間が経つほどナレッジシェアなども進んでチームとしての成熟度も上がり、生産性の向上が見込めます。
その他
- スクラム開発の知識と慣れが必要
- POなども含めてですが、スクラムチーム全員がスクラム開発の知識と各種イベントに対する慣れが必要だと感じました。特に私はウォーターフォール開発からスクラム開発に移ったので、最初は複数ある長尺なスクラムイベントに対してけっこう疲労感がありました。ですが、これは慣れの問題で数スプリントも過ぎれば疲労感もだいぶ緩和されます。
- スクラム開発は技術力が必要
- スクラム開発では自己組織化されたチームが特徴で、このタスクは特定の誰かしかやらないというようなことがない状態がベストなので、開発者はなんでもできる必要があります。
- ただ、開発が始まった初期段階などはある程度担当を分けて環境の整備や実装などもした方が効率的ではあると思うので、全く担当を分けないというのは難しいのかなと感じました。
- 長期的な見通しを立てるのが難しい
- スクラム開発は課題に対して短いサイクルで柔軟に対応できる反面、仕様などが都度変更されることによりスケジュールの長期的な見通しが立てづらいというデメリットもあります。
ウォーターフォール開発でも使えそうと思ったもの
- 開発内部だけのレトロスペクティブをやってみる
- レトロスペクティブは本来POさんも参加してやるものですが、開発内部だけの簡単なレトロスペクティブを定期的にやるのは良さそうだなと思いました。アクションプランなども取り入れてみて継続的にチームを改善できると思います。
- タスク切り1時間単位でやってみる
- これはスクラム開発だからという内容ではありませんが、タスク切りの際の個人的なルールとして決めてやってみるとかでも良いかなと思います。個人的にはおすすめです。
- ペアプロやモブプロを取り入れる
- ペアプロやモブプロはコミュニケーションを取りながらナレッジシェアできるので、誰かに特定のタスクが偏ってしまっている場合や、途中から案件に参加した人などいろいろな場面で有用だと思います。
