Definition of Done: Kenapa ‘Sudah Coding’ Belum Tentu Task Selesai

Banyak programmer pemula menganggap sebuah task sudah selesai ketika kode berhasil jalan di local machine.

Misalnya:

“Fitur login sudah selesai, Pak. Di laptop saya sudah bisa.”

Sekilas terdengar aman. Tapi dalam project nyata, terutama project yang dikerjakan tim, kalimat seperti itu belum cukup.

Kenapa?

Karena task software development tidak selesai hanya karena coding selesai.

Task baru bisa dianggap selesai ketika hasil pekerjaan sudah memenuhi standar yang disepakati tim. Standar inilah yang sering disebut Definition of Done.

---

Apa Itu Definition of Done?

Definition of Done adalah daftar kriteria yang menentukan kapan sebuah task benar-benar dianggap selesai.

Bukan selesai menurut perasaan developer.

Bukan selesai karena “sudah dicoding”.

Bukan selesai karena “tidak error di laptop saya”.

Tapi selesai karena sudah memenuhi standar kualitas yang disepakati oleh tim.

Contoh sederhananya:

Sebuah task dianggap selesai jika:

• acceptance criteria terpenuhi
• kode sudah dites
• kode sudah direview
• kode sudah di-merge
• fitur sudah bisa berjalan di environment yang ditentukan
• dokumentasi dibuat jika diperlukan

Dengan kata lain, Definition of Done membantu tim menjawab pertanyaan:

“Apakah task ini benar-benar siap dipakai, atau baru sekadar selesai diketik?”

---

Kenapa “Sudah Coding” Belum Cukup?

Coding hanyalah salah satu bagian dari proses development.

Dalam project nyata, fitur yang baik bukan hanya fitur yang bisa berjalan di komputer developer. Fitur tersebut juga harus bisa:

• dipahami oleh user
• sesuai kebutuhan bisnis
• aman dari bug besar
• bisa dibaca dan dipelihara developer lain
• bisa digabung dengan kode utama
• bisa berjalan di server atau environment target

Misalnya kamu mendapat task:

Membuat fitur upload dokumen untuk user.

Kamu membuat form upload, menyimpan file ke folder lokal, lalu berhasil melakukan upload dari laptopmu.

Apakah task selesai?

Belum tentu.

Ada banyak pertanyaan lanjutan:

• Apakah ukuran file dibatasi?
• Apakah tipe file divalidasi?
• Apakah pesan error sudah jelas?
• Apakah file bisa dibuka kembali?
• Apakah fitur sudah dites dengan file besar?
• Apakah path penyimpanan aman di server?
• Apakah sudah sesuai requirement user?
• Apakah sudah direview oleh senior atau teammate?
• Apakah sudah di-merge ke branch utama?
• Apakah sudah dicoba di staging?

Kalau semua itu belum jelas, maka kemungkinan task tersebut baru selesai secara coding, tapi belum selesai secara delivery.

---

Acceptance Criteria: Syarat Minimal Fitur Diterima

Salah satu bagian penting dari Definition of Done adalah acceptance criteria.

Acceptance criteria adalah daftar kondisi yang harus dipenuhi agar sebuah fitur dapat diterima.

Contoh task:

Sebagai admin, saya ingin dapat mengubah status user menjadi inactive agar user tersebut tidak dapat login ke sistem.

Acceptance criteria-nya bisa seperti ini:

1. Admin dapat melihat tombol "Deactivate" pada halaman detail user.
2. Setelah tombol ditekan, sistem menampilkan konfirmasi.
3. Jika admin menyetujui, status user berubah menjadi inactive.
4. User dengan status inactive tidak dapat login.
5. Sistem mencatat history perubahan status.
6. Admin melihat pesan sukses setelah proses berhasil.

Kalau developer hanya membuat tombol “Deactivate”, tapi belum membuat user inactive tidak bisa login, maka task belum selesai.

Walaupun coding sudah ada.

Walaupun tombol sudah muncul.

Walaupun tidak ada error.

Karena acceptance criteria belum terpenuhi.

---

Testing: Jangan Hanya Coba Happy Path

Kesalahan umum developer pemula adalah hanya mencoba skenario normal.

Contoh:

Upload file PDF ukuran kecil berhasil. Berarti fitur upload selesai.

Padahal fitur upload juga perlu diuji dengan skenario lain:

- Upload file dengan format tidak valid
- Upload file terlalu besar
- Upload tanpa memilih file
- Upload ketika koneksi lambat
- Upload file dengan nama yang sama
- Upload oleh user yang tidak punya akses

Testing bukan hanya membuktikan bahwa fitur bisa berjalan.

Testing juga membantu menemukan kemungkinan fitur gagal.

Dalam project nyata, bug sering muncul bukan di skenario normal, tapi di skenario pinggir atau edge case.

Contoh sederhana:

Happy path:
User mengisi semua field dengan benar, lalu submit berhasil.

Negative case:
User mengosongkan field wajib, lalu sistem harus menampilkan pesan error.

Edge case:
User mengisi nama dengan 255 karakter, sistem tetap harus aman dan tidak rusak.

Kalau fitur hanya dites dari satu jalur normal, task sebenarnya belum cukup matang.

---

Code Review: Kode Tidak Hanya Untuk Mesin

Kode memang dijalankan oleh komputer.

Tapi kode juga dibaca oleh manusia.

Karena itu, code review menjadi bagian penting dari Definition of Done.

Melalui code review, teammate atau senior developer bisa mengecek:

• apakah logic sudah benar
• apakah kode mudah dibaca
• apakah ada duplikasi
• apakah ada potensi bug
• apakah ada risiko security
• apakah perubahan terlalu besar dan sulit dipahami
• apakah naming variable dan function sudah jelas

Contoh kode yang “jalan” tapi kurang baik:

if (x == 1) {
    y = true;
}

Kode tersebut mungkin berjalan, tapi developer lain akan bertanya:

x itu apa?
1 itu status apa?
y itu maksudnya apa?

Kode yang lebih jelas:

if (userStatus == STATUS_ACTIVE) {
    canLogin = true;
}

Fungsinya mungkin sama, tapi versi kedua lebih mudah dipahami.

Di sinilah code review membantu. Bukan untuk mencari kesalahan personal, tapi untuk menjaga kualitas bersama.

---

Merge: Task Belum Selesai Kalau Masih di Branch Sendiri

Dalam workflow Git, developer biasanya bekerja di branch masing-masing.

Misalnya:

feature/user-deactivation

Kamu bisa saja sudah menyelesaikan kode di branch tersebut.

Tapi selama kode belum di-merge ke branch utama, misalnya develop, main, atau branch release, maka fitur tersebut belum benar-benar menjadi bagian dari aplikasi.

Kenapa ini penting?

Karena kode yang berjalan di branch sendiri belum tentu aman ketika digabung dengan kode orang lain.

Bisa saja terjadi:

• conflict dengan perubahan developer lain
• test gagal setelah merge
• ada dependency yang belum ikut masuk
• ada migration database yang belum dijalankan
• ada konfigurasi environment yang belum tersedia

Jadi, task yang masih berhenti di branch pribadi biasanya belum bisa dianggap selesai sepenuhnya.

---

Deploy: Local Machine Bukan Production

Kalimat klasik di dunia programming:

“Tapi di laptop saya jalan.”

Masalahnya, user tidak memakai laptop developer.

User memakai aplikasi yang berjalan di environment tertentu, misalnya development server, staging, UAT, atau production.

Karena itu, task yang sudah jalan di local belum tentu siap digunakan.

Perbedaan environment bisa menyebabkan masalah seperti:

- versi database berbeda
- environment variable belum tersedia
- permission folder berbeda
- konfigurasi server berbeda
- dependency belum terinstall
- file path berbeda antara Windows dan Linux

Contoh:

Di local kamu menyimpan file upload ke:

C:\Users\Alam\uploads

Tapi server production menggunakan Linux dan tidak punya path tersebut.

Akibatnya, fitur upload gagal setelah deploy.

Itulah kenapa mindset production-ready penting. Developer perlu berpikir:

“Apakah fitur ini hanya jalan di laptop saya, atau benar-benar siap berjalan di environment target?”

---

Dokumentasi: Tidak Semua Harus Panjang, Tapi Yang Penting Jangan Hilang

Tidak semua task membutuhkan dokumentasi formal yang panjang.

Namun beberapa perubahan perlu dicatat agar tidak membingungkan tim di kemudian hari.

Dokumentasi bisa diperlukan jika task mencakup:

• endpoint API baru
• perubahan struktur database
• konfigurasi environment baru
• perubahan flow bisnis
• rule validasi baru
• cara menjalankan job atau scheduler
• integrasi dengan sistem lain

Contoh dokumentasi sederhana untuk API:

POST /api/users/{id}/deactivate

Description:
Menonaktifkan user agar tidak dapat login.

Request:
- id: ID user

Response success:
{
  "message": "User deactivated successfully"
}

Business rule:
- Hanya admin yang dapat menonaktifkan user.
- User inactive tidak dapat login.

Dokumentasi seperti ini membantu frontend developer, QA, technical writer, support team, bahkan developer masa depan yang akan maintenance fitur tersebut.

---

Contoh Definition of Done Sederhana

Berikut contoh Definition of Done yang bisa digunakan dalam tim development:

Sebuah task dianggap Done jika:

1. Semua acceptance criteria sudah terpenuhi.
2. Kode sudah dibuat sesuai standar project.
3. Developer sudah melakukan self-testing.
4. Negative case dan edge case penting sudah dicek.
5. Unit test atau integration test dibuat jika diperlukan.
6. Tidak ada error besar di console atau log.
7. Pull request sudah dibuat.
8. Code review sudah selesai.
9. Feedback review sudah diperbaiki.
10. Kode sudah di-merge ke branch target.
11. Fitur sudah berhasil dijalankan di environment yang ditentukan.
12. Dokumentasi dibuat atau diperbarui jika ada perubahan penting.

Daftar ini bisa berbeda antar tim.

Tim kecil mungkin menggunakan versi yang lebih sederhana.

Tim enterprise mungkin punya standar yang lebih ketat, termasuk security scan, performance test, approval QA, dan release note.

Yang penting, tim punya definisi yang jelas dan disepakati bersama.

---

Contoh Kasus: Task Login dengan Google

Misalnya ada task:

Implement login menggunakan Google Account.

Developer pemula mungkin menganggap selesai ketika tombol “Login with Google” berhasil membuka popup dan mendapatkan email user.

Tapi kalau menggunakan Definition of Done, checklist-nya bisa lebih lengkap:

Acceptance Criteria:
- User bisa login menggunakan akun Google.
- Jika email sudah terdaftar, user masuk ke dashboard.
- Jika email belum terdaftar, sistem menampilkan pesan sesuai rule bisnis.
- Jika user membatalkan login, sistem menampilkan pesan yang sesuai.
- Jika token tidak valid, sistem menolak login.
- Login activity tercatat di log.

Testing:
- Test akun valid.
- Test akun belum terdaftar.
- Test cancel login.
- Test expired token.
- Test koneksi gagal.

Review:
- PR dibuat.
- Logic auth direview.
- Tidak ada credential hardcoded.

Deploy:
- Client ID dan secret tersedia di environment target.
- Callback URL sesuai dengan domain staging atau production.

Documentation:
- Environment variable dicatat.
- Flow login diperbarui jika diperlukan.

Dari contoh ini terlihat bahwa “sudah coding” hanyalah satu bagian kecil dari pekerjaan.

---

Mindset Production-Ready

Definition of Done mengajarkan developer untuk berpikir lebih luas.

Bukan hanya:

“Bagaimana cara membuat fitur ini jalan?”

Tapi juga:

“Bagaimana agar fitur ini aman, sesuai kebutuhan, bisa dites, bisa direview, bisa dimaintain, dan siap digunakan?”

Inilah perbedaan antara mindset local-ready dan production-ready.

Local-ready

- Jalan di laptop sendiri
- Dicoba satu skenario
- Belum tentu sesuai semua requirement
- Belum direview
- Belum siap dipakai user

Production-ready

- Sesuai acceptance criteria
- Sudah dites dengan skenario penting
- Sudah direview
- Sudah terintegrasi dengan kode utama
- Bisa berjalan di environment target
- Ada dokumentasi jika dibutuhkan

Developer yang punya mindset production-ready akan lebih dipercaya dalam tim, karena tidak hanya mengirim kode, tetapi mengirim hasil kerja yang benar-benar siap digunakan.

---

Kesalahan Umum Developer Pemula

Beberapa kesalahan yang sering terjadi:

1. Menganggap task selesai saat fitur terlihat jalan

Padahal bisa saja hanya tampilan yang benar, tapi rule bisnis belum lengkap.

Contoh:

Tombol approve sudah muncul, tapi belum ada validasi role user.

2. Tidak membaca acceptance criteria dengan teliti

Developer langsung coding tanpa memahami syarat diterimanya fitur.

Akibatnya, fitur selesai secara teknis tapi meleset dari kebutuhan user.

3. Tidak mencoba skenario gagal

Hanya mencoba input benar, tapi tidak mencoba input kosong, data invalid, atau akses tanpa permission.

4. Tidak mengecek dampak ke fitur lain

Perubahan kecil di satu module bisa merusak module lain.

Contoh:

Mengubah struktur response API tanpa koordinasi dengan frontend.

5. Tidak menulis catatan perubahan penting

Akibatnya, tim lain bingung ketika ada konfigurasi baru, endpoint baru, atau perubahan flow.

---

Checklist Pribadi Sebelum Bilang “Done”

Sebelum mengubah status task menjadi Done, coba tanyakan ke diri sendiri:

1. Apakah semua acceptance criteria sudah terpenuhi?
2. Apakah saya sudah mencoba skenario normal?
3. Apakah saya sudah mencoba skenario error?
4. Apakah tidak ada error mencurigakan di log?
5. Apakah kode saya mudah dibaca?
6. Apakah saya sudah membuat pull request?
7. Apakah feedback review sudah saya perbaiki?
8. Apakah kode sudah masuk ke branch target?
9. Apakah fitur berjalan di environment yang diminta?
10. Apakah ada dokumentasi yang perlu dibuat atau diperbarui?

Kalau banyak jawaban masih “belum”, berarti task belum benar-benar Done.

Mungkin task tersebut baru:

Coding Done

Tapi belum:

Development Done

---

Penutup

Dalam software development, menyelesaikan task bukan hanya tentang menulis kode.

Task yang baik harus memenuhi requirement, dites, direview, digabungkan, dijalankan di environment target, dan didokumentasikan jika perlu.

Itulah fungsi Definition of Done.

Definition of Done membantu developer dan tim memiliki standar yang sama tentang arti kata “selesai”.

Jadi, lain kali ketika ingin mengatakan:

“Task ini sudah selesai.”

Pastikan maksudnya bukan sekadar:

“Sudah jalan di laptop saya.”

Tapi benar-benar:

“Sudah siap digunakan sesuai standar tim.”