アジャイルソフトウェア開発という考え方
以下はアジャイルソフトウェア開発宣言の抜粋である。
プロセスやツールよりも個人と対話を
包括的なドキュメントよりも動くソフトウェアを
契約交渉よりも顧客との協調を
計画に従うことよりも変化への対応を
これに加え、アジャイル宣言の背後にある原則というものがあり、
これらは、いわばアジャイルソフトウェア開発が目指しているビジョンだと思っていいかもしれない。
つまり、余計なしがらみを排除し、顧客に最大限歩み寄って、
速やかに顧客に価値を提供するという考え方に思える。
主要なアジャイルソフトウェア開発の手法
これらのビジョンを体現するには、具体的な手段が必要となる。
代表的なアジャイルソフトウェア開発の手法としては以下のようなものがあるが、今回はそのうちのスクラム開発に焦点をあてる。
スクラム開発の概要をざっくり
スクラム開発と、従来のウォーターフォール開発との違い
ウォーターフォールと違い、スクラム開発では、実際に動く成果物(インクリメント)をスプリントという単位で作っていき、そのフィードバックを次のスプリントで活かすという形をとる。
つまり、毎スプリントの最後には、顧客が動作確認できる成果物が存在していることとなる。
これを繰り返すことで、プロダクトをより顧客の要望に沿った形にするのだ。
スクラムにおける３つの役割
スクラムにおいての役割は、基本的に以下の３つしか存在しない。
プロダクトオーナー
プロダクトに責任をもち、プロダクトバックログを充実させる。
スクラムマスター
組織、開発チーム、プロダクトオーナーに対してのサポートやスクラム支援を行う。
チームマネジメントは行わない。
開発チーム
開発チームは以下にあるようなフィーチャーチームを形成し、各スプリントの終わりに成果物(インクリメント)を作成できるよう集中する。
開発チームのあり方
データベース専門のチームを作ったり、特定の領域の専門家で集めたコンポーネントチームではなく、スキルセットが横断型で、そのチーム単体で顧客に価値を提供できるフィーチャーチームを作る。
スクラムミーティング
スクラム開発では、スプリントという単位で開発を進めていく。
各スプリントの最後には、開発チームの成果物(インクリメント)からフィードバックを受けるフェーズがある。それを元にまた次のスプリントの計画を練る。
スプリントは決められた時間がすぎれば終わる。だいたい２周間とかで組むところが多い。
スプリント計画
プロダクトオーナーがプロダクトバックログ(顧客の要求が一個一個のアイテムとなって乗っかってるボード的なもの)にあるアイテムのビジネス的な優先順位を決め、開発チームと技術的な部分を踏まえて、スプリントでやることを決める。
スプリントバックログにプロダクトバックログからPBIsをもってくる。
スプリントバックログに乗ったPBIsを分割し、タスクにする。
つまり、何(PBIs)をどうするか(タスクに落とし込む)決めるのがこのフェーズ。
デイリースクラム
毎日やるやつ。次の２４時間にやることを決める。
スプリントレビュー
開発チームの成果物(インクリメント)に対してのフィードバックをうける。
スプリントの振り返り
KPTなどを用いて、次スプリントの改善を目的として、
近スプリントを振り返る。
バックログリファインメント
大きなプロダクトバックログアイテムを、より小さいストーリーに分割して明確にする。
プロダクトバックログを最新の状態に更新する。
ソフトウェア開発における依存関係は空想の産物
例えば家の建造などは「土台を作り、骨組みを組み立て、その後に屋根を作る・・・」などと順序だてて作る必要がある。
従来のこういった分野では、土木や、建築など専門色が強く、横断的なスキルを持つフィーチャーチームが組みにくいのと、むしろそれをやってしまうと効率が圧倒的に下がるのではないかと思える。
設計が決まってからの変更要求などはソフトウェアと違って生じにくいからだ。変更がほとんど生じないなら、ウォーターフォールが効率的だ。
たしかに、こういった物理的なものを使ったものづくりは、手順に依存関係があったり、ウォーターフォールが効率的な場合があるだろうが、ソフトウェアにまで同じ法則を適用する必要はない。
インターフェースで切ってモックを作っておいたり、一見依存関係に見えてる部分があっても、やりようはある。 だってソフトウェアだもの。
参考
詳細は、スクラムリファレンスカードやスクラムガイドなどによくまとめられている。