独創的なプロジェクトの標準設定は、私の意見ではかなり貧弱であり、分散チームプロジェクトの作業を監視/制御する必要がある場合、またはマネージャー（マネージャーまたは他のボス）がタスクの進行状況を確認したい場合、適切な透明性を提供しません。 私の意見では、標準設定では、タスクの現在のステータスについて自信を持って話すことはできません。
通常のタスクボードには、アジャイルプロセスを構築する一般的なプロジェクト管理成果物の基本設定（UserStory、Task、Bug）よりも多くの状態があります。 これらは考慮し、さらに設定する必要がある基本的なものであるように思えますが、それはまさに私自身とチームのためにしたことです。 以下のストーリーでは、要素のプロパティに影響を与えることなく、状態遷移プロセスの設定についてのみ触れます。 つまり 外観とプロパティのカスタマイズはありません。
先に進む前に、必要なツールを説明します。 説明されているすべての操作は、インストールされたTFS Power Toolsパッケージを使用してTFS2010で実行されます。 また、TFS管理者権限が必要になると思います。
それがどのようであったかを見ることから始めましょう。
ユーザーストーリー
すぐに使用できる設定
ユーザーストーリーの初期状態図は非常に貧弱で惨めに見えます。
写真の大きなバージョンはこちら
実際、ユーザーストーリーには3つの状態しかありませんが、ユーザーストーリー（以下、単に「ストーリー」）にはさらに「自然な」プロセスがあるため、明らかに不十分です。
最初に、表記法にもう少し注意を払うことを提案します。 赤は、ストーリーが存在する可能性のある状態を示します。 ブロック内のフィールドを指定することは、この状態に移行するときに満たす必要があるいくつかのルールに参加することを示します。 クリアされるフィールドにはマイナス記号が付いています;アスタリスクは、これがオプションであるという事実の修飾子です。
青色は、状態間の遷移を示します。 そのような各ブロックには、必ず遷移の理由が含まれている必要があります;これがないと、構成された回路を保存できません。 「アクション」セクションには、トリガーの指示が含まれており、その後に遷移を適用する必要があります。 Fieldsは、自動的に入力されるフィールド、または必ず入力する必要のあるフィールドを示します。 アスタリスクは、システムによって自動的に入力されるフィールドを示します。 プラス記号は必須フィールドを示します。
ダイアグラムには、初期状態のない単一の遷移が必ず含まれている必要があります。
話に戻りましょう。 基本バージョンでは、次の3つの状態のみが含まれます。
- アクティブ
- 解決済み
- 閉店
次の理由から、これでは十分ではないと思います。
- 作成されたばかりの新しいストーリーを、現在進行中のストーリーから分離することは不可能です。
- 履歴、要件の形式化、開発、テスト、または他の何かで作業のタイプを決定することは不可能です。
- 追加のソリューションを必要とする実装の新しい側面が発見された場合、履歴の作業を中断することは不可能です。
- ストーリーを意味を失ったと指定することで、ストーリーを取り消すことは不可能です。
もっと多くの理由を思いつくことができますが、それはおそらくユーザー履歴に取り組むというあなたの機能からすでに流れているでしょう。
ユーザーストーリー状態システムの「正しい」組織を確認するにはどうすればよいですか？ 今からお話しします。
カスタマイズされた
調整されたバージョンはもちろん大きく見えるので、ダイアグラム上のすべての遷移条件を考慮する必要はありません。 主なものは、移行の本質を説明することであり、理由は独立して説明できます。
写真の大きなバージョンはこちらです。
現在、ストーリーに取り組む標準的なプロセスは次のとおりです。
- 新しい
- 分析
- 開発の準備ができて
- 進行中の作業（WIP）
- 解決済み
- 公開済み
- 閉店
- +ホールド
私の意見では、以前のアクティブ状態はあまりにも多くのアクティビティを決定する可能性があり、実際の状況を調べるにはあまりにも多くの人々を調査するため、ストーリーの状態はより正確に決定できます。 したがって、状態の目的を考慮してください。
新しい
すべては、ビジネスアナリストや開発者のアイデアや希望から始まります。 つまり 簡潔に表現でき、ビジネスにとって有益なアイデアがいくつかあります。 これがNewの状態です。
テストはまだありません。これがプロジェクトにどのように適合するかはまだ明確ではありません。人件費は不明です-ただのアイデアがあります。 これが話をする理由です。 最初のアイデアが修正されて初めて、作業の他のフェーズに進むことができます。
この段階で、タスクのイニシエーターから、提案されたアイデアの重要性についての回答を得るための質問が行われる場合があります。
分析
このフェーズでは、タスクの要件のより詳細な収集が開始され、要件の一貫性がチェックされます。 タスクを完了するために何をする必要があるか、アプリケーションアーキテクチャにどのように当てはまるかを分析します。 収集して使用する必要があるデータが収集および分析されています。 データストリームが決定されます。 複雑さとタスクを完了するための時間のおおよその評価が与えられます。 受け入れテストが必要です。
指定されたデータが収集および検証された後、タスクのドキュメントが作成され、次のフェーズへの移行が進行中です。
この段階で責任を負うのは、アナリストと一部開発者、またはテクニカルリードです。
開発の準備ができて
前の段落でトリックをしました。 このフェーズの開始までに、開発者向けのタスクはすでに定義されているはずです。 開発者自身がこれらのタスクを記述し、サイズと構成を個別に決定します。 この同じステータスマークは、すべての準備作業が完了し、ストーリーを開発に移せることを示しています。 同時に、開発の結果としての問題が高い確率で発生しないことを確信できます。
特定のタスクの形成中に、さまざまなあいまいさが発生し、追加の分析のためにタスクが送信されます。 このプロセスは数回繰り返すことができます。 それが繰り返されるほど、専門家のアナリストは私の意見ではあまり適していない。 それでも一部のタスクには技術的な制限がある場合がありますが、履歴の分析に戻る場合は正常です。
この段階では、このストーリーがスプリントに含まれるプロジェクトマネージャーからの需要があります。
仕掛品
積極的な開発のプロセスの歴史。 すべてのタスクは、チームメンバーによって明確に記述され、積極的に実行されます。
開発者が短期間で自分で解決できない予期しない問題がある場合、問題が解決されるまでタスクは保留状態になります。
このような歴史の中での需要は、完全に開発者にあります。
解決済み
開発者が機能を作成し、受け入れテストに合格すると、ストーリーは解決済み状態になります。つまり、受け入れテストと、すべてが正しく理解され実行されたかどうかを評価する準備ができています。 このフェーズの後、ストーリーを公開またはWIP状態の改訂のために送信して、欠落している機能の説明または見つかったエラーの説明を送信できます。
ストーリーの状態およびビジネスアナリストとテスターからの要求（存在する場合）に対する責任。
公開済み
この状態は、ナビゲートしやすくするために導入されました。実際のユーザーが受信したり、変更ログアプリケーションをコンパイルする将来の潜在的な自動化のために既にいくつかのバージョンに移行しています。
これは実際にはインジケータです。 本質はResolvedの本質と同じです。
閉店
ストーリーのこの状態は、ストーリーが受け入れられ、すべての受け入れテストが合格し、誰も苦情を言わないことを意味します。
もちろん、テスターまたはアナリストが遅いか、または追加の実装要件をストーリーにプッシュするのに十分な持続性がある場合、この状態のストーリーはWIP状態に移行できます。
私の意見では、このようなユーザーストーリーの状態は、その作業のプロセスをより正確に特徴付けており、責任の領域をより明確に形式化および分割することが可能です。 このアプローチを使用すると、セクションの冒頭で尋ねられた質問に対する答えが簡単に見つかります。 歴史に沿って何が行われているかを明確に言うことができます。少なくとも、状況を把握するために杖で突く必要がある人の数は減っています。
タスク
すぐに使用できる設定
ユーザーストーリーの状態を理解した後、タスクについて話しましょう。 タスクワークプロセスの基本形式は次のとおりです。
何て言えばいいのかわからない。 そのような状態については、物語が作られたかどうかを除いて、何も言えません。 これは明らかに私の意見では十分ではありません。 繰り返しますが、タスクの状態、誰かが仕事に取り込んだかどうか、それが難しいかどうかなどについて、100万の質問が発生します。
このようなスキームでは、タスクが動作しているか、単に翼で待機しているかを判断する必要がある回り道を考え出す必要があります。 これには[担当者]フィールドを使用できますが、タスクを最初に特定の人に割り当てる必要がある場合、特定の困難が生じます。
もうあなたを拷問することなく、あなたが今仕事で使っている外観に移ることができます。
カスタマイズされた
調整されたプロセスには、レポートのレポートを追跡およびコンパイルするタスクを容易にするために設計された4つの新しいタスク状態が含まれています。
これで、タスクを処理する典型的なシナリオは4つのステップで構成されます。
- 提案された
- アクティブ
- 解決済み
- 閉店
タスクにアナリストの説明が必要な場合、または問題をすぐに解決できない場合は、 保留状態が提供されます。
タスクがキャンセルされた場合、 Abandoned状態があります。 これにより、タスクが閉じられた理由を分析する代わりに、完了したタスクと何らかの理由で実行されたタスクをすばやく区別できます。
提案された
すべてのタスクは、最初にこのステータスで作成されます。 文字通り：タスクは仕事のために提供されます。 [担当者]フィールドにはまだ姓がなく、料金はありません。 タスクが翼で待機していて、誰もそれをしていないことがわかります。 さらに、すでに述べたように、2つのオプションが可能です。
アクティブ
タスクは積極的に開発されており、進捗状況や期限に関心を持つことができます。 誰がそれを作ったかがはっきりとわかります。
放棄された
何らかの理由で、タスクは無関係になり、このステータスは、指定されたタスクが実装されていないことを示しています。
ホールド
タスクがアナリストによる明確化を必要とする場合、または問題を迅速に解決できない場合、この状態になり、問題が解決されるまでその状態になります。 その後、タスクはアクティブ状態にのみ移行できます。
解決済み
開発者は、タスクが完了したと判断すると、この状態に移行します。 理論的には、この状態では、タスクのテストが必要であり、結果は実行可能でなければなりません。
閉店
タスクは、テストプロセス、またはストーリー全体の承認後にこの状態になります。 テストで欠陥が明らかにならない場合、タスクは終了したと見なされます。
繰り返しになりますが、TFSへのリクエストの書き込みが一段と簡単になり、タスクのテキストに手を加えたり、技術リーダーや開発者自身にポーリングしたりすることなく、タスクのステータスを評価できます。
虫
すぐに使用できる設定
何もしない人は間違っていません。 そのため、どのように方向を変えても、作業中にエラーが発生するため、同じ方法でそれらの作業を追跡する必要があります。 分析するには、結論を導きます。
バグの基本的な状態図では、すべてがそれほどスムーズでもありません。 繰り返しますが、ほとんどの質問はバグに取り組む最初の段階で出てきます。 バグを確認するための作業が進行中であるのか、それともすでにそれを修正するプロセスにあるのかを確実に言うことはできません。 または彼はちょうど来て、誰もまだ彼を見ていませんでしたか。
これらの質問に対する回答を一目で把握できるようにするために、スキームを作成しました。
カスタマイズされた
大きな画像サイズはこちら
大きな変更がプロセスの開始に影響しました。 主なシナリオは次のとおりです。
- 提案された
- 分析
- アクティブ
- 解決済み
- 公開済み
- 閉店
これらの状態をさらに詳しく考えてみましょう。
提案された
この状態から、プログラムの疑わしい動作の記録が始まります。 これは、誰かが記述された動作を誤っていると考える指標です。 ただし、これはバグが発生していることを意味するものではなく、プロセッサまたは何か他のものにインパルスが誘導される惑星の特徴または失敗した位置である可能性があります。
この場合、バグを開始した人の観点からの機能の正しい動作を記述する必要があります。
分析
バグの記録が作成されたら、少なくともプログラムの動作を分析し、バグが開発者またはテスターのマシンで実際に再現されることを確認する必要があります。 また、この動作が実行される原因の初期分析により、作業の量とタイミングを評価して、望ましくない動作を修正できます。 これらの作業の結果に基づいて、バグのタスクが作成されます。
エラーを分析した後、バグはクローズされるか、動作するようになったときにアクティブステータスに移行されます。
バグをクローズするもう1つの理由は、バグと機能の性質の誤解、またはバグが独立したビジネス要件に発展した場合の副作用かもしれません。
アクティブ
この状態は、バグが修復中であり、開発者がバグの原因や結果の除去に忙しいことを示しています。
解決済み
一般的に、UserStoryとTaskの同じアイテムに似ています。 条件は、作業が完了したことを示し、2回目の受け入れテストを実施できます。 不要な動作が続く場合、バグはアクティブ状態に戻ります。
公開済み
この状態は、ナビゲートしやすくするために導入されました。実際のユーザーが受信したり、変更ログアプリケーションをコンパイルする将来の潜在的な自動化のために既にいくつかのバージョンに移行しています。
これは実際にはインジケータです。 本質はResolvedの本質と同じです。
閉店
受け入れテストに合格し、バグが修正され、誰もが満足しています。
私の意見では、このような小さな改善により、バグの作業の進行をより正確に制御できるようになります。
合計
このような作業計画に基づいて、より一貫性があり、透明性があり、生産的な作業のために、プロジェクトに関与している役割と人々の責任を決定することはすでに容易だと思います。 質問で互いに気を散らさないために、その答えはTFSと時間を与えることができます。
ワークフローの仕組みを教えてください。 一般に、どのシステムが使用されているかは問題ではなく、ほとんどの最新のバグ追跡システムを調整できます。
このすべての幸せを改めて設定することについて。 既製のサンプルテンプレートはこちらから入手できます 。