ソフトウェアファクトリーのご紹介

エンジニアリング チームが時間があればやりたいと思っていることのほとんどは、難しいことではありません。誰もやりたくない依存関係の増加よりも緊急の何かが常に存在するため、これは明らかで、小規模であり、永久に優先順位が低くなります。

ソフトウェアファクトリーはその山のために存在します。

その形

それをバックログ項目に向けます。問題を読み取り、周囲のコードを読み取り、変更を計画し、書き込み、テストを実行し、何を行ったのか、そしてその理由を説明するプル リクエストを開きます。

ある人は、同僚のプル リクエストをレビューするのと同じ方法で、そのプル リクエストをレビューします。それが相互作用全体です。

何ができないのか

合併しません。失敗したテストが許容されるかどうかを決定するものではありません。与えられたチケットを超えてそれ自体の範囲を広げることはありません。これは小さな制約のように聞こえますが、レビュー可能な変更と広範囲にわたる変更の違いです。

境界は、命令で要求されるのではなく、アクションが発生する場所で強制されるため、意図ではなくシステムのプロパティです。

なぜプラットフォームの横ではなくプラットフォームに置かれているのか

スタンドアロンのコード生成ツールのデモはうまくいきますが、3 週目あたりから難しくなります。このとき、40 個のツールが実行されており、何を変更したのか、コストはいくらなのか、課金に影響を与えたツールの所有者は誰なのか、誰も言えなくなります。

すべての Software Factory の実行は通常のエージェントの実行であるため、プラットフォームがすでに提供しているもの (エージェントごとに割り当てられた支出、ブロックする予算、アクションの瞬間に適用されるポリシー、実行ごとの評価スコア、および完全な監査証跡) を継承します。

これらはいずれも Software Factory の機能ではありません。むしろそれがポイントです。

どこから始めるべきか

それを最大限に活用するチームは、明確に指定されたリスクの低い作業のカテゴリーを 1 つ選択し、評価スコアが面白くなくなるまでそこで実行し、その後境界を広げます。デモで示唆されているよりも遅く、最初の 1 か月は生き残るバージョンです。

次へ

Software Factory のページではこれについて詳しく説明しており、Agent Orchestration System のページではその下にあるガバナンス、コスト、評価層について説明しています。自分のバックログと照らし合わせて確認するには、デモを予約してください。