アジャイル開発とスクラムについて

はじめに

アジャイル開発とスクラムについてまとめました。こういう働き方が出来たら楽しいだろうな、というのが一番の感想です。SCRUM BOOT CAMP THE BOOKのチームもスクラムについては色々経験不足だったりしてますが全体的に良い人が多そうで本当に楽しそう。

アジャイル開発について

 従来のソフトウェア開発ではウォーターフォール開発という手法がデファクトスタンダードだった。ウォーターフォール開発においては要件定義→基本設計→詳細設計→実装→単体テスト結合テストシステムテスト・受け入れテストというように進むのが基本だった。  しかし、このウォーターフォール開発というものは製造業、ハードウェア開発などでは向いているもののソフトウェア開発には不向きな開発スタイルであった。何故かと言うと、要件定義後に顧客・利用者が実際にソフトウェアに触れることが出来るのはシステムテスト・受け入れテストの段階になり、その時点においては要件定義段階で存在していたニーズがすでに変化していることが多かったからだ。また、ウォーターフォールにおいては不必要なドキュメントが生成され、そのドキュメントをまた基本設計担当、詳細設計担当、実装担当、テスト担当というように要件の又聞きで進められることになり、要件定義で決まったことが正確に下流工程に伝わらないことがあるなどのデメリットがあった。  ハードウェアと異なるソフトウェアの強みというのはいつでも変化を加えることができるということであるはずだ。ハードウェアの製造方法を参考にしたウォーターフォール開発はソフトウェア開発にはマッチしないと言わざるを得ない。そこで提案されたのがアジャイル開発である。  アジャイル開発というのは顧客や利用者からのフィードバックを反映しつつ、漸進的に進めるソフトウェア開発の手法である。はじめに最低限動作するミニマルなプロダクトを作成し、それに対する顧客とユーザからのフィードバックを受け、改善を加えてソフトウェアをあるべき姿へと変化させていく。  アジャイル開発を可能にしたのは幾つかの手法である。それは、続的インテグレーションと継続的デリバリー、自動化されたテスト、ソフトウェアの柔軟な変化を可能にする設計方針、変化に強いプロジェクトマネジメントなどの導入である。  これらの手法により、ソフトウェア開発者はソフトウェアに対して漸進的に変化を加えつつフィードバックを受けてより改善するための力を手に入れることができた。これらの手法の導入によりアジャイル開発は可能となり、アジャイル開発スタイルは現代のソフトウェア開発のデファクト・スタンダードとして採用されている。

スクラムについて

チーム構成

スクラムチームは以下の構成になる

  • スクラムマスター
  • プロダクトオーナー
  • 開発チーム

見積もりと計画

ベロシティ

プロジェクトを進めるにあたって、何の作業をいつまでに終わらせるか決める必要がある。 必要な機能を洗い出し、それぞれのポイントを開発チーム内で決める。 決める際にはプランニングポーカーなどで決める場合がある。 決めたあと、すべての合計ポイントを算出する。例えば、合計が200ポイントになるとする。 2週間を1スプリントとし、1スプリントに20ポイントを獲得するとすると、 プロジェクトは20週間で終わることになる。 この1スプリントで獲得する合計ポイントをベロシティと呼ぶ

ユーザーストーリー

どんなユーザー[who]がどんなときに[when]どんなところで[where]どんなふうに[how]どんなこと[what]をしたいのか、機能を作る際にユーザーストーリーとして決めておく。決めておいたユーザーストーリーはそのままスプリントレビュー、受け入れテスト時のデモ手順として利用できる。

進捗確認

スプリントが始まったあとは順調に進んでいるか確認する必要がある。

デイリースクラム

多くのスクラムチームでは朝会形式で15分程のミーティングを行うと良い。 これをデイリースクラムと呼ぶ。

スプリントレビュー

スプリント完了時にはそのスプリント内で完成したものを顧客に見てもらう。 デモ状態でも確実に動く状態で見せられるようにする必要がある。 動くソフトウェアを披露し、顧客からフィードバックを得て次回以降のスプリントに活かす。

計画の変更

ベロシティの変更について

ベロシティを上げる要求が発生するケースもある。例えばリリース日を早めたいなど。 安易に人員を増加するなどで対応した場合、ベロシティが安定せず、むしろベロシティが下がるなどの状況もありえる。人員を増やす場合は計画して取り組む必要がある。

ゴールの変更

状況によってはやむを得ない要因により、ゴールの変更を行う必要性が出てくることもある。 その際に調整が可能なのは、予算、期日、スコープになる。 予算は上記ベロシティの変更にあるように必ずしも予算の増加がベロシティ改善やゴール達成へつながるとは限らない。期日については変更できれば追加可能なリソースも増えるが、その分予算が増えたり、期日自体が変更できないケースも多い。一番有効なのはスコープの変更になる。やるべきものを選択し、必要ないものは削除する取捨選択を行うことでよりゴールへ近づきやすくなる。

問題の報告

スプリントが遅れる要因となる問題が発生したときはチーム全体に共有するようにする。場合によってはスプリントを中断するなどして問題に対処するケースもある。いずれにしろ問題が発覚した時点で速やかに共有を行う。

参考資料

www.amazon.co.jp

www.amazon.co.jp

www.amazon.co.jp