Tracを利用したアジャイル開発を見直すの巻

今のプロジェクトにおいて、どうやって開発を進めていくかということが話題に上がり、
開発方法を見直すことになりました。
そこで、今後の開発プロセスをどう行っていくか現状も含めて整理してみました。

まだたたき台で脳みそ整理中ですが、突っ込み歓迎。

基本的な方針として、まずはプロセスを確認してワークフローを組み立てます。
その後、ワークフローに関してツール(Trac)をどのように活用するか検討していきたいと思います。
大切なのはツールではなくプロセス(ワークフロー)であることを忘れないようにしたいと自戒しておきます。

なお、通常の俗にいうアジャイル開発と異なる点として

開発のみではなく、運用工数が発生する

という問題があります。
これは、現在動いているサーバの保守メンテナンスも工数に含まれているためです。
現行では分離出来ないため、この件に関してはイテレーション内部にあらかじめ運用管理用の予備工数を確保して保険をかけることにします。

はじめに

今回、顧客から発生するアクションは以下の4つになります。

1. 要望(機能要求)
2. 障害報告(既存機能のバグ)
3. QA対応(機能に関するQA)
4. 運用作業(本番サーバのメンテナンス)

プロセスを見直す

プロジェクトマネージメントとしてはスクラム方式を取り、
開発プラクティスとしてはXPのなかで必要なものを取り込んでいくことを目的にプロセスを見直していきます。
(やっているうちに微妙にごっちゃになりましたが(汗)

1. 要望(機能要求)

計画ゲーム

1. 顧客) 要望(ストーリーカード))の提示
   ※顧客から欲しい機能の要望を提供してもらう。
2. 顧客&開発者) 仕様検討
   ※顧客と開発者で顧客により提示された機能の仕様検討を行い概要に関して検討する。
3. 顧客) ユーザシナリオの作成(受け入れテストレベル扱いになるため、顧客により作成されたユーザシナリオを開発者が修正？)
   開発者)タスクの実体化(WBSによる工数見積もり)
4. 顧客) リリース時期を決定
   顧客&PM&開発者) イテレーション計画(2週間~4週間で基本的には同期間)を決定し要望を振り分ける
5. 開発者) 実体タスクをイテレーションに割り当て

イテレーションフェイズ

• スクラムミーティング
• 開発(実装・バグfix)
• ユニットテスト
• リファクタリング
• 継続ビルド(デイリーレビュー)

機能テスト

• 受け入れテスト実施

リリース

• リリース

2. 障害報告

障害情報に関しては、緊急度が高い場合は現行のイテレーションに組み込み、
低い場合は次のイテレーション設定時にどこに組み込むか検討します。
※むしろリリース単位で考えるなら次の計画ゲームしれませんが、この辺りはどうなんでしょう？
なお大きな工数がかかり、かつ緊急度が高い場合、現在のイテレーション計画内容を見直して対応することとします。

1. 顧客) 一次情報の収集
2. 顧客) 運用サイドか開発サイドかの問題きりわけ(出来る範囲で
3. 顧客) 発生箇所の担当者に連絡
4. 開発者) 調査し内容をフィードバック
5. 開発者) タスクを作成し優先度を設定してイテレーションに組み込む
6. 顧客&開発者) 全体に影響の大きい障害あるいは、工数が大きい障害に関してはイテレーション計画を調整する。

3. QA対応

QA対応に関しては、あらかじめイテレーション計画内に対応工数としてある程度確保しておきます。
もし、QA対応において多大な工数が発生する場合は現在のイテレーション計画内容を見直して対応を行います。

1. 顧客) QA発行
2. 開発者) タスクを作成し、最優先タスクとしてイテレーションに組み込む
3. 開発者) 対応。対応の結果大きな工数が必要になった場合(例えばドキュメント作成など)はイテレーション計画の調整を行う。

4. 運用作業

運用作業に関してもあらかじめイテレーション計画内に対応工数を確保します。

1. 顧客) 運用作業発行
2. 開発者) タスクを作成し、タスクとしてイテレーションに組み込む
3. 開発者) 対応。対応の結果大きな工数が必要になった場合(例えばドキュメント作成など)はイテレーション計画の調整を行う。

プロセスをツールとマッチさせる

上記開発プロセスを、Tracとマッチングさせていきます。
基本的にはチケットして存在していない作業は、存在しないものとすることを前提としてチケットの登録を厳守します。

なお、下記図にあるように複数のTracを利用するため、
暫定的に要望管理Trac(顧客がメインで利用)と、開発用Trac(開発者が利用)と名称を分けています。

要望

	対象	プロセス	ツールとのマッチング
1	顧客	要望(ストーリーカード))の提示	要望管理Trac上に要望をチケットとして登録する
2	顧客&開発者	仕様検討	仕様を確認しながら詳細な作業を洗い出す。補足や議事録などの情報に関しては要望管理Tracに記述する
3	顧客	ユーザシナリオの作成(受け入れテストレベル)	背景を聞き出して要望の背景から求める機能のユーザシナリオを作成する。シナリオ情報はチケットに概要をまとめ、不足があれば別途Wikiに書き出す(注意点：ここは必要があればテスト管理ツールを使う方法もあり)
	開発者	タスクの実体化(WBSによる工数見積もり)	WBS単位で分割されたタスクに見積もりを行う。みつもられたタスクは開発Tracにチケットとして登録する。その際に元となる要望管理Tracへの参照を忘れないようにすること。
4	顧客	リリース時期を決定	既存の見積もりから作業実績を確認し、具体的なリリース時期を定義し、要望管理用Tracのマイルストーンに設定を行う 設定したマイルストーンにリリースする要望チケットを紐付ける
	顧客&開発者	イテレーション計画(2週間~4週間で基本的には同期間)を決定し要望を振り分ける	イテレーション計画自体は開発用Tracのマイルストーンとして設定を行う。
5	開発者	実体タスクをイテレーションに割り当て	作成したイテレーション(開発Tracマイルストーン)単位でチケットを割り当てる。

といった感じです。

イテレーション内部や、バグ対応、QAなどに関してはまた後日。。。