唯一の直観的なインターフェースは女性の乳房であり、他のすべてを学ぶ必要があります。 この民俗の知恵が今朝私に来たとき、私は3番目の同僚に詳細と色を伝えました。 この記事では、いくつかのスケッチの例を使用して、日常の仕事に人気のあるJiraの例を使用してタスク管理システムを使用するための可能なオプションの概要を説明します。 もちろん、レセプションは可能なものだけではありませんが、非常にシンプルで普遍的であり、Jiraだけでなく、Redmine、Trac、Bugzillaなどの最も一般的なタスク管理システムにも適用できます。

タスクの内部

タスク管理の基礎となる基本的なブリックは、実際にはタスクです。 タスク自体の名前とオプションの説明に加えて、タスクには3つの主要なプロパティがあります。これらのプロパティを中心に、すべてが回転し、運命を決定します。

• 顧客 （別名Reporter）は、タスクを開始した人です。 これは、何らかの理由でこのタスクを完了することが重要な人であると理解されています。 用語の曖昧さに注意してください-「レポーター」は英語から「報告された」、「報告した人」と翻訳されます。 歴史的に、このプロパティはバグレポートに使用されていました。レポーターは明らかにバグを発見し、報告するのが面倒ではありませんでした。 しかし、タスク管理システムの進化により、バグ修正のログ記録だけでなく、一般的なタスクの操作にも使用されるようになりました。「新しい機能の追加」、「Habrに関する記事の作成」、「スタンドアップミーティング（毎日）」です。 範囲は変更されましたが、用語は変わりません。「これを言った人」と「仕事をするように言われた人」を共有するタスク管理システムはほとんどありません。 一般的に、レポーターは、作業を行う必要がある人であり、作業が行われたことを確認します。
• 請負業者 、彼は譲受人です-タスクを実行する人。
• 状態 、それはステータスでもあります（何らかの理由で、状態という用語はほとんど使用されません）-このタスクで現在何が起こっているか。

タスクの進化

仕事が必要な人がこの悲しい事実に気づいたとき、彼は仕事を作ります。 この行動は非常に自然であり、常識と一致しており、キャプテンエビデンスによって承認されています。 新生児の仕事の特徴は何ですか？ 担当者-仕事をする必要がある人とステータス-彼女の新生児を反映するように設計された現在の状態。 ほとんどのシステムでは、新しく作成されたタスクは「 オープン 」状態になります。 この状態は、「ダモクレスの剣を持っている人にこの仕事がかかっており、その作業はすでに進行中であるか、まもなく実行される」ということです。 「オープン」状態のタスクを「自分で」見た請負業者は、現在のタスクとその優先順位に応じて、しばらくしてから作業を開始することが理解されています。

パフォーマーがタスクを手に入れたとします。 ここから楽しみが始まります-タスクに応じて、オプションが可能です：

1. パフォーマーにとって、すべては明らかです。 彼は仕事を始め、一定の時間（数時間、数日、数ヶ月、または数年）働いた後、仕事が完了したと考えます。 顧客がこの楽しいイベントについて知るために、請負業者はタスクの状態を変更し、 「解決済み」に設定します。 この単純なアクションでは、多くの面白いニュアンスが隠されており、長年にわたって開発者とそのリーダーの両方に幸福と喜びをもたらしてきました。 従業員がタスクが完了したと考えるという事実は、タスクが実際に完了したことを意味しません。 顧客だけが完了したと見なすことができます-タスクを設定し、実行されたことが実際に実行する必要があることを確認する能力を持っている人。 したがって、「解決済み」タスクの状態は、主にパフォーマーから顧客に投げられるバレーボールです。 「私にとっては-確認しました。」 したがって、「解決済み」状態のタスクを確認したら、顧客は作業が実際に完了したことを確認し、次の2つのアクションのいずれかを実行する必要があります。
   
   
   1. 作業が実際に完了すると、タスクの状態は「終了」に変わります。 このようにして、「アーカイブにタスクを送信」し​​ます-すべてが完了し、追跡するものはもうありません。
      
      
   2. しかし、それはしばしば異なって起こります-何が行われたかを見て、顧客は頭をつかみ、輪になって走り、文字「A」を叫び、他の方法で彼の驚きを表現します。 この場合、請負業者は、行われたことが顧客の期待に完全に対応していないことを説明する必要があります。この目的のために、状態は再び「 オープン 」に設定されます。 一部のシステムでは、同じ目的で特別な「 再オープン 」状態がありますが、実践が示すように、その存在はほとんど変わりません-最初の試行と10番目の試行を本当に区別する必要がある場合はめったにありません-タスク状態ログに表示されます。
      
      
   
   
   
2. パフォーマーにとってすべてが明らかな場合がある場合、反対のパフォーマーが何も理解していない場合があります。 不明確なバグレポート、不十分な定式化された要件、長い説明-これらすべてがパフォーマーに楽観主義を加えることはめったになく、論理的に明確にしたいという願望につながります。 ここで最も興味深い部分が始まります-請負業者がタスクを完了していないが、顧客に何をする必要があるかを明確にしたい場合-これはすべて「 解決済み 」状態と同じです！ 多くの人がつまずく十分な直感に反するもの。 上で書いたように、「解決した」とはタスクの完了ではありません。 これは出演者が何かをしたというサインです 。 たとえば、私は問題を見て、顧客がそれを明確にすると良いと判断しました:)。 解決されるのは、顧客へのバレーボールのパスであり、彼に優先権を与えます。 このタスクの状態は、「次のステップは顧客向け」であることを示しています。 彼は、実行者にとって明らかでないことを読んで、タスクをまったく実行する必要がないと判断することができます-その後、状態は「終了」に変わります。 または、理解できないものを明確にし、状態を再び「 Open 」（「Reopened」）に変更できます。
   
   注意深い読者©は間違いなくそれに興味を持ちますが、顧客はパフォーマーが何をしたかをどのように判断しますか？ あなたはタスクを完了しましたか、または彼は彼が明らかにされることを望んでいますか？ 悪魔は、いつものように、詳細に確実に隠されています -「解決済み」タスクの状態には「解決策」というプロパティがあります 。 そして、実行者がタスクで何をしたか、何をしなかったかを正確に示すのはこのプロパティです。 一般的なオプション：「修正済み」（タスクが完了し、バグトラッカーの重い遺産）、「未完了」（何をすべきか明確ではありません-ここで説明したこと）、「再現できない」（以下を参照）、「修正しない」（詳細を参照）、「複製」（詳細を参照）。 Resolutionプロパティの正しい使用は、タスク管理システムの使用の基礎であり、誰もが認識しているわけではありません。
   
   
3. 「Resolution」プロパティの値によって決定される、受信したタスクに対するエグゼキュータの一般的な反応も少なくなります。 「Fixed」（「Complete」、「Done」）および「Incomplete」（「Need more info」）がほとんどすべての一般的なタスク管理システムに存在する場合、他のプロパティは異なります。 最も人気のあるものをあげます：
   
   
   1. 再現できません -請負業者はタスクに示されているものを見つけられませんでした。 開発者がエラーを繰り返すエラーを検出しない場合、エラーの処理で最もよく使用されます。 しかし、このプロパティはルーチンにもあります。たとえば、タスクが「昼食まで掘る、トイレのシャベル」と言う場合、トイレにはO_Oシャベルはありません。
      
      
   2. 修正しない-請負業者は作業を行いたくない。 おそらく既に推測されているように、プロパティの名前はバグトラッカーの大きな遺産です。 したがって、バグを修正するときに、これがバグではないことが実行者に確信している場合に使用されます。 チェーンの人気プログラムのバグトラッカーでは、「開く」->「修正しない」->「再オープンする」->「修正しない」->「クローズする」->「再オープンする」-> ...
      
      
   3. 複製 -請負業者は、このタスクが既に完了した、または完了しているだけの別のタスクを複製すると信じています。 したがって、顧客はこれに同意する場合があります-同意しない場合があります。
      
      
   4. 待機 -請負業者は何かを行ったため、外部イベントの発生を待つ必要があります。たとえば、フリーランサーとしての仕事の完了や、休暇からの会計士の帰還などです。 原則として、顧客はこのような状態で何らかの形でタスクに応答する必要はありません。請負業者自身が予想されるイベントの発生を追跡し、さらなるアクションを実行する必要があります。 しかし、そのようなタスクの制御は害になりません-実行者が何かを待っていることを忘れた場合はどうなりますか？ :)
      
      
   
   
   

Jiraのドキュメントの詳細に確実に埋め込まれたタスクの概略図。 「進行中」のステータスに注意してください-エグゼキュータに多くのタスクがある場合によく使用され、経営者が現在どのタスクを実行しているかを知ることが重要です。 実際には、ほとんどの場合、この条件は使用できません。

フィルターは私たちのすべてです

大きくて深刻なプロジェクトのタスク管理システムを見ると、次のようになります。



この線形リスト内のタスクの総数に注意してください。 もちろん、Jiraはすべてを表示しますが、「オープンのみ」のフィルターをインストールしても、3万から6に変更しても根本的に何も変わりません。 多くの開発者は、タスク管理システムを初めて使用してそのようなタスクリストを見ると、「ツリービューでどのように表示されるか」に興味を持ちます。 一見、ファイルシステムからツリーアーキテクチャをコピーするというアイデアは成功しているようです。親タスク、サブタスクがあります。一部のシステムは、そのような階層を実装し、「サブタスクの無制限の深さ」を競争上の主な利点の1つとして宣言しています。 しかし、jira、redmine、tracなどの一般的なシステムでは、原則として「タスク-サブタスク」関係のみがあり、めったに使用されませんか？ ユーザーがキロメートルタスクリストを使用する理由と方法

この質問に対する答えは、一言で言えばフィルターです。 ほとんどのタスク管理システムに実装されているフィルターを使用すると、1つの簡単なことができます-特定の要求によってタスクをグループ化します。 たとえば、「レポーターを使用してタスクを解決し、ステータスが解決された」場合、請負業者が顧客として報告したタスクがすぐに表示され、何らかのアクションを実行する必要があります。 フィルターの大きな利点は、タスク管理システムの各ユーザーが自分に都合の良い形式でタスクを表示する独自のフィルターセットを構成できることです。 たとえば、私の部署の従業員の仕事を示すJira Clientのフィルターフラグメント：

役に立つヒント

• システムに「解決済み」タスクのステータスに必要なプロパティがありませんか？ ほとんどのシステムでは、独自のプロパティを追加できます。 たとえば、Jiraは問題なくWaitプロパティを追加しました。
  
  
• タスクの実行を制御するには、特定のタスクに費やされた時間を示すために、一日の終わりに「ログ作業」を行うと便利です。 ほとんどのタスク管理システムでは、これらのログのレポートが許可されているため、多くの人が恐れている「私たちがしたことの月次レポート」は2回クリックするだけで編集できます。
  
  
• 「ログ作業」は、あなたが顧客でもタスクの実行者でもない場合でも実行できます。 多くのシステムは、複数のアーティストの任命をサポートしていませんが、タスクに実際に取り組んだ人なら誰でも「ログ作業」を行うことができるため、これは問題ではありません。
  
  
• タスクの状態を変更する場合、顧客または請負業者を変更することは推奨されません。 多くのユーザーは、タスクの状態を「解決」に設定するときに誤って担当者をReporterと同じ人にインストールします。 これにより、上記の作業ロジックが破壊され、あらゆる方法でタスクを使用した「ワンクリック」作業が妨げられます。
  
  
• 私は議論の結果としてここに何かを追加したいと思います:)
  
  

シムの締めくくり。 この重要で非常に単純なトピックではなく、誰かが何か言いたいことがあれば、コメントでそれを聞いて喜んでそれを議論しようとします。