1
Help us understand the problem. What are the problem?

More than 1 year has passed since last update.

posted at

updated at

ざっくりスクラム開発とスクラムチームの役割

アジャイルソフトウェア開発という考え方

以下はアジャイルソフトウェア開発宣言の抜粋である。

プロセスやツールよりも個人と対話
包括的なドキュメントよりも動くソフトウェア
契約交渉よりも顧客との協調
計画に従うことよりも変化への対応

これに加え、アジャイル宣言の背後にある原則というものがあり、
これらは、いわばアジャイルソフトウェア開発が目指しているビジョンだと思っていいかもしれない。

つまり、余計なしがらみを排除し、顧客に最大限歩み寄って、
速やかに顧客に価値を提供するという考え方に思える。

主要なアジャイルソフトウェア開発の手法

これらのビジョンを体現するには、具体的な手段が必要となる。

代表的なアジャイルソフトウェア開発の手法としては以下のようなものがあるが、今回はそのうちのスクラム開発に焦点をあてる。

スクリーンショット 2019-12-18 23.54.41.png

スクラム開発の概要をざっくり

スクラム開発と、従来のウォーターフォール開発との違い

スクリーンショット 2019-12-19 0.15.37.png

ウォーターフォールと違い、スクラム開発では、実際に動く成果物(インクリメント)をスプリントという単位で作っていき、そのフィードバックを次のスプリントで活かすという形をとる。
つまり、毎スプリントの最後には、顧客が動作確認できる成果物が存在していることとなる。
これを繰り返すことで、プロダクトをより顧客の要望に沿った形にするのだ。

スクラムにおける3つの役割

スクリーンショット 2019-12-19 0.21.24.png

スクラムにおいての役割は、基本的に以下の3つしか存在しない。

プロダクトオーナー

プロダクトに責任をもち、プロダクトバックログを充実させる。

スクラムマスター

組織、開発チーム、プロダクトオーナーに対してのサポートやスクラム支援を行う。
チームマネジメントは行わない。

開発チーム

開発チームは以下にあるようなフィーチャーチームを形成し、各スプリントの終わりに成果物(インクリメント)を作成できるよう集中する。

開発チームのあり方

データベース専門のチームを作ったり、特定の領域の専門家で集めたコンポーネントチームではなく、スキルセットが横断型で、そのチーム単体で顧客に価値を提供できるフィーチャーチームを作る。

スクリーンショット 2019-12-19 1.08.12.png

スクラムミーティング

スクラム開発では、スプリントという単位で開発を進めていく。
各スプリントの最後には、開発チームの成果物(インクリメント)からフィードバックを受けるフェーズがある。それを元にまた次のスプリントの計画を練る。
スプリントは決められた時間がすぎれば終わる。だいたい2周間とかで組むところが多い。

スクリーンショット 2019-12-19 1.29.16.png

スプリント計画

プロダクトオーナーがプロダクトバックログ(顧客の要求が一個一個のアイテムとなって乗っかってるボード的なもの)にあるアイテムのビジネス的な優先順位を決め、開発チームと技術的な部分を踏まえて、スプリントでやることを決める。

スプリントバックログにプロダクトバックログからPBIsをもってくる。
スプリントバックログに乗ったPBIsを分割し、タスクにする。
つまり、何(PBIs)をどうするか(タスクに落とし込む)決めるのがこのフェーズ。

デイリースクラム

毎日やるやつ。次の24時間にやることを決める。

スプリントレビュー

開発チームの成果物(インクリメント)に対してのフィードバックをうける。

スプリントの振り返り

KPTなどを用いて、次スプリントの改善を目的として、
近スプリントを振り返る。

バックログリファインメント

大きなプロダクトバックログアイテムを、より小さいストーリーに分割して明確にする。
プロダクトバックログを最新の状態に更新する。

ソフトウェア開発における依存関係は空想の産物

例えば家の建造などは「土台を作り、骨組みを組み立て、その後に屋根を作る・・・」などと順序だてて作る必要がある。
従来のこういった分野では、土木や、建築など専門色が強く、横断的なスキルを持つフィーチャーチームが組みにくいのと、むしろそれをやってしまうと効率が圧倒的に下がるのではないかと思える。
設計が決まってからの変更要求などはソフトウェアと違って生じにくいからだ。変更がほとんど生じないなら、ウォーターフォールが効率的だ。

たしかに、こういった物理的なものを使ったものづくりは、手順に依存関係があったり、ウォーターフォールが効率的な場合があるだろうが、ソフトウェアにまで同じ法則を適用する必要はない。
インターフェースで切ってモックを作っておいたり、一見依存関係に見えてる部分があっても、やりようはある。 だってソフトウェアだもの。

参考

詳細は、スクラムリファレンスカードスクラムガイドなどによくまとめられている。

Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
Sign upLogin
1
Help us understand the problem. What are the problem?