ワークフローによって得られる充実感と利点

敬遠されがちな「プロセス」にきちんと向き合いましょう。確立されたワークフローなしでは何も達成できません。

Dan Radigan Dan Radigan

Every software team has a process they use to complete work. Normalizing that process–i.e., establishing it as a workflow–makes it clearly structured and repeatable, which, in turn, makes it scalable. At Atlassian, we take an iterative approach to workflow management because it helps us meet our goals faster and exemplifies our team culture. We are experts in agile workflow management (if we do say so ourselves), and we want to help you become experts too.

まずはシンプルなものから、今すぐ始めましょう

チームにワークフローを実装するときには、必ずシンプルなものから始めましょう。数週間かけて過剰なエンジニアリングを行いたいという誘惑と戦ってください。複雑すぎるワークフローは理解しにくく、採用も適応も困難です。ソフトウェアチームには次の基本的なワークフロー状態を使用することをお勧めします。

To Do

Work that has not been started

In Progress

Work that is actively being looked at by the team.

コードレビュー

Work that is completed, but awaiting review.

Done

Work that is completely finished and meets the team's definition of done.

課題管理システムでは、これらのステータスの間で遷移します。ワークフローはこれらの遷移によって構造化されています。 

Agile workflow | Atlassian agile coach

ソフトウェアチームによっては、ステータスをより正確に把握するために追加の状態をワークフローに設定することもあります。

Awaiting QA

Work that has been implemented, but is still waiting for a tester review (see our article on agile testing for more details).

Ready to merge

Code that has been reviewed and is ready to merge into the master or release branch.

ワークフローの状態にそれぞれ異なるメンバーが対応する必要はありません。アジャイルチームが成熟するにつれ、開発者が対応する作業が増加します (デザインからデリバリーまで)。自律性のあるチームがさまざまな作業を行えることは、アジリティの証です。

チームのふりかえりでそれぞれの問題点について話し合いましょう。チームの価値観はプロジェクトやテクノロジースタック、作業方法によって少しずつ異なることに注意してください。だからこそ、柔軟なワークフロー設定が可能な課題管理システムを選択することが重要なのです。多くのチームがそれぞれの作業スタイルをあきらめて特定のツールセットに合わせていては、全員が不満を募らせることになります。チームメンバーはそのツールの使用を避けるようになり、チーム全体に不満がたまって、多くの場合は混乱が生じます。士気が低下すると、生産性が低下します。この二重苦はなんとしてでも避けたいものです。  

アジャイルを初めて導入する、または部門横断型のスキルを持たないチームのワークフローは、「小さなウォーターフォール」になりがちです。例えば、デザインは模型を使った作業項目から始まります。開発で実装し、テストで品質を確認します。前の状態が完了しないと、次の状態に進むことはできません。このお馴染みの手法がウォーターフォールです。しかし、アジャイルワークフローによってチームを解放すれば、開発はもっと簡単になります。 

ワークフローの最適化

基本ワークフローに慣れ、カスタマイズできるようになったら、チームのプロセスの作業タイプに合わせてステータスを作成しましょう。発案、デザイン、開発、コードレビュー、テストは機能的に異なり、個々のステータスとすることができます。 作業のフェーズがはっきるとわかるような無駄のない一連のステータスを目指してください。

プロジェクトステータスを他の部門と共有することもできます。ワークフローを構築するときには、レポートすべき重要な指標と、チームメンバー以外にとっての関心事項について考えましょう。例えば、適切にデザインされたワークフローは次の疑問に対する答えをもたらします。

  • チームはどのような作業を完了したか?
  • 作業のバックログは増加しているか、それともチームのペースと揃っているか?
  • 各ステータスにどれくらいの項目があるか?
  • チームの足を引っ張っているボトルネックはあるか?
  • 平均的なタスクを完了するのにどれくらい時間がかかっているか?
  • 初回で品質基準に合格しなかった作業項目はどれくらいあったか?

The next step in optimizing the workflow is to ensure a steady stream of work through the workflow. Work-in-progress (WIP) limits dictate a minimum and maximum number of issues in a particular state of the workflow, making sure each state in the workflow has enough work to keep the team fully utilized, but not so much that they lose focus because they're juggling priorities. Enforcing work-in-progress limits will quickly show which processes in the team are slowing down the overall work through the pipeline. As the team learns to optimize around its work-in-progress limits, throughput will increase. (See the article on WIP limits for more details.) 

ワークフローの拡張に関する課題

複数のアジャイルチームを展開している組織では、ワークフローに関する特別な課題があります。チームは多くの場合、固有のプロセスや文化を反映させてワークフローを最適化しようとします。それは当然のことです。しかし、さまざまなチームが異なるプロセスを使用して同じプロジェクトに取り組む場合には悩みの種となります。

Agile teams that work together can benefit from sharing the same workflow. Using the same workflow can make transitioning work between agile teams easier, because they use the same conventions for defining and delivering work. Creating a common process usually involves some give and take from both teams. That's good! They'll learn from one another and come out with a better workflow in the end. 

pro tip

With Jira Software, Atlassian's issue tracker, teams can share workflows but have different representations of the process on their agile board. This ability leads to flexible visualization options without sacrificing the shared asset of workflow. 

どのようなワークフローであっても、ワークフロー開発プロセスもアジャイルである必要があります。時折ふりかえりで話し合い、チームの文化や構成の変更に伴って適応させましょう。