マイケルです！
アジャイル開発とスクラムの基礎知識
について、整理がてらまとめていくよ！
アジャイルってよく聞くクマが何なのクマ？
変化に柔軟に対応できることから、IT業界以外でも注目されつつあるんだ！
代表的な手法になっているよ！
是非クマ業界にも取り入れてみたいものクマ
それじゃさっそく勉強してみよう！
参考書籍・ドキュメント
こちらはだいぶ前に自分がアジャイル検定の資格受験した時に使ったものです。
アジャイル検定公式テキスト アジャイルソフトウエア開発技術者検定試験 レベル1対応
スクラムについても、公式のスクラムガイドを見るのが一番です！
従来のソフトウェア開発
どのようなものだったのか見てみよう！
ウォーターフォール開発
下記のように設計からテストまで１つの流れで開発する手法となっていました。
この開発方法には下記のような問題がありました。
[ウォーターフォール開発のデメリット]
・変化を容認できないため、イノベーションを抑制し、後半に提案されるいいアイデアは危険なモノとされる。
・情報伝達の方法で文書化を重要視しているが、ドキュメントは不完全であり読んだ時に抽象的な考え方を創造してしまう。
設計書通りに実装できないことで文句を言っている開発者や、
変更が積み重なって炎上してしまう
光景を何度も見てきました・・・
このような問題を解決するために生まれたのがアジャイル開発手法です！
アジャイルソフトウェア開発
アジャイル開発とは
下記のようにイテレーティブ(反復型)のプロセスであることが特徴です！
一定の期間の中でリリース可能なものを作り上げて確認してもらうため、
要件変更や追加にも柔軟に対応することができるプロセスとなっています。
必要最低限の機能に抑えることができるようになっているんだね。
ただその代わりに、開発メンバーは設計からテストまで行える多能工であることが求められるよ！
アジャイル開発の考え方について見ていこう！
アジャイルソフトウェア開発宣言
という考え方が公開されています。
プロセスやツールよりも個人と対話を
包括的なドキュメントよりも動くプログラムを
契約交渉よりも顧客との協調を
計画に従うよりも変化への対応を
アジャイルソフトウェア開発宣言
プロセスやツールよりも個人と対話を
直接対話をすることで本来の意図や情報の抜け漏れも防ぎ、仕事を円滑に進めようという考え方です！
またコミュニケーションを円滑にすることにより、チーム内での知識共有にも繋がります。
包括的なドキュメントよりも動くプログラムを
ドキュメントで判断するのでなく動くプログラムで判断しましょうという意味になります。
ドキュメントを書き終えても実際の価値には繋がっていないので、実物で判断することは重要になってきます。
契約交渉よりも顧客との協調を
しかし、アジャイル開発では変更を受け入れることを前提に顧客が求める価値を提供することを重要視しています。
かなりの問題があったクマね
計画に従うよりも変化への対応を
計画を改善しながら進めていくことを意味しています。
12の原則
こちらもしっかり目を通して考えておきましょう！
私たちは以下の原則に従う:顧客満足を最優先し、
価値のあるソフトウェアを早く継続的に提供します。
要求の変更はたとえ開発の後期であっても歓迎します。
変化を味方につけることによって、お客様の競争力を引き上げます。
動くソフトウェアを、2-3週間から2-3ヶ月という
できるだけ短い時間間隔でリリースします。
ビジネス側の人と開発者は、プロジェクトを通して
日々一緒に働かなければなりません。
意欲に満ちた人々を集めてプロジェクトを構成します。
環境と支援を与え仕事が無事終わるまで彼らを信頼します。
情報を伝えるもっとも効率的で効果的な方法は
フェイス・トゥ・フェイスで話をすることです。
動くソフトウェアこそが進捗の最も重要な尺度です。
アジャイル･プロセスは持続可能な開発を促進します。
一定のペースを継続的に維持できるようにしなければなりません。
技術的卓越性と優れた設計に対する
不断の注意が機敏さを高めます。
シンプルさ（ムダなく作れる量を最大限にすること）が本質です。
最良のアーキテクチャ・要求・設計は、
自己組織的なチームから生み出されます。
チームがもっと効率を高めることができるかを定期的に振り返り、
それに基づいて自分たちのやり方を最適に調整します。
アジャイル宣言の背後にある原則
各種手法
これらはあくまで概念であり、実際の手法は別に定義されています。
ここではアジャイルの概念を適用できる主要な手法について２つ紹介します！
スクラム
というと難しそうですが、イテレーションを回して開発を行っていくためのフレームワークというものになります。
エクストリームプログラミング(XP)
この中に具体的な手法がいくつもあり、主要なものを紹介します！
ペアプログラミング
2人1組で1台のマシンを利用して1つのプログラムを開発する手法。
レビューも同時に行うことで品質の高いコーディングが期待できる。
最近では3〜4人を1組で1つのプログラムを開発する「モブプログラミング」も流行っている。
リファクタリング
ソフトウェアの振る舞いを買えずに内部の構造を安全に改善する。
バグ発見が容易になる、提供するまでの時間が短くなる等の利点がある。
常時結合(継続的インテグレーション、CI)
自動的な結合、ビルド、テスト等の一連のプロセスを行うことでこまめに確認する。
開発が完了したコードから自動で常時ビルドを行う。
テスト駆動開発
テストコード作成→実装→リファクタリング
を短いサイクルで繰り返すことで開発を進める手法。
動く状態を保ちつつソースコードの構造を考えながらリファクタリングすることで、信頼性を高めながら開発できる。また、CIも行いやすくなるという利点もある。
スクラム開発
基本的に、下記のスクラムガイドを参考にまとめてみました！
スクラム開発とは
1つのイテレーションを1スプリントとして扱い、複雑な問題に対応することのできる軽量なフレームワークとなっています。
経験主義とリーン思考
経験主義
透明性を高めた上で、検査と適応のサイクルを回すことを重視しています。
・透明性
→プロセスや作業を、作業を実行する人と作業を受け取る人に見えるようにする。
・検査
→望ましく無い変化や問題を検知するため、頻繁かつ熱心に検査する。
・適応
→許容範囲を逸脱していたり、成果が受け入れられなかったりした時には調整する。
リーン思考
これは説明するのが難しいですが、例をあげるとすれば
・やらなくてもいい作業はやらずに最低限のことだけ行うよう改善する
・フローの中のボトルネックを改善する
といったことがあげられます。
５つの価値基準
・確約
→ゴールを達成し、お互いにサポートすることを確約する。
・集中
→スプリントを達成できるよう集中する。
・公開
→スクラムチームとステークホルダは、作業や課題を公開する。
・尊敬
→お互いに個人として尊敬し、同じように尊敬される。
・勇気
→正しいことをする勇気や困難な問題に取り組む勇気を持つ。
スクラムチーム
スクラムチームは「プロダクトオーナー」「スクラムマスター」「開発者」で構成されます。
それぞれの役割は下記のようになっています。
開発者
10人以下(6人程度が推奨)で構成され、利用可能なインクリメントを作成することを確約する。
また、次の結果に責任を持つ。
・スプリントバックログを作成する。
・完成の定義を忠実に守る。
・ゴールに向けて毎日計画を適応させる。
プロダクトオーナー
1つのプロダクトに1名で、プロダクトの価値を最大化することの結果に責任を持つ。
また、効果的なプロダクトバックログ管理にも責任を持つ。
スクラムマスター
スクラムを確立させることの結果、スクラムチームの有効性に責任を持つ。
スクラムチーム、各メンバーに対してスクラム進行の支援を行い、障壁があれば取り除く。
というポジションがあるクマね
これら３つの役割で構成されて、更に
機能横断型で自己管理型な組織であることが求められます。
・機能横断型
→価値を生み出すために必要な全てのスキルを備えている。
・自己管理型
→誰が何をいつ行うかをスクラムチーム内で決定し、権限も与えられている。
４つのイベント
反復、改善することで進めていきます！
スプリント内でレビュー可能な成果物を作成し、レビューと振り返りを行なうことで改善していきます。
それぞれのイベントについて何をするのかについては下記になります！
スプリントプランニング
スプリントで実行する作業の計画を立て、スクラムチーム全体の共同作業によって作成される。
プロダクトオーナーは参加者に対して、最も重要なプロダクトバックログアイテムとそれらとゴールの関連性について話し合う準備ができているかを確認する。
デイリースクラム
計画された今後の作業を調整しながらスプリントゴールに対する進捗を検査し、
必要に応じてスプリントバックログを適応させる。
コミュニケーションを改善し、障害物を特定し、迅速な意思決定を促進する。
スプリントレビュー
スプリントの成果を検査し、今後の適応を決定する。
スプリントで何が達成され、自分達の環境で何が変化したかについてレビューする。
スプリントレトロスペクティブ
品質と効果を高める方法を計画する。
どのように進んだか、迷わせた仮説があれば特定しその真因を探求する。
不都合な問題が隠されてしまうため、スクラムマスターは心理的安全性を確保するよう気をつける。
これらのサイクルを通して少しずつ改善していく、というわけです。
理解されていなかったりするため、別途リファインメントのイベントを設ける場合もあります。
バックログリファインメント
大きなエピックは小さなユーザーストーリー形式のプロダクトフィーチャーに分割する。
小さくすることで重要な価値を早く提供することができる。
実施すべきイベントが定義されていると、現場にも取り入れやすいクマね
３つの作成物
これらは透明性を高めるための確約が含まれており、イメージと概要は下記のようになります。
プロダクトバックログ
プロダクトの改善に必要なものの一覧であり、作業の唯一の情報源である。
リファインメントの活動を通じて、選択に必要な透明性を獲得する。
確約：プロダクトゴール
プロダクトの将来の状態を表しており、計画のターゲットとなる。
スプリントバックログ
スプリントゴール(なぜ)、選択されたプロダクトバックログアイテム(何を)、
実行可能な計画(どのように)で構成され、開発者のための計画である。
確約：スプリントゴール
スプリントの唯一の目的であり、スプリントプランニングで作成される。
インクリメント
プロダクトゴールに向けた具体的な踏み石である。
価値を提供するためには、インクリメントを利用可能にしなければならない。
確約：完成の定義
プロダクトの品質基準を満たすインクリメントの状態を示した正式な記述である。
プロダクトバックログアイテムが完成の定義を満たした時に誕生する。
管理しやすくなります。
また、スプリントバックログについてはタスクボードやカンバンを使用することで透明性を高めることができます。
実際に適用して体で感覚を掴んでいくのが一番な気がするね
ニワトリとブタ
むかしむかし、ニワトリとブタが話をしていました。
「いいアイデアがあるんだ」とニワトリは叫びました。
「レストランをオープンしようよ。店名はハムエッグ」と聞いてブタは少し考えて、こう答えました。
「遠慮しとくよ。キミはただ卵を産むだけ（関与するだけ）で、ボクは身を切らないと(コミットしないと)いけないからね。」
アジャイルなゲーム開発 より
スクラムにおける役割を例えた話です。
ブタと今後のスプリントゴールを議論し優先順位を決定する必要があります。
ニワトリはチームが邪魔されずに達成できるようにコミットすることで、スクラムが機能する、ということのようです。
おわりに
どうだったかな？
それぞれの現場に応じて独自のルールを取り入れるのも大事になってくるよ！
例えばゲーム開発だとどのように適用するべきか？については、下記の書籍が参考になりました！
アジャイルなゲーム開発 スクラムによる柔軟なプロジェクト管理
基本的な概念は同じだからそこは押さえておきたいね！
業界の違いだけに限らず、現場それぞれなところもあるから柔軟に取り入れていこう！！
アデュー！！
【開発手法】アジャイル開発の考え方とスクラムの基礎知識について 〜完〜
