品質改善をしないアジャイル ~ウォータースクラムフォール~
ウォータースクラムフォールをガチでディする全４回連載の３回目です。はい、そうです。前２回のエントリは今回ウォータースクラムフォールをガチでディする為の前振りです。ウォータースクラムフォールの説明は以下のページをご覧下さい。
実用主義者が勝ったのか？Water-Scrum-Fallが一般的に
ウォータースクラムフォールの問題点
ウォータースクラムフォールの問題点は上記の記事のこちらの一節に凝縮される。
多くのアジャイル導入は実作業者によって主導され、実作業者が最も緊密に作業する領域、つまりソフトウェア開発ばかりにフォーカスすることから、このようなことが起きるのだとForrester社は見ている。リリース管理やプロジェクト計画のような領域は、未だに伝統的な手法で行われているのだ。
ウォータースクラムフォールの問題は、プロジェクト関係者がソフトウェア開発ばかりにフォーカスする事で、テストや運用計画、リリース管理等のソフトウェアの品質改善に直接貢献するプロセスが全く回らない事。
スクラムでスプリントを分割しイテレーションで開発するのは
- プロジェクトの外部要因の変化への対応を容易にする
- プロジェクト内からのフィードバックループにより改善する
が大きな目的だ。しかし、多くのウォータースクラムフォールプロジェクトでは1.にばかり注目し2.の意味を軽視している。
プロジェクトの始めに、一番大きな仮説についてプロトタイプを作る事はもちろん外部要因の変化に対応するため重要だ。だがそのプロトタイプをきちんとテストし、アーキテクチャや運用設計についてフィードバックループを回さなければ、そのプロトタイプはシステムの品質には寄与しない。（ 連載第一回目の記事：プロトタイプはリアルプロダクトたりえないのか？ )
スプリント中でいくら単体テストを自動化したとしても、コンポーネントの結合やシステム運用レベルの仮説はまだまだ残っている。機能やユースケース等の外部品質はもとより、使用性や運用性などの利用時品質は実際にデプロイして、試用してみなければその評価や改善をする事は出来ない。（連載第二回目の記事：「継続的デリバリー」から考えるソフトウェア開発の入り口、出口問題 )
ウォータースクラムフォールには品質改善のフィードバックループというソフトウェア開発の重要な概念が抜けてしまっている。
ウォータースクラムフォールが品質を向上させない理由
スクラムはソフトウェア開発プロジェクトのプロセス品質を向上させる為の素晴らしいプラクティスだ。ストーリーを定義しベロシティを計測する事はプロジェクトの進捗の予測性を改善するし、レトロスペクティブはその自己的な改善活動を促進するだろう。定期的なクライエントへのデモは要求とのギャップを改善し、手戻りを大幅に減らすだろう。
しかし、スクラムは内部品質や外部品質の向上には寄与しない。それらも改善する為にはXPのCIやTDDを導入する事が必要だ。CIはコンポーネントの結合に関するリスクを大幅に減少させるし、TDDはプロセス品質、内部品質、外部品質を劇的に改善する素晴らしいプラクティスだ。
問題は、多くのウォータースクラムフォールと呼ばれるプロジェクトでCIやTDDが正しく導入されていない事。開発とQAが独立した組織では対立構造を作りやすいためCIやTDDの導入は困難だ。また、テスターの設計•プログラミングスキル不足により、テスターが品質に寄与出来るようになるまでプロジェクト終盤まで待たなければならないというのも問題だ。同じように開発者の品質への理解不足は間違ったアジャイルを促進しTDD自体の品質向上を徹底的に妨げる。
結局のところ、スクラム、XP、そして品質についてもスキルの高い開発者ばかりを集めて、正しいアジャイルを実践する以外に品質を向上させる手段はないという結論になってしまうのかもしれない。
ウォータースクラムフォールを乗り越える為に
いや、その結論でこの問題を結論づけるのは早計だ。では設計やテスト、品質それぞれ一つのスキルに特化したメンバーが集まっているチームで品質を上げて行く為にはどうしたら良いのか？そのヒントは品質大国日本の生産工程そしてリーンにある。
- Agile and Lean from altitude 12,000 feets // Speaker Deck
-
Beyond Agile Testing to Lean Development — Rakuten Technology Confere…
ウォータースクラムフォールや間違ったアジャイルに欠けている品質改善のフィードバックループを作る為にはアジャイルテストを越えて、継続的システムテストそしてリーン開発へと進まなければならない。
全４回連載、最後のエントリとなる次回ではスキルに特化したメンバーが集まったチームでの品質改善フィードバックについて述べる。
次回エントリはこちら
