ブログ

ryuzeeによるブログ記事。不定期更新

スプリントでの作業の進め方

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

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

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

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

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

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

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

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

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

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

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

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

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

  • 複数の成果を統合しようとした段階でコンフリクトが発生したり、似たコードがあちこちに作られたりしていることが分かり、統合が終わらない
  • スプリントの途中で開発が終わった分だけ先にリリースしたいと思ってもリリースできない
このやり方をしてしまう理由の1つはテストの負荷です。テストの多くが手作業だと何度も手作業でテストをするのを避けるために、バッチサイズを大きくしてまとめて対処しようとしがちです。ですが、そもそも手作業による網羅的なテストのままでアジャイル開発を進めるのはなかなか厳しいです。例えばこんな流れで問題が起こります。
  • プロダクトが大きくなるに連れてテストのボリュームがどんどん肥大化していく
  • そして徐々にスプリントでのテストが終わらなくなったり、無理やり終わらせようとして雑なやり方になったりして、あとから問題が起こる
  • そこでテスト範囲を狭めるために、既存のコードの変更を避けて機能開発をすすめてしまう。結果的に重複コードが増えたり、コードが肥大化したりする
事実上、短いスプリントに切って開発をしていく上ではテスト自動化は必須です。もちろん全てが自動化できるわけでもなく、また自動化する意味がないテストもありますが、ある程度の安心感を確保する上で自動化の果たす役割は大きいです。 また、探索的テストのようなアプローチを併用する必要もあります。

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

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

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

  • スプリントに入ってから要件を確認したり1から設計を考えたりすると問題が出たときに対処が難しいので、スプリントが始まる前に上位のプロダクトバックログアイテムは「ある程度」の準備ができた状態にしておく(スクラムチームとしてReadyにしておく)。
  • 同時仕掛りの数を減らす。この例では同時に着手しているプロダクトバックログアイテムの数を2個にしています。モブプログラミングを採用しているチームの場合は、仕掛りが1になります。いずれにせよ同時に着手するものは減らして、着手したものを完成させてから次に進みます
このようなやり方をすることで、スプリントの成果が0になるリスクを低減でき、スプリントの成果が安定して、予測精度が向上していきます。

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

アジャイルコーチングやトレーニングを提供しています

株式会社アトラクタでは、アジャイル開発に取り組むチーム向けのコーチングや、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください。

詳細はこちら
  • スクラム実践者が知るべき97のこと
  • 著者/訳者:Gunther Verheyen / 吉羽龍太郎 原田騎郎 永瀬美穂
  • 出版社:オライリージャパン(2021-03-23)
  • 定価:¥ 2,640
  • スクラムはアジャイル開発のフレームワークですが、その実装は組織やチームのレベルに応じてさまざまです。本書はスクラムの実践において、さまざまな課題に対処してきた実践者が自らの経験や考え方を語るエッセイ集です。日本語書き下ろしコラムを追加で10本収録
  • プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける
  • 著者/訳者:Melissa Perri / 吉羽龍太郎
  • 出版社:オライリージャパン(2020-10-26)
  • 定価:¥ 2,640
  • プロダクト開発を作った機能の数やベロシティなどのアウトプットで計測すると、ビルドトラップと呼ばれる失敗に繋がります。本書ではいかにしてビルドトラップを避けて顧客に価値を届けるかを解説しています。
  • SCRUM BOOT CAMP THE BOOK 【増補改訂版】
  • 著者/訳者:西村直人 永瀬美穂 吉羽龍太郎
  • 出版社:翔泳社(2020-05-20)
  • 定価:¥ 2,640
  • スクラム初心者に向けて基本的な考え方の解説から始まり、プロジェクトでの実際の進め方やよく起こる問題への対応法まで幅広く解説。マンガと文章のセットでスクラムを短期間で理解できます。スクラムの概要を正しく理解したい人、もう一度おさらいしたい人にオススメ。
  • みんなでアジャイル ―変化に対応できる顧客中心組織のつくりかた
  • 著者/訳者:Matt LeMay / 吉羽龍太郎、永瀬美穂、原田騎郎、有野雅士
  • 出版社:オライリージャパン(2020-3-19)
  • 定価:¥ 2,640
  • アジャイルで本当の意味での成果を出すには、開発チームだけでアジャイルに取り組むのではなく、組織全体がアジャイルになる必要があります。本書にはどうやってそれを実現するかのヒントが満載です
  • レガシーコードからの脱却 ―ソフトウェアの寿命を延ばし価値を高める9つのプラクティス
  • 著者/訳者:David Scott Bernstein / 吉羽龍太郎、永瀬美穂、原田騎郎、有野雅士
  • 出版社:オライリージャパン( 2019-9-18 )
  • 定価:¥ 3,132
  • レガシーコードになってから慌てるのではなく、日々レガシーコードを作らないようにするにはどうするか。その観点で、主にエクストリームプログラミングに由来する9つのプラクティスとその背後にある原則をわかりやすく説明しています。
  • Effective DevOps ―4本柱による持続可能な組織文化の育て方
  • 著者/訳者:Jennifer Davis、Ryn Daniels / 吉羽 龍太郎、長尾高弘
  • 出版社:オライリージャパン( 2018-3-24 )
  • 定価:¥ 3,888
  • 主にDevOpsの文化的な事柄に着目し、異なるゴールを持つチームが親和性を高め、矛盾する目標のバランスを取りながら最大限の力を発揮する方法を解説します
  • ジョイ・インク 役職も部署もない全員主役のマネジメント
  • 著者/訳者:リチャード・シェリダン / 原田騎郎, 安井力, 吉羽龍太郎, 永瀬美穂, 川口恭伸
  • 出版社:翔泳社( 2016-12-20 )
  • 定価:¥ 1,944
  • 米国で何度も働きやすい職場として表彰を受けているメンローの創業者かつCEOであるリチャード・シェリダン氏が、職場に喜びをもたらす知恵や経営手法、より良い製品の作り方などを惜しみなく紹介しています
  • アジャイルコーチの道具箱 – 見える化の実例集
  • 著者/訳者:Jimmy Janlén / 原田騎郎, 吉羽龍太郎, 川口恭伸, 高江洲睦, 佐藤竜也
  • 出版社:Leanpub( 2016-04-12 )
  • 定価:$14.99
  • この本は、チームの協調とコミュニケーションを改善したり、行動を変えるための見える化の実例を集めたものです。96個(+2)の見える化の方法をそれぞれ1ページでイラストとともに解説しています。アジャイル開発かどうかに関係なくすぐに使えるカタログ集です
  • カンバン仕事術 ―チームではじめる見える化と改善
  • 著者/訳者:原田騎郎 安井力 吉羽龍太郎 角征典 高木正弘
  • 出版社:オライリージャパン( 2016-03-25 )
  • 定価:¥ 2,138
  • チームの仕事や課題を見える化する手法「カンバン」について、その導入から実践までを図とともにわかりやすく解説した書籍。カンバンの原則などの入門的な事柄から、サービスクラス、プロセスの改善など、一歩進んだ応用的な話題までを網羅的に解説します。
  • Software in 30 Days スクラムによるアジャイルな組織変革“成功"ガイド
  • 著者/訳者:Ken Schwaber、Jeff Sutherland著、角征典、吉羽龍太郎、原田騎郎、川口恭伸訳
  • 出版社:アスキー・メディアワークス( 2013-03-08 )
  • 定価:¥ 1,680
  • スクラムの父であるジェフ・サザーランドとケン・シュエイバーによる著者の日本語版。ビジネス層、マネジメント層向けにソフトウェア開発プロセス変革の必要性やアジャイル型開発プロセスの優位性について説明
  • How to Change the World 〜チェンジ・マネジメント3.0〜
  • 著者/訳者:Jurgen Appelo, 前川哲次(翻訳), 川口恭伸(翻訳), 吉羽龍太郎(翻訳)
  • 出版社:達人出版会
  • 定価:500円
  • どうすれば自分たちの組織を変えられるだろう?それには、組織に変革を起こすチェンジ・マネジメントを学習することだ。アジャイルな組織でのマネージャーの役割を説いた『Management 3.0』の著者がコンパクトにまとめた変化のためのガイドブック