さらに、リソースよりも常に多くのタスクがあります。 すべての顧客は、できるだけ早くタスクを実行する必要があり、誰もがタスクの優先順位を上げます。 開発者がこれらの緊急タスクのどれが最も緊急であるかを判断するのに時間がかかりすぎました。 これは開発を大きく妨げ、何かをしなければなりませんでした。 すべての開発者が、今日行う必要のあるタスクと、明日、来週、毎月まで延期できるタスクを確実に把握するため。
最終的に、私たちの問題のほとんどはアジャイルボードとスクラムの助けを借りて解決されましたが、私たちはすぐにではなく、段階的にこれに取り組みました。
最初にフィルターを取得しました。 多くの場合、マネージャーが最初にタスクが非常に緊急であると主張する場合、すべてが本番で壊れた場合などがあります。 そして、この問題が何人のユーザーに影響を与えるかを考え始めると、3人が1日あたりこの特定の機能を使用しており、バグが毎回再現されるわけではありません。 したがって、問題は1か月で解決できます。 また、タスクをレイアウト（色補正、インデントなど）とインフラストラクチャのみに影響するタスクに分割しました。これらのソリューションには、バックエンド開発者が関与する必要もあります。
すべてのコンポーネントと呼びました。 どのタスクをいつ実行するかがより明確になりました。 フィルターのおかげで、開発者に毎日かかっているタスクの数を約20に減らすことができました。それらをナビゲートするのがはるかに簡単になりました。
しかし、それでも可視性に問題がありました。 そして、最初にダッシュボードの助けを借りてそれを解決しようとしました。 ソリューションは理想とはほど遠いものでした。 まず第一に、ダッシュボードには双方向性が欠けていました。 たとえば、タスクのステータスを変更したり、実行者を変更したりするには、新しいページを開く必要がありました。 JIRAはJIRAです。
これらのすべての欠陥にもかかわらず、我々が正しい方向に向かっていることは明らかであり、さらに先へ進む必要があります。 そして、アジャイルボードを試すことにしました。 スクラムとかんばんを実行できるすばらしいGreen HopperプラグインをJIRAに既にインストールしています。
ウィキペディアが言うように、スクラムは柔軟なソフトウェア開発のための情報システムの開発に積極的に使用されているプロジェクト管理方法論です。 スクラムは、開発プロセスの品質管理を明確に強調しています。
これを説明する非常に良い写真もあります。
プロジェクトには特定の数のタスクがあり、スプリントのための予備フィルタリングが必要です。 スプリントは、新しい機能を導入してバグを修正する繰り返しの開発プロセスです。
職場を準備する
私たちは小さなことから始めました-JIRAで物事を整理します。 多数のコンポーネントとバージョンの代わりに、次のように残しました。
- コンポーネント「レイアウト：インフラストラクチャ」;
- コンポーネント「レイアウト：インターフェイス」;
- オプションの製品または技術コンポーネント。例：プラットフォーム-iOS、製品-地下室。
- バックログバージョン。
- 起動用の製品バージョン。
さらに、書き込みタスクとレイアウトタスクに関する特定のルールセットを導入しました。
- 短く明確な見出し、動詞でより良い。
- 必要なすべてのデータを使用して、できれば外部ソースを参照せずに、タスクの最小限の必要かつ明確な説明。
- コンポーネントとバージョンを示す必要があります
- タスクは測定可能で有限です。
- 「新しい画像インターフェイスを起動する」などの巨大なペアレンタルタスクを拒否します。
- 親タスクは、1週間で実行できるタスクに使用されます。
- 親タスクのすべてのサブタスクは、実際にはタスクの分解です。
- タスクが相互に関連している場合、タスクをリンクするメカニズムを使用します。
アジャイルボードのカスタマイズ
まず、タイプを選択する必要があります：スクラムまたはかんばん。
次に、データを入力する必要があります。
アジャイルボードのデータソースであるフィルターを作成しました。 このフィルタは、「バックログ」のバージョンが付加されたレイアウトコンポーネントを含む設計タスクを選択します。 バックログは、次のスプリントでこのタスクを実行する必要があることを意味します。
タスクのワークフローに従って、新しい列を追加し、それらに適切なステータスを割り当てる必要があります。
デフォルトでは、3つの列があります：実行中、実行中、完了。 それらがもっとあります：
- to do-現在のスプリントで実行しなければならないタスク。
- 進行中-現在実行中のタスク。
- レビュー時-現在実装をレビューしているタスク。
- コミット済み-既にプログラムされているが、テストの準備が整っていないタスク。
- テスト-テストの準備ができているタスク、または現在テスト中のタスク。
- done-完了したタスク。
最後の2つの列は1つに結合できます。 たとえば、現在、プロジェクトの1つに「テスト」列はありませんが、すぐに「完了」しました。
タスクのグループ化を設定します。 デフォルトでは、担当者ごとにグループ化されています。 私たちにぴったりでした。
バグと機能を視覚的に区別できるように、カードの色を調整します。
クイックフィルターを設定します。 非常に便利なもの。 多くのタスクがある場合、さまざまなパラメーターでタスクをすばやくフィルタリングできます。 フィルターを組み合わせることができます。
見積もり、営業日、および問題の詳細ビューはまだ使用していません。
- 見積りは、将来の計画を立てるために、計画段階でタスクを評価するために必要です。
- 営業日を使用すると、プロジェクトの営業日を設定できます。
- 問題の詳細ビューは、タスクのプレビューに追加のフィールドを表示するのに役立ちます。
アジャイルボードの使用
1週間のスプリントを取りました。 したがって、最初のプロジェクトの同期では、1週間タスクを募集し、仕事に持っていきます。 これは[プラン]タブで発生します。
スプリントを埋めるには2つの方法があります。
- ブロックを引き伸ばし、バックログから必要なタスクをキャプチャするだけです。
- ドラッグアンドドロップタスクをバックログからスプリントにドラッグします。
バックログ内のタスクは、簡単なドラッグアンドドロップで好きなように並べ替えることができます。 同期について会うまで、私たちはこれをプロジェクトマネージャーと週に1回行います。
タスクを記入するとき、あなたはどんなタスクでも突くことができます、そして、タスクの説明は右の列に現れます：
スプリントがいっぱいになると、開始します。 次に、[作業]タブで作業できます。
これは非常にクールなことであり、すべてのタスクのステータスと従業員の雇用を追跡できます。 パンツのグループ化、アバター、色の区別により、このプロセスは可能な限り便利で楽しいものになります。
このモードでは、タスクの詳細な説明を表示したり、ドラッグアンドドロップ（進行中からレビュー中にドラッグ）でタスクのステータスを変更したりすることもできます。 このタブは、週の半ばに同期して表示され、タスクの進捗状況が議論されます。
新しい週の初めに、スプリントを終了し、[レポート]タブに移動します。 この場合、実行したタスクの数と、実行していないタスクの数がすぐにわかります。 未完了のタスクはバックログの先頭になり、最初の次のスプリントで実行されます。 さらに、次のようないくつかのレポートがあります。
- スプリントレポート;
- 管理図。
2番目のグラフは、終了するまでの平均作業時間を示しています。 グラフは、サージがあることを示しています。
これは、長時間実行されるパフォーマンス測定タスクです。 具体的には、このタスクでは-すべては問題ありませんが、他のタスクでは-問題の定式化が正しくないこと、および/または分解が必要であることを明確に示します。 このグラフと各タスクの[スプリント]フィールドを使用して、タスクの完了期限を追跡し、タスクがフリーズした場合にアクションを実行できます。
私たちに続いて、他のいくつかのYandexサービスのチームがそのようなタスク計画形式に切り替えました。 すべての大規模な開発チームにこのアプローチをお勧めします。 タスクのソースが複数あり、他のチームのプログラマーをソリューションに参加させる必要がある場合、私たちの意見では、アジャイルボードが最適な選択肢です。