半年間スクラム開発をした感想
今年に入ってから、仕事でスクラム開発をするようになりました
実はこれまでスクラム開発をしたこと(大学でちょっとしたくらい)がなかったので、これまでしてきた感想を書いてきます
スクラムとは?
本題に入る前に、スクラムを簡単に説明します
アジャイル開発と呼ばれるソフトウェア開発手法の一つです
1週間〜1ヶ月に期間を区切って、その中で開発する機能や調査などやりたいこと、作りたいことを決定して、それに向けて成果物を完成させます
これを繰り返し行って、最終的なプロダクトを作ることになります
具体的な定義はスクラムガイドというドキュメントがありますので、これに準じることになります
やってみた感想
ここからは感想をひたすらに書きます
これまでやっていたウォーターフォールと比較できるところがあれば、比較しながら感想を書いていきます
横文字多すぎる
大学でちょっとやっていたので、ある程度の言葉は知っていたものの、各単語を理解するのに苦労しました
今後の感想を書く上でこれらの横文字を使いまくるので、用語集的な感じで書きます
スクラムガイドにこれらの用語とその説明はありますが、横文字多くて理解に時間がかかるので、私の体験ベースで書きます
チーム
以下の役割で構成される人の基本単位になります
- スクラムマスター
- プロダクトオーナー
- 開発者
「マスター」や「オーナー」がついているので、スクラムマスターやプロダクトオーナーが階層的に上位層な雰囲気がありますが、スクラムでは階層は存在しないので、皆平等です
ちなみに、私の立ち位置は開発者になります
どうでもいいですが、開発者が唯一横文字じゃない気がします(なぜディベロッパーとかにしなかったのか?)w
スクラムマスター
スクラムがちゃんとできているかを確認する人です
スクラムガイドに書かれていることが実行できているか、実行できていない部分があればその改善を行う、新規参加者がいたらスクラムの意義を説明して理解してもらうなど、スクラムが機能しているかを確認します
プロダクトオーナー
チームに何を作って欲しい、何をしてほしいのかを決める人です
基本的にこの人が仕様を握っています
作ったものがちゃんとできているかの責任者でもあります
開発者
横文字じゃありませんが、一応書きます
プロダクトオーナーのやりたいことを実現する人です
やりたいことを聞いて、それを実際に作ることになるのが、基本的な役割です
やりたいことに障害が発生したとき、報告するのもここの役割になります
スプリント
スクラムとはで書かれている期間の単位になります
1週間〜1ヶ月に期間を区切って、その中で開発する機能や調査などやりたいこと、作りたいことを決定して、それに向けて成果物を完成させます
私のプロジェクトでは2週間に区切られているので、スプリントの期間が2週間になります
この間に何をするかを決めて、それに向けて成果物を作る、ということになります
この期間は1週間から1ヶ月の長さで期間を決める必要があります
短すぎると成果物が未完成の状態になりやすかったり、長すぎるとスプリント内で最初に決めたやりたいことが変わる可能性が高まるためです
なお、スプリントが終了すると、次のスプリントがすぐに開始されます
そのため、次のスプリントでやりたいこと、作りたいことを決めるにあたって必要な判断材料が少なければ、それを探すこともします
イベント
簡単に言うと、定期的に行うチーム全員参加の会議や打ち合わせになります
スクラムガイドで定義されているイベントは以下になります
- プランニング
- デイリースクラム
- スプリントレビュー
- レトロスペクティブ
プランニング
スプリントの最初に行うイベントで、スプリントで行う作業計画を立てます
例えば、A機能の実装を行う場合、この機能を実装するために必要なタスクを洗い出して、各タスクでどれくらいの時間が必要なのか見積もって、実装は2日かかり、テストはそれから更に2日かかり、不具合修正に1日かかる・・・というスケジュールを行います
また、もしB機能の実装を同じスプリントで行い、かつA機能を利用する前提だった場合、B機能の実装を行うには少なくとも、A機能の実装が終わってからになりますが、それを待つのは時間がもったいないので、B機能は先にテスト項目を作ってから機能開発を行う、といったプランニングをする必要があります
デイリースクラム
毎日行う定例会のようなイベントです
スプリントの最初でプランニングを行って計画を立てていますが、この計画が問題なく進んでいるか、なにか問題が発生した場合はどういった問題で、それが計画に影響するのかを話し合います
プランニングの項目で出した例を流用すると、A機能の開発を進めていたけど、開発タスクが不足していて製造が終わるのが1日遅れそうというのを報告するのがこの場になります(特に問題なく進んでいるなら、そんなに議論はしない)
この問題を解消するために、チーム内で解決するのか、他チームの手助けも必要なのか、ここで決定します
なお、問題報告は必要に応じてするべきなので、このイベント以外では問題報告を禁止されているわけではありません
スプリントレビュー
スプリントの最後から2番目に行うイベントで、いわば発表会です
A機能やB機能の実動作を見せたり、調査であれば調査結果を報告するといった内容になります
ここでやりたいこと、作りたいことが実現できているか判定されるようなイメージになります
レトロスペクティブ
スプリントの最後に行うイベントで、いわば反省会です
今後のスプリントでもっとより良いものを作っていくにはどうするか?を話し合います
より良くするものは、開発のプロセスやツール、開発環境はもちろん、人間関係、チーム関係なども含めます
具体的にはスプリント内で発生した問題があれば、それに対してどうすればよかったのか?今後そもそも発生させないようにするにはどうするべきなのか?などを話し合って、やるべきことが決まったら、次のスプリントで実際にそれを試して改善に進むのかを確認します
他にもこんなやり方で開発進めたら楽に開発が進められたみたいなこともこの場で提案するのもありです
リファインメント
スクラムではイベントではありませんが、私のプロジェクトではイベントっぽく扱われているので記載します
ここでは、作りたいもの、やりたいことの確認を行う、いわば要件定義や基本設計に近いところになります
A機能の実装方針を決めたり、実装するために必要な機能の確認を行ったりします
プランニングでのタスクをより明確化したり、材料を作るイメージになります
成果物
スクラムをする上で、以下の重要な成果物のようなものがあります
- プロダクトバックログ
- スプリントバックログ
プロダクトバックログ
プロダクトオーナーが作る、いわゆるやりたいことリスト(TODOリスト)になります
ここにA機能の開発、B機能の開発、ライブラリの調査など、色々あります
この中から、スプリントでやりたいこと、作りたいことを決めて、スプリント内で成果物を作ることになります
スプリントバックログ
プロダクトバックログから作りたいことを決めたら、それを実現するためにプランニングをしますが、プランニングの成果物がこれになります
これにプロダクトバックログから決めた作りたいことをより具体的に書き出して、スケジュールを組みます
基本的には最初にプランニングで作成したスプリントバックログに従って作業を進めていくのですが、何らかが開発に問題があった場合はスケジュールを変更します
自走力が要る
スクラムは自己管理型のチームを目指します
簡単に言うと、個人個人にやりたいことを決めたり、主張する権利があり、それをベースにチームとしてやることを決めます
やりたいことを自由に決められるということは、やりたいことを自分で見つけなければならないので、積極性を始めに提案力や問題を見つける力などが必要になってきます
リーダーのような立ち位置の人から指示が出るわけではないので、そのような開発に慣れている人からすると、結構きつく感じる可能性があります
私がまさにそうだったのですが、幸いにもこれまでの仕事の中で問題の見つけ方や提案の仕方はある程度わかっていたので、そこまで時間をかけずに順応したと思います
開発でも同じことで、なにかに詰まったら、自力で解決する力が必要になります
私が自力で解決する具体的な方法は大体↓になります
- ググる(プログラミングのエラー系は大体これ)
- プロジェクトで管理しているWikiを見る(環境固有の問題、モジュールの問題はこれ)
- チームメンバーに聞く(既存のコードの動きを手っ取り早く知りたいときはこれ)
- クライアントに相談する(何らかの原因でスプリント内で実装できないなど、あまりない)
基本的に上3つがあれば、自力で問題解決できます(クライアントに相談するのは最終手段に近い)
「チームメンバーに聞く」のは、自力で解決する手法と言えるのか・・・?と思われる方もいらっしゃるかもしれません
重要なのは、自分で何が問題を見つけて、それをできる限り早く解決できる能力が大事です
何でもかんでもメンバーに聞くのはよくなさそうに聞こえますが、既存のコードや内製のライブラリなどはググってもわからないことがあるのは事実なので、素直に聞くことも大事です
優秀すぎる人がいると不安定になる?
これは憶測なのですが、頭一つ飛び抜けた優秀な人がいると、スクラムが機能しないような気がします
優秀な人がいると、他の人はその人に頼ることになりかねないからです
例えば、何か開発で詰まったときにはその人に聞いて解決する、何か問題があったらその人にまずどうするか聞く、とかすると思います
ここで一番厄介なことになるパターンが、「とりあえず、その人に聞いて行動する」が定着してしまうことです
スクラムは自己管理型のチームを目指すとともに、チーム単位で行動を決めるので、メンバー一人ひとりが自己管理しないし、チーム全体の行動がその人の行動と同等になってしまう可能性があります
聞くこと自体は問題ではないのですが、「どうしてその行動を取るのか?」や「自分ならこうするつもりだったけど、他に有効な策はありませんか?」といった自分から考える行動を疎かにするのは、スクラムにとっては不安定になる要素ではないかと思っています
感想を書いてみて
思ってたより整理できてなかった気もする・・・
これからも思ったことがあったら追記します
書き足すならスクラップにしたほうが良かったのではないか説
Discussion