チーム開発ツールを使った場合の日常

「拝啓、サカモトと申します。」 経由。

＠IT Special － Visual Studio 2008快適活用ガイド 第2回

開発者が理解しやすいように、 ありがちな機能紹介ではなく、 「開発者の1日の作業の流れ」を追いながら、 VSTS と TFS によってチーム開発がどう改善されるのかを説明していく。

ぅん、 ぅん、 こういう記事がいっぱい出るといいなぁ。 (^^;

さかもと画伯氏曰く、 「結構なお値段しますよねー」。
ですます。 でも、 ようは VSTS を入れるかどうかですね。 TFS 自体は、 ( チームメンバ分の VSTS に比べれば ) 安いもんですから。 f(^^;

また、 たしかに労力も掛ります。 とくに立ち上げ時に。
数人×数ヶ月といった程度のプロジェクトでは、 ちょっと見合わないかもしれないですね。

# 今やってるプロジェクトは、 十数人×十数ヶ月ってサイズだもんで、 なんとか入れてもらえましたです。 f(^^;

以下、 記事の中身にちょっとツッコミ。

一覧 （の ［作業項目の種類］ 列） を見ると、 自分の担当作業項目として、 複数の通常の 「タスク」 （＝作業） に加え、 「バグ」 対応が 1件あることが分かる。

…というところの画面キャプチャ。 ちょうどそのバグが表示されてますが…
マテ、 トリアージが空欄のままですぞ～。
つまり、 直すべきかどうか、 直すとしたらそれはコードか仕様書か、 その優先順位はどのくらいか… といった判定が、 まだなされていない、 って状態です。
ひょっとしたらバグじゃなくて、 テストのミスなのかもしれんし。

そんな状態で、 勝手に 「バグ修正」 を始めちゃダメですよ～ f(^^;

開発中のソリューションをIDEで開き、 該当個所のバグ除去作業を開始。 ソース・コードの編集を開始する

バグの修正は11時には終わった。 だが、 ソース・コードの編集を完了する前に、 このコードが正しく動作するのか検証しておかなければならない。

マテマテ、 TFS でチーム・プロジェクトを作ったときに、 MSF Agile と MSF CMMI のどっちのプロセスを選んだか知らないけど ( 画面に表示されてる項目を見ると、 たぶん MSF Agile )、 どっちにしても、 バグ修正の手順としては間違ってるぞ～ f(^^;

1. 関係してる範囲内のテストを、 全部実行して、 問題無いことを確認しておく。
2. バグを再現できるテストを書く。 ( または、 そのようにテストを修正する。 )
3. テストに通るように、 ソース・コードを直す。
4. さきほど 2. で用意したテストを実行する。
    パスしたら 5. へ。 パスしなかったら 3. ( または 2. ) に戻る。
5. コードカバレッジとコード分析をチェックする。 必要ならソース・コードを修正し、 4. に戻る。
6. ソース・コードにリファクタリングすべきところはないか、 チェックする。 あったらリファクタリングし、 4. に戻る。
7. 以上で、 バグ修正は終わったので、 エンバグしてないかチェックする。 ( 1. で確認したテストを、 もう一度全部実行する。 )

VSTS では、 チェックインのついでに 「作業項目の完了（＝解決）」 を指定できる。 つまり、 この機能によって、 口頭でチーム・リーダーに作業完了報告するという手順を省略できるのだ。

ここはチームごとの運用になりますが、 作業項目一覧で次の担当者を指定しちゃうこともあります。 今はバグを修正したのですから、 次はテスタが確認テストを行う番です。 なので、 担当者を自分からテスト担当者 ( あるいは、 テストリーダかも ) に変えます。