GROWSメソッドのワークフロー

GROWSメソッドのワークフローはシンプルなOODAループ（Observe: 観察, Orient: 状況判断, Decide: 意思決定, Act: 行動）をベースにしている。

GROWS開発ループ

「GROWS開発ループ」

継続的なレビュー

フィードバックの評価 → 出口
↓ データ
発見
- 「要求」
- 対話
- 共有学習
↓ 理解
TODOリスト
↓ WTF
DevOps
- CI/CD/CM
- デプロイ
↓ プロダクト

I. 観察：しっかりと観察する

ループの最初のステップは、フィードバックを収集するチャンスである。 非公式で構わないので、チームのパフォーマンス、会社の業績、技術的負債の量などの最新のデータを収集する。

開発サイクルの最初のループでは、以下のようなさまざまなレベルからデータを収集する必要がある。

  • 個人
  • チーム
  • プラクティス
  • 会社
  • 競合他社
  • 顧客

アウトカム: 利用可能なデータ

II. 状況判断：イメージを構築する

次のステップは、状況の理解とコンテキストの構築である。 目標となるのは、現状を明らかにして、チーム全体で知識を獲得することである。 これには、要求の発見、アウトカムとビジョン（ビジネスゴールやシステム全体のアーキテクチャのビジョンを含む）の接続なども含まれる。

このステップでは話しをすることが重要だ。 独り言や文書ではなく、人々との対話である。 対話によって、適切な質問をし、知識を共有し、探索し、発見するのである。

共通理解を生み出す

もちろん、これは言うは易く行うは難しである。 認知バイアスが働くため、見るべきものを見ることも難しい。 したがって、このステップにはバイアスを排除することも含まれる。

アウトカム: 十分な情報に基づいた理解

III. 意思決定：次に何をするかを選択する

次に、チームは何をするか（何をしないか）を決定し、作業キューを作成する。 作業キューはTODOリストのようなシンプルなもので済む場合もあれば、一般的な方法論で使用される正式なバックログが必要となる場合もある。 いずれにしても、リーンの理想に従い、仕掛品（WIP: work-in-process）は最小限に抑えたい。

タスクを小さく管理しやすくする

このステップの目標は、選択した作業項目（機能開発以外の場合もある）を小さく管理しやすいタスクに分解し、優先順位を付けることである。

タスクは1時間から半日で終わるように選択する必要がある。 ひとつのタスクにかかる時間は最大で3日を超えてはならない。

イテレーションの時間を埋めるようにタスクを積み上げるか（スクラム方式）、キューからタスクをプルして提供するアジャイルな手法（リーンやカンバン方式）にするかを選択できる。

「プッシュ」モデルか「プル」モデルかどうかにかかわらず、タスクは常に小さく提供可能にしておきたい。 これにより、占い（「見積り」とも言う）の罠を回避し、ストーリーポイントなどの代替品の計算のムダを排除できる。 作業を分解して、順番に実行するだけでいい。

[[ 3つのトラックで攻撃する ]]のプラクティスが示すように、機能を提供する以外のタスクがあるかもしれない。 他の2つのトラックの作業項目もキューに入れる必要がある。

アウトカム: 優先順位が付けられたタスクのキュー

IV: 行動：継続的に開発する

これまでのステップにはそれほど時間はかからない。 基本的なレベルを理解し、タスクのキューを作成するだけでいい。 それでは、行動の時間である。 継続的パラダイムを使用して、ユーザーに新しい能力を提供するWTF（working tested features: 動作するテストされた機能）を生み出そう。

継続的パラダイムの背後にある考え方は、 [[ 継続的インテグレーション ]]、テスト、デプロイ、監視を使用して、できるだけ早くフィードバックを取得するというものである。

フィードバックの頻度が制限速度になる

つまり、逆効果になるプラクティスもあるということだ。 たとえば、gitを使ったワークフローでは、開発用のフィーチャーブランチを作成し、数日、数週間、数ヶ月後にマージすることがある。 これはやめてほしい。 マージを遅延させると、コンフリクトや頭痛の種が生じる可能性が高い。 [[ 継続的開発 ]]の要点は、全員が常にメインのブランチで開発することである。

そのためには、堅実な自動化とデプロイのプラクティスが必要になる。 これは現代のソフトウェア組織にとって必要な最初のステップである。

最後のステップで述べたように、成長させるのはコードだけではない。 [[ 継続的開発 ]]は、プロセス自体、個人およびチームのスキル、そして最終的には組織の能力にも適用される。

アウトカム: ユーザーの能力、スキルの向上、プロセスの改善

I. 観察：しっかりと観察する

最初のステップに戻ってきた。 フィードバックを評価し、再び観察しよう。 今回（およびその後のループ）は、初回では得られなかったフィードバックやデータがプロジェクトから得られる。 それには以下のような領域が含まれる。

  • 技術的負債を発見する（例: [[ ソフトウェアX線 ]]）
  • ユーザーからの詳細なフィードバックを収集する
  • ふりかえり活動

OODA開発ループを進めていくと、人々、プロセス、コード、アーキテクチャ、メンタルモデル、前提などを変更しなければならないことが明らかになる。そのことに注意することが重要である。

必要な変更を加えよう

壊れた窓を放置せず、できるだけ早く修理しよう。

アウトカム: 利用可能なデータ

原文

Notes mentioning this note

役割別の習慣
コア習慣

Here are all the notes in this garden, along with their links, visualized as a graph.