こんにちは。
数年前のソフトウェアの開発は、ウォーターフォール開発で行われていました。
ウォーターフォール開発とは、滝の水のように、上流工程から下流工程へ順番に作業していく開発です。
つまり、要件定義、基本設計、詳細設計、製造、テスト、リリースと順番に開発するのです。
しかし、ここ数年、アジャイル開発でソフトウェアを開発するプロジェクトが多くなりました。
アジャイル開発は、アジャイルソフトウェア開発宣言で謳われた内容を基本として作業する開発です。
＞＞＞アジャイルソフトウェア開発宣言
私も、ここ数年、アジャイルのスクラム開発でソフトウェアを開発してきました。
スクラム開発は、アジャイル開発の手法のひとつで、コミュニケーションを中心に開発を進めていきます。
しかし、私が経験したスクラム開発は、ことごとく失敗しています。
そこで、失敗の原因と改善について考えてみました。
スクラム開発で失敗する理由
スクラム開発で失敗する理由は、以下の３つです。
- なんちゃってスクラム開発
- ステークホルダを取り込めていない
- スプリントを意識していない
それぞれ、説明していきます。
なんちゃってスクラム開発
1番多いのが、なんちゃってスクラム開発です。
ステークホルダ（利害関係のある人：お客様やプロジェクトオーナーなど）と定期的に会議をしているから、スクラム開発だと主張するプロジェクトです。
確かに、ステークホルダとのコミュニケーションを取りながら開発を進めるのがスクラム開発です。
しかし、正しいコミュニケーションが取れていない以上、それはスクラム開発とは言えません。
また、ドキュメントを作っていない（動くソフトウェアがすべて）プロジェクトも多いです。
これらは、アジャイル開発やスクラム開発の一面のみを取り入れた、なんちゃってスクラム開発です。
ステークホルダを取り込めていない
ステークホルダと定期的に会議を行っていても、その内容が仕様に関する会議ばかりでは、スクラム開発としてステークホルダを取り込めていることにはなりません。
スクラム開発において、ステークホルダが参加する会議は、スプリントレビューです。
スプリントレビューは、実装したものをステークホルダを含めてレビューする会議です。
それ以外にも、バックログ（要求一覧）の作成などにも、ステークホルダが参加します。
スプリントを意識していない
スプリントとは、２週間から１ヶ月で行う作業タスクです。
なんちゃってスクラム開発では、スプリント＝機能と捉えられていることが多いです。
スクラム開発では、バックログにタスクを作成する際、できるだけ小さいタスクまで分解します。
しかし、ウォーターフォールの開発と同じ感覚でタスクを設定しているため、１つのタスクが大きくなり過ぎていることがよくあります。
スクラム開発で最も重要なこと
スクラム開発で最も重要なことは、ステークホルダをプロジェクトに取り込むことです。
従来の、ウォーターフォール開発では、お客様からの要求をSE（システムエンジニア）がまとめ、エンジニアが設計、製造、テストを行いました。
しかし、それでは、お客様からの要求が満たされていないなどが発生し、手戻りも大きかったのです。
スクラム開発では、お客様を含むステークホルダが、バックログの作成やスプリントレビューに参加することで、本来、お客様が必要としているソフトウェアを作成できるようになります。
スクラム開発の正しい流れ
では、スクラム開発では、どのように開発を進めれば良いのでしょうか。
スクラム開発は、スクラムガイドで、役割やイベントが詳細に定義されています。
＞＞＞スクラムガイド
スクラムガイドでの大きくな流れになります。
- バックログの作成
- スプリント・プランニング
- デイリースクラム
- スプリント・レビュー
２〜４がスプリントになります。
また、バックログは、常に見直しを行い、内容を精査します。
では、以下で詳しく説明します。
バックログの作成
作成するソフトウェアの機能を洗い出し、一覧を作成します。
機能ごとに、因数分解を行い、タスクに落とし込みます。
タスクには、優先順位をつけ、優先度の高いタスクから、スプリントで作成していきます。
スプリント・プランニング
スプリト・プランニングでは、一つのスプリントで、何を、どのように作るかを決めます。
スクラムガイドでは、「スプリントは、１ヶ月以内の決まった長さ」とされていますが、２週間を一つのスプリントとした方が良いように思います。
スプリント内で、タスクの製造、テスト、ドキュメントの作成を行います。
よくドキュメントの作成は、スプリントに含めないプロジェクトが多いですが、ドキュメントを後で作成するのは大変なのでスプリントに含めた方が良いでしょう。
デイリースクラム
デイリースクラムでは、その日の作業について確認し、障害に対する迅速な対応を行います。
デイリースクラムは、15分程度の朝会なので軽視されることがありますが、毎日、開発者が報告しあうことで、進捗の遅れや抱えている問題が明確になり、対応も迅速に行うことが可能となります。
スプリント・レビュー
スプリント・レビューでは、スプリントで作成した成果物について、ステークホルダを含めてレビューをします。
ここで、要求とのズレがある場合は、バックログにその修正タスクを用意します。
まとめ
今回は、スクラム開発の失敗の原因について、私の経験をもとに書きました。
私が経験したソフトウェアのスクラム開発の失敗は、スクラムガイドを無視た開発を行ったのが原因です。
スクラムガイドでは、大きく以下の流れでの開発方法が書かれています。
- バックログの作成
- スプリント・プランニング
- デイリースクラム
- スプリント・レビュー
まずは、スクラムガイドを読んで、書かれている通りの開発を行うことが大事だと思います。
では、今日はこの辺で。
コメント