ブログ

みなさんこんにちは。@ryuzeeです。

スプリントでの作業の進め方について以下のような質問を頂きました。

2週間スプリントでスクラムに取り組んでいます。 スプリントの中では、要件定義→開発→テスト項目作成→テスト→ユーザー受け入れテスト→リリースの順番に進めていますがミニウォーターフォール型との違いが分かりません。どう進めたら良いでしょうか？

スクラムに慣れておらず、ウォーターフォールの考え方からの転換が不十分なときによく遭遇する問題です。いくつか作業の進め方の例を見ていきましょう。 （ご質問ではスプリントの最後でリリースしていますが、スクラムではリリースを必ずスプリントの最後にしなければいけないという決まりはなくいつでもできます。話を簡単にするために今回はリリースへの言及はしません）

図の見方ですが、PBIはプロダクトバックログアイテムを指し、横軸はスプリント内の日数を指します。イベント等は分かりにくくなるので抜いています。おおよそのイメージとして捉えてください。

なお、よくない例として紹介しているものでも、それでうまく行っているチームはあるかもしれません。現状でうまく行っているのであればそれを無理に変える必要はありません。

よくない例1：ミニウォーターフォール

スプリントの最初の数日で複数のプロダクトバックログアイテムをまとめて設計し、次にそれをまとめて開発をし、最後にまとめてテストをするやり方です。 これはまさにミニウォーターフォールと言えます。

このやり方をした場合には次のような問題が発生します。

• 工程に分断しているため、前の工程が終わらないと次の工程に入れない
• 設計に多くの時間がかかったり、設計した結果見積もった規模には収まらないことがスプリント開始後に分かったりする
• つまり1箇所で遅延すると全てが遅延する。多くの場合最後のテストが終わらない、テストで問題が見つかるが直す時間がないといったことが起こる
• 言い換えればリスクが後半ほど大きくなるが、リスクが顕在化した時点で対処が難しい
• 結果的にスプリントの成果が0になりやすく、成果の量が安定しない。そのため計画の予測精度が上がらない
• 完成しなかったプロダクトバックログを次のスプリントにそのまま持ち込んでしまって、計画の柔軟性がなくなる

スプリントという短い期間でこのようなやり方は相当辛いことになります。 なお、この状況は大きなプロダクトバックログアイテムを1つだけスプリントに投入しているような状況でも発生します。一般的には1スプリントに投入するプロダクトバックログアイテムは3個以上がお勧めです。

よくない例2：まとめてテスト

この例はプロダクトバックログ単位で順番に開発を進め、統合とテストだけ最後にまとめてやるやり方です。それぞれのプロダクトバックログアイテムごとにスプリント開始時点のコードを元にフィーチャーブランチを切って進めているイメージが近いです。

このやり方でも設計の肥大化、見積り精度、後半ほど高リスクといった前述のミニウォーターフォールの問題点がいくつか当てはまりますが、ここではそれに加えて発生しうる問題をいくつか紹介します。

• 複数の成果を統合しようとした段階でコンフリクトが発生したり、似たコードがあちこちに作られたりしていることが分かり、統合が終わらない
• スプリントの途中で開発が終わった分だけ先にリリースしたいと思ってもリリースできない

このやり方をしてしまう理由の1つはテストの負荷です。テストの多くが手作業だと何度も手作業でテストをするのを避けるために、バッチサイズを大きくしてまとめて対処しようとしがちです。ですが、そもそも手作業による網羅的なテストのままでアジャイル開発を進めるのはなかなか厳しいです。例えばこんな流れで問題が起こります。

• プロダクトが大きくなるに連れてテストのボリュームがどんどん肥大化していく
• そして徐々にスプリントでのテストが終わらなくなったり、無理やり終わらせようとして雑なやり方になったりして、あとから問題が起こる
• そこでテスト範囲を狭めるために、既存のコードの変更を避けて機能開発をすすめてしまう。結果的に重複コードが増えたり、コードが肥大化したりする

事実上、短いスプリントに切って開発をしていく上ではテスト自動化は必須です。もちろん全てが自動化できるわけでもなく、また自動化する意味がないテストもありますが、ある程度の安心感を確保する上で自動化の果たす役割は大きいです。 また、探索的テストのようなアプローチを併用する必要もあります。

どうテストするのか？はスクラムチームとステークホルダー間で認識が違うことも多いので、初期の段階から継続的に議論しておくとよいと思います。

よい例：1個づつ片付ける

最後にうまくいきやすい例です。ポイントは次のようになります。

• スプリントに入ってから要件を確認したり1から設計を考えたりすると問題が出たときに対処が難しいので、スプリントが始まる前に上位のプロダクトバックログアイテムは「ある程度」の準備ができた状態にしておく（スクラムチームとしてReadyにしておく）。
  • 参考：プロダクトバックログアイテムはReadyなものだけスプリントに投入するべきという話
  • スクラムチームごとにどれくらい準備しておくかは異なりますが、最低限「何ができていれば、そのプロダクトバックログアイテムは完成か」は明らかにしておくとよいでしょう
  • 間違っても全てのプロダクトバックログアイテムを事前に詳細にしないでください。あくまで着手が近づいている上位の項目に着目します
• 同時仕掛りの数を減らす。この例では同時に着手しているプロダクトバックログアイテムの数を2個にしています。モブプログラミングを採用しているチームの場合は、仕掛りが1になります。いずれにせよ同時に着手するものは減らして、着手したものを完成させてから次に進みます

このようなやり方をすることで、スプリントの成果が0になるリスクを低減でき、スプリントの成果が安定して、予測精度が向上していきます。

本サイトで取り上げてほしい内容がありましたら、是非ページ下部のフォームからお知らせください（匿名で送れます）。 それでは。