Breaking News

Memperkenalkan Global Lean Agent Method (GLAM)

Oktober 17, 2026

Hampir semua tim yang saya temui sudah memakai AI saat menulis kode. Copilot aktif di IDE, jendela chat terbuka di monitor kedua, dan potongan kode berpindah dari chat ke editor puluhan kali sehari. Pertanyaannya: apakah alur kerja tim ikut berubah? Sering kali jawabannya tidak. Story masih ditulis seadanya, review masih menumpuk di akhir sprint, dan konteks proyek tetap tinggal di kepala satu dua orang.

Laporan DORA 2024 bahkan mencatat bahwa kenaikan adopsi AI sebesar 25% berkorelasi dengan turunnya stabilitas delivery sekitar 7,2%. Masalahnya bukan pada kemampuan AI menulis kode. Masalahnya ada pada flow: bagaimana pekerjaan bergerak dari ide sampai siap dipakai.

Artikel ini membahas cara praktis untuk mengubah flow tersebut. Saya menyebutnya Lean Agent Method (LAM): versi sederhana dari gabungan Lean dan BMAD yang tidak memerlukan instalasi apa pun. Cukup tiga file agent, satu file aturan bersama, dan folder docs/ di repositori Anda. Kita akan menjalankan satu sprint kecil bersama tiga agent bernama Kevin, Bob, dan Stuart.

Yang Anda butuhkan: Visual Studio 2026 atau VS Code dengan GitHub Copilot (agent mode), dan opsional Claude Code. Contoh kode memakai C# .NET 10, tetapi metodenya berlaku untuk bahasa apa pun.

1. Apa itu Global Lean Agent Method?

BMAD Method (Breakthrough Method for Agile AI-Driven Development) adalah metode open-source yang membagi pekerjaan ke beberapa agent khusus: Analyst, PM, Architect, Scrum Master, Developer, dan QA. Mereka saling menyerahkan pekerjaan lewat dokumen: brief, PRD, arsitektur, story, dan QA gate. Ide intinya sangat kuat: konteks disimpan di dokumen, bukan di memori chat. 

GLAM - global lean agent method adalah metode pengembangan perangkat lunak global extreme programming (terdistribusi) dikombinasikan dengan konsep BMAD tetapi disederhanakan dengan prinsip Lean

Masalahnya, untuk tim kecil, enam agent dan rangkaian workflow terasa berat. LAM mengambil intinya dan membuang sisanya. Hasilnya adalah tim dengan tiga manusia dan tiga agent:

Peran Jenis Tanggung jawab Keputusan
PM Manusia Menjaga flow, prioritas, dan metrik Story mana yang ditarik berikutnya
Product Owner Manusia Menjaga nilai produk Menyetujui brief dan setiap story
Dev Lead Manusia Arsitektur dan code review Menyetujui merge dan QA gate
Kevin Agent Analyst: menulis brief dan story Tidak ada, hanya mengusulkan
Bob Agent Developer: mengimplementasikan story Tidak ada, hanya mengusulkan
Stuart Agent Tester: menulis test dan QA gate Tidak ada, hanya mengusulkan

Prinsipnya bisa diringkas dalam satu kalimat: manusia memutuskan, agent mengusulkan, artefak menghubungkan keduanya.

Di atas struktur ini, Lean menyumbang tiga aturan yang tidak boleh dilanggar:

  1. WIP = 1. Setiap agent hanya mengerjakan satu story pada satu waktu. Generasi kode itu murah; yang mahal adalah kode setengah jadi yang menunggu review.
  2. Stop the line. Build merah atau QA gate gagal menghentikan alur. Tidak ada story yang lanjut dengan test gagal.
  3. Build quality in. Setiap acceptance criterion (AC) harus punya minimal satu test. Kualitas dirancang sejak story ditulis, bukan diperiksa belakangan.

2. Apa yang dibuang dari BMAD, dan mengapa

Di BMAD Di GLAM Alasan
Installer dan CLI Tidak ada; cukup salin file Markdown Nol dependensi, mudah diadopsi di repo mana pun
Agent PM, Architect, Scrum Master Diambil alih oleh manusia: PM dan Dev Lead Keputusan prioritas dan arsitektur sebaiknya tetap dipegang orang yang bertanggung jawab
PRD dan dokumen arsitektur terpisah Satu docs/brief.md dengan bagian catatan arsitektur Tim kecil cukup dengan satu sumber kebenaran
Sharding dokumen otomatis menjadi story Kevin menulis story satu per satu Story kecil lebih mudah disetujui dan diukur
Workflow dan template YAML Dua template Markdown: story dan QA gate Mudah dibaca manusia dan agent
Agent QA dengan banyak mode Stuart dengan satu alur: test, jalankan, putuskan Cukup untuk menjaga kualitas tiap story

Yang dipertahankan dari BMAD adalah hal yang paling bernilai: peran yang jelas, handoff lewat dokumen, story dengan AC yang bisa diuji, dan QA gate.

3. Studi kasus: DriveWise

Sepanjang artikel, kita memakai proyek fiktif DriveWise: aplikasi web yang membantu pembeli mobil pertama membandingkan beberapa mobil sebelum membeli. Datanya diambil dari layanan web fueleconomy.gov milik EPA, yang bersifat publik dan tidak memerlukan API key.

Fitur utamanya sederhana: pengguna memilih hingga enam mobil, mengisi profil berkendara (jarak tempuh per tahun, preferensi bahan bakar, bobot efisiensi, biaya, dan emisi), lalu DriveWise menampilkan peringkat beserta alasannya. Stack: C# .NET 10, Blazor Web App, xUnit.

4. Langkah 1: Siapkan struktur repositori

Buat struktur berikut di root repo. Semua file tersedia di starter kit yang saya lampirkan di akhir artikel.

DriveWise/
├── .github/
│   ├── copilot-instructions.md     # aturan tim untuk Copilot
│   └── agents/
│       ├── kevin.agent.md
│       ├── bob.agent.md
│       └── stuart.agent.md
├── .claude/
│   └── agents/                     # agent yang sama untuk Claude Code
│       ├── kevin.md
│       ├── bob.md
│       └── stuart.md
├── CLAUDE.md
├── docs/
│   ├── brief.md                    # project brief + catatan arsitektur
│   ├── flow-log.md                 # log lead time (PM)
│   ├── stories/
│   │   └── _TEMPLATE.md
│   └── qa/
│       └── _TEMPLATE.md
└── src/ ...

Perhatikan bahwa folder docs/ berada di samping kode dan ikut di-commit. Inilah memori bersama tim. Ketika Bob bekerja, ia tidak bergantung pada riwayat chat siapa pun; ia membaca file yang sama yang dibaca Dev Lead.

5. Langkah 2: Tulis aturan bersama

File .github/copilot-instructions.md dibaca otomatis oleh GitHub Copilot di setiap permintaan. Isinya adalah aturan tim, bukan detail teknis.

# Team rules (Lean Agent Method)

Humans: PM (flow), Product Owner (value), Dev Lead (architecture and review).
Agents: Kevin (Analyst), Bob (Developer), Stuart (Tester). Humans decide; agents propose.

## Always
* Work from one approved story in `docs/stories/`. No story, no work.
* Read `docs/brief.md` before changing code.
* One story at a time (WIP = 1). Keep changes small.
* Build and run the tests before you say you are done. A red build stops the line.
* Cite the story ID and acceptance criteria numbers in every summary.
* Never invent API fields, packages or files. If unsure, ask.

Untuk Claude Code, cukup buat CLAUDE.md yang merujuk ke file yang sama, sehingga kedua tool memakai satu sumber aturan:

# Claude Code guide

Follow the team rules in `.github/copilot-instructions.md`.
Subagents: `kevin`, `bob`, `stuart` in `.claude/agents/`.
Default role for Claude Code in this repo: independent reviewer. Compare a diff with
its story and report gaps per acceptance criterion. Do not edit files unless asked.

Tips: Saya sengaja menulis aturan dalam bahasa Inggris karena model cenderung lebih konsisten mengikutinya. Dokumen untuk manusia (brief dan story) boleh dalam Bahasa Indonesia.

6. Langkah 3: Definisikan Kevin, Bob, dan Stuart

Setiap agent adalah satu file Markdown dengan frontmatter. Bagian terpenting bukan daftar "Can", melainkan daftar "Cannot". Batasan inilah yang menciptakan pemisahan tugas (separation of duties), konsep yang sama yang kita ajarkan di mata kuliah kualitas perangkat lunak.

.github/agents/kevin.agent.md

---
name: Kevin
description: Analyst. Turns a stakeholder request into one small story with testable acceptance criteria.
handoffs:
  - label: Hand story to Bob
    agent: Bob
    prompt: Implement the story Kevin just wrote, after the Product Owner approves it.
    send: false
---
# Kevin, the Analyst

## Can
* Read anything in the repo.
* Write or edit files in `docs/` only (brief, stories).

## Cannot
* Edit source code or tests.

## Workflow
1. Ask up to 3 questions if the user, goal or constraint is unclear.
2. Create the next story from `docs/stories/_TEMPLATE.md`.
3. Check INVEST. Split the story if it is larger than 5 points.
4. List open questions for the Product Owner.
5. End with: story ID, points, "Needs PO approval".

.github/agents/bob.agent.md (ringkas)

---
name: Bob
description: Developer. Implements one approved story with small, reviewable changes, then builds and tests.
handoffs:
  - label: Ask Stuart to test
    agent: Stuart
    prompt: Test the story Bob just implemented and write a QA gate.
    send: false
---
## Can
* Edit source code and project files. Run build and test commands.
## Cannot
* Change stories or the brief. Add packages without Dev Lead approval.
* Delete or weaken existing tests.
## Workflow
1. Read the story and `docs/brief.md`. Restate the AC you will satisfy.
2. List the files you plan to touch. Stay inside the story.
3. Implement. Build. Run the tests. Fix code, not tests.
4. Summarize: files changed, AC covered, anything deferred.

.github/agents/stuart.agent.md (ringkas)

---
name: Stuart
description: Tester. Writes tests traced to acceptance criteria, runs them, and issues a QA gate decision.
---
## Can
* Write and edit test projects. Run tests. Write `docs/qa/<ID>-gate.md`.
## Cannot
* Change production code. Report defects to Bob instead.
## Workflow
1. List every acceptance criterion. Write at least one test per criterion, plus edge cases.
2. Run the tests and report counts.
3. Fill the gate: AC, tests, result. Decide PASS, PASS with concerns, or FAIL.

Untuk Claude Code, isi yang sama disimpan di .claude/agents/kevin.md, bob.md, dan stuart.md, dengan tambahan baris tools: di frontmatter. Contoh untuk Kevin: tools: Read, Grep, Glob, Write, Edit (tanpa Bash, karena Kevin memang tidak perlu menjalankan apa pun).

Bagian handoffs membuat tombol serah terima muncul di Copilot Chat VS Code setelah agent selesai, sehingga alur Kevin ke Bob ke Stuart terasa seperti papan Kanban kecil. Jika fitur custom agent belum tersedia di versi Visual Studio Anda, simpan instruksi yang sama sebagai prompt file di .github/prompts/ lalu panggil dengan # di Copilot Chat.

7. Langkah 4: Kevin menulis story

Product Owner datang dengan permintaan. Di VS Code, buka Copilot Chat, pilih agent Kevin, lalu tulis:

The Product Owner says: "Buyers want to rank their shortlist by how they actually drive:
miles per year, fuel cost, efficiency and emissions." Draft the next story.

Kevin menghasilkan docs/stories/DW-2-recommendation-engine.md. Potongan bagian terpentingnya:

# DW-2: Recommendation engine
Status: Draft | Developer: Bob | Tester: Stuart | Points: 5

As a buyer, I want my shortlist ranked against how I drive so that I can see the best fit.

## Acceptance criteria
1. Given a shortlist and a driving profile, Recommend returns ranked vehicles (rank 1 first)
   and a list of excluded vehicles.
2. Score = 100 x (efficiency, cost and emissions, each min-max normalized, weighted).
3. Weights are normalized to sum 1; if all weights are 0, use equal weights.
5. Annual cost = EPA fuelCost08 x AnnualMiles / 15000.
6. Exclude with a reason: powertrain mismatch, class mismatch, over budget.
9. Each ranked vehicle has at least one human-readable reason.
10. Ties are broken by lower annual cost, then lower id.

(AC 4, 7 dan 8 tidak ditampilkan di sini agar ringkas; versi lengkapnya ada di repo contoh.)

Momen manusia: Product Owner membaca AC, mengubah satu kalimat bila perlu, lalu mengganti status menjadi Approved. Tanpa persetujuan ini, Bob tidak boleh mulai. Inilah aturan pull dalam Lean: pekerjaan ditarik ketika siap, bukan didorong.

Ukuran story: Jika Kevin menghasilkan story di atas 5 poin, minta ia memecahnya. Story besar adalah sumber utama rework, karena agent cenderung "mengisi kekosongan" dengan asumsinya sendiri.

8. Langkah 5: Bob membangun

Pindah ke Visual Studio 2026. Buka Copilot Chat dalam mode Agent, pilih Bob, lalu tulis:

Implement docs/stories/DW-2-recommendation-engine.md.
Register the engine in Program.cs. Build the solution before you finish.

Bob akan menjalankan loop agentic: membaca story, merencanakan file, mengedit, menjalankan dotnet build, memperbaiki error, lalu melaporkan AC yang terpenuhi. Hasilnya untuk DriveWise adalah RecommendationEngine.cs dan beberapa record pendukung. Potongan intinya:

public RecommendationResult Recommend(IEnumerable<Vehicle> shortlist, DrivingProfile profile)
{
    profile.Validate();                                   // AC8
    // ... filter kandidat dan kumpulkan alasan eksklusi (AC6)
    var scored = candidates.Select(v => (Vehicle: v,
            Score: Math.Round(100 * (we * Eff(v) + wc * Cost(v) + wg * Co2(v)), 1),  // AC2
            Cost: AnnualCost(v, profile)))                                         // AC5
        .OrderByDescending(x => x.Score)
        .ThenBy(x => x.Cost)                              // AC10
        .ThenBy(x => x.Vehicle.Id)
        .ToList();
    // ... susun Recommendation dengan alasan (AC9)
}

Review oleh Dev Lead. Jangan mereview semua baris dengan bobot yang sama. Fokus pada tiga hal:

  1. Kesesuaian dengan story. Cocokkan ringkasan Bob dengan nomor AC. Apakah ada AC yang tidak disebut?
  2. Batasan arsitektur. Di DriveWise, layer Recommendation tidak boleh melakukan I/O. Cek tidak ada HttpClient atau akses file di sana.
  3. Hal yang tidak diminta. Fitur tambahan yang tidak ada di story adalah waste (extra features dalam istilah Lean). Minta Bob menghapusnya.

9. Langkah 6: Stuart menguji dan membuat QA gate

Kembali ke VS Code, pilih agent Stuart:

Test story DW-2. Write xUnit tests traced to every acceptance criterion,
run dotnet test, and write docs/qa/DW-2-gate.md with your gate decision.

Stuart menulis test dengan nama yang terbaca seperti kalimat:

[Fact]
public void Rescales_EPA_fuel_cost_to_annual_miles_and_ownership_years()
{
    var profile = new DrivingProfile { AnnualMiles = 30_000, OwnershipYears = 3 };
    var r = _engine.Recommend([Gas()], profile).Best!;

    Assert.Equal(3200, r.AnnualFuelCostUsd);    // 1600 x 30k / 15k (AC5)
    Assert.Equal(9600, r.OwnershipFuelCostUsd);
}

Lalu mengisi QA gate:

AC Test Hasil
1 Ranks_most_efficient_cheapest_cleanest_vehicle_first Pass
5 Rescales_EPA_fuel_cost_to_annual_miles_and_ownership_years Pass
6 Filters_by_powertrain_preference (3 kasus), Excludes_vehicles_over_fuel_budget_with_reason Pass
8 Invalid_profile_throws (3 kasus) Pass
10 Hanya teruji tidak langsung Concern

Keputusan: PASS with concerns. Stuart menemukan bahwa aturan tie-break (AC10) belum punya test eksplisit. Temuan seperti ini justru paling berharga. Dev Lead yang memutuskan apakah concern ini memblokir rilis atau cukup dicatat untuk story berikutnya.

Mengapa Stuart tidak boleh memperbaiki kode? Karena agent yang menguji pekerjaannya sendiri cenderung menyesuaikan test dengan kode, bukan dengan story. Dengan larangan ini, setiap defect kembali ke Bob lewat handoff, dan jejaknya tercatat.

10. Langkah 7: Review silang dengan Claude Code

Langkah ini opsional tetapi sangat saya sarankan: minta agent dari vendor berbeda untuk mereview. Di terminal VS Code:

claude -p "Review the uncommitted git diff against docs/stories/DW-2-recommendation-engine.md \
and docs/brief.md. For each acceptance criterion say Met, Partially met or Not met with file \
and line. Flag any I/O inside src/DriveWise.Core/Recommendation. Do not edit files."

Karena seluruh konteks ada di repo, Claude Code tidak perlu dijelaskan ulang apa pun. Ia membaca story, brief, dan diff yang sama dengan yang dibaca Copilot. Inilah manfaat praktis dari prinsip artefak menghubungkan: tool menjadi bisa saling menggantikan, dan Anda tidak terkunci pada satu vendor.

11. Langkah 8: Ukur flow

Lean tanpa pengukuran hanyalah slogan. PM cukup mengisi satu tabel di docs/flow-log.md setiap kali story selesai:

Story Disetujui Masuk review Selesai Lead time Rework Defect setelah selesai
DW-2 Sen 09.00 Sen 11.30 Sen 15.00 0,25 hari 1 0
DW-3 Sel 09.00 Sel 10.45 Sel 13.00 0,2 hari 0 1

Tiga indikator yang saya pantau:

  • Lead time per story: dari disetujui PO sampai QA gate PASS. Inilah metrik utama flow.
  • Rework loop: berapa kali story bolak balik antara Bob dan Stuart. Angka tinggi biasanya menandakan AC yang kabur, bukan agent yang buruk.
  • Defect setelah selesai: masalah yang ditemukan setelah gate PASS. Jika angkanya naik, perketat AC atau tambah test edge case.

Dalam simulasi DriveWise yang saya pakai untuk keynote ICoSEIT 2026, perbaikan terbesar justru terjadi di depan alur: waktu dari ide sampai story disetujui. Pembuatan kode tidak pernah menjadi hambatan utama. Catatan: angka DriveWise bersifat ilustratif karena proyeknya fiktif.

12. Jebakan yang sering terjadi

Jebakan Gejala Solusi
Konteks tinggal di chat Agent "lupa" keputusan kemarin Setiap keputusan ditulis ke docs/. Jika tidak tertulis, anggap tidak pernah terjadi
Story terlalu besar Bob menyentuh 15 file, review terasa melelahkan Batasi 5 poin. Minta Kevin memecah story
Agent menguji dirinya sendiri Test selalu hijau, bug lolos ke pengguna Pertahankan larangan "Cannot" di Bob dan Stuart
Terlalu percaya output yang lancar Kode rapi, tetapi salah memakai field API Aturan "Never invent API fields" dan test dengan data nyata atau snapshot
WIP diam diam naik Tiga story setengah jadi sekaligus PM menegakkan WIP = 1 per agent; story berikutnya ditarik setelah gate PASS
Junior hanya mereview Kemampuan membangun menurun Rotasi: sesekali junior berperan sebagai "Bob manusia" dengan agent sebagai reviewer

13. Penutup: ceklis adopsi

Lean Agent Method bukan tentang menambah AI ke proses lama. Ini tentang merancang proses sehingga manusia dan agent berbagi satu alur yang jelas. Agentic AI menyediakan kapasitas, struktur ala BMAD menyediakan kontrak, dan Lean menjaga alurnya tetap jujur.

Mulai minggu depan dengan ceklis berikut:

  • [ ] Salin starter kit ke root repo Anda.
  • [ ] Isi docs/brief.md, terutama bagian catatan arsitektur.
  • [ ] Sesuaikan daftar "Can" dan "Cannot" untuk stack Anda.
  • [ ] Tunjuk siapa PM, Product Owner, dan Dev Lead (satu orang boleh merangkap dua peran di tim kecil).
  • [ ] Minta Kevin menulis satu story kecil (maksimal 5 poin).
  • [ ] Product Owner menyetujui story sebelum Bob mulai.
  • [ ] Bob membangun; Dev Lead mereview dengan tiga fokus di Langkah 5.
  • [ ] Stuart menulis test per AC dan mengisi QA gate.
  • [ ] Opsional: review silang dengan Claude Code.
  • [ ] PM mencatat lead time dan rework di docs/flow-log.md, lalu bahas di retrospektif.

Unduh: starter kit Lean Agent Method (template brief, story, QA gate, flow log, serta agent Kevin, Bob, dan Stuart untuk GitHub Copilot dan Claude Code) dan contoh solusi lengkap DriveWise tersedia bersama artikel ini. 

Selamat mencoba, dan ceritakan hasil sprint pertama Anda di kolom komentar.



Referensi

  • BMAD Method, Breakthrough Method for Agile AI-Driven Development. https://github.com/bmad-code-org/BMAD-METHOD
  • Google Cloud DORA, Accelerate State of DevOps Report 2024. Ringkasan temuan AI: https://redmonk.com/rstephens/2024/11/26/dora2024/
  • M. Poppendieck dan T. Poppendieck, Lean Software Development: An Agile Toolkit, Addison-Wesley, 2003.
  • U.S. EPA, fueleconomy.gov Web Services. https://www.fueleconomy.gov/feg/ws/index.shtml

Tidak ada komentar

Langganan: Posting Komentar ( Atom )