アジャイルでは、TFSのような厳格な管理フレームワークを使用して、プロジェクトの開始時の基本的なインフラストラクチャタスクをオンラインでどのように計画して割り当てますか？
ここで私は、比較的小さな新しいソフトウェア開発プロジェクトの範囲を定め、見積もっている最中です。私は、お客様から提案されたユーザーストーリーに目を通し、それぞれに対してタスクを配置しました。見積もりと、タスクの実行方法に関する簡単なメモを付けました。受け入れ基準があります。すべてが世界と良くなるべきです。
予定していた作品を見て、何か足りない部分があることに気づきました。機能を追加できるものをセットアップするだけの初期費用がかかります。 1つの特定のユーザーストーリーではなく、すべてのユーザーストーリーに属するもの。
たとえば、このアプリケーションの一部は、XMLを解析するサービスです。ユーザーの視点から見ると、XMLの内容に応じてさまざまな処理を行う必要がある特定のストーリーがあります。実際にXMLパーサーを作成すること（ファイルを検索し、ファイルを読み取り、コンテンツをどう処理するかを決定する前に関連データを抽出すること）は、これらすべてのストーリーの一部です。インストーラーなどを使用してWindowsサービスにラップする場合と同様です。これは、ユーザーに直接関係のない開発者中心のタスクです。
この特定のアプリケーションのもう1つの関連する例は、このアプリの機能に役立つ貧弱なレガシーコードのブロックを取得して書き換えることです。繰り返しますが、これはユーザーに直接の結果はありませんが、必要な作業です。ユーザーストーリーに焦点を当てたプロジェクト計画の中で、この作業の計画と実行はどこで「ライブ」ですか？
ユーザーストーリーを「開発者として、私はしたい...」と書いて人々がこれを解決するのを見てきましたが、他の場所で説明されているように、これはuserストーリーではありません。それは開発者のものです。
私（および他の人）がオンラインでTFSのような厳密な管理フレームワークを使用してプロジェクトを計画するのを助けるために、これに対する具体的な答えを探しています。これらは、「利害関係者の物語」または回答の中で言及されている他のあいまいなメタソリューションを作成する機能を備えていない傾向があります スクラムチームは計画会議でインフラストラクチャタスクをどのように説明しますか？
可能な限り多くの「ツール」コードをイテレーション0に入れると言う他の答えが好きです。しかし、これらの種類のツールは、プロジェクトがすでに始まった後に現れることがあります。おそらくイテレーション3では、今後のさまざまなストーリーで使用する汎用のXMLパーサーウィジェットが必要であることがわかります。
その場合、これらの内部のアーキテクチャの部分に依存する最初のユーザーストーリーは、それらが属するものですです。ストーリー＃345に取り掛かろうとしていて、XMLパーサーが「完了」としてカウントされる前にXMLパーサーに依存している場合、そのストーリーを完成させるために、再利用可能なパーサーが作業としてアタッチされます。
私のチームは上記のアプローチを使用しており、私たちにとってはうまく機能しているようです。
インフラストラクチャの場合、通常はIteration Zeroに配置されます。イテレーションゼロとはこれは通常、実際の反復が始まる前のキックオフと計画の間の時間です。
たとえば、新しいWebサービスが必要だとします。そのため、プロジェクトの作成、継続的インテグレーションのセットアップ、ソース管理リポジトリのセットアップ、ビルドスクリプトのセットアップ、自動デプロイメントなどを行う必要があります。ユーザーはこれらについてあまり気にしていませんが、関係なく必要です。
したがって、その作業はイテレーション0で行われます。イテレーション1が開始されるまでに、コンパイル、自動ビルドスクリプトがあり、展開する新しいプロジェクトシェルが既に存在します。現在、ユーザー機能はありませんが、準備は整っています。
私は引き続き、この作業を反復0作業の一部として追跡および計画します。
リファクタリングは テクニカルストーリー のように聞こえます。
インフラに依存します。
インフラストラクチャが非常に重要である場合、または複雑なコンプライアンス規制に準拠する必要がある場合は、独自のスケジュールを持つ独立したインフラストラクチャチームがいる可能性があります。アジャイルかもしれないし、滝かもしれません。この場合、インフラストラクチャの構築はプロジェクトで 外部依存関係 として管理されます。
インフラストラクチャがチームによって管理され、1回だけセットアップされる場合は、Jonが説明する反復0手法を使用できます。
インフラストラクチャのセットアップに数回の反復が必要な場合（たとえば、ビルドサーバーを今すぐセットアップするが、QAおよびpreprodサーバーが少し後でビルドされる場合）、それらのビルドアウトを機能しないPBIとして管理できます。機能PBIはこれらに特定の依存関係を持っている可能性があります。これは、「先行」リンクを使用してTFSで体系化できます。
もちろん、上記のすべてを組み合わせて使用することもできます。たとえば、継続的ビルドサーバーなしでは多くのことを実行できないため、反復0に配置できます。一方、プレプロダクションサーバーは反復2および3のタスクとして定義され、DBAチームに外部依存関係がある場合があります（アジャイルではない人）データセンターでDBインスタンスを割り当てる人。あるいは、特定の機能についてSSL証明書が発行されるのを待つ必要があるかもしれません。それらは反復4に進むことができ、それらの証明書に依存するすべての機能アイテムは、先行/後続の関係でそれらにリンクする必要があります。
すべての場合において、覚えておいてください：
- 常に明確な受け入れ基準を定義します。ハードウェアの人は、サーバーを立ち上げて、検証されていないときにサーバーを呼び出してしまうという迷惑な傾向があります。
- チームのイテレーションキックオフ中、チームは、PBIまたは作業項目にコミットする前に、依存関係とその可用性を調べる必要があります。