ステータスの簡素化

---

ここで大きな推測をしていますが、あなたのチームは製品要件を保持するために Jira を使用していると思いますか? 65,000 を超える企業が世界中で使用しているため、私はただの予想にすぎません。 Jira は素晴らしいですが、その素晴らしい機能のすべてについて、カスタマイズ可能なワークフローについて説明します。

製品バックログの各 PBI にはライフサイクルがあります。作成され、おそらく作業され、完成します。シンプルですね。私がこれまで一緒に仕事をしたすべてのチームは、Jira ワークフローを使用して PBI ライフサイクルをモデル化しており、非常に効果的です。次に例を示します。

開発チームは、作業が完了するまで各 PBI のステータスを移動します。しかし、作業が「オープン」にあるチーム メンバーが常に存在し、デイリー スクラムで「ああ、ごめんなさい、ほぼ完了です。ステータスを変更していないだけです」とアナウンスしていることに気づいたことはありませんか?ステータスを最新に保っていないのは彼らのせいですか？それとも、プロセスが複雑すぎるだけですか?

ワークフローの複雑さは本当に価値がありますか?

これに答えるには、スプリント バックログの目的を考慮する必要があります。これは、スプリント ゴールを達成するための開発チームの予測計画を示すアーティファクトです。毎日検査されます (必要に応じて調整されます)。重要なのは、透明であることです。私の経験では、開発チームがスプリント バックログを検査するとき、彼らは「ああ、ちょうどその作業を統合しようとしているところだ」とか「いや、リリース前にもう少し手動テストが必要だ」などの話をします。詳細レベルでは、複雑な Jira ワークフロー ステータスが誰のためのものかを検討してください。あなたのチームに聞いてください！結局のところ、それは彼らのプロセスです。

スクラム チームにこれを尋ねたところ、答えは…でした。 *肩をすくめる*.いくつかの 5 つの理由の後、私たちはこれを打ち破りました *肩をすくめる* 3つのことまで：

• 開発チームは複雑なステータスを必要としません。彼らは、PBI の詳細なステータスを知っています。
• プロダクト オーナーもステータスを使用しませんでした。彼らが知りたかったのは、スプリントの目標が達成される可能性があるかどうかだけでした。
• 複雑なステータスの利点は外部にありました (プロジェクト マネージャーとリリース マネージャーの「補完的な」役割)。

スクラムの愛好家は、このガイドが PBI が移行する必要がある「状態」を明示的に参照していないことを知っているでしょう (これは方法論ではなくフレームワークであるためです 😊)。しかし、いくつかは暗示されていますか？私の考えでは、はい！

まず、「完了」 – 完了の定義を満たす PBI は「完了」です。次に、作成されたばかりの PBI は「To Do」またはそのような用語です。そして第三に、単に「To Do」でも「Done」でもない PBI は….Doing?進行中？それらを何と呼びたいとしても、私たちの Jira ワークフローは単に「To Do」、「In Progress」、および「Done」でしょうか?これを決定するのは、スクラム マスターである私ではありません。プロセスはスクラム チームが所有します。しかし、この単純化は、チームが参照するためのよりシンプルで共通の言語を提供するため、役立つと思います。

あなたが考えているなら、私のチームはより複雑なワークフローを使用していますが、それは私たちにとってうまくいきます...それは素晴らしいです!プロセスが機能する場合は、クラッキング!しかし、この複雑さが誰の役に立っているのか自問してみてください。PBI の進捗状況を知る必要がある人々は、すでに知っているのでしょうか?コミュニケーションを複雑なステータスに置き換えようとしていますか?複雑さに価値はありますか？そうでない場合は、チームに検討させ、ソリューションを中心にどのように自己組織化したいかを確認します。

考えてみてください。すべてがどれほど簡単でしょうか。

この単純なワークフローには欠点がありますか?以下は、私のチームが私に提出した質問と、言い換えた回答です。

外部要因によって PBI がブロックされた場合はどうなりますか?

公正な質問。ブロック済みのステータスを追加できます。しかし、PBI が別のチームによってブロックされた場合、それはまだ進行中ですか?あなたはまだその進歩に関わっていますか？では、「進行中」のままでよいのでしょうか?

テストのために PBI を渡す必要がある場合はどうなりますか?

スクラムは、クロスファンクショナル チームによって採用されるフレームワークです。開発チームは、PBI を完了にするためのすべての作業を担当します。定期的に他のチームに仕事を任せていますか?なぜ？

何年にもわたって「進行中」である場合、より大きな PBI で進行中であることをどのように示すことができますか?

プロダクトオーナーとのコミュニケーション。進展が見られることを PO が認識している場合、PO の責任は、関係者を最新の状態に保つことです。進歩を見せていないことにプレッシャーを感じている場合、チームは信頼をどのようにモデル化していると感じていますか?それとも、このことから学び、PBI をより小さなチャンクに分解できますか?

この記事は残しておきます。この簡素化がすべての人に気に入られるわけではないことは承知していますが、ここから 1 つ取り除けば、複雑な Jira ワークフローは、古き良き時代の口頭でのコミュニケーションと透明性に取って代わるべきではないことを覚えておいてください。

タグ: ジラ, スクラム, ワークフロー