この記事は、ソフトウェア開発グループのRedmineに基づいてタスク追跡プロセスを自動化することを最初に決定した人々に役立つと思います。 記事では、このプロセスがどのように組織化されているか、導入したタスクの新しいフィールド、およびこれらのフィールドが解決する問題について説明します。 この記事は幅広い人々に役立つと思う、私の意見では、タスクのライフサイクルを設定することは、この仕事は「明白な-明白ではない」というスローガンの下にある。
もっと！ 私たちは大規模な企業環境で働いており、主に内部顧客（およびいくつかあります）を対象としており、この状況はライフサイクルに反映されています。
始めましょう。
それはすべて、美しい瞬間にタスクが表示され、そのタスクが表示された後、そのタスクが論理的に作成者に落ち着くという事実から始まります。 なぜ？！ タスクには、それ以上の実行を担当する従業員、常にタスクの速度を落としている従業員、「ボール」側の従業員、および「このボールを別のボールに渡す」、サッカーパスなど。 時々、この人はすべきではありません。 たとえば、タスクが閉じられたときにタスクに対してアクションを実行する必要がなくなったとき。
タスクを作成するユーザーに入力するためにどのような情報を要求しますか？
もちろん、これはタスクの種類、タイトル、説明ですが、次のようなものでもあります。
- 「顧客」-このタスクに興味があり、その実装を要求した従業員。 その後、作業結果を確認し、パフォーマンスを評価します。
- 「目標」は、タスクが解決しなければならない究極の目標です。 すぐにこの分野にたどり着きませんでした。 一方で、何をすべきかを説明する詳細な説明がある場合、なぜ目標が必要なのでしょうか？！ しかし、考えてみると、目標はまったく異なります。 タスクの説明は、目標を達成するために何をする必要があるかを示しています。目標が固定されていない場合、タスクを完了する過程で目標が失われる可能性があります。
たとえば、目標は次のとおりです。
「任意の数式に基づいてRFPの基本部分を計算する可能性を実現する。」
また、説明には、目標を達成するためのより詳細な主要な手順と要件があります。 たとえば、「MathMLライブラリの接続、式を計算期間に関連付ける機能」など。
一般に、説明は一般にパフォーマーのスキルに依存する場合があり、場合によっては数行である場合があります（パフォーマーとの良好なコミュニケーションがある場合、よく働いてお互いをよく理解します）。
新しいタスクはどこに行くことができますか？
ほとんどの場合、優先度の高いタスクを持っていることが多いため、プランに送信されます（これは、クライアントの方向性や、顧客が将来について考えたくないということです）。
ただし、タスクは優先順位ではなく、キュー（または必要に応じてバックログ）に移動できます。
タスクが計画に送信された場合、次のフィールドに入力するように求められます。
- 「時間の見積もり」-開発マネージャーによると、この作業にはプログラマーの純粋な時間がどれだけかかりますか。 この値を正確に決定することはほとんど不可能です。 ただし、おおよその判断が必要です。 この時間は実際には問題の価格であるため、つまり これは時間ではなく、これは顧客が開発チームからこのタスクの実行を購入するためのお金です。
- 開始日と期日。 ここではすべてが論理的なようです。 また、プログラマーが期限までにタスクを不当に浪費する場合、これはGPに影響します。
- 「ステージ」-タスクを完了する予定の同じプラン、バージョン、またはスプリント。 私たちの段階は月と一致します。 ステージとパフォーマーによって、作業の進行を制御します。
- 「誰に」-タスクの実行を担当する従業員。
計画の設定時に、「誰」フィールドの値が「実行者」タスクフィールドに常にコピーされます。 遅かれ早かれ、タスクは従業員に実行の責任を任せますが、実行の責任はなくなるべきではありません。したがって、完了した各タスクは常にエグゼキューターを保持します。
そして、キューにある場合、フィールドが少なくなります：
- 「優先度」。これにより、後でキューから優先度の高いタスクを最初に描画します。
- 「時間の見積もり」。これにより、将来の計画に適合するものとそうでないものを決定できます。
そしてもちろん、キューからのタスクは常に計画に入ることができます。または、タスクを閉じて「Closed」のステータスを取得することもできます。 ステータス「Closed」は、タスクで実行されたタスクがないという点で「Completed」と根本的に異なります。
パフォーマーはタスクで何ができますか？
議論の余地はありますが、生命機能の権利があります。「開始」と「一時停止」で、それぞれタスクのステータスを「予定」から「作業中」に、またはその逆に変更します。 小さなグループでは、この関数は特に根を張らず、一部の大きなグループでは根を引きました。 プログラマが多く、彼らが現在実行しているタスクをマークしている場合、アーティストが現在作業しているタスクのスライスを作成できます（一種の「進行中の作業」）。
ほとんどすべてのステータスで、その時点でタスクが作成者、マネージャー、顧客などから情報を要求できる従業員。 もちろん、出演者も例外ではありません。
もちろん、請負業者の主な機能は、確認用のタスクと同じ名前の「確認用」ボタンを送信する機能です。 ボタンはタスクをテスターに送信します。テスターはプログラマーによって完了する必要があります。
- チェック方法ボックスは驚くほどシンプルで便利なものです。 スクラムに関する本で初めてこの分野について読んだ。 検証のためにタスクを引き渡すプログラマーは、新しい機能を利用するために行う必要があることをテスターとエンドカスタマーに書き込む必要があります：リポジトリからどのブランチを取るか、どの設定をするか、インターフェースのどこに行くか、何をするか。 その結果、テスター、顧客、チームリーダーからの多くの不要な質問がなくなります。
- フィールド「何をするか」。 プログラマは、タスクの説明に最初に書かれていることを常に行うとは限りません。 時には何か特別なことをすることもありますし、時にはプログラマーに実行の自由を与えることもあります。 このフィールドを通じて、プログラマーはマネージャー、顧客、テスターに、実行の結果として正確に何をしたかを通知します。 とりわけ、顧客によるタスクの評価に基づく金銭的インセンティブを導入しており、この分野ではプログラマーはタスクの詳細に顧客の注意をさらに引き付けることができ、評価の向上につながります。
- 「誰」フィールドは、タスクをテストするテスターです。
- チェックマーク「テストサーバーにタスクを投稿しました。」 このフィールドに入力しないと、確認のためにタスクを送信できません。 テスターはタスクをチェックするための独自のテストサーバーを持っていますが、検証のためにタスクをリリースする前に、プログラマーはテストサーバー上でタスクを正常に動作させる必要があります。 まず、リーダーがタスクの品質を評価できるようにするために、テストサーバーにタスクを配置したり、自分でタスクを実行したりする必要はありません。
検証のためにタスクを送信すると、そのステータスは論理的に「検証中」に変わります。 これで、テスターはタスクをさらに実行する責任を負います。
テスターはタスクで何ができますか？
それは理解できることです。修正のためにタスクを送信するか（[元に戻す]ボタン）、実稼働サーバーにさらにスキップします（[チェック済み]ボタン）。
また、インスペクター（および同じ名前のボタン）を変更することもできます。また、グループでは、タスクが（他のグループではなく）リーダーを介して2回目の検査に合格するように管理上修正されています。
頭を確認する必要がある理由：
- まず、これは2回目のチェックであり、2回目のチェックが必要になることはめったにありません。
- 第二に、デザインとユーザビリティに関する完璧主義に苦しんでいます。 そして、インターフェイスをより調和させることができると思うと、私はそれをすべてやりすぎますが、作業はすでに作業中のものに達しました。
- 第三に、プロダクションサーバーでタスクをレイアウトするには、関係者の特定のグループへの通知が必要になる場合があり、通知の必要性についてはヘッドのみが決定できます。
いずれにせよ、ステータスが「チェック中」から次のステータス「稼働中」への移行には、いくつかのフィールドへの入力が伴います。
- 「検証検証」および「評価検証の説明」。 評価では、テスターまたはマネージャーを配置できます。 この評価により、プログラマのGPなどに影響を与えることができます。
- 「計算の希望日。」 本番サーバーでタスクをレイアウトするのが素晴らしい場合（別の人がグループ内のレイアウトを担当します）。
- 「警告が必要です。」 新しい機能の利用可能性などについて従業員に通知する必要がありますか。 必要に応じて、テスターはレイアウトする前にこれを行う必要があります。
- 「プレゼンテーション」。 タスクが顧客に提示されるとき（これは興味深い手順ですが、別の記事で説明します）。
タスクを作業環境に送信する前にチェックするためのチェックマークがまだたくさんあります。 それらをリストしますが、突然誰かに役立つでしょう：
- RakMiniProfilerを使用して、再帰的および循環的なSQLクエリがないことを確認しました。
- さまざまなブラウザー解像度でレイアウトを確認しました。
- 最新バージョン（Chrome、Firefox、Opera、Intenet Explorer）のさまざまなブラウザーでレイアウトとパフォーマンスを確認しました。
- さまざまなデータベース（MS SQLサーバー、MariaDB、PostgreeSQL）でプラグインのパフォーマンスを確認しました。
- 基本的なルール「Redmineプラグインを書くための基本的なルール」に準拠しているかどうかの割り当ての実行を確認しました。
- 従業員に保有を通知する必要性を分析しました。 タスクでのアラートの必要性に注意してください。
- 指示内の情報を更新する必要性を分析しました（必要に応じて、タスクを開始しました）。
- タスクはテストサーバーに投稿されます。
- 自動テストを作成するためのタスクが開始されました。
これは簡単な検証手順ではありません。
Redmine管理者はタスクで何ができますか？
彼はそれを動作中のサーバーに置くことができ、それによってタスクを「チェック用」ステータスから「使用中」ステータスに移行できます。 タスクが顧客に割り当てられます。
顧客はタスクで何ができますか？
顧客はジョブを受け入れる場合と受け入れない場合があります。 それが受け入れられない場合、彼はコメントを書くことによって再検査のためにテスターにタスクを送ります。 受け入れられたら、「完了」ボタンを押して、実装の評価と評価の説明を添付します。 これらの見積もりは、請負業者と管理者の給与に影響します。
全体として、タスクライフサイクルのこのような図を取得します。
記事で説明されているよりもはるかに多くのステータス間の遷移があります。 ほとんどの場合、これらは管理者がテスターやプログラマーを待たずに次の状態にタスクを転送する必要がある場合、マネージャーの特権的な移行です。
もちろん、これがタスクのライフサイクルで私たちが持っているすべてではありませんが、私がすべてについて書いたなら、おそらく小さな本が判明したでしょう。
あなたの国でどのライフサイクルが使用されているかについての情報を共有していただければ幸いです。 タスクを追跡するときに、どのフィールドに記入するように従業員に依頼しますか？その理由は？
最後まで読んでくれたみんなに感謝します。