スプリントを台無しにする可能性のある 4 つの不健全なプロセス

前回の記事では、最終的に (遅かれ早かれ) デリバリーの失敗につながる、スクラム チーム内での不十分な習慣についての議論を始めました。この記事では、このトピックをもう一度拡張して、チーム内の機能プロセスに焦点を当てたいと思います。

これらはチームの技術的な優秀さと同様に重要です。たとえ内部の人々がこれから提供しようとしている仕事に関して非常に熟練しているとしても、完璧を目指す努力が台無しになる可能性のある領域が依然として存在します。そして、プロジェクト管理の決定と、目的に合ったプロセスでチームにサービスを提供し、明確な意図と予測可能なアクティビティでチームをサポートする能力は、直接の責任であるため、それは彼らの責任ではありません。

独特のスキルセットを備えた高度に分離されたチーム

チームに、完全に独立しており、約束を守り、スプリント終了直前に合意されたスプリント コンテンツを配信する能力を備えた熟練した開発者がいると想像してください。このような完璧なシナリオ (いずれにせよ、実現する可能性は非常に低いですが) であっても、チーム メンバー間でスキルが厳密に分離されている場合、チームは (増え続ける) バックログ機能に対応するのに問題が生じます。

いくつかの例

• チームには、自動化されたパイプラインに変更を加えたり、プラットフォーム内のサービスを管理したりできる DevOps エンジニアが 1 人か 2 人いますが、チームの残りのメンバーはそのようなことについてまったく知りません。そして、スクラムセレモニーでそれらのストーリーを改良のような形で議論すると、チームの大部分が参加せずに会議を保留することになり、時間の無駄になります。またその逆も同様です。DevOps 開発者は、残りの機能指向のストーリーには興味がありません。会議の時間もほとんど無駄になってしまいます。
• チーム全体に対して 1 人のデータベース エキスパートがいます。チームが開発しているシステム内のデータ ソリューションの複雑さと使用状況によっては、この人は、特に優先順位を考慮した場合、すぐに完了する見込みのないストーリーで常に過負荷になる可能性があります。さらに悪いことに、他のストーリーもデータベース ストーリーによって提供されるデータ ソースに依存しているため、待機する必要があります。
• 特定の製品が主にバックエンド開発を指向している場合、万が一に備えてフロントエンド開発者だけがそこにいます (いずれにしても、UI アプリケーションにさえ小さな変更が必要になる場合があるため)。その場合、繰り返しになりますが、このチームメンバーの知識はフロントエンドのみに限定されており、他は何も重要ではないため、スクラムセレモニーのほとんどはこのチームメンバーにとって時間の無駄です。

結論はどこにあるのか

上記のいずれの場合でも、結果として人々は時間を無駄にするか、あるいはバックログの需要に追いつくことができなくなります。これらは、チームの残りのメンバーが次のストーリーの作業を開始するのを妨げたり、スプリント内で利用されない時間が多すぎるため、スクラム チームの全体的な効率を事実上低下させたりします。

ただし、チームにはまだこれだけの数の開発者がいます。チーム内の人々が、特定のスキルセットに偏りすぎているという理由だけで、一部のストーリーを引き受けることができないことは、外部からは見えません (暴露されたくなくても)。そのため、たとえ彼らの能力がそれを可能にし、ストーリーの優先順位も同様にそれを優先したとしても、他のチームメンバーのストーリーを手伝うことはできません。

プロダクトオーナーは、各ストーリーに何人で作業できるか、また、より多くの同様のストーリーが同時にスプリントに持ち込まれるかどうかを常に念頭に置く必要があるため、チームにとって有意義なスプリント コンテンツを作成することさえ困難です。 、実際にそれらのストーリーに取り組む可能性のある人がいたとしても、最終的にはチームのキャパシティがオーバーフローしますが、彼らはそれらのストーリーを開始するためのスキルセットを持っていません。

ジレンマを解決する

これは解決すべきジレンマであり、プロジェクト マネージャーは選択するルートを認識する必要があります。具体的には、次のいずれかを選択します。

• 幅広いコンテンツに取り組むことができるフルスタック開発者が多数いますが、多くのトピックの専門家ではありません。したがって、広くはできますが、深くはできません。そうすれば、納品は早く進む可能性がありますが、品質が低下する可能性があります。
• 各テクノロジーに専任の専門家を配置しますが、その制限を受け入れて、より適切な印刷コンテンツの開発に熱心に取り組んでいます。そうすれば、人々は深く掘り下げて素晴らしいストーリーを構築できるようになりますが、ストーリーには順番にアプローチする必要があるため、配信までに時間がかかります。

弱いプロダクトオーナー

これは必ずしも定義上「プロセスの問題」というわけではありませんが、私がそのように扱っているのは、確かなストーリーの作成が、チームが強固で開発チームと互換性を持つことを望むべきプロセスとして理解できるからです。

私が「弱い」という意味で言っているのは、個人の知識特性を指す必要はなく、開発者が理解でき、製品ロードマップの観点から見て明確に意味のあるストーリーをチームに提供する製品所有者の能力を指します。これらは両方とも、スクラム チームを成功させるために非常に重要です。

開発者が目的、機能的価値、または技術的な期待を明確に理解するための詳細がストーリーに欠けている場合、基本的に 2 つのシナリオが発生する可能性があります。

• 開発者は、製品所有者が実際に望んでいたものとは異なるものを構築することになります。ほとんどのプロダクトオーナーはストーリーの進行状況をこれほど詳細なレベルで追跡する能力を持っておらず、ほとんどの PO は物事が (魔法のように) 起こることをただ期待しているだけであるため、スプリント自体の間にそれを把握することさえ困難です。
• 開発者は、ストーリーを構築し始めるのではなく、ストーリーを明確にして何度も議論することに非常に多くの時間を費やすことになります。これには、多くの追加の電話、繰り返しの合意、およびスプリント後期フェーズへの作業の延期が含まれます。ストーリーの元の見積もりがもはや正確であるとは考えられない点に達し、ストーリーはスプリント内で終了することができず、次のスプリントに持ち込まれます。最悪の場合、後続のスプリントでも状況が繰り返されます。

内省の時間

通常、これを認めるのは難しいですが、製品所有者は時間を見つけて熟考し、作成されたバックログのストーリーを確認し、最終的には製品ロードマップのビジョンと比較する必要があります。これら 2 つの間にまだ合理的な関連性がある場合、つまりロードマップがある場合は、それを製品ロードマップのビジョンと比較する必要があります。全然。そうでない場合は、それを解決するのが最初です。場合によっては、解決策は、プロダクト所有者がチームから遠すぎ、自分自身の目標からも遠すぎることを認めることです。

このような場合、チームのプロダクトオーナー部分を解決する必要があります。少なくとも、ビジネスの内容よりもチームの内容を重視する堅実なビジネス アナリストをチームに迎え入れることは (この場合、すでにプロダクト オーナーがいます)、たとえコストを犠牲にしても、有効な選択肢となる可能性があります。チームの総コストが増加しました。

固定スケジュールなしでプロセスをテストする

テスト活動がスクラム スプリント内の具体的なスケジュールに厳密に準拠していない場合はどうすればよいでしょうか?

一見すると、これはアジャイル/スクラム チームにとって望ましいもののように見えるかもしれません。柔軟性はいつでも歓迎されており、外部に提示すると良い印象を与えます。

私の経験によると、この自由の結果は柔軟性というよりも混乱になることがわかります。これは、開発完了直後に専用のテストフェーズを続ける「スプリント内にウォーターフォール」を作成することが、この問題の解決策であるという意味ではありません。この場合、これは決して正しいアプローチではありません。これについて詳しくは、スクラム テスト戦略とアジャイル テスト ライフ サイクルに関する私の投稿をご覧ください。

現在の開発チームとチームが提供する特定の製品特性に最も適していると思われるテスト スケジュールを、ある程度の柔軟性を考慮して選択することができます。ただし、この選択によって達成されるべき主な目標が 2 つあります。

1. テスト作業中の開発の進行の中断を最小限に抑えます。
2. チーム内で (コンテンツの観点から) 堅固で、(発生の観点から) 信頼性が高く、(予測可能性の観点から) 繰り返されるアクティビティを作成します。

これらの条件が満たされれば、チームは自然にフィッティング プロセスに適応し、予定外の長期にわたるテスト活動によって納品スケジュールが影響を受けることはありません。

結局のところ、最も重要なのは信頼性があり、予測可能なスプリント リリースです。これがこのブログの最後のポイントにつながります。

未定義のリリースプロセス

さて、これは各スクラムチームにとって非常に明白なことです。しかし、興味深いことに、これは通常、最も過小評価されているプロセスの 1 つでもあります。

多くの場合、スクラム チームは各スプリントの後にリリースすると言うだけですが、それはしっかりしたプロセスによって裏付けられていません。実際に何が起こるかというと、リリース期間中に多くの混沌とし​​た予測不可能なアクティビティが発生することになります。突然、全員が「リリースタスク」に忙殺され、誰も新しいスプリントストーリーの開発を続けることに集中できなくなります。スプリント指標がオフになっており、第三者 (通常はクライアント) の視点からは、リリースはランダムで予測不可能なアクティビティのように見えます。

人々はバックログ、スプリント コンテンツ、開発、テスト、そして最終的には結果を提示することに集中するあまり、これらすべてが完了すると、次のスプリントがすでに進行中であり、すでに時間をロスしていることを忘れてしまいます。

リリースするのに良い時期を探しています

では、チームは実際に本番環境にリリースするのはいつ正確に行うべきなのでしょうか?最後に大切なことはただ一つ。

その質問に対する答えは、あなたがすでに持っていると仮定して、プロセスの中にあります。に応じて：

• チームがスプリントで作成するコンテンツの複雑さ、
• スプリントの継続時間、
• システム内の影響を受けるコンポーネントの数
• 変更を使用およびリクエストしている人の数、

繰り返しの放出プロセスを確立し、今後もそれに従う必要があります。プロセスの正確なルールも柔軟に定義できます。しかし、テスト活動と同様に、それを予測可能で将来の具体的な日に予定された堅実な習慣にすることで、信頼して参照できるものになります。

選択すべき選択肢

このようなプロセスの可能な形式は、次のいずれか、またはその他の形式になります。

• 次のスプリント中に現在のスプリントの機能のテストを完了し、そのスプリントの終了時に (テストが完了したら) コンテンツをリリースします。つまり、各リリースには最後のスプリントのコンテンツは含まれませんが、前の 2 つのスプリントのストーリーは含まれます。
  • リリース前の最後のスプリントは常に、前の 2 つのスプリントのコンテンツのテストに専念します。
  • これは、「テスト スプリント」中の開発が停止されることを意味するものではありません。そのテスト スプリントで開発されたコンテンツは次のリリースにはまだ含まれないとだけ書かれています。
• すでに十分な自動テスト活動が実施されている場合は、各スプリントの終了後にリリースを実行するように努めてください。となると、これは非常に厳格なプロセスであり、専任のスタッフがその数日間に 100% 集中する必要があります。開発チームの他のメンバーにはいかなる影響も及ぼさないはずです。
• 主にエンド ユーザーの観点から問題ない場合は、月に 1 回、または N か月に 1 回のリリースを選択することもできます。これにより、各スプリントのテスト側の労力が増加します (リリースごとにコンテンツが大きくなるため)。しかしその一方で、時間の経過とともに繰り返されるアクティビティの量が減ることを意味し、この場合はチームにとってメリットが得られる可能性があります。その結果、機能が実際に本番稼働するまでのペースが遅くなるにもかかわらず、チームはリリースの間にさらに多くの新機能を構築できるようになります。

しかし、すでに何度か述べたように、これらのプロセスのどれが選択されるかはそれほど重要ではありません。その後、チームがどれだけそのプロセスに固執し、それを永続的な習慣にできるかがはるかに重要です。

リリース管理プロセスと実践方法については、このガイドもお読みください。