はじめに

いわゆるSIerでの業務システム開発では、業務知識を持った担当者でないと
顧客のエンドユーザーのみならずシステム担当者とも十分に要件の具体化が
出来ない場合があります。

そんな分野でもスクラムの恩恵を受けられるのか、数々の試行錯誤をして進めた結果、
成果はあったと思うので誰かのお役に立てるようノウハウを発信したいものです。
どんな登場人物がいるのか、開発時の役割分担などは以下の記事を参照ください。
https://qiita.com/takeout44/items/c6ad238b9efcff059e9c

本記事では初回リリースに向けた取組を書いていきます。

リリーススプリント関連

初回リリースタイミングは決まっていた

アジャイルのベストプラクティスとしては、そのシステムで狙った価値が生まれる
最低限の機能が開発完了したときにリリースをして効果検証するというものですが、
システム開発着手前にリリースタイミングが決まっているということがよくあります。

というのも、多くの日本企業ではシステム開発着手の前提として
「○円の予算をかけて○年○月にシステムリリースを行うことで、
3年ないしは5年以内に○円の収益増加/経費削減の効果を見込む」
という見込を宣言して予算化するため、必然的にこのタイミングに
システムリリースを行うことを前提としたスケジュールが多くなります。

スプリント内の進捗管理（余談）

Team Foundation Serverにはスクラムによる継続的な開発のために必要な
一通りの機能がありますので、スプリント内での進捗管理はこれで十分に満たされました。

非営業日や各メンバーの休暇予定などをキャパシティの設定に反映させておき、
バックログ一覧からスプリントバックログを対象スプリントに登録、スプリントバックログについて
必要な作業をタスクとして起票して残存作業を入力すると、バーンダウンチャートが
作成されます。（キャパシティ設定を反映した最適な進捗の目安も描かれます）

後は各開発者が日々タスクのステータスと残存作業を更新すれば、バーンダウンチャートの推移と
プランニング時に描画された最適な推移との差を追いかけて、スクラムマスターが
各開発者の課題解決をサポートするなどして開発速度の維持・向上を目指します。

※スプリントプランニングなど無視できない時間がかかるものは開発作業以外でも
　タスクにして残存作業時間を入れることでチャートの歪さを解消していました

リリースに向けた進捗管理

一方で、Team Foundation Serverには、スプリントを跨いだ進捗管理として使える機能は
全バックログに対するステータス毎の個数の推移グラフくらいしかありませんでした。
（私には他に見つけられませんでした）

私がこの機能で不足を感じたのは以下の二点です。

個数が基準なので、バックログ毎のストーリーポイントの重みが考慮されない
初回リリースでの開発対象バックログだけで推移を見たいが全バックログが対象

そこで、スプリント期間終了の毎に初回リリース対象バックログだけをフィルタして
ストーリーポイント基準のバーンアップチャートを作成して、
リリース時期に対して開発が順調かどうかをチェックしていました。

バーンアップチャートについてはBacklogさんのこの記事などが
具体的で分かりやすいです。

バーンアップチャートの副次的な効果

特に開発の前半において、要件具体化の進行による開発着手可能なバックログの残量と
開発によるバックログの消化スピードを見比べるのに役立ちました。

両チームのサポートをしていた筆者のリソースをどちらにより多く割くのかを決めるため、
どちらの進捗がリリースへのクリティカルパスを握っているのかを確認したかったためです。

リリースに向けたテスト関連

前回同様に書きたいことが多くて書ききれないので、また後日に持ち越します。（2018/09/09）