複雑なソフトウェアシステムを作成するためのプロジェクトの開発管理。 MS ProjectおよびTeam Foundation Serverの使用経験

多くのプログラマーは、開発時に開発管理のパスを選択しますが、残念ながら新しいプログラミング言語とテクノロジーを学ぶ創造的なプロセスを制限しています。



そして、この瞬間から、マネージャーとして、私たちはソフトウェアプロジェクトの開発の複雑さ、すべての参加者による統一的な理解の複雑さ、外部環境の変化に伴って絶えず生じる変化を考慮する複雑さに対処せざるを得ません。 特効薬がないというブルックスの予言的な声明に焦点を当て、ソフトウェア開発の規模、生産性、信頼性、および単純さではないにしても、向上させる管理手法を見つける方法を探しています。



したがって、各リーダーはガントチャートとは何かを知っており、全員がMSプロジェクトを使用しました。 さらに多くの読者、プログラマーがタスク管理システムを使用しています。 そして、ほとんどすべての非孤独なプログラマーがソース管理システムを使用しています。



統一された開発プロセスを提供するという非常に実用的なタスクに直面しています。要件の新しい変更を考慮すると、プロジェクトパラメーターの変更を明確に確認できます。



この問題を応用レベルで定式化します。 プロジェクトを一連のステージとして提示します。各ステージは、多数のユーザーシナリオ、ストーリー、およびタスクに分解される各タスクを含む高レベルのタスクのリストで構成されます。 この記事では、GOSTまたはアジャイルのいずれかでこのような混合用語を使用します。顧客はプロジェクトをステージのほぼ詳細レベルで見ており、開発者はアジャイルが何であるかを知ることにまったく関心がなく、開発者はタスクのレベルと彼らは、順番に、GOSTについて考えることに興味がありません。



さらに、プロジェクトに関する新しいデータが到着すると、利用可能なすべての情報を考慮した再計画が可能な限り迅速に行われ、顧客に提供するためにプロジェクト全体で可能な限り最速のフィードバックを受け取ることができるようにする必要があります独自の製品）。



目標を達成するために今どのツールを使用する必要がありますか？ これらのツールの次の選択基準を示します。

1）ガントチャートは、視覚的なツールとして、および計画段階のツールとして必要です。

2）ツールは、高レベルのタスクをユーザースクリプトに分解し、プログラマーとアナリストのタスクに分解できるようにする必要があります。

3）ツールは、自動化された方法で、高レベルのガントチャート内のタスクとタスク間の変更間の関係を確認する必要があります。 たとえば、タスクの1つを評価する際にミスを犯し、プログラマがタスクに2倍の時間を費やした場合、上位レベルのステージのいずれかの期間が長くなる可能性があります。 また、ハイレベルステージの締め切りを中断させたくないため、要件とリソースのバランスを再調整するためにクリティカルパスを分析する必要があります。 レベル間の相互接続により、ガントチャートで起こりうる故障の問題を確認するのに役立つツールが必要です。

4）また、ソースコード管理システムでプログラマタスクとソースコード間のリンクを追跡できることが望ましい

5）ソースコード管理システムは、 ブランチモデルをサポートする必要があります。たとえば、 多数のgit + gitflowが適切です。

6）タスク管理システムでは、実際に割り当てられた時間を記録し、タイムバランスの量を考慮し、作業の進捗状況に関するレポートを受信できる必要があります。



そのようなツールを選択するためのいくつかのオプションがありますが、私たちに最も適していると思われる3つを検討してください。

1）MS Project + Team Foundation Server

2）ジラ

3）Redmine

JiraとRedmineは、以下の記事で検討されます。この記事では、MS Project + Team Foundation Server（+ Visual Studio）に焦点を当てます。

MS ProjectおよびTeam Foundation Serverの使用

Team Foundation Server 2013自体のインストールは簡単です。 事前にSQL Serverをインストールして、リポジトリとして使用します。 TFSを設定するには、 http：// hostname：8080 / tfs （デフォルト）からアクセスできるコントロールパネルWebアプリケーションと、Administration Console Windowsアプリケーションの両方を使用する必要があることに注意してください。 たとえば、コントロールパネルからコレクションへのアクセスを許可し、管理コンソールでのみコレクションを作成できます。



国務省で働いており、会議の後、1週間でサイトを展開するタスクを得たと仮定します。これにより、負荷がかかったときに「そこに行く国のすべての市民」とモバイルアプリケーションを保持できます。



仕事は仕事です。プロジェクトでは、次の計画を作成します。







この点で、開発者、アナリスト、デザイナー、レイアウトデザイナー、テスター、エンジニアにとって問題があります。 タスクはシーケンスの順序でバランスが取れており、個々の実行者で重複することはなく、ある場合には効率的な負荷分散のためのギャップが含まれています。



すべてのスペシャリストはエネルギーに満ちており、戦いに熱心なので、このプランからTFSのタスクのリストを取得する必要があります。 TFSでは、コレクションを最初に作成し、プロジェクトを作成する必要があります（Visual Studioで作成する必要があります。プロセステンプレートとしてAgile Software Development 2013.4のMSFを選択しました）。



TFSへのアップロードを構成するには、TFSのインストール後に表示される[チーム]タブの[プロジェクト]に移動し、チームプロジェクトを選択します。







次に、タスクを公開します。







...そして問題に遭遇する：







もちろん、どうしてすぐに推測できなかったのでしょう。結局のところ、TFSの要素の種類を決定する必要があります。 これを行うには、TFSのインストール後に表示される[作業項目の種類]列をProjectに追加する必要があります。 TFSの要素を適切にグループ化するには、囲んでいるタスクのタイプがUser Storyであり、含まれるタスクがTaskである必要があることに注意してください。







スクリーンショットは、作業項目タイプだけでなく、エリアパスと反復パスも追加したことを示しています。 これらのフィールドは、TFSでタスクを作成するためにも必要であり、それぞれ、開発されたシステムとバージョンのモジュールを特徴付けます。



意味によって示されたセルをバインドする必要があり、対応するリソースがADにあり、エリアパスと反復パスが作成されていることを確認します。











...そしてデータを再度公開してみてください。 タスクを表示するには、Visual Studioも使用する必要があります。すべてが標準であり、コレクション、プロジェクトに接続し、タスクのリストを表示するためにクエリ（クエリ）を実行します。







また、対応するアイテム識別子がProjectのWork Item ID列に表示され、ProjectとTFSの間でデータを同期するために使用できることもわかります。







[期間]列に、計画された作業の代わりにゼロが表示されました。 実際、TFSのワークアイテムは異なるタスクを使用してタスクの期間を決定します：元の見積り、完了した作業、および残りの作業。 期間に関しては、最初の近似では、元の推定フィールドが最も適切であり、これはプロジェクトの基本作業フィールドにマッピングされます







そして、マッピング、つまりプロジェクト列とTFSフィールドの対応にたどり着いたので、どのように変更できるかを簡単に述べます。 MSDNの 1つの記事では、Projectのフィールドをマッピングするためのファイルについて説明し、別の記事では、このファイルのTFSへのエクスポートとインポートについて説明しています。

また、人件費への期間の転送を処理するために、MDSNで別の記事の資料を使用します ） ここではドキュメントを処理できません。 この記事で推奨されているように、プロジェクトのスケジューラーの基本設定を設定します（ファイル->オプション->スケジュール）







...そして、タスクの期間に基づいて、基本的な人件費を定義します











その結果、Basic Labor列には対応する値が入力されます。







そして、TFSで変更を公開します。



そこで、MS ProjectおよびTFSでガントチャートを取得しました。これは、専門家が使い慣れたツール、つまりVisual Studioを介してアクセスできる関連タスクのセットです。



要件はすべて満たされていますか？ はい。TFSにはバージョン管理システムが組み込まれており、これもGITに置き換えることができます。そのため、このようなスキームでは、基準リストの項目4と5も自動的にサポートされます。 そして、そうでなければ、すべてがうまくいくようです

タールのバレル、またはマイクロソフト、どうですか？

批判は最も楽しいことではありませんが、この場合、客観性は記事の形式を必要とします。 それでも、これはProjectおよびTFSのチュートリアルではありません。このバンドルは、プランを操作する際の人件費を実際に削減するツールと見なす必要があります。そのため、ツールの使用における不必要な困難を回避する必要があります。

ProjectとTFSの実際の使用で発生するいくつかのケースを考慮してください。

ケース1.誤って存在しないバグを追加した

自然には存在しないバグがTFSの現在の反復に追加されたとします。 間違いは起こりますが、それについて何もすることはありません。 または、バグはバグではなく、機能でした。 これはあなたに起こったことがありますか？ アナリストは最後まで声明を読んで何かを理解し、テスターはタスクに添付されたすべてのファイルを開き、プログラマーは長い間彼を苦しめていたすべての質問をすることにしました（TDDについては考えないでください、例は条件付きです）



この場合、計画の中で何をすべきか？ バグはTFSで安全に閉じることができますが、Projectで変更を更新（更新）しても、計画から消えることはありません。 論理的なようで、エンティティはどこでも削除されません。 しかし、単一のプロジェクト計画についてはどうでしょうか？ 手ですべてを支配する必要があります。



おわりに ワークアイテムが誤ってTFSに追加された場合、プロジェクトから自動的に削除することはできません。

ケース2.反復の期間が変更された

また、経験から...記事の最初から顧客を覚えていますか？ 次の会議で、彼は反復時間を2週間から1週間に短縮しました。 すぐに出向かなければならないことは明らかですが、計画を適切に更新したいと考えています。 では、TFSの反復を短縮してみましょう。 タスクにどのように影響しましたか？ 反映されません。 タスクは、反復の時間枠に収まらないことを理解しません。 マイクロソフト、変更をProjectにアップロードしましょう。







そして、何が変わったのですか？ 何もありません。ProjectはTFSの反復名についてのみ耳にし、タイミングについては何も知りません。



おわりに 反復の条件を変更する場合、手動モードでタスクごとに条件を処理する必要があります。

ケース3.問題の一般化：再計画

ここで、Habré-Megamindには、ユーザーganouver による素晴らしい記事があり、その中で彼がProjectを使用してプロジェクトを管理することについて説明しています。 特に、そこでは、計画のバランス、Projectを扱うための独創的な戦術について読むことができ、コメントでは次のフレーズを見つけることができます。

... TFSの束-プロジェクトはなんとなく不器用で不便です。

そして彼の記事には、Tom KiteがOracle DBMSについて説明しているのと同様に、開発管理について説明している声明があります。

主なものは、計画の定期的な更新です。

実際のプロジェクトで作業項目の種類の変更、不要なタスクの削除などに加えて、計画は、高レベルのタスク（ストーリー）のタスクの構成、および反復の期間と構成の両方でほぼ完全に変更できます。 ProjectとTFSは、これらの変更を考慮し、タスクをモーフィングし、計画を再調整し、リソースを計算し、反復期間の変更を考慮し、新しいリリース計画を準備するために何を提供しますか？ 何も提供しません。

おわりに

Project + TFS + Visual Studio製品共有という形のMicrosoftのプロジェクト管理およびソフトウェア開発ソリューションは、1回限りの作業計画に使用でき、継続的な自動再計画にはあまり適していません。



問題のProject + TFSテクノロジースタックはタスクを解決するのにあまり適さないと結論付けた記事を公開するかどうかを考えて、ネガティブな経験も経験であり、少なくとも読者が自分で作成できるようにすることを決めました選択肢。



したがって、これらのツールで完全な開発管理の問題を解決するには、計画を最初に作成してから、マネージャーまたはアシスタントの半自動化された作業に基づいて行う必要がありますが、再計画には通常の操作に時間がかかります。



次の記事では、他のツールキットを見ていきます。最初の候補はJiraとRedmineです。