【読書】スクラムブートキャンプ
スクラムブートキャンプを読んでみて思ったこと
はじめに
このブログは、新米エンジニアの僕が感じたこと、思ったことを書き留めています。 内容の認識に間違えなどあるかもれませんがその時はご指摘いただけると幸いです。
読むことになった経緯
僕はいま『Ruby on Rails』を中心にアジャイル開発という手法をつかって、開発に取り組んでいる。
エンジニアになって約半年が経過しようとしている中、日々わからないことだらけで毎日開発に四苦八苦している 。
開発スピードがなかなか上がらないし、作業の目安はわからないし、きれいなコードもよくわかんないし、、、
毎月次回の作業計画を立てたり、見積もりしたりするスプリントプランニング、レトロスペクティブ。
これらも漠然と次のスプリントの作業を考えていて、見積もりのカードも自信がないので多めにみつもったカードを出していた。
毎日のデイリースクラムもなんでそんなやるのかわからなかった。
ベロシティーとかも作曲ソフトに音の強弱をつける機能にその単位が使われていたのでなんとなくわかっていたようで、わかっていなかった。
そんな漠然とした認識のなかで『スクラム開発』をしていてもしかたないと、薄々気づきはじめていた最中、
上司が与えてくれたのが『スクラムブートキャンプ』だった。
前置きめっちゃ長くなってしまったけれど、こういった経緯で読むことになった。
ここからは、漠然とした認識で使っていたスクラム開発の用語などメモしていく。
スクラム開発とは
スクラム開発とはアジャイル開発手法の1種
【アジャイル開発とは？】
プロダクトに関係するメンバーは目的達成のためにお互いに協力しあいながら開発を進める。
利用者や関係者の反応やフィードバックを継続的に得ながら、計画を柔軟に調整する。
一度にまとめて作るではなく（計画を立てたら変更なく一気に作るのではなく）、少しずつフィードバックを得ながら、実際に作ったものをこまめに動かし、テストをしながら頻繁に調整をしなが開発していく。
という柔軟に変更は意見、フィードバックなど取り入れて勧めていく手法。
『事前にすべてを正確に予測し、計画することはできない』 を大きな前提としているのが大切。
【ウォーターフォール開発】
アジャイル開発とよく比較される『ウォーターフォール開発』もサラッと書いておく。
- ウォーターフォール手法は古典的な発想の開発マネジメントシステム
- 配信日やプロジェクト完了期日が決定している
- 製品の最終仕様が開発の途中で変更されることはないのが大前提
- 緻密な計画を立てて開発するのがウォーターフォール型の手法
しっかりと計画を立てて開発をしていくため、長期のプロジェクトで最もよく採用されている。
スクラム
全員が一丸となって行うべき作業・会議・成果物を定めたルール
スクラム開発は全員が一丸となって行うべきことをルールに過ぎない。 けれど、定めたルールを確実に守って取り組むことで最大限の成果が出せるというもの。
- 固定の短い時間に区切り、作業を進める(タイムボックスという)
- 開発すべき機能やドキュメントなどの作成順序を常に並べ替え、リストを作成していき、上から順に作成していく(プロダクトバックログ)
- 現在の問題点や状況を常に明らかにしていき、透明性を保つ（開発などに迷いが1ミリでもあれば言う）
- 定期的に進捗の確認や作成物が正しいのか、仕事の進め方に問題がないか検査をする。
- やり方に問題があったり、もっと良い方法があれば取り入れていくと言う柔軟性。
このような感じで『ふりかえり』をこまめにしていく。そして疑問などはすぐに言うことが重要。
スプリント
開発する期間を区切り、繰り返し開発をする。期間の単位
この期間は短くて『1週間で1スプリント』、長くて『4週間で1スプリント』
注意すべきなのが、プロジェクトでスプリントの長さを決めたら途中で変更できない
、してはいけない。
スプリントではリリース判断可能なプロダクトを作る。
各スプリントで開発する内容は『スプリント計画ミーティング』で決める。
ベロシティ
1スプリントで開発チームがどのくらい開発できるかの指標
まずスプリントで作業する内容に見積りをつけます。
見積もりはフィボナッチ数列を使い、『1〜21』で作業内容の重さを表します。数字が高いほど重たい作業ということになります。
この見積もった作業が1スプリントでどのくらいの消化できたかで、チームの作業スピードがわかります。 この作業スピードの指数が『ベロシティー』ということになり、今後のプロダクト計画で大切な指数となります。
ロール
ロールとは役割のこと
- プロダクトオーナー
- 開発チーム
- スクラムマスター
上記の役割があり、それぞれ人数によってロール(役割)は兼任ができる
ロールはあくまでも目印のようなもので、『おれ開発チームだし他のこと知らなくていいや』は無し！
プロダクトオーナー
- プロダクトの結果の責任を取る
- プロダクトバックログの管理者で並び順(開発する順序)の決定をする
- プロジェクトオーナーは必ず一人必要
- 開発チームには相談はできるものの、干渉はできない
- プロダクトのビジョンを明らかにする(進むべき方向指針)
このような役目があり、他にも『予算管理』『おおよそのリリース計画(変更可能な計画)』『外部関係者とのコミュニケーション(顧客・上司・他部署)』『作られたプロダクトが要求とあっているか検証』 など、様々な役割がある。
開発チーム
- リリース判断可能なプロダクトを作る
- 3〜9人で構成する
- 全員揃えばプロダクトを作れる(機能横断とは開発に必要なこと全部やる笑)
- 上下関係は必要ない
- 機能横断的なチームであること(コーディング、設計 、サーバー、テスト、ドキュメント作成、要求分析など)
【リリース判断可能なプロダクトとは？】
リリース判断可能なプロダクトとは、『完了の定義を満たしたプロダクト』を作ること。
じゃあ完了の定義ってなによ？（なによ？とは？ばっかり笑）
言い換えると品質基準ってやつですな。
などなど、プロジェクトによって様々な基準があるがこれらが完了の定義とされていて、これらを満たすことがリリース判断可能なプロダクトとされている(ほんと説明 of 説明www)
スクラムマスター
スクラム開発のプロダクトを円滑にまわしていく存在。
プロダクトオーナー・開発チームを支えたり、外部からチームを守る役割。
- わかりやすいバックログの書き方を教える
- バックログの良い管理方法を教える
- プロダクトオーナーや開発チームにアジャイル開発やスクラム開発を教える
- スクラムイベント（スプリント計画ミーティングとかレトロスペクティブとか）の進行、管理（タイムボックス厳守）
- プロダクトオーナーと開発チームの会話を促す
この他にもスクラムチームを妨害するものを排除する役目でもある。（上司からの無理難題をうまく断るとかｗ） とにかく、チームの生産性、快適さ、心理的安全性を１番に考える役目。
スプリント計画ミーティング
- 今回のスプリントでは何を作るのか
- どのようにつくるか
- 1スプリント1ヶ月ならミーティングは8時間
- 1スプリント2週間ならミーティングは4時間
- スプリント計画は二部構成
- プロダクトオーナーは何をしてほしいのか(第一部)
- 開発チームは1スプリントでどのくらい作業できるのか(第一部)
- 開発チームはどうやって機能などを作るのか(第二部)
1スプリントで行う作業をスプリントバックログで並べ替え、優先して開発するものを上に持ってくる。
そして、1スプリントでこのくらいの作業をしてほしいというもの決める。
決めた結果、1スプリント中に開発チームが難しいと判断場合はプロダクトオーナーに相談し、次のスプリントに回す。
デイリースクラム
デイリースクラムは『朝会』みたいなもので、開発チームの状況を共有することが目的。
15分間のタイムボックスで行われ延長はできません。
- 前回のデイリースクラムからやったこと（昨日やった作業内容）
- 次回のデイリースクラムまでにやること（今日やる作業内容）
- 困っていること（これまじで重要w、困りごと解き明かさないとあとで負債となるし、後戻りが発生するから早く言うこと）
- このデイリースクラムは開発、チーム全体に報告するので特定のメンバーに報告するわけではない
- 問題などの報告はするものの、あくまでも情報共有なので、問題解決などの相談はデイリースクラム後に行う
スプリントレビュー
スプリント中に開発した成果物を確認、チェックする。
開発した成果物は、プロダクトオーナーに触ってもらい機能などを『実際に動かして』確認する。
動かして確認すること。口頭の説明やスライドショーなどの文章で説明のみの検証はよろしくない。
- 開発チームが完了できなかった作業の説明をする（すべて予測なので、次回のスプリントの予測の目安にする）
- プロダクトオーナー プロダクトの状況やビジネス面での状況の説明する（予算とか？） -プロダクトバックログに追加すべき項目の相談
- プロジェクトを進める上での問題事項についてみんなで相談 -これらを踏まえたリリース日の予測を立てる（毎回リリース日これで大丈夫か確認する）
スプリントレビューは、1ヶ月1スプリントであれば4時間・2週間であれば2時間となる。
スプリントレトロスペクティブ
スプリントの最後には『スプリントレトロスペクティブ』を行います。
日本では、『ふりかえり』という。まあ、ふりかえりしようってことですな。
スプリントレトロスペクティブでは、直近のスプリントでの開発で問題がなかったか、もっとうまく開発する方法はないのかなどを考える時間。
より良い方法が見つかれば、柔軟に取り入れていくことも大切。（コードの書き方とか、使ってるツールとか）
感想
スクラム開発はルールを守り、透明性を高めて、みんなで取り組むことが大切でした。 ほんと、スクラム開発は読まないとわかりません笑
