複数のプロジェクトの追跡。
本日、プログラムマネージャーがTFSを使用してすべてのプロジェクトを管理し、レポートを使用して複数のプロジェクトの変更を一度に追跡する方法を説明します。
手始めに、プロセス自体について少し説明させてください。
毎週、私たちが取り組んだプロジェクトの健全性をチェックすることを目標とするマネージャーの会議を開催しました。
これらの会議は、私たちのグループのプログラムマネージャーであるジムボイルによって開催されました。 彼は優れたプログラムマネージャーであり、作業の実行を監視した経験が豊富です。
毎週、ジムはこのようなレポートを見せてくれました。 彼は私たちが取り組んだすべてのプロジェクトを表示しました。
いくつかの説明：
- 緑-プロジェクト全体に関連して完了した作業の割合。
- 黄色-最後のレポート期間（通常は1週間）に完了した作業の割合。
- 赤-今後の作業の時間数。
- 機能に関する作業の終了日には、エグゼキュータの名前が伴います。
このレポートが表示された後、ジムは次のような質問を始めました。
- 過去1週間に進歩が見られないのはなぜですか？
- なぜそんなに少ないのですか？
- 終了日は1月3日に設定されていますが、残りの労働時間は1450時間です。 あなたはまだこれらの期限に間に合うと思いますか？
ジムは拳をテーブルに叩きつけて、「何をしているの？」と尋ね始めませんでした。 データは矛盾を示し、彼はそれを表明しただけです。
答えは次のとおりです。
- 「データを更新しませんでした。」 そのような答えは受け入れられませんでした。 このような答えの後、時間通りにデータを更新することの重要性を思い出して、言葉によるむち打ちが始まりました。 ちなみに、これはジムではなく、プロダクトユニットマネージャー（ブライアンハリー）によって行われました。
- 「私たちはその週、他の緊急の仕事のために引き抜かれました」-この答えはまったく受け入れられました。 そのような会議では優先順位の変更がありましたが。 つまり、経営者は、この緊急の作業がプロジェクト全体ほど重要ではないことを理解できます。 このような状況では、経営陣はプロジェクトの状況をよりよく把握していました。
- 「すべてがうまくいき、困難や問題がなければ、私たちはすべてを時間通りに行うことを望みます」-ここでは、誰かが最初の日付を保つことができると信じるのに苦労しています。 彼は日付をずらしたくない、なぜならそれはあまり良く見えないからだ。 基本的に、答えは次のとおりでした。作業が最大の確率で行われる日付が必要です。 移動する必要がある場合は、後で移動するよりも、すぐにそれを知った方がよいでしょう。
このアプローチでは、チーム内の文化を変える必要があることに気づいたかもしれません。 透明性は、あなた自身を証明させます。 このようなオープン性の文化により、経営陣は「すべての費用で完了日を維持する」という道をたどることができ、実行者はプロジェクトの現在のステータスをすべてオープンに表示するか、悪いニュースを隠すかを決定する必要があります。 それは双方にとって学習プロセスでした。
グレッグ・ボーア追加。
前の記事の発行後、私が話したレポートについてさらに詳しく説明するように頼まれました。 内部レポートに取り組んでいる友人に尋ねたところ、彼の答えがありました（ありがとう、ダグ！）。 彼がくれた.RDLファイルも添付します。
引用：
「以下は、特定の過去の日付の完了済みおよび保留中の作業の現在のボリュームを受け取るリクエストのテキストです（この日付はパラメーターです）。 フィールドを使用する目的：N日間の作業量を返す測定システムの[すべて]は、名前、製品グループ、現在のステータスなどを持つシナリオを検索することです。 示された日付で異なる意味を持ちました。 実際、他のフィールド（たとえば、ステータスなど）のフィルター値に関係なく、N日間の完了および保留中の作業の量を教えてください。
と
メンバー[対策]。[ValueOfCompletedWorkAsOfNDaysAgo] AS
（
[対策] [Microsoft_VSTS_Scheduling_CompletedWork]、
[作業項目]。[Microsoft_DeveloperDivision_Classifications_Group]。[すべて]、
[作業項目]。[Microsoft_DeveloperDivision_Classifications_Project]。[すべて]、
[ワークアイテム]。[システムタイトル]。[すべて]、
[作業項目]。[システム状態]。[すべて]、
[作業項目]。[Microsoft_DeveloperDivision_Features_RiskLevel]。[すべて]、
STRTOMEMBER（@MDXDateForWorkCompletedSinceDate）
）
メンバー[対策]。[ValueOfRemainingWorkAsOfNDaysAgo] AS
（
[対策] [Microsoft_VSTS_Scheduling_RemainingWork]、
[作業項目]。[Microsoft_DeveloperDivision_Classifications_Group]。[すべて]、
[作業項目]。[Microsoft_DeveloperDivision_Classifications_Project]。[すべて]、
[ワークアイテム]。[システムタイトル]。[すべて]、
[作業項目]。[システム状態]。[すべて]、
[作業項目]。[Microsoft_DeveloperDivision_Features_RiskLevel]。[すべて]、
STRTOMEMBER（@MDXDateForWorkCompletedSinceDate）
）
メンバー[対策]。[FeatureEndDate] AS
抽出物（
NonEmpty（
[Microsoft_DeveloperDivision_Features_DateEnd]。[日付]。[日付] *
[作業項目]。[システムID] .CurrentMember、
[対策]。[現在の作業項目数]
）、
[Microsoft_DeveloperDivision_Features_DateEnd]。[日付]
）.Item（0）.Member_Value
選択
空ではない
{
[対策]。[FeatureEndDate]、
[対策] [現在の作業項目Microsoft_VSTS_Scheduling_CompletedWork]、
[対策] [現在の作業項目Microsoft_VSTS_Scheduling_RemainingWork]、
[対策]。[ValueOfCompletedWorkAsOfNDaysAgo]、
[対策] [ValueOfRemainingWorkAsOfNDaysAgo]
}列では、
NonEmpty（
STRTOSET（@ WorkItemMicrosoftDeveloperDivisionClassificationsGroup、CONSTRAINED）*
STRTOSET（@ WorkItemMicrosoftDeveloperDivisionClassificationsProject、CONSTRAINED）*
[ワークアイテム]。[システムID]。[システムID] *
[作業項目]。[Microsoft_DeveloperDivision_Features_RiskLevel]。[Microsoft_DeveloperDivision_Features_RiskLevel] *
[ワークアイテム]。[システムタイトル]。[システムタイトル]、
[対策]。[現在の作業項目数]
）DIMENSION PROPERTIES MEMBER_CAPTION、MEMBER_UNIQUE_NAME ON ROWS
FROM [現在の作業項目]
どこ
（
[作業項目]。[System_WorkItemType]。＆[Orcas Feature]、
STRTOSET（@WorkItemSystemState、制約あり）
） "
FC-High-Level-Summary-of-Work.rdlグレッグ・ボーアリスク追跡
前回、複数のプロジェクトの進行状況を同時に追跡することについて話しましたが、ここでは、これらのプロジェクトのリスクを追跡することについて説明します。
まず、Featureレコードの[進行状況]タブを見てみましょう。
この図には、リスクに関連する2つのフィールドがあります。 リスクレベル-信号機の種類のインジケータ。 緑=時間通りに作業を完了します。 黄色=リスクがあります。 赤=時間どおりに作業を完了しません。 2番目のフィールドには説明テキストが含まれています。
毎週、プロジェクトマネージャーは、Featureタイプのレコードに示されている日付を確認し、指定した日付にチームが作業を完了できるかどうかを評価し、この評価に従ってリスクレベルを設定する必要がありました。 必要に応じて、リスクのコメントフィールドにコメントが追加されました。
結果は次のレポートです。
このレポートは、リスクレベル<>緑のクエリを使用したExcelで作成されました。 Excel自体を使用して追加された背景色。
毎週、グリーンプロジェクトとは異なるリスクゾーンに自分自身を確立したプロジェクトのチームは、他のチームに、そのような人生をどのようにして達成したか、グリーンゾーンに戻るために何をしていたか（または行うべきか）を説明する必要がありました。
このリスクがスケジュールの変更を単に反映する場合は、スケジュールが変更されたこと、およびその理由、終了日が更新されたことを全員が理解できるように、1週間レッドゾーンにインストールする必要があります。 その後、このリスクはグリーンゾーンに戻ります。
上記のレポートは降雪/氷嵐の予報に似ていると思うかもしれません。 シアトルの私たちは降雪をうまく処理しません。 笑うかもしれませんが、地元の人は私を完全に理解してくれたと思います。 :)
このシステムを機能させる方法は？
あなたは尋ねることができます：なぜ誰かが正直に自分のリスクを黄色または赤色で示すべきなのでしょうか？ なぜそれらを緑のままにしないのですか？ そんなに暑くないだろう？
これには2つの答えがあります。
最初の。 もちろん、プロジェクトに問題がある場合、チームは日付を変更する必要があります。 リスクを最初に変更せずに、突然1日が4週間ずれる場合、他の人は「なぜこれを以前に知らなかったのですか？」または「以前にそれを知っていたのなら、なぜ教えなかったのですか？」 これにより、チーム間の整合性を維持できます。
2番目は、文化の変化です。 リスクレベルを変更しても、何か間違ったことをしているとは限りません。 非常に多くの場合、リスクは制御できません。 ただし、ステータスの変更を報告するのはあなたの権限です。 実際、人々はプロジェクトのリスクではなく、情報提供に責任がありました。 もちろん、日付を頻繁に変更する場合は、当局の誰かが間違いなくあなたと話します。
次回は、このシステムを使用して品質ゲートを管理する方法について説明します。