アジャイルでは、TFSなどの厳格な管理フレームワークを使用して、プロジェクトの開始時の基本的なインフラストラクチャタスクをどのように計画して割り当てますか？

ここで私は、比較的小さな新しいソフトウェア開発プロジェクトの範囲を定め、見積もっている最中です。私は、お客様から提案されたユーザーストーリーに目を通し、それぞれに対してタスクを配置しました。見積もりと、タスクがどのように達成されるかについての簡単なメモを付けました。受け入れ基準があります。すべては世界と良くなるべきです。

予定していた作品を見ていると、何か足りない部分があることに気づきました。機能を追加できるものをセットアップするだけの初期費用がかかります。特定の1つのユーザーストーリーではなく、すべてのユーザーストーリーに属するもの。

たとえば、このアプリケーションの一部は、XMLを解析するサービスです。ユーザーの観点から見ると、XMLの内容に応じてさまざまな処理を行う必要がある特定のストーリーがあります。実際にXMLパーサー（ファイルを探し、それを読み取り、内容をどうするかを決定する前に関連データを取り出すビット）を書くことは、これらすべてのストーリーの一部です。インストーラーなどを使用してWindowsサービスにラップする場合と同様です。これは、ユーザーに直接関係のない開発者中心のタスクです。

この特定のアプリケーションのもう1つの関連する例は、このアプリの機能に役立つ貧弱なレガシーコードのブロックを取得して書き換えることです。繰り返しますが、これはユーザーに直接の結果はありませんが、必要な作業です。ユーザーストーリーに焦点を当てたプロジェクト計画の中で、この作業の計画と実行はどこで「ライブ」ですか？

「開発者として、私はしたい...」というユーザーストーリーを書いて人々がこれを解決するのを見てきましたが、他の場所で議論されているように、これはユーザーストーリーではありません。それは開発者のものです。

私（および他の人）がオンラインでTFSのような厳密な管理フレームワークを使用してプロジェクトを計画するのを助けるために、これに対する具体的な答えを探しています。これらは、「利害関係者の物語」や、計画会議でのスクラムチームによるインフラストラクチャタスクの説明への回答で言及されている他のあいまいなメタソリューションを作成する機能を備えていない傾向があります。

可能な限り多くの「ツール」コードをイテレーション0に入れると言う他の回答が好きです。しかし、これらの種類のツールは、プロジェクトがすでに始まった後に現れることがあります。おそらくIteration 3では、今後のさまざまなストーリーで使用するために、汎用のXMLパーサーウィジェットが必要であることに気付くでしょう。

その場合、これらの内部の建築物に依存する最初のユーザーストーリーは、それらが属するものです。ストーリー＃345に取り掛かろうとしていて、XMLパーサーに依存しているため、「完了」としてカウントされる場合、そのストーリーを完成させるための作業として、再利用可能なパーサーがアタッチされます。

私のチームは上記のアプローチを使用しており、私たちにとってはうまく機能しているようです。

インフラストラクチャの場合、通常はIteration Zeroに配置されます。イテレーションゼロとは これは通常、実際の反復が始まる前のキックオフと計画の間の時間です。

たとえば、新しいWebサービスが必要だとします。そのため、プロジェクトを作成し、継続的インテグレーションをセットアップし、ソース管理リポジトリをセットアップし、ビルドスクリプトと自動デプロイメントをセットアップするなどの必要があります。ユーザーはこれらについてあまり気にしませんが、関係なく必要です。

つまり、その作業はイテレーション0で行われます。イテレーション1が開始されるまでに、コンパイル、自動化されたビルドスクリプトを備え、展開する新しいプロジェクトシェルがすでに存在します。現在、ユーザー機能はありませんが、準備は整っています。

イテレーション0の作業の一部として、この作業を引き続き追跡および計画します。

リファクタリングは技術的な話のように聞こえますが、どのイテレーションでも実行できます。

インフラストラクチャによって異なります。

インフラストラクチャが非常に重要である場合、または複雑なコンプライアンス規制に準拠する必要がある場合は、独自のスケジュールを持つ独立したインフラストラクチャチームがいる可能性があります。それはアジャイルかもしれないし、滝かもしれない。この場合、インフラストラクチャの構築は、プロジェクトで外部依存関係として管理されます。

インフラストラクチャがチームによって管理され、1回だけセットアップされる場合は、Jonが説明する反復0手法を使用できます。

インフラストラクチャのセットアップに数回の反復が必要な場合（たとえば、ビルドサーバーを今すぐセットアップするが、QAおよびpreprodサーバーは少し後でビルドされる場合）、それらのビルドアウトを機能しないPBIとして管理できます。機能的なPBIはこれらに特定の依存関係を持っている可能性があります。これは、「先行」リンクを使用してTFSで体系化できます。

もちろん、上記のすべてを組み合わせて使用​​することもできます。たとえば、継続的ビルドサーバーなしでは多くのことを実行できないため、反復0に配置できます。一方、プリプロドサーバーは反復2および3のタスクとして定義され、DBAチームに外部依存関係がある場合があります（アジャイルではない人）データセンターでDBインスタンスを割り当てる人。あるいは、特定の機能に対してSSL証明書が発行されるのを待つ必要があるかもしれません。それらは反復4に進むことができ、それらの証明書に依存するすべての機能アイテムは、先行/後続の関係でそれらにリンクする必要があります。

すべての場合において、覚えておいてください：

1. 常に明確な受け入れ基準を定義します。ハードウェアの人は、サーバーを立ち上げて、検証されていないときにサーバーを呼び出してしまうという迷惑な傾向があります。
2. チームのイテレーションのキックオフ中に、チームは、PBIまたは作業項目にコミットする前に、依存関係とその可用性を調べる必要があります。