税トラッカーおよびバグトラッカーとして、Redmineを使用します。 この記事では、redmineでタスクを操作するという実装された概念についてお話したいと思います。
ご存知のように、現在、プロジェクト管理にはいくつかのアプローチがあります。柔軟、厳格、そして多くの場合それらの組み合わせです。 トラッカーでタスクのライフサイクルを監視するためのツールを提供するタスクを設定します。一方で、ソフトウェア生産の技術的側面を考慮することができます。他方では、チームまたは従業員のグループに作業方法を課すことはありません。タスク（統一された状態ステータス、同一のメトリックなど）。
新しい機能を導入するタスクのライフサイクルを考慮してください（このような段階は当社で利用可能です）：
人生では、残念ながら、タスクはしばしば前の段階に複数回戻ります-回路を乱雑にしないために、逆矢印は描かれませんでした。 通常、このようなタスクを実行するプロセスは、図の図のように「額」の赤字で編成されます。タスク（チケット）が作成され、ステータスが変化して請負業者から請負業者に転送されます。 このようなスキームは、常設チームが事前に設計された計画を実装する場合、またはタスクが部門から部門に組織的に転送される（たとえば、開発者からテスターに）カスケード管理モデルにより適しています。 しかし、アジャイルなアプローチの場合、または専用サービスを実行する場合、このようなスキームはあまり便利ではありません。 したがって、説明されているスキームの利点（「1つのタスク-1つのクーポン」と呼びましょう）：
- 作成、検索、「理解」しやすい単一のエンティティ。
- すべてのストーリーとコメントを1か所で。
スキームの短所「1つのタスク-1つのクーポン」：
- アクティビティの種類ごとに複雑さと計画リードタイムを評価することは困難です（少なくとも1段階の時間を見積もることができないため、多くの追加フィールドを入力する必要があり、フロート全体としてのタスク全体の評価）。
- タスクが現在どの段階で完了しているかを明確にするには、「開発準備完了」、「テスト中」などの追加ステータスを入力する必要があります。 これにより、メトリックの設計と適用が複雑になります。
- 特定の時間のタスクは1人の実行者にしか割り当てることができないため、アクション（ドキュメントやテストなど）を並列化することはできません。
- 最終段階（文書化またはテスト）でタスクを受け入れた請負業者が現在の状況を理解することは困難です。コメントに問題ステートメントを書き留める必要があります。これは方法論的に間違っています。
- スプリントを使用する場合、1つのクーポンで長いタスクを計画するのは不便です。なぜなら、それらは通常複数の反復内で実行されるからです。
「1つのタスク-1つのチケット」スキームに従って実行される作業のチケットは、次のようになります（すべての作業が1人のハードワーカーVasya Pupkinによって行われる場合）。
タスク「1つのタスク-1つのクーポン」（これ以上の苦労を伴わないトラッカーは「タスク」と呼ばれます）の移行スキームは、単純に次のようになります（「フィードバック」、「承認中」などの追加ステータスはカウントしません）。
新規->ビジネス分析の準備->ビジネス分析->システム分析の準備->システム分析->開発の準備->開発の準備->テストの準備->テスト->ドキュメントの準備->ドキュメント->準備実装->展開->完了->クローズ。
「1つのタスク-1つのクーポン」スキームの問題を解決するために、1人の実行者が実行するアトミックアクティビティごとに個別のクーポン（サブタスク）を作成するスキームが開発されました。 この場合の一般的なステートメントは、親タスク（トラッカー「一般タスク」）、およびサブタスクとしてのアトミックタスクで形成されます。 つまり 機能ドリルダウンは、ライフドリルドリルに置き換えられました。 このようなスキームを「1つのサブタスク-1つのクーポン」と呼びます。
このスキームによるクーポンは次のようになります。
アクティビティのタイプをトラッカーの名前から削除すると、単一の移行スキームを適用できます。
新規->インライン->進行中->完了->クローズ。
スキームはシンプルであり、マネージャーと請負業者の両方が理解できるため、統一されたメトリックとアジャイルツール（ステッカー付きの仮想ボードなど）を使用できます。
スキーム「1つのサブタスク-1つのクーポン」の利点：
- 特定のエグゼキューターに対して個別のタスクを形成する可能性-誤解のリスクが軽減されます。
- サブタスクを並列化する機能-それぞれに独自のチケットとパフォーマーがあります。
- このサブ問題の正確な時間推定と計画完了日を、他のサブ問題とは無関係に添付することができます。
- 移行スキームの均一性とシンプルさ。
それとは別に、次の利点についてお話しします。外部サービスと同様に内部サービスを使用する場合、技術的な観点と政治的な観点の両方から、タスクの単一チケットを転送することは完全に正しいとは限りません。 したがって、テストを外部委託した場合、これらの人たちは、たとえばドキュメントがどのように通過するかを知る必要はありません。 同様に、内部サービスでは、たとえば、職業別のプロジェクト間チーム（テクニカルライター、製品開発グループ）を形成しています。 彼らはプロジェクトの実装の特徴を知らないため、背景を理解することに興味がなく、明確に定義されたタスクが必要です。
しかし、そのようなスキームには欠点もあります。
- redmineで多くのクーポンを作成する必要があります（タスクごとに5〜10）。ナビゲーションは将来問題になる可能性があります。
- 請負業者がタスクの背景を知る必要がある場合、彼は他のクーポンでそれを探す必要があります。
- このようなタスクのライフサイクルの管理は、マネージャーがさまざまなクーポンのステータスを監視および同期する必要があるため、より困難です。
残念ながら、理論的にはすべてが人生よりもはるかに美しく見えます。 2つの提案されたスキームの作業を開始すると、すぐにそれらが互いに別々に存在することはできず、それらを組み合わせる必要があることに気付きました。 たとえば、「1つのタスク、1つのクーポン」という概念に取り組んでいるチームが、サブタスクを外部委託または内部サービスに転送する必要がある場合。 ソリューションは非常に簡単に見つかりました-「タスク」タイプのチケットでは、必要に応じて、「1つのサブタスク-1チケット」スキームに従ってサブタスクを追加することを提案しました。これは並行して実行でき、残りのサブタスクの順次実行に干渉しませんでした。
このようなチケットは次のとおりです。
練習はどうですか？ 当社の部門の1つは、約3か月前に説明された概念に取り組むようになりました。 現在、395個のクーポンを作成しています。
- 「1つのタスク、1つのクーポン」248の概念によると、
- 「1つのサブタスク、1つのクーポン」という概念に従って147。
これまでのところ、「1つのタスク、1つのクーポン」という概念が大きなマージンでリードしているという事実にもかかわらず、数値は、提案されたツールの両方が需要があることを示しています。
Redmineの運用計画に関する興味深いアイデアと実装は、 ここにあります 。