Webエンジニアの日常とリーグオブレジェンド

Webエンジニアとして働いている猫のブログ。EmacsとMySQLとリーグオブレジェンド(LoL)が好物。主に技術的な記事かLoLの記事を書く。

技術評論社『スクラム実践入門』読書録 Part 1

スクラム実践入門

スクラムについてしっかり学んでおきたく、技術評論社から出ている『スクラム実践入門』を読むことにしたのでその記録です。*1非常に平易にかかれているので、スクラムわからない人がとりあえず読むにはいい本だと思います。技術評論社のこのシリーズの本は読みやすいしハズレが無い気がする。

スクラムとは

複雑で変化の激しい問題に対応するための手法。価値の高いプログラムを生産的にそしていい感じに作るのを目的にしている。

スクラムでは、1週間〜1ヶ月の「スプリント」と呼ばれる期間に区切って開発を行う。

  • スプリントの最初にプランニングする。
  • スプリントの最後に、そのスプリントできたもののレビューとかをする。
    • 実際に動かしてみてちゃんと動くかを見たりとか
    • 使いやすいかを見たりだとか
  • レビューが終わったらその反省を生かして次のスプリントへ

ってのがざっくりした流れになる。

「何を作るか」と「どうやって作るか」が重要

スクラムで重要なのが「何を作るか」と「どうやって作るか」を分けて考えることである。本書中では What(何を作るか)と How(どうやって作るか)という言葉を使っている。

レビュー

スプリントが終わったらレビューとして

  • スプリントレビュー
  • スプリントレトロスペクティブ

を行う。

スプリントレビュー

そのスプリントで「何ができたか」(つまりWhat)に付いての評価をして、問題点を次のスプリントで修正する。

スプリントレトロスペクティブ

そのスプリントで開発プロセス(つまり「どうやって作るか」、How)を評価して、問題点を次のプロセスで修正する。

スクラムチームと役割

スクラムはチームで開発を行う手法である。チームには

  • プロダクトオーナー(1人)
  • スクラムマスター(1人)
  • 開発チーム(3〜8人)
    • 9人以上になるとコミュニケーションコストが増えるのでこの程度の人数が良いとされる

プロダクトオーナー

「何ができたか」のWhatに責任を持つ。プロダクトの品質とか。要件の整理とか、実装の優先順序などを管理する。

チームの外部の人とのやり取りもすべてプロダクトオーナーが行う。開発者が直接チーム外の人とやり取りすることはない。

スクラムマスター

「どうやって作ったか」のHowについて責任を持つ。

スクラムについて詳しい人がこの役割に付き、チーム開発がスクラムのルールに則っているかどうかもスクラムマスターが見る。また、チームに対してスクラムの勉強会を開き、スクラムへの理解を広めることなども行う。

他にも、チームのコミュニケーションなどにも責任を負う。

まとめ

多分この辺のことを抑えておけばざっくりスクラムは理解したと言えるような気がする。細かい点はかなり端折っているので、ちゃんと理解したい人は本を読むことをおすすめする。

*1:本当はアジャイルザムライとか読もうと思ったけど、会社にアジャイルザムライが見当たらなかったのでとりあえずこれを読んでスクラムについて理解する