スクラム

スクラム開発のプロジェクト管理 – 進捗管理・品質管理・バージョン管理

はじめに

ウォーターフォールは多くの管理プロセスを行いますが、スクラムでは動く成果物を作成することに注力するため最小限の管理しか行いません。
スクラムにおける管理はプロジェクトにより様々ですが、「進捗管理」「品質管理」「バージョン管理」の考え方について解説します。

ここで管理という言葉を使っていますが、リーダや責任者が取りまとめを行うのではなく、開発チームのメンバが状況把握するために使用します。
チームで連携して確認するプロセスがあると言った方が合います。

進捗管理

進捗管理には「プロジェクトの進捗管理」「スプリントの進捗管理」の2つがあります。

プロジェクトの進捗管理

スクラムではタスクの入れ替えや変更を是としているため、進捗管理にWBSやガントチャートは向きません。
そこで使用するのがバーンダウン・チャートです。

バーンダウン・チャートは作業量と時間をもとに作業の進み具合をグラフにしたものです。
縦軸は残作業量であり、スプリントごとの作業量であるベロシティを日々消化していくと、いつまでに完了するのか予測します。
これが計画線で、作業実績と比較することで予実管理します。
実績線が計画線と大きく乖離している場合、予定通りプロジェクトが進んでいない状態を示します。

バーンダウン・チャートの活用では、次の点に注意してください。

  • プロダクトバックログの見積もりを全て行っている
  • スプリントごとにベロシティを見直して計画を最適化する

スプリントの進捗管理

開発チームが日々の作業状況を把握するために使用するのがタスクボードです。

タスクボードはTODO(未着手)、WIP(仕掛中)、DONE(完了)の状態を付箋紙やツールを使って表現します。
作業が進んだらタスクの位置を更新していき、全体の進み具合が一目でわかるようにします。

タスクボードの活用では、次の点に注意してください。

  • 全員がいつでも確認できる状態にする
  • タスクボードの管理者を作らない
  • タスクが滞留しないように仕掛中のタスクを優先する

品質管理

スクラムでは、ウォーターフォールで登場するバグ密度やテストケース密度のような指標値は使いません。
スプリント内で作成するステップ数は少ないため、バグ密度にステップ数をかけ合わせても、「バグ発生件数が0~1件」のように指標値として参考にならないことが多いです。
そのため品質分析するために時間を使うのでなく、品質を高める作業に注力します。

次に品質を担保する考え方です。
ウォーターフォールでは設計、製造などの各工程でレビューや品質分析といった品質管理を行いますが、スクラムではテストで品質を担保します。
つまりスクラムではテストが非常に重要なのですが、テストに時間をかけすぎるとアジャイルの思想から外れます。

そのためスクラムではテストを自動化することが多いです。
あらかじめテストコードを作成し、製造とテストを繰り返すことで品質向上させます。
この方法はテスト駆動開発(TDD)に近いため、テスト仕様書を片手に作業することに慣れた人は困惑すると思います。
そのため開発者はテスト駆動開発について学習しておくと良いでしょう。

バージョン管理

スクラムでは素早くリリースすることが求められるため、プログラムのバージョン管理にはGITなど分散型バージョン管理を使用します。
ブランチの切り方はプロジェクトによって様々ですが、プロジェクト立ち上げ時に運用ルールを明確にして、スプリントゼロなどで運用に問題ないか確認します。
スプリントゼロについては、別記事「スプリントプランニングの進め方」を参照ください。

余談ですがGITを使用することはバージョン管理だけでなく、モジュールのマージ機能や、Jenkinsなどのツールと連動させてビルド・リリースを自動化するなど、作業効率向上につなげることも重要になります。