Workflow #

Dalam software engineering, workflow sering dianggap sekadar urutan langkah: backlog → development → testing → release. Tapi definisi sesempit itu menyembunyikan sesuatu yang jauh lebih penting — workflow adalah cara tim berpikir dan berkoordinasi untuk mengubah ide menjadi nilai nyata bagi pengguna. Tim yang punya workflow yang baik tidak hanya bergerak lebih cepat, tapi juga lebih jarang mengerjakan ulang pekerjaan yang salah. Artikel ini membahas apa itu workflow dalam konteks Scrum, mengapa ia penting, dan bagaimana cara merancangnya agar sehat dan adaptif.

Apa Itu Workflow dalam Software Engineering? #

Workflow adalah pola alur kerja yang disepakati tim untuk mengubah requirement menjadi software yang siap digunakan. Tapi dalam praktiknya, workflow mencakup lebih dari sekadar urutan tahap:

• Bagaimana sebuah ide atau kebutuhan masuk ke sistem dan mendapat prioritas
• Kapan dan bagaimana developer mulai mengerjakan sebuah task
• Bagaimana perubahan kode diuji, di-review, dan akhirnya dirilis
• Bagaimana feedback dari pengguna kembali masuk ke tim dan memengaruhi prioritas berikutnya

Dalam kerangka Scrum, workflow hidup di antara artefak dan event resmi Scrum:

flowchart LR
    PB[Product Backlog] --> SP[Sprint Planning]
    SP --> EX[Sprint Execution]
    EX --> SR[Sprint Review]
    SR --> RT[Retrospective]
    RT -->|prioritas diperbarui| PB

    EX -.->|bug, feedback internal| EX
    SR -.->|feedback stakeholder| PB

Workflow bukan Scrum itu sendiri — ia adalah cara tim engineering memanfaatkan Scrum agar kerja harian tetap terstruktur tanpa kehilangan fleksibilitas untuk beradaptasi.

Workflow ≠ Proses Kaku #

Kesalahan paling umum dalam merancang workflow adalah memperlakukannya sebagai aturan permanen yang tidak boleh disentuh. Workflow yang sehat justru sebaliknya: ia berevolusi seiring tim dan produk berkembang.

// ANTI-PATTERN: Workflow sebagai aturan tetap yang tidak boleh diubah
"Proses kita sudah ditetapkan dari awal tahun, ikuti saja"
→ Tim bekerja di sekitar proses, bukan dengan proses
→ Bottleneck terlihat tapi tidak ada yang berani mengubah
→ Retrospective membahas masalah yang sama sprint demi sprint

// BENAR: Workflow sebagai perjanjian hidup yang terus dievaluasi
"Kita ikuti workflow ini sebagai default, tapi kita evaluasi tiap sprint"
→ Tim merasa memiliki workflow
→ Perubahan kecil dilakukan saat ada sinyal masalah
→ Workflow mencerminkan kondisi tim yang sesungguhnya

Ada spektrum antara terlalu kaku dan terlalu longgar — keduanya sama-sama berbahaya:

Workflow yang sehat berada di tengah: cukup terstruktur untuk prediktabel, cukup fleksibel untuk adaptif.

Nilai Penting Workflow bagi Tim Engineering #

Sebelum merancang workflow, penting untuk memahami mengapa ia penting. Workflow bukan ritual administratif — ia memberikan nilai konkret yang langsung dirasakan tim sehari-hari.

Menciptakan Predictability #

Salah satu pertanyaan yang paling sering diajukan stakeholder adalah: “Kapan fitur ini selesai?” Tanpa workflow yang konsisten, jawaban selalu berupa tebakan. Dengan workflow yang baik, tim bisa menjawab berdasarkan data:

Tanpa workflow yang jelas:
  Stakeholder: "Kapan fitur checkout baru siap?"
  Developer: "Mungkin... dua minggu? Tergantung testing."
  → Tidak ada dasar estimasi yang bisa dipegang

Dengan workflow yang konsisten:
  Stakeholder: "Kapan fitur checkout baru siap?"
  PM: "Story sudah masuk sprint, berdasarkan velocity historis kami, 
       estimasi siap demo di Sprint Review minggu depan."
  → Estimasi berbasis data, bukan intuisi

Predictability bukan soal estimasi yang selalu tepat — tapi tentang alur kerja yang cukup konsisten sehingga pola bisa diamati dan dijadikan dasar perencanaan.

Mengurangi Cognitive Load Developer #

Tanpa workflow yang jelas, developer menghabiskan energi mental untuk keputusan-keputusan yang seharusnya sudah dijawab oleh proses:

// Pertanyaan yang muncul tanpa workflow yang jelas
"Apakah story ini sudah siap dikerjakan atau masih perlu klarifikasi PO?"
"Apakah saya harus tunggu testing selesai dulu sebelum mulai story berikutnya?"
"Apakah perlu minta approval dulu sebelum deploy ke staging?"
"Siapa yang harus saya minta untuk code review?"

// Pertanyaan yang TIDAK perlu dijawab ulang jika workflow jelas
→ DoR menjelaskan kapan story siap dikerjakan
→ Board menunjukkan status setiap task secara real-time
→ DoD menjelaskan kapan story benar-benar Done
→ Workflow menentukan siapa reviewer dan berapa lama turnaround-nya

Setiap keputusan kecil yang dieliminasi oleh workflow adalah energi mental yang tersisa untuk memecahkan masalah teknis yang sesungguhnya.

Menjaga Kualitas Tanpa Memperlambat Tim #

Tanpa workflow, kualitas sering menjadi fase terpisah di akhir — “nanti QA yang cek”. Ini mahal karena bug ditemukan terlambat. Workflow yang matang mengintegrasikan kontrol kualitas ke dalam alur, bukan sebagai checkpoint tersendiri:

flowchart LR
    subgraph Workflow Immature
        A1[Dev selesai] --> B1[Kirim ke QA]
        B1 --> C1[Bug ditemukan]
        C1 --> D1[Kembali ke Dev]
        D1 --> E1[QA lagi]
    end

    subgraph Workflow Mature
        A2[Dev selesai] --> B2[Self-test + unit test]
        B2 --> C2[Code review]
        C2 --> D2[QA — acceptance criteria]
        D2 --> E2[Done]
    end

Workflow mature tidak lebih lambat — ia menghindari iterasi rework yang sebenarnya jauh lebih mahal.

Menjadi Media Komunikasi Tim #

Workflow yang terdokumentasi dan tervisualisasi menjadi bahasa bersama antara semua role:

Antara Product dan Engineering:
  PO tahu kapan story bisa diambil sprint (DoR)
  PO tahu kapan story dianggap selesai (DoD)
  Tidak ada ambiguitas "sudah selesai tapi belum di-deploy"

Antara Engineering dan QA:
  QA tahu kapan story siap masuk queue testing
  QA tahu acceptance criteria apa yang harus dipenuhi
  Tidak ada handoff yang bergantung pada verbal communication

Antara Tim dan Stakeholder:
  Stakeholder bisa melihat progress di board tanpa harus tanya
  Status pekerjaan transparan dan tidak bergantung pada laporan manual

Ketika workflow jelas, konflik antar role sering berkurang karena masalah terlihat sebagai masalah sistem — bukan masalah individu.

Anatomi Workflow Engineering yang Sehat #

Sebelum membahas prinsip desain, penting untuk tahu seperti apa anatomi workflow yang baik. Workflow engineering umumnya terdiri dari beberapa tahap dengan transisi yang jelas:

stateDiagram-v2
    [*] --> Backlog : Story dibuat
    Backlog --> Ready : Lulus DoR
    Ready --> InProgress : Developer mengambil
    InProgress --> InReview : Code review
    InReview --> InProgress : Perlu perbaikan
    InReview --> Testing : Code approved
    Testing --> InProgress : Bug ditemukan
    Testing --> Done : Lulus acceptance criteria
    Done --> [*]

Setiap transisi di atas harus punya kriteria yang jelas — kapan sebuah story boleh berpindah dari satu status ke status berikutnya. Tanpa kriteria transisi, status di board hanya menjadi label kosong yang tidak mencerminkan kondisi aktual.

// Contoh kriteria transisi yang jelas
Backlog → Ready:
  □ Acceptance criteria sudah ditulis dan divalidasi PO
  □ Story sudah diestimasi dalam Story Points
  □ Dependency sudah diidentifikasi

InProgress → InReview:
  □ Implementasi selesai di lingkungan lokal
  □ Unit test ditulis dan lulus
  □ PR/MR sudah dibuat dengan deskripsi yang lengkap

InReview → Testing:
  □ Minimal 1 reviewer sudah approve
  □ Tidak ada requested changes yang belum diselesaikan
  □ CI pipeline lulus

Testing → Done:
  □ Semua acceptance criteria terpenuhi
  □ Tidak ada bug critical atau major yang terbuka
  □ Fitur sudah di-deploy ke staging

Prinsip Merancang Workflow #

1. Mulai dari Masalah, Bukan Tool #

Workflow paling sering gagal bukan karena pilihan tool yang salah, tapi karena dirancang dari tool ke masalah — bukan sebaliknya.

// ✗ Pendekatan yang salah: workflow mengikuti tool
"Kita pakai Jira, jadi workflow-nya To Do → In Progress → Done"
→ Workflow generik yang tidak mencerminkan cara kerja tim sesungguhnya
→ Status board tidak informatif karena tidak ada kriteria transisi

// ✓ Pendekatan yang benar: workflow menjawab masalah nyata
Tanya dulu:
  - Di mana pekerjaan paling sering macet?
  - Tahap mana yang paling sering menghasilkan rework?
  - Di mana komunikasi paling sering putus antar role?
Lalu rancang workflow untuk menjawab pertanyaan itu
→ Tool mengikuti workflow, bukan sebaliknya

2. Visualisasikan Alur Kerja #

Workflow yang tidak terlihat sulit dievaluasi dan sulit diikuti. Visualisasi bukan hanya tentang membuat board yang cantik — ia tentang membuat status pekerjaan transparan bagi seluruh tim.

Prinsip visualisasi yang baik:

✓ Setiap tahap punya nama yang bermakna (bukan hanya "In Progress")
✓ Jumlah status tidak berlebihan — 5–7 status cukup untuk sebagian besar tim
✓ Transisi antar status punya kriteria yang terdokumentasi
✓ WIP (work in progress) terlihat jelas di setiap tahap
✗ Jangan punya status yang "tidak pernah dipakai" — hapus jika tidak relevan
✗ Jangan punya status yang ambigu seperti "Waiting" tanpa konteks menunggu apa

3. Batasi Work in Progress (WIP) #

Ini adalah prinsip paling sering diabaikan dan dampaknya paling besar. Tanpa batasan WIP, semua orang sibuk tapi tidak ada yang selesai.

// ANTI-PATTERN: Tidak ada WIP limit
Tim 5 developer, 18 story "In Progress" bersamaan
→ Semua orang context switching
→ Tidak ada yang selesai di tengah sprint
→ Code review menumpuk karena tidak ada yang bisa fokus mereview

// BENAR: WIP limit diterapkan
Tim 5 developer, WIP limit: maksimal 2 story per developer
→ Setiap developer fokus menyelesaikan 1–2 story sebelum mulai yang baru
→ Jika ada blocker, terlihat lebih cepat karena WIP tidak menyembunyikannya
→ Code review diselesaikan lebih cepat karena ada slack time

flowchart TD
    A{Apakah kamu punya task\nyang hampir selesai?} -- Ya --> B[Selesaikan dulu\nsebelum mulai yang baru]
    A -- Tidak --> C{Apakah WIP kamu\nsudah di batas?}
    C -- Ya --> D[Bantu rekan yang butuh\nreview atau unblock]
    C -- Tidak --> E[Ambil story berikutnya\ndari Ready queue]

WIP limit yang tepat berbeda untuk setiap tim. Mulai dari aturan sederhana: tidak boleh punya lebih dari 2 task aktif sekaligus per developer — lalu sesuaikan berdasarkan observasi.

4. Jadikan Definition of Done sebagai Penjaga Workflow #

DoD dan workflow harus saling menguatkan. DoD yang tidak terintegrasi ke dalam workflow akan dilanggar di bawah tekanan sprint.

// ✗ DoD yang ada tapi tidak terintegrasi ke workflow
DoD ada di Confluence, tidak pernah dibaca
Developer memindahkan card ke "Done" berdasarkan intuisi
QA sering menemukan story "Done" yang belum di-deploy ke staging

// ✓ DoD sebagai gate dalam workflow
Card tidak boleh dipindah ke "Done" tanpa checklist DoD dicentang
Board dikonfigurasi untuk menampilkan DoD checklist di setiap card
Review dilakukan di Sprint Review — jika story tidak memenuhi DoD, tidak boleh didemonstrasikan

5. Rancang Feedback Loop yang Cepat #

Scrum menekankan inspect and adapt — dan workflow harus mendukung itu. Semakin lambat feedback masuk, semakin mahal cost of mistake.

sequenceDiagram
    participant Dev as Developer
    participant CI as CI Pipeline
    participant QA as QA
    participant PO as Product Owner
    participant User as End User

    Dev->>CI: Push kode
    CI-->>Dev: Feedback dalam menit (test, lint, build)
    Dev->>QA: Story siap testing
    QA-->>Dev: Feedback dalam jam (bug, edge case)
    QA->>PO: Story siap validasi
    PO-->>Dev: Feedback dalam hari (acceptance criteria)
    PO->>User: Fitur dirilis
    User-->>PO: Feedback dalam sprint (usage, pain points)

Setiap lapisan feedback yang lebih lambat punya cost yang lebih besar. Workflow harus dirancang untuk mempersingkat setiap loop ini.

6. Review Workflow Secara Berkala #

Workflow bukan keputusan sekali jadi. Ia harus di-review secara reguler — dan tempat terbaik untuk itu adalah retrospective.

Pertanyaan untuk evaluasi workflow di retrospective:
  □ Tahap mana yang paling sering menjadi bottleneck sprint ini?
  □ Apakah ada status di board yang tidak pernah dipakai atau selalu ambigu?
  □ Apakah ada langkah dalam workflow yang terasa redundan atau tidak memberikan value?
  □ Apakah ada masalah yang berulang karena workflow tidak mencegahnya?
  □ Apakah workflow kita hari ini masih relevan dengan ukuran dan maturity tim saat ini?

Anti-Pattern Workflow yang Harus Dihindari #

Beberapa anti-pattern berikut adalah yang paling sering muncul di tim engineering — dan sering tidak disadari karena sudah terlalu lama berjalan.

// ✗ Terlalu banyak approval gate
Story harus disetujui oleh: TL, Senior Dev, Scrum Master, PO, dan QA Lead
sebelum bisa masuk sprint
→ Overhead lebih besar dari value yang dihasilkan
// ✓ Approval gate hanya ada di titik yang benar-benar menambah nilai
Misalnya: code review cukup 1 developer senior, bukan seluruh tim

// ✗ Workflow berbeda antara teori dan praktik
Board mengatakan ada 6 tahap, tapi tim tidak pernah mengisi
semua status dengan benar
→ Board tidak mencerminkan realita → tidak ada yang percaya pada board
// ✓ Sederhanakan workflow hingga tim bisa mengikutinya secara natural

// ✗ Workflow dipakai sebagai alat kontrol, bukan alat bantu
Manager memantau board untuk mengukur produktivitas individual
→ Developer mengisi status board untuk "terlihat sibuk", bukan untuk kolaborasi
// ✓ Workflow adalah alat koordinasi tim, bukan alat surveillance

// ✗ Workflow tidak pernah berubah meski tim sudah berkembang
"Ini workflow yang kita pakai dari dua tahun lalu, jangan diubah"
→ Workflow tidak lagi sesuai dengan ukuran tim, stack teknologi, atau domain
// ✓ Workflow di-review minimal sekali per kuartal atau saat ada perubahan signifikan

Checklist Merancang Workflow yang Sehat #

DESAIN AWAL:
  □ Workflow dirancang berdasarkan masalah nyata, bukan mengikuti tool
  □ Semua role (Dev, QA, PO) terlibat dalam merancang workflow
  □ Setiap tahap punya nama yang bermakna dan kriteria transisi yang jelas
  □ Jumlah status tidak lebih dari 7

WIP & FLOW:
  □ WIP limit diterapkan per tahap atau per developer
  □ Ada mekanisme untuk mendeteksi bottleneck (task yang macet terlalu lama)
  □ Prinsip finish before start diterapkan dan dipahami tim

KUALITAS:
  □ Definition of Done terintegrasi ke dalam workflow, bukan dokumen terpisah
  □ Ada gate otomatis (CI pipeline) yang tidak bisa di-bypass
  □ Code review adalah bagian dari alur, bukan langkah opsional

FEEDBACK:
  □ Workflow mendukung feedback loop yang cepat di setiap lapisan
  □ Bug yang ditemukan di testing langsung kembali ke developer yang sama hari itu
  □ Feedback dari stakeholder di Sprint Review langsung masuk ke backlog

EVALUASI BERKALA:
  □ Workflow dievaluasi setiap retrospective (minimal bertanya: ada bottleneck?)
  □ Perubahan pada workflow di-track dan efeknya diamati sprint berikutnya
  □ Tidak ada status atau langkah yang tidak pernah dipakai (hapus jika ada)

Ringkasan #

• Workflow adalah cara tim berkoordinasi, bukan daftar langkah — ia mencakup bagaimana requirement masuk, bagaimana kerja didistribusikan, dan bagaimana feedback kembali ke tim.
• Mulai dari masalah, bukan tool — rancang workflow untuk menjawab bottleneck nyata, lalu pilih tool yang mendukungnya.
• WIP limit adalah prinsip paling penting yang paling sering diabaikan — sedikit task selesai sepenuhnya jauh lebih baik dari banyak task yang hampir selesai.
• Setiap transisi status harus punya kriteria — tanpa kriteria transisi, board hanya label kosong yang tidak mencerminkan kondisi aktual.
• Definition of Done harus terintegrasi ke dalam workflow — bukan dokumen terpisah yang dibaca sekali lalu dilupakan.
• Workflow harus mendukung feedback loop yang cepat — semakin lambat feedback masuk, semakin mahal biaya kesalahan.
• Workflow yang tidak pernah berubah adalah workflow yang sudah usang — evaluasi secara berkala di retrospective dan jangan takut mengubah yang tidak bekerja.
• Workflow yang terlalu kaku dan terlalu longgar sama-sama berbahaya — cari keseimbangan yang cukup terstruktur untuk prediktabel, tapi cukup fleksibel untuk adaptif.

← Sebelumnya: Sprint   Berikutnya: RFC →