最近スクラム形式でプロジェクトを進めているので、いったんまとめてみる
スクラムとは
ソフトウェア開発における反復的で漸進的なアジャイルソフトウェア開発手法の1つ。
よくアジャイルとの違いが言われるが、アジャイル開発の手法の一つという理解でよいと思う。
１スプリント１週間～４週間という単位で、開発、まとめ、レビュー、調整を行う。
メリット
１．短期間で、最大限の成果
優先順位の高い機能から実装していくので、短期間で高い成果を上げられる。
２．作業工数見積もりの精緻化
短いスパンで開発を区切って、計画を立てるのでチームメンバーのパフォーマンスなどを計画に取り入れやすく、作業工数の見積もりが従来のウォーターフォール形式より比較的正確に行うことができる。
３．チーム内での問題の素早い把握
スクラム開発では日々ミーティングを行うため、チーム内の問題把握がすぐに行える。
４．軌道修正の速さ
短いスパンで、作成している機能が正しいか確認を受けるため、要望と違うものができていてもすぐに気づける。
デメリット
１．飛び込みのタスクに弱い
スクラムは１スプリント中にどれだけの量をこなすかをまず決め、細かいタスクをみんなで出していき、各タスクにどれだけ時間がかかりそうか見積もりをし、最終的にスプリント内でやりきれそうか判断し、開発をする。なので優先度が高い飛び込みのタスクが次々入るとスプリント内でやると決めた作業が増えるため稼働が跳ね上がる。
そのためなにを引き受けて、その代わりに何を後回しにするかなどをスクラムマスターが管理する必要がある。
２．メンバーが頻繁に変わるときつい
スクラムではベロシティを測り、自分たちがどれだけこなせたかを可視化し、エンジニアに達成感を与える。達成感がまたモチベーションに繋がり、自立性を高め、生産性にも繋がっていく。
しかし、チームメンバーがよく抜けたり入ったりすると教育が必要だったりで工数が取られたりとチーム全体の生産性が下がる。
３．スキルレベルの差があるときつい
スクラム開発では、ビジネス要件をもとにみんなで細かいタスクに落とし込んでいく。
タスクには、何時間でこなせるか工数見積もりをつけるが、これがスキルレベルに差がありすぎると辛い。
なぜなら、タスクは誰でも取れるのが理想だからだ。
スクラムでは生産性を上げるためにも「自立や向上」を目指している。
そのためには、属人化を出来るだけ排除する必要がある。
属人化を排除するためには技術的な部分でも「透明性」が不可欠だ。
（１つの要件に１人が対応するパターンだと、その機能がその人しか分からないということになるし、その人がやった方が早く終るので結局属人化していく）
それなのに１時間で終わる人もいれば８時間かかる人もいるとなると辛くなる。
そうなるとフラットにしていくまでにかなり時間がかかる。
４．始めは既存の開発手法より生産性が落ちることが多い
頻繁にミーティングを行うため、開発をする作業時間自体が少なくなる。
スクラム開発における役割
〇プロダクトオーナー
作成するプロダクトの責任者。「どのような機能が必要だ」、「この機能は優先順位が高い」といったプロダクトのビジョンを考える。そして、それを他のメンバーに共有・説明することで実際に開発を進める。プロダクトオーナー自身は開発を行わず、プロジェクトのスケジュールや予算の管理をする。
〇スクラムマスター
プロジェクトを円滑に進めるための“調整役”のようなポジション。スクラムのルールや進め方をプロダクトオーナー・開発メンバーに説明し、効果的な実践を促す。また、プロダクトオーナーや外部メンバーからの無理な要望から開発メンバーを守ったり、タスクを調整して特定のメンバーに負荷がかかりすぎないようにしたりする。スクラムマスターは専任の場合もありますし、開発メンバーとの兼任の場合もある。
〇開発メンバー
実際に開発を行うメンバー。すべてのメンバーは、設計、ドキュメント作成、コーディング、テスト、運用といったひととおりのスキルを持っていることが求められ、「○○の分野しかやらない・出来ない」といったことは望ましくない。もし苦手分野がある場合でも、作業を融通し合いながら全てのメンバーが全ての仕事を出来るようになることを目指す。また、メンバーはみな平等であり、役職や年齢による上下関係はない。
まとめ（大事なこと）
とにかくチームワークが重要。
過剰とも思えるほどコミュニケーションをとれ。
チームメンバー間での隠し事無し（プロジェクトに関して）
メンバー一人ひとりが自立して作業できるレベルを目指す。
徹底して属人化した作業をなくす。
