Workflow #
Setiap tim engineering punya cara kerja — ada yang terdokumentasi, ada yang hanya ada di kepala masing-masing anggota. Yang membedakan tim yang produktif dari yang sering kacau bukan seberapa canggih tools-nya, melainkan seberapa jelas alur dari sebuah ide menjadi fitur yang benar-benar sampai ke tangan pengguna. Itulah esensi workflow. Tapi dalam praktiknya, workflow sering dirancang salah: terlalu kaku sehingga menghambat, atau terlalu longgar sehingga tidak memberikan struktur apapun. Artikel ini membahas apa itu workflow dalam konteks engineering, mengapa ia penting, bagaimana merancangnya dengan benar, dan anti-pattern apa yang harus dihindari.
Apa Itu Workflow dalam Software Engineering? #
Workflow adalah pola alur kerja yang disepakati tim untuk mengubah kebutuhan menjadi software yang siap digunakan. Definisi ini terdengar sederhana, tapi cakupannya luas: workflow mencakup bagaimana sebuah ide masuk ke sistem, bagaimana prioritas ditentukan, kapan developer mulai mengerjakan sesuatu, bagaimana perubahan diuji dan di-review, sampai bagaimana feedback dari pengguna kembali masuk ke backlog.
Dalam Scrum, workflow hidup di antara artefak dan event yang sudah ada:
Product Backlog
│
▼
Sprint Planning ←── Workflow menentukan: story apa yang siap diambil?
│
▼
Sprint Execution ←── Workflow menentukan: bagaimana developer bekerja sehari-hari?
│ ←── Bagaimana code review dan testing dilakukan?
▼
Sprint Review ←── Workflow menentukan: apa yang dianggap "selesai" dan siap demo?
│
▼
Retrospective ←── Workflow dievaluasi dan diperbaiki di sini
Workflow bukan Scrum itu sendiri — ia adalah cara tim mengoperasionalkan Scrum agar kerja sehari-hari tetap terstruktur tanpa kehilangan fleksibilitas.
Workflow Bukan Proses Kaku #
Kesalahan paling umum dalam merancang workflow adalah memperlakukannya seperti SOP pabrik — aturan tetap yang harus diikuti tanpa pertanyaan. Tim yang jatuh ke dalam perangkap ini biasanya menghasilkan workflow yang penuh bottleneck, banyak friction antar role, dan fokus ke compliance daripada value.
// ANTI-PATTERN: Workflow sebagai aturan kaku
"Setiap story WAJIB melalui 5 approval gate: PM → Tech Lead → Senior Dev → QA Lead → CTO"
→ Story sederhana (fix typo, update config) menunggu berminggu-minggu
→ Tim menyiasati dengan bypass informal
→ Workflow ada di atas kertas, tidak di praktik
// BENAR: Workflow yang proporsional dengan risiko
Story berisiko rendah: Developer → Code Review → Merge
Story berisiko sedang: Developer → Code Review → QA → Merge
Story berisiko tinggi: Developer → Code Review → QA → Tech Lead review → Staging → Merge
Di sisi lain, workflow yang terlalu longgar juga bermasalah:
// ANTI-PATTERN: Tidak ada workflow yang disepakati
"Kalau sudah selesai, langsung push dan deploy aja"
→ Tidak ada code review → bug lolos ke production
→ Tidak ada testing gate → regresi tidak terdeteksi
→ Tidak ada visibility → tidak ada yang tahu siapa mengerjakan apa
// BENAR: Workflow minimal tapi konsisten
Setiap perubahan melalui: branch → PR → review → merge → CI/CD
Setiap story melalui: To Do → In Progress → In Review → Done
Workflow yang sehat berada di titik keseimbangan: cukup terstruktur untuk memberikan predictability, cukup fleksibel untuk tidak menghambat.
Mengapa Workflow Penting bagi Tim Engineering #
Menciptakan Predictability #
Tim yang tidak punya workflow yang jelas selalu kesulitan menjawab pertanyaan sederhana: kapan fitur ini selesai? Di tahap mana story ini sekarang? Apa yang sedang menghambat?
Predictability bukan tentang estimasi yang sempurna. Ini tentang alur kerja yang konsisten sehingga tim dan stakeholder bisa punya gambaran yang sama tentang kondisi pekerjaan saat ini.
Tim tanpa workflow jelas:
PM: "Story A sudah selesai belum?"
Dev: "Hampir, tinggal testing"
QA: "Belum ada yang kasih ke saya untuk dites"
→ Tidak ada yang tahu status sebenarnya
Tim dengan workflow jelas:
Board: Story A ada di kolom "In Review"
→ Semua tahu: kode sudah selesai, menunggu code review
→ QA tahu kapan harus bersiap
→ PM tahu kapan bisa di-demo
Mengurangi Cognitive Load Developer #
Tanpa workflow yang jelas, developer menghabiskan energi untuk hal-hal yang seharusnya sudah terjawab oleh sistem: apakah task ini sudah siap dikerjakan? Perlu approval dulu atau langsung mulai? Setelah selesai kode, langsung ke QA atau harus ada code review dulu?
Setiap keputusan kecil yang berulang seperti ini menguras energi mental yang seharusnya dipakai untuk problem teknikal yang lebih substansial. Workflow yang baik menghilangkan keputusan-keputusan rutin tersebut dari kepala developer — jawabannya sudah ada di sistem.
Menjaga Kualitas Tanpa Memperlambat Delivery #
Workflow bukan hanya soal kecepatan — ia adalah mekanisme kontrol kualitas. Pertanyaannya: kapan code review wajib? Kapan automated test menjadi gate sebelum merge? Kapan manual verification dibutuhkan?
Tanpa gate kualitas dalam workflow:
Story selesai di dev → langsung deploy → bug ditemukan di production
Cost: tinggi (user terdampak, hotfix urgent, reputasi rusak)
Dengan gate kualitas terintegrasi dalam workflow:
Story selesai di dev → code review → CI test lulus → QA → deploy
Cost: rendah (bug ditemukan sebelum sampai ke user)
Workflow yang matang menjadikan kualitas sebagai bagian dari alur, bukan sebagai fase terpisah yang “dilakukan kalau ada waktu.”
Menjadi Bahasa Bersama Tim #
Workflow yang terdokumentasi dan disepakati adalah bahasa bersama antara product dan engineering, antara engineering dan QA, antara tim dan stakeholder. Ketika ada masalah — story tidak selesai tepat waktu, bug lolos ke production, handoff yang lambat — workflow membantu mendiagnosisnya sebagai masalah sistem, bukan menyalahkan individu.
Tanpa workflow:
Bug lolos ke production
→ "Siapa yang tidak testing?"
→ Finger pointing, moral turun
Dengan workflow:
Bug lolos ke production
→ "Di tahap mana bug ini seharusnya tertangkap?"
→ "Apakah gate QA-nya tidak cukup? Atau acceptance criteria kurang jelas?"
→ Identifikasi masalah sistemik → perbaikan workflow
Prinsip Merancang Workflow yang Sehat #
1. Mulai dari Masalah, Bukan Tool #
Workflow sering gagal karena dirancang terbalik — dimulai dari tool yang sudah dipilih, lalu workflow disesuaikan agar cocok dengan tool tersebut. Hasilnya: workflow yang memaksakan cara kerja yang tidak natural bagi tim.
// ANTI-PATTERN: Workflow didiktekan tool
"Kita pakai Jira, jadi workflow kita: Backlog → Selected for Dev → In Progress
→ In Review → QA → Done (karena itu default Jira)"
→ Status tidak mencerminkan realita kerja tim
→ Board hanya untuk laporan ke manajemen, bukan alat kerja tim
// BENAR: Tool dikonfigurasi mengikuti workflow tim
Tim mengidentifikasi masalah dulu:
"Kita sering tidak tahu story mana yang siap dikerjakan"
"Code review sering menumpuk dan tidak ada yang notice"
"QA sering surprised saat sprint mau berakhir"
→ Rancang workflow yang menjawab masalah ini
→ Baru konfigurasi Jira/Linear/Trello mengikuti workflow tersebut
2. Visualisasikan Alur Kerja #
Workflow yang tidak terlihat tidak bisa dievaluasi. Papan Kanban — baik fisik maupun digital — adalah cara paling efektif untuk membuat workflow menjadi visible.
Prinsip papan yang efektif:
✓ Setiap kolom merepresentasikan satu status yang bermakna
✓ Transisi antar kolom jelas: kapan sebuah card berpindah?
✓ Jumlah kolom minimal tapi cukup (5–7 kolom adalah sweet spot)
✓ Card yang sudah lama tidak bergerak mudah teridentifikasi
Contoh kolom workflow tim engineering:
┌──────────┬────────────┬───────────┬───────────┬──────────┬──────────┐
│ Backlog │ Selected │ In │ In │ QA │ Done │
│ (Ready) │ for Dev │ Progress │ Review │ Testing │ │
└──────────┴────────────┴───────────┴───────────┴──────────┴──────────┘
Kolom "Selected for Dev": story yang sudah memenuhi DoR, siap diambil
Kolom "In Review": kode selesai, PR open, menunggu reviewer
Kolom "QA Testing": PR merged ke staging, menunggu verifikasi QA
3. Batasi Work in Progress (WIP) #
WIP limit adalah salah satu prinsip terpenting dari Kanban yang sering diabaikan saat tim mengadopsi workflow berbasis board. Tanpa batasan WIP, papan terlihat ramai tapi deliverynya lambat.
// ANTI-PATTERN: Tidak ada WIP limit
In Progress: story A (Dev 1), story B (Dev 2), story C (Dev 1), story D (Dev 3)
In Review: story E, story F, story G, story H
QA Testing: story I, story J, story K
→ Code review menumpuk → tidak ada yang segera di-review
→ Developer tidak bisa mulai story baru karena review menunggu
→ QA kewalahan dengan banyak story sekaligus
→ Banyak story "hampir selesai" tapi tidak ada yang benar-benar Done
// BENAR: WIP limit diterapkan per kolom
In Progress: maks 3 story (satu per developer aktif)
In Review: maks 2 story (setiap PR harus di-review dalam 4 jam)
QA Testing: maks 3 story
→ Developer selesaikan dulu yang ada sebelum ambil yang baru
→ Review tidak menumpuk karena ada batas yang memaksa prioritas
→ Bottleneck terlihat jelas: jika kolom Review penuh, dev bantu review dulu
WIP limit memaksa tim untuk menyelesaikan pekerjaan sebelum memulai yang baru. Ini terasa counter-intuitive tapi secara konsisten menghasilkan throughput yang lebih tinggi karena menghilangkan multi-tasking dan context switching.
Mulai dengan WIP limit yang longgar (misalnya jumlah developer + 1 per kolom), lalu kencangkan secara bertahap berdasarkan observasi. WIP limit yang terlalu ketat di awal bisa justru menghambat sebelum tim terbiasa dengan ritmenya.4. Jadikan Definition of Done Penjaga Workflow #
Workflow dan Definition of Done (DoD) harus saling menguatkan. DoD mendefinisikan kapan sebuah story boleh berpindah ke kolom “Done” — dan ini harus eksplisit, bukan diserahkan ke penilaian masing-masing developer.
// ANTI-PATTERN: Done = kode selesai di lokal developer
Developer push kode → mark story sebagai Done
→ QA baru test esok hari → ditemukan bug → dibuka kembali
→ "Done" yang tidak benar-benar Done merusak kepercayaan pada board
// BENAR: Done = kriteria yang disepakati tim terpenuhi semua
Story dianggap Done jika:
□ Kode sudah merged ke branch utama (bukan hanya di PR)
□ CI pipeline lulus (unit test, integration test, linting)
□ QA sudah memverifikasi di staging environment
□ Acceptance criteria semua terpenuhi
□ Tidak ada known bug yang di-defer tanpa tiket
Ketika DoD terintegrasi dalam workflow, kolom “Done” memiliki makna yang sama bagi semua anggota tim.
5. Rancang Workflow untuk Mendukung Feedback Cepat #
Scrum menekankan feedback loop — dan workflow adalah mekanisme utama untuk mempercepat atau memperlambat feedback tersebut. Workflow yang baik meminimalkan waktu antara “kode selesai” dan “feedback masuk.”
Alur feedback yang lambat:
Kode selesai → PR dibuat → menunggu 2 hari untuk di-review
→ Review ada komentar → developer baru lihat 1 hari kemudian
→ Fix → QA baru bisa test setelah 3 hari
Total: 6+ hari dari "selesai" ke feedback
Alur feedback yang cepat:
Kode selesai → PR dibuat → notifikasi ke reviewer → review dalam 4 jam
→ Feedback langsung didiskusikan → fix hari yang sama
→ QA langsung test saat story masuk staging
Total: 1–2 hari dari "selesai" ke feedback
Beberapa mekanisme yang membantu feedback cepat:
- SLA review: setiap PR harus mendapat review pertama dalam N jam
- Notifikasi otomatis saat ada PR baru atau saat pipeline gagal
- QA mulai testing segera saat story pertama masuk staging, bukan menunggu akhir sprint
- Pair programming atau mob programming untuk feedback instan tanpa menunggu PR
6. Review Workflow Secara Berkala #
Workflow bukan keputusan sekali jadi. Tim yang bertumbuh, produk yang berubah, dan stack teknologi yang evolve — semua ini mempengaruhi apakah workflow yang ada masih relevan.
Pertanyaan untuk evaluasi workflow di retrospective:
□ Tahap mana yang paling sering membuat story macet (stuck)?
□ Apakah ada kolom di board yang sering kosong atau selalu penuh?
□ Apakah ada aturan workflow yang sering diakali tim?
□ Apakah ada handoff yang butuh waktu terlalu lama?
□ Apakah workflow masih sesuai dengan ukuran dan komposisi tim saat ini?
Perubahan workflow tidak harus besar. Perubahan kecil tapi konsisten — misalnya menambahkan SLA review, atau menggabungkan dua kolom yang ternyata redundant — jauh lebih sehat daripada redesign besar yang dilakukan sekali setahun.
Jika anggota tim secara rutin meng-bypass atau tidak mengikuti workflow yang ada, itu adalah sinyal bahwa workflow perlu diperbaiki — bukan bahwa timnya tidak disiplin. Workflow yang baik diikuti secara alami karena memang membantu pekerjaan, bukan karena ada yang mengawasi.
Anti-Pattern yang Harus Dihindari #
Terlalu Banyak Approval Gate #
Setiap approval gate menambahkan waktu tunggu. Untuk perubahan berisiko tinggi, ini masuk akal. Tapi ketika setiap perubahan — bahkan yang trivial — harus melewati banyak gate, workflow menjadi bottleneck.
// ✗ Anti-pattern: Gate yang tidak proporsional
Fix typo di dokumentasi:
Developer → PM approval → Tech Lead review → QA test → CTO sign-off → Merge
→ Proses: 3–5 hari untuk perubahan 2 kata
// ✓ Solusi: Gate yang proporsional dengan risiko perubahan
Low risk (typo, config minor): Developer → peer review → merge
Medium risk (fitur baru): Developer → code review → QA → merge
High risk (payment, auth): Developer → code review → QA → Tech Lead → staging period → merge
Workflow yang Berbeda antara Teori dan Praktik #
Ini adalah anti-pattern yang paling berbahaya karena tidak terlihat dari luar. Board terlihat rapi, workflow terdokumentasi, tapi di lapangan tim bekerja berbeda.
// ✗ Anti-pattern: Workflow di kertas vs di praktik
Di dokumentasi: Story harus through QA sebelum Done
Di praktik: Developer langsung Done saat kode merged karena "QA nanti menyusul"
→ Board tidak merepresentasikan realita
→ PM dan stakeholder membuat keputusan berdasarkan data yang tidak akurat
→ Bug lolos ke production karena QA step diskip
// ✓ Solusi: Audit reguler antara workflow yang didokumentasikan vs yang dipraktikkan
Setiap retrospective: "Apakah kita benar-benar mengikuti workflow yang kita sepakati?"
Jika tidak: perbaiki workflow (bukan paksa orang mengikuti aturan yang tidak practical)
Workflow Dirancang untuk Mengontrol, Bukan Membantu #
Beberapa workflow dirancang lebih untuk memberikan visibility ke manajemen daripada untuk membantu tim bekerja lebih efektif. Ini menghasilkan workflow yang terasa seperti surveillance, bukan struktur.
// ✗ Workflow untuk kontrol:
Setiap task harus di-update statusnya setiap 2 jam
Daily report harus diisi manual oleh setiap developer
Manager bisa melihat real-time siapa yang sedang mengerjakan apa
→ Developer menghabiskan waktu update status daripada coding
→ Trust erosi karena developer merasa diawasi
→ Produktivitas turun, bukan naik
// ✓ Workflow untuk membantu:
Board di-update saat status benar-benar berubah (pindah kolom)
Visibility datang dari board yang akurat, bukan dari micro-reporting
Workflow membuat pekerjaan lebih mudah diselesaikan, bukan lebih banyak dilaporkan
Tidak Pernah Memperbarui Workflow #
Workflow yang tidak pernah berubah adalah workflow yang sudah mati. Tim yang bertumbuh dari 3 developer menjadi 10 developer tidak bisa menggunakan workflow yang sama. Tim yang berpindah dari monolith ke microservices perlu menyesuaikan cara kerjanya.
// ✗ Anti-pattern: Workflow dibuat sekali, tidak pernah di-review
"Ini workflow kita sejak 2 tahun lalu, kita ikuti saja"
→ Tim baru kebingungan karena workflow tidak mencerminkan cara kerja saat ini
→ Banyak langkah workflow yang sudah tidak relevan tapi masih diikuti
// ✓ Solusi: Review workflow minimal setiap kuartal
Agenda tetap retrospective: "Apakah ada bagian workflow yang perlu diubah?"
Perubahan kecil → implementasi langsung di sprint berikutnya
Perubahan besar → diskusi dedicated, eksperimen selama 2 sprint, evaluasi
Workflow dan Tooling #
Tool adalah enabler, bukan penentu workflow. Pilihan tool yang tepat bisa mempercepat adopsi workflow yang baik — tapi tool yang salah tidak bisa memperbaiki workflow yang buruk.
Beberapa pertimbangan saat memilih tool untuk workflow:
Pertanyaan yang perlu dijawab sebelum memilih tool:
□ Apakah tool ini bisa dikonfigurasi mengikuti workflow kita?
(bukan sebaliknya)
□ Apakah semua role — developer, QA, PM — bisa menggunakannya?
□ Apakah visibility-nya cukup tanpa memerlukan manual update berlebihan?
□ Apakah terintegrasi dengan toolchain yang sudah ada (GitHub, CI/CD)?
□ Apakah biayanya proporsional dengan ukuran tim?
Tool yang populer dan cocok untuk workflow engineering:
Linear → cocok untuk tim produk yang cepat, UI bersih, opiniated workflow
Jira → fleksibel untuk tim besar, bisa sangat dikustomisasi
GitHub Projects → cocok jika tim sudah all-in di GitHub, tanpa tool tambahan
Notion → cocok untuk tim kecil yang butuh dokumentasi terintegrasi
Trello → paling sederhana, cocok untuk tim yang baru mulai dengan Kanban
Yang paling penting: gunakan tool yang benar-benar dipakai tim, bukan yang paling canggih atau paling populer.
Checklist Workflow yang Sehat #
DESAIN WORKFLOW:
□ Workflow dirancang berdasarkan masalah tim, bukan default tool
□ Setiap kolom/status memiliki definisi yang jelas dan disepakati
□ Transisi antar status memiliki kriteria yang jelas (kapan card berpindah?)
□ Gate kualitas proporsional dengan risiko perubahan
□ Tidak ada langkah yang ada "karena dulu begitu" tanpa alasan jelas
VISIBILITY DAN WIP:
□ Board selalu mencerminkan status pekerjaan aktual
□ WIP limit ditetapkan dan diterapkan per kolom
□ Pekerjaan yang stuck (tidak bergerak > 2 hari) mudah terlihat
□ Semua role (dev, QA, PM) bisa membaca board dan memahami kondisi
DEFINITION OF DONE:
□ DoD terdokumentasi dan disepakati seluruh tim
□ DoD diintegrasikan dalam workflow (bukan dokumen terpisah)
□ Tidak ada story yang di-mark Done tanpa memenuhi DoD
FEEDBACK DAN ADAPTASI:
□ Ada SLA untuk review (PR harus di-review dalam N jam)
□ QA tidak menunggu akhir sprint untuk mulai testing
□ Workflow dievaluasi di setiap retrospective
□ Perubahan workflow di-track: dicoba selama 2 sprint, lalu dievaluasi
ADOPSI TIM:
□ Workflow diikuti secara konsisten tanpa perlu pengingat atau pengawasan
□ Tidak ada langkah yang sering di-bypass
□ Anggota baru bisa memahami workflow dalam 1–2 hari
□ Workflow terdokumentasi dan mudah diakses
Ringkasan #
- Workflow adalah cara tim mengoperasionalkan Scrum — ia hidup di antara artefak dan event Scrum, menentukan bagaimana pekerjaan mengalir sehari-hari.
- Workflow bukan proses kaku — ia harus evolusioner, kontekstual, dan disepakati bersama. Workflow yang tidak pernah berubah adalah workflow yang sudah tidak relevan.
- Mulai dari masalah, bukan tool — identifikasi bottleneck dan friction yang ada, rancang workflow yang menjawabnya, baru pilih tool yang mendukung.
- Visualisasikan workflow — board yang akurat adalah sumber kebenaran bersama. Workflow yang tidak terlihat tidak bisa dievaluasi dan diperbaiki.
- WIP limit bukan hambatan — ia adalah akselerator — membatasi pekerjaan yang berjalan bersamaan meningkatkan throughput karena menghilangkan context switching dan mengurangi pekerjaan yang menggantung.
- Gate kualitas harus proporsional dengan risiko — terlalu banyak approval gate membunuh kecepatan; terlalu sedikit membiarkan bug lolos. Rancang gate yang sesuai dengan level risiko setiap jenis perubahan.
- DoD adalah penjaga workflow — tanpa DoD yang terintegrasi, kolom “Done” tidak bermakna dan board tidak bisa dipercaya.
- Workflow yang baik mempercepat feedback — dari code review, dari QA, dari stakeholder. Semakin cepat feedback masuk, semakin kecil biaya kesalahan.
- Jika workflow sering di-bypass, itu masalah workflow, bukan masalah orangnya — workflow yang baik diikuti secara alami karena memang membantu.
- Review workflow secara berkala — gunakan retrospective untuk bertanya mana yang macet, mana yang tidak relevan, dan perubahan kecil apa yang bisa dicoba sprint berikutnya.