すべてを待つのをやめる:ワークフローの依存関係を分解する

ワークフローの依存関係とは、作業項目が別の作業項目の開始または完了を待機してから開始する必要がある場合です。これは待つことを意味します。したがって、ワークフローの依存関係は、システムに遅延が組み込まれていることを意味します。遅延は、製品のフィードバックループ(たとえば、必要なものを構築しているかどうかを確認する)と市場への納品の両方を長引かせ、本質的にコストを増加させ、ROIを低下させます。

依存関係の例

依存関係を引き起こすいくつかのシナリオを調べてみましょう。良いものもあれば、悪いものもあり、単に避けられないものもあります。

新しい機能では、ベンダーが製品に何かを追加する必要があります。私たちの機能は、彼らが完成してその部分を提供するまでリリースできません。
チーム A のソフトウェアは、チーム B が開発中のハードウェアを使用します。チーム B がそれをサポートできるハードウェアを提供するまで、チーム A は新機能の作成を開始できません。
複数のチームで開発するために大きな機能が分割されています。
エピックは、複数の個別のバックログ項目に分割されています。これらは相互に構築され、順番に実行する必要があります。

依存関係の影響
特定の種類の依存関係からいくつかの肯定的な用途があります。

エピックを個々のバックログ項目に分割すると、依存関係を整理しておくことができますが、フィードバックループを短縮するために、管理可能でテスト可能なチャンクで作業を行うという利点があります。
ベンダーの製品を使用すると、時間とリソースが節約され、チームは会社のコア製品と価値に集中できます。
複数のチームを使用して機能に群がると、特定の機能のより高速な配信が可能になります (ただし、保証されるものではなく、場合によっては妨げられることもあります)。

ポジティブな使い方もありますが、ほとんどの依存関係は多くのマイナスの影響をもたらし、微妙ではありますが広範囲に及ぶ可能性があります。例は次のとおりです。

すべてのチームが同じ優先順位を持っているわけではありません – チームAにとって高い優先順位はチームBにとって低い優先順位である可能性があるため、チームAの最優先事項はチームBを待っている可能性があります。
依存関係により、バックログが複雑になります。この複雑さはリスクを増大させ、リスクは正確な予測をより困難にします。
依存関係によってバグ修正の外部依存関係が作成され、サービスレベルアグリーメント (SLA) を満たすことがより困難になる可能性があります。これは、チーム A が機能を所有し、SLA を担当しているが、バグがチーム B の製品に存在する可能性があるために発生します。チーム A は、この問題に対処するためにチーム B と協力する必要があります。これにより、複数のチームからの作業が必要になるため、バグ修正のコストも増加します。
バックログの順序は常にこれらの依存関係を回避する必要があるため、バックログの優先順位の変更はより困難になります。順序付けの依存関係と他のチームへのコミットメントはそのまま維持する必要があります。これにより、組織が新しい情報や状況に適応する能力が制限されます。
ワークフローの依存関係により、プロジェクトの複雑さが増し、リリース後の不具合の数が増加します。

上記の影響に加えて、依存関係は多くの場合、次のような他の機能障害の症状です。

コンポーネントに重点を置いたチーム (部門横断的な機能ベースのチームではなく)
スキルの専門化(サイロ化など)
コミュニケーションチャネルが厳しすぎる(チーム内およびチーム間の両方)
不適切な量の設計
- 詳細すぎて柔軟性がない-これにより、個々のチームがコミュニケーションを取り、協力することができなくなります
- 設計が不十分 – 開発標準とプロジェクトの境界が定義されていないため、チームAは、チームBが入力/出力が何であるかを確認できるように、自分の役割を完了する必要があります
プロジェクトの緊密な結合 – 不適切な設計と同様に、プロジェクトは合意されたAPIを使用するのではなく、他のプロジェクトが内部でどのように機能するかを知る必要があり、組織がそれらを個別に作業する能力を制限します。あるプロジェクトの内部変更により、他のプロジェクトに作業が追加される可能性があります。たとえば、製品は、適切な要求構文を持つ代わりに、オブジェクトを検索するための SQL クエリを公開します。別のデータベースに移動する場合は、プロジェクトのすべてのユーザーは、SQL 要求を新しいデータベースの要求として更新する必要があります。密結合は技術的負債も増大させます。
効果のない製品バックログの透明性と予測 – 発見が遅すぎるとチームが提供できないため、他のチームがより迅速に提供できるように支援されました

これは、すべての依存関係が間違っているという意味ではありません(多くは間違っていますが)。依存関係は、ベンダーや外部製品を扱うとき、またはハードウェアとソフトウェアの開発などの重要な境界を越えるときに発生する可能性があります。エピックをより小さなバックログ項目に分割するときに依存関係を並べ替えることも許容されます。また、プロジェクトのニーズにより適したアーキテクチャを決定するためのプロトタイプを作成するなど、決定が後続のバックログ項目に影響を与える場合もあります。

技術的負債と同様に、依存関係 (サードパーティのサービスの使用など) を使用すると、組織がより迅速に行動し、より多くのことを達成できる場合があります。ただし、技術的負債と同様に、依存関係の賢明でない使用 (たとえば、制御できないサードパーティへの長期的な依存関係にロックするなど) は、開発を遅らせ、より多くの費用がかかり、ユーザーエクスペリエンスの低下につながる可能性があります。

良い依存関係と悪い依存関係を区別する

それぞれの依存関係は異なり、独自のメリット(および危険)で評価する必要があります。依存関係を評価するときに使用するガイドラインの質問を次に示します。

この依存関係は簡単に回避できますか?
この依存関係は機能障害の症状ですか?
この依存関係に対処するには、いくつの通信チャネルが必要ですか?
この依存関係から得られる利点は何ですか?
顧客が機能全体に問題を見つけた場合、それに対処するためのプロセスはどのようになりますか?

依存関係を持つことに特定の利点がある場合は、先に進みます。依存関係が他の問題を隠蔽しているように見える場合、または大きな利益なしに過度の複雑さを引き起こしている場合は、依存関係を完全に回避する方法を見つけることをお勧めします。

既存の依存関係に対処する

依存関係が有効な場合でも、悪影響を最小限に抑えることができる手法があります。

依存関係を 1 つのチームに保持する

依存するバックログ項目を 1 つのチームに保持できる場合は、変更に対処するために必要な通信チャネルの数が減ります。これにより、依存するバックログ項目をより迅速に変更できます。

これは、部門連係チームのコアプラクティスに戻ります。チームが部門横断的である場合、アイテムを達成するために外部の支援 (依存関係) が必要になる可能性は低くなります。

バックログ項目を作成するための INVEST 基準に従う

頭字語 INVEST は、バックログ項目の説明の品質を判断するのに役立ちます。 INVESTは、独立した、交渉可能、価値のある、推定可能、小さい、テスト可能な略です。

無所属

ストーリーの書き方が原因で依存関係が存在する場合があります。たとえば、カートに項目を追加してからチェックアウトするためのバックログ項目があるチームを想像してみてください。彼らは、チェックアウトがカートにアイテムが入っていることに依存していると見なすかもしれません。ただし、バックログ項目を作成して、ユーザーに特定の金額を請求することができます。それはカートなしで開発(そしてテスト)することができます。これにより、あるチームはカートにアイテムを追加する機能に取り組み、別のチームは請求(クレジットカード情報の取得、請求の実行など)に取り組むことができます。バックログ項目を独立させることで、2 つのチームが連携し、依存関係を最小限に抑えることができました。その後、カートの請求の最終依存明細が発生する可能性があります。

独立したバックログ項目が多いほど、異なるチームがお互いのつま先を踏んだり、余分な調整を必要とせずに、異なる項目を簡単に取得できます。

別のバックログ項目を完了する前に 1 つのバックログ項目を完了する必要がある場合がありますが (多くの場合、これは適切な依存関係です)、別のバックログ項目を開始するために 1 つを開始する必要があり、どちらか一方を実行するために両方が実行中である必要があることは、通常または適切な依存関係ではありません。これは、PBIの分解における機能不全を意味します。

交渉

ストーリーをできるだけ緩やかに保つことで、チームは迅速に適応できます。すべての詳細が要件として不必要にロックダウンされている場合、チームがバックログ項目を達成するためのより良い方法を見つけた場合、バックログ項目を書き直すために、製品所有者、または外部の利害関係者を追跡する必要があります。チームが詳細を交渉できるようにすることで、会話と意思決定が迅速になります。

貴重

バックログ項目が価値があることに焦点を当てると、機能の垂直スライスであるバックログ項目が生成される傾向があります。垂直スライスにより、順序付けの依存関係が減り、各バックログ項目をテスト、レビュー、および使用できるため、フィードバックループが短縮されます。

見積

チームがサイズを見積もることができない場合は、サイズが十分に定義されていない可能性があり、不明な依存関係が潜んでいる可能性があります。

小さい

バックログ項目が小さいほど、複雑さが軽減されます。大きすぎて見積もることができない場合、バックログ項目に他の依存関係があるかどうかを知るのが難しくなります。

テスト

バックログ項目を分類できるようにする鍵は、各項目が個別にテスト可能であることを確認することです。機能が機能していることを保証するために自動テストが記述されている限り(単体テスト、または完全な統合とシステムテスト)、スプリント内で提供されたと見なすことができます。また、チームがバックログ項目全体を保証できる場合は、依存関係がなかったことを意味します。

API と境界を定義する

依存関係に対処するための主要なアクションの 1 つは、API と境界が適切に定義されていることを確認することです。これにより、API定義を支持している限り、異なるチームメンバーまたは異なるチームが並行して作業できます。これにより、各ピースのテストも簡単になります。

たとえば、あるチームは、e コマース Web サイトでページングを使用して一度に特定の数の製品を表示できるようにする新機能を作成しているとします。スプリント計画では、チームはこのリクエストがどのように表示されるか (例: /products?page=3) と結果がどのようになるか (製品の JSON リスト) を決定できます。その後、バックエンドで作業してAPIを実装し、そのAPIを使用してフロントエンドで作業している人(モック結果を使用)、そのAPIをテストする統合テストを作成する人を持つことができます。これをさらに進めて、各ページオブジェクトが持つCSSクラスを定義することができるので、フロントエンドテストを作成して、ページ上に50個のアイテムのみがあることを確認することができます(そのCSSクラスを使用してオブジェクトを検索することによって)。この例は、チームの境界を越えて拡張することもできます。

API の定義に関する注意事項: API を変更するための通信チャネルを明確に定義する必要があります。 APIで作業すると、元の設計では不十分であることを示す詳細が明らかになる場合があるため、チームは、機能のニーズに合わせてAPIを変更するための通信方法を知っている必要があります。

コード内の依存関係を抽象化する

上記の 2 つの項目と同様に、境界が明確に定義され、項目自体がテスト可能である場合は、メインコードベースの大部分が依存バックログ項目のコードの詳細を認識しないようにコードを記述できます。たとえば、これはラッパークラスで、単体テストでモックを使用して行うことができます。つまり、依存バックログ項目のコードまたは製品が変更された場合でも、メインコードの変更は、複数のファイルをクロールするのではなく、1 つのクラスまたは領域でのみ行われます。これは、多くの場合、依存関係の逆転の原則と呼ばれます。これにより、コードの保守が容易になる傾向があります。

依存関係の回避

前述のように、多くの依存関係は、一般的なアジャイルプラクティスを使用することで回避できます。これらのプラクティスは、依存関係を回避するのに役立つだけでなく、一般的に品質の向上と速度の向上につながる傾向があります。

クロスファンクショナルチーム

チームが機能横断的でない場合、論理的な境界 (UI やデータベースなど) を越えるバックログ項目は、自動的にチーム間の依存関係になります。垂直スライス全体で作業できる部門横断的なチームを持つことで、バックログ項目を複数のチームに拡張する必要性が劇的に低下します。技術的な依存関係は、多くの場合、社会的依存関係を反映しています。

T字型チームメンバー

クロスファンクショナルチームと同様に、クロスファンクショナル、マルチスキル、またはT字型のチームメンバーを持つことで、1人のチームメンバーがチームの他のメンバーの依存関係(つまり、単一障害点)にならないようになります。これにより、チーム全体がチームにとって最優先事項に取り組むことができます。

このようにスタートするチームはありません。チームメンバーは、スキルセットを拡大する機会を継続的に監視する必要があります。これには、なじみのない領域でのタスクの実行、ペアプログラミング、またはシャドウイングが含まれます。スプリントは、これらのアクティビティに対応し、計画する必要があります。

バックログの絞り込み

バックログの絞り込みでどのバックログ項目に外部依存関係があるかを監視することで、チームは他の必要なチームと協力して、調整が必要な設計、API、その他の選択肢を伝達および調整できます。これらの会話には、設計会議、依存関係がタイムリーに完了するように他の製品所有者との調整、またはチームが互いにどのように連携したいかを定義することが含まれる場合があります(たとえば、スクラムオブスクラムミーティング(重要な時期にチーム間の毎日のスクラム)を開催する)。アイテムが作業される前にこのコミュニケーションプロセスを開始すると、適切な議論が行われ、作業が妨げられることはありません。

適切なサイズのデザイン

アジャイル手法を誤解している多くの人は、アジャイル手法はアンチデザインであると考えています。本当じゃない。アジャイルの価値観と原則は、過剰な設計(つまり、決定を下すために必要な情報を得る前に詳細を設計すること)を思いとどまらせません。また、過剰な設計を避けることで、チームはより多くの情報を得たときに設計上の決定を下すことができます。適切な事前設計には、先に進むための一般的な機能の結果と基になるアーキテクチャの決定の定義が含まれます。特定の設計は、学習内容と必要な時期に応じて出現する必要があります。

プロダクトバックログ項目と同様に、設計の必要性がなくなるほど、現在必要な詳細は少なくなります。設計の実装が近づくほど、より詳細になります。製品バックログの改良は、開発の準備ができていると見なされる前に、追加の設計が必要な項目を特定し、必要性と優先順位が上がるにつれてそれらの設計を段階的に精緻化するプロセスです。

依存関係の管理はすべての人にとって良いことです

依存関係を正しく管理すると、複数のチームが協力して製品を早期にリリースできます。依存関係の管理を誤ると、技術的負債が発生し、バグ解決が遅くなり、製品のリリースが遅れる可能性があります。メリットがコストを明らかに上回り、それらのコストに対処する計画が明確でない限り、依存関係を最小限に抑えるのが最も安全です。

依存関係によって速度が低下し、ROIが制限されている場合は、今すぐお問い合わせください。

[monarch_share center=”true”]