Task Breakdown SDD: Memecah Spec Golang Menjadi Unit Kerja yang Executable
Teknik task breakdown dalam Specification-Driven Development: memecah spec Golang menjadi unit kerja kecil yang bisa dieksekusi secara incremental dengan Claude Code.
Task Breakdown: Memecah Spec Menjadi Unit Kerja Golang
Task breakdown golang SDD adalah jembatan yang hilang antara plan yang bagus dan eksekusi yang rapi. Implementation plan yang sudah dibuat di Plan Mode masih terlalu abstrak untuk langsung dikerjakan. “Implementasikan CancelWithStockRestore di repository” adalah plan item, bukan task yang bisa di-assign ke developer dan di-track progress-nya.
Task Breakdown adalah proses memecah implementation plan menjadi unit-unit kerja yang:
- Bisa diselesaikan dalam 1-4 jam
- Punya clear definition of done
- Bisa di-commit secara independen
- Bisa di-test secara isolated
Di artikel ini, kita bahas teknik task breakdown yang efektif untuk SDD workflow di Golang.
11.1 Mengapa Task Breakdown Penting
Ada pola yang sangat umum: developer punya spec bagus, punya plan bagus, tapi eksekusinya berantakan karena tidak ada task breakdown yang jelas. Dua timeline berikut memperlihatkan bedanya bekerja tanpa dan dengan breakdown.
1Tanpa task breakdown:
2
3Day 1 pagi: Mulai implementasi (buka semua file sekaligus)
4Day 1 siang: Setengah-setengah, banyak uncommitted changes
5Day 1 sore: "Stuck" di satu bagian yang ternyata complex
6Day 2: Masih "in progress," tidak jelas berapa persen selesai
7Day 3: Akhirnya selesai, tapi susah di-review karena satu PR raksasaTanpa breakdown, progress tidak terukur dan risiko menumpuk di akhir. Bandingkan dengan pendekatan yang memecah pekerjaan menjadi task kecil ber-commit.
1Dengan task breakdown:
2
3Task 1 (30 menit): Tambah StatusCancelled ke entity.go → commit
4Task 2 (45 menit): Tambah interface methods ke repository.go → commit
5Task 3 (60 menit): Implementasi SQL di order_repository.go → commit
6Task 4 (90 menit): Implementasi CancelOrderUseCase → commit + test
7Task 5 (60 menit): Implementasi HTTP handler → commit
8Task 6 (30 menit): Integrasi dan smoke test → commit
9Total: ~6 jam, 6 commits, progress terukurPerbedaannya bukan pada total waktu, tapi pada visibilitas dan kontrol: setiap commit adalah checkpoint yang bisa diverifikasi dan di-rollback.
11.2 Prinsip Task Breakdown yang Efektif
Prinsip 1: Single Responsibility per Task
Setiap task harus punya satu tujuan yang jelas. Bukan “implementasi cancel order” (terlalu besar), bukan “tambah field” (bisa lebih besar dari kelihatannya jika ada cascade effects). Contoh berikut mengkontraskan task yang fokus dengan task yang terlalu luas.
1✅ Task yang baik:
2"Tambah method GetByIDAndUserID ke OrderRepository interface
3dan implementasi di PostgreSQL repository"
4
5Ini jelas: satu interface change, satu SQL query, satu test.
6
7❌ Task yang terlalu besar:
8"Implementasi semua repository methods untuk cancel order"Task yang fokus pada satu perubahan membuat estimasi lebih akurat dan review lebih cepat karena scope-nya bisa dipegang dalam kepala sekaligus.
Prinsip 2: Verifiable Definition of Done
Setiap task harus punya kriteria selesai yang bisa di-check. Contoh berikut menunjukkan definition of done yang objektif, bukan sekadar “sudah selesai”.
1Task: Implementasi CancelOrderUseCase
2Done when:
3✅ File cancel_order.go ada dengan struct dan method yang benar
4✅ go build ./... berhasil tanpa error
5✅ Unit test untuk happy path lulus
6✅ Unit test untuk AC7-AC10 (semua error cases) lulus
7✅ go test -race ./internal/usecase/order/... lulusDengan kriteria yang bisa dicek satu per satu, “selesai” berhenti menjadi opini dan menjadi fakta yang bisa diverifikasi siapa saja.
Prinsip 3: Independent Commit
Setiap task harus bisa di-commit secara independen tanpa breaking build. Contoh berikut menunjukkan cara menjaga buildability dengan stub sementara.
1Task 2: Tambah interface methods ke repository.go
2→ Tambah methods ke interface
3→ Tambah stub implementation di postgres/order_repository.go
4 (bisa return error "not implemented" sementara)
5→ go build harus masih lulus
6→ Commit: "feat(order): add cancel order repository interface"Menjaga setiap commit tetap bisa di-build berarti riwayat git selalu berada di state yang sehat — kapan pun kamu bisa bisect atau rollback tanpa menemukan commit yang rusak.
Prinsip 4: 1-4 Jam per Task
Task yang lebih pendek dari 1 jam sering terlalu granular (overhead lebih dari value). Task yang lebih panjang dari 4 jam sudah terlalu besar dan perlu dipecah lagi. Rentang ini adalah sweet spot antara tracking yang berguna dan overhead yang minimal.
11.3 Task Breakdown untuk Cancel Order: Contoh Lengkap
Dari implementation plan di artikel sebelumnya, berikut task breakdown yang lebih terstruktur. Dokumen berikut memecah fitur cancel order menjadi sembilan task dengan estimasi, file, dan definition of done masing-masing.
1# Task Breakdown: Cancel Order Feature
2# Spec: specs/order/cancel-order.md v1.3
3# Total estimasi: 6-8 jam
4
5## TASK 1: Domain Entity Update [30 menit]
6File: internal/domain/order/entity.go
7Changes:
8- Tambah StatusCancelled Status = "CANCELLED" ke enum
9- Tambah method CanBeCancelled() bool
10 (return true jika Status == StatusPending && time.Since(CreatedAt) <= 15*time.Minute)
11Done when: go test ./internal/domain/... lulus
12
13## TASK 2: Repository Interface [30 menit]
14File: internal/domain/order/repository.go
15Changes:
16- Tambah GetByIDAndUserID(ctx, orderID, userID uuid.UUID) (*Order, error)
17- Tambah CancelWithStockRestore(ctx, orderID uuid.UUID) error
18- Update mock: mockgen -source=... -destination=...
19Done when: go build ./... lulus, mock terupdate
20
21## TASK 3: Database Migration [20 menit]
22File: migrations/20250701_cancel_order_index.sql
23Content: CREATE INDEX CONCURRENTLY IF NOT EXISTS idx_orders_user_id_status
24 ON orders(user_id, status) WHERE deleted_at IS NULL;
25Done when: Migration tested di local development DB
26
27## TASK 4: Repository Implementation [90 menit]
28File: internal/repository/postgres/order_repository.go
29Changes:
30- Implementasi GetByIDAndUserID
31- Implementasi CancelWithStockRestore (dengan transaction + SELECT FOR UPDATE)
32Done when: Integration test dengan test DB lulus untuk kedua methods
33
34## TASK 5: UseCase Implementation [90 menit]
35File: internal/usecase/order/cancel_order.go
36Changes:
37- CancelOrderInput struct
38- CancelOrderUseCase struct + constructor
39- Execute method dengan full business logic
40- Custom error types
41Done when: go build lulus
42
43## TASK 6: UseCase Tests [60 menit]
44File: internal/usecase/order/cancel_order_test.go
45Coverage required:
46- TestSuccess (AC1-AC6)
47- TestOrderNotFound (AC7, AC8)
48- TestNotCancellable_Confirmed (AC9)
49- TestNotCancellable_WindowExpired (AC10)
50- TestConcurrentCancel_BothCall_OnlyOneSucceeds (EC1 — via mock)
51- TestKafkaFails_StillSucceeds (EC2)
52Done when: go test -race -cover ./internal/usecase/order/... Coverage > 85%, semua lulus
53
54## TASK 7: HTTP Handler [60 menit]
55File: internal/delivery/http/handler/order_handler.go
56Changes:
57- CancelOrder method
58- Error mapping (ErrOrderNotFound→404, NotCancellable→409, etc.)
59Done when: Handler test lulus untuk happy path dan semua error cases
60
61## TASK 8: Route Registration [15 menit]
62File: internal/delivery/http/router/router.go
63Changes:
64- Tambah: DELETE /api/v1/orders/:id → handler.CancelOrder
65- Pastikan middleware auth terpasang
66Done when: go build lulus, route test lulus
67
68## TASK 9: End-to-End Smoke Test [30 menit]
69Action: manual curl test untuk happy path (204), not found (404), already confirmed (409)
70Done when: Semua manual test scenarios berhasil sesuai expected
71
72## Dependencies Antar Task
73Task 1 → Task 2 → Task 4 → Task 5 → Task 6
74Task 3 (bisa paralel dengan Task 1-2)
75Task 5 → Task 7 → Task 8 → Task 9Perhatikan bagian Dependencies di akhir: memetakan urutan antar task sejak awal mencegah kamu memulai Task 4 sebelum Task 2 yang menjadi prasyaratnya selesai.
11.4 Menggunakan Claude Code untuk Task Breakdown
Setelah plan di-approve, kita bisa minta Claude Code untuk mem-breakdown plan menjadi task list. Prompt berikut menetapkan requirement eksplisit untuk setiap task agar output langsung bisa dipakai.
1Berdasarkan implementation plan yang sudah kita buat untuk cancel order,
2buat task breakdown yang lebih granular.
3
4Requirements untuk setiap task:
51. Estimasi waktu (dalam menit)
62. File yang diubah
73. Perubahan spesifik yang dilakukan
84. Definition of Done (bagaimana tahu task ini selesai?)
95. Dependencies ke task lain
10
11Format: Markdown list yang bisa langsung di-copy ke project management tool.
12Target: Setiap task 30-90 menit. Tidak ada yang lebih dari 2 jam.Dengan menetapkan lima requirement dan batas waktu per task, kamu memaksa Claude menghasilkan breakdown yang actionable — bukan daftar bullet abstrak yang masih perlu diterjemahkan.
11.5 Executing Tasks Secara Incremental
Setelah task breakdown ada, eksekusi dilakukan satu task per waktu dengan Claude Code. Prompt pembuka berikut memulai Task 1 dengan referensi spec dan kriteria verifikasi.
1Task 1 — Mulai:
2"Implementasikan Task 1: tambah StatusCancelled ke entity.go
3dan method CanBeCancelled().
4
5Spec: Cancel hanya bisa dalam 15 menit pertama (AC4) dan hanya jika status PENDING (AC3).
6
7Setelah selesai, tunjukkan perubahan yang dibuat dan
8konfirmasi bahwa go test ./internal/domain/... lulus."Perhatikan bahwa prompt menyertakan AC yang relevan dan langkah verifikasi. Setelah Task 1 selesai dan di-commit, lanjut ke Task 2 dengan menegaskan state sebelumnya.
1Task 2 — Lanjut:
2"Task 1 sudah selesai dan di-commit.
3Sekarang implementasikan Task 2: tambah dua method ke OrderRepository interface
4dan update mock dengan mockgen.
5
6Method signatures yang dibutuhkan:
7[dari plan]
8
9Setelah selesai, jalankan go build ./... untuk verify tidak ada compile error."Pendekatan incremental ini memberikan beberapa keuntungan: setiap langkah bisa di-verify sebelum lanjut, error mudah diisolasi ke task tertentu, progress terukur, dan rollback lebih mudah jika ada masalah.
11.6 Task yang Baik vs Task yang Buruk
Untuk mengasah intuisi ukuran task, mari bandingkan tiga contoh: terlalu besar, terlalu kecil, dan tepat.
Task yang Terlalu Besar
Contoh berikut adalah task tanpa scope jelas yang bisa membengkak menjadi seharian penuh.
1❌ Task: "Implementasikan cancel order endpoint"
2Masalah: Tidak jelas scope-nya, tidak ada definition of done,
3 bisa butuh 1 hari atau lebih.Task sebesar ini menyembunyikan kompleksitas dan membuat progress mustahil diukur di tengah jalan.
Task yang Terlalu Kecil
Sebaliknya, contoh berikut terlalu granular sehingga overhead tracking-nya melebihi nilainya.
1❌ Task: "Tambah import 'time' ke cancel_order.go"
2Masalah: Terlalu granular, overhead tracking lebih dari value.
3 Ini harusnya bagian dari task yang lebih besar.Task sekecil ini seharusnya menjadi detail di dalam task yang lebih besar, bukan entri tersendiri.
Task yang Tepat
Contoh berikut berada di sweet spot: satu tanggung jawab, estimasi jelas, dan bisa di-review berdiri sendiri.
1✅ Task: "Implementasikan CancelOrderUseCase.Execute method"
2- Scope jelas: satu method di satu file
3- Estimasi: 90 menit
4- Done when: unit test untuk AC1-AC6 lulus
5- Satu commit yang bisa di-review standaloneTask yang tepat inilah yang membuat estimasi bisa dipercaya dan review bisa selesai dalam satu duduk.
11.7 Task Breakdown untuk Fitur yang Melibatkan Multiple Service
Untuk task yang melibatkan lebih dari satu service, breakdown perlu mempertimbangkan service boundaries. Contoh berikut membagi pekerjaan lintas tim dengan dependency antar service yang eksplisit.
1# Task Breakdown: Cancel Order (Multi-Service)
2
3## Order Service Tasks (Tim A)
4- Task 1: Entity update (30 menit)
5- Task 2: Repository interface + impl (90 menit)
6- Task 3: CancelOrderUseCase (90 menit + test)
7- Task 4: HTTP handler + route (60 menit)
8
9## Kafka Event Tasks (Tim A, setelah Task 3)
10- Task 5: Define ORDER_CANCELLED event schema (30 menit)
11 → Document di api/events/order-cancelled.json
12- Task 6: Implementasi Kafka publisher untuk event (45 menit)
13
14## Notification Service Tasks (Tim B, setelah Task 5)
15- Task 7: Consumer untuk ORDER_CANCELLED event (90 menit)
16- Task 8: Email template untuk order cancellation (60 menit)
17- Task 9: Test end-to-end consumer (45 menit)
18
19## Integration Dependency
20Task 5 (event schema) harus selesai sebelum Task 7 (consumer)
21Tim B bisa mulai Task 7 saat Tim A masih di Task 3-4Kunci breakdown multi-service adalah mengidentifikasi kontrak bersama (di sini event schema) lebih dulu — begitu schema fix, kedua tim bisa bekerja paralel tanpa saling menunggu implementasi penuh.
11.8 Handling Blocking Tasks
Kadang ada task yang ter-block oleh faktor eksternal. Dokumentasi berikut mencatat blocker beserta workaround dan target unblock-nya secara eksplisit.
1## Blocked Tasks
2
3Task 3 (Database Migration):
4→ BLOCKED: Butuh approval DBA untuk CONCURRENTLY index
5→ Workaround: Jalankan tanpa CONCURRENTLY di development,
6 dokumentasikan bahwa production perlu approval
7→ Unblock target: Selasa (meeting dengan DBA)
8→ Tidak blocking task lain (app bisa jalan tanpa index, hanya lebih lambat)
9
10Task 6 (Kafka Publisher):
11→ BLOCKED: Kafka topic "order-events" belum dibuat di staging
12→ Workaround: Implement dengan feature flag, disable di staging
13→ Unblock target: Rabu (DevOps team akan setup)
14→ Tidak blocking task lainDengan tracking blocking tasks secara eksplisit, kamu bisa lanjut ke task lain yang tidak ter-block, raise ke tim lebih awal, dan menghindari kejutan di akhir sprint.
11.9 Task Breakdown dan Git Workflow
Setiap task idealnya menghasilkan satu commit yang bermakna. Contoh berikut memperlihatkan commit granular yang mereferensikan AC dari spec di pesannya.
1# Task 1 commit
2git add internal/domain/order/entity.go
3git commit -m "feat(order): add StatusCancelled and CanBeCancelled method
4
5- Add StatusCancelled to order Status enum
6- Add CanBeCancelled() bool that checks PENDING status and 15-min window
7
8Implements: specs/order/cancel-order.md AC3, AC4"
9
10# Task 2 commit
11git add internal/domain/order/repository.go \
12 internal/domain/order/mock/repository_mock.go
13git commit -m "feat(order): add cancel order repository interface methods
14
15- Add GetByIDAndUserID to OrderRepository interface
16- Add CancelWithStockRestore to OrderRepository interface
17- Regenerate mock with gomock"Dengan commit granular seperti ini, git log menjadi riwayat implementasi yang readable, cherry-pick jadi mudah, dan review bisa dilakukan per-commit begitu task selesai.
11.10 Task Estimasi yang Realistis
Estimasi waktu dari AI sering optimis. Dari pengalaman, kalikan estimasi AI dengan faktor koreksi berikut sesuai jenis pekerjaannya.
1Task melibatkan SQL baru:
2× 1.5 jika query straightforward
3× 2.0 jika ada transaction/locking
4× 2.5 jika ada subquery atau CTE complex
5
6Task melibatkan test:
7× 1.5 untuk happy path test saja
8× 2.0 untuk semua AC + EC tests
9× 2.5 jika ada concurrent scenario test
10
11Task melibatkan interface change:
12× 2.0 (selalu ada cascade yang tidak terprediksi)
13
14Task yang "familiar":
15× 1.0-1.3 (tergantung familiarity dengan codebase)
16
17Task yang "unfamiliar" (library baru, pattern baru):
18× 2.0-3.0Faktor koreksi ini bukan aturan kaku, tapi titik awal kalibrasi: catat estimasi vs aktual selama beberapa sprint, lalu sesuaikan multiplier dengan realita tim dan codebase kamu.
11.11 Task Breakdown untuk Refactoring
Task breakdown untuk refactoring punya karakteristik khusus — harus memastikan tidak ada behavior change. Contoh berikut memecah refactoring dengan constraint dan verification rule yang eksplisit.
1# Task Breakdown: Refactor CreateOrderUseCase
2
3## Constraint
4Tidak boleh ada behavior change. Semua test existing harus tetap lulus.
5
6## Task 1: Extract StockValidator [45 menit]
7Extract stock validation logic ke function/type terpisah.
8Done when: go test ./internal/usecase/order/... lulus (semua test existing)
9
10## Task 2: Extract OrderCreator [45 menit]
11Extract order creation logic ke function terpisah.
12Done when: go test ./internal/usecase/order/... lulus
13
14## Task 3: Refactor CreateOrderUseCase.Execute [30 menit]
15Execute sekarang delegate ke StockValidator dan OrderCreator.
16Done when:
17- go test ./internal/usecase/order/... lulus
18- Kode lebih readable (review dengan tech lead)
19
20## Verification Rule
21Setiap task selesai → jalankan FULL test suite → jika ada yang fail → rollback taskVerification rule di akhir adalah inti refactoring aman: test suite yang hijau setelah setiap langkah adalah bukti bahwa behavior tidak berubah, dan rollback langsung jika merah mencegah bug menyusup.
11.12 Progress Tracking dengan Task Breakdown
Task breakdown yang terstruktur memudahkan tracking progress. Tabel status berikut memberi gambaran instan berapa persen fitur selesai dan apa yang menghambat.
1## Cancel Order Feature Progress
2
3| Task | Estimasi | Status | Commit | Notes |
4|------|----------|--------|--------|-------|
5| 1. Entity update | 30 menit | ✅ DONE | abc123 | |
6| 2. Interface | 30 menit | ✅ DONE | def456 | Mock regenerated |
7| 3. Migration | 20 menit | 🔄 IN PROGRESS | - | Waiting DBA approval |
8| 4. Repository | 90 menit | 🔄 IN PROGRESS | - | Started |
9| 5. UseCase | 90 menit | ⏸ PENDING | - | Blocked by Task 4 |
10| 6. UseCase Tests | 60 menit | ⏸ PENDING | - | |
11| 7. Handler | 60 menit | ⏸ PENDING | - | |
12| 8. Router | 15 menit | ⏸ PENDING | - | |
13| 9. E2E Test | 30 menit | ⏸ PENDING | - | |
14
15Progress: 2/9 tasks done | Estimate remaining: 5.75 jamTabel seperti ini mengubah “hampir selesai” yang subjektif menjadi angka “2/9 tasks, sisa 5.75 jam” yang bisa dilaporkan ke stakeholder dengan percaya diri.
11.13 Task Breakdown dan Pair Programming dengan AI
Task breakdown membuat pair programming dengan AI lebih terstruktur. Tiga pendekatan berikut menunjukkan cara memetakan task ke sesi Claude Code.
1Approach 1: Task per session
2→ Setiap session Claude Code, fokus pada satu task
3→ Selesaikan task, commit, baru mulai session baru untuk task berikutnya
4→ CLAUDE.md pastikan context konsisten antar session
5
6Approach 2: Full task dalam satu session
7→ Buka satu session Claude Code
8→ "Implementasikan semua task dari breakdown berikut satu per satu"
9→ Review setelah setiap task selesai
10→ Satu session bisa handle 3-5 task untuk fitur medium
11
12Approach 3: Parallel tasks (untuk tim)
13→ Task 1 dan Task 3 bisa dikerjakan paralel oleh berbagai developer
14→ Task breakdown jadi "assignment" yang bisa di-distributePilih pendekatan berdasarkan ukuran fitur dan context window: task per session menjaga konteks tetap fokus, sedangkan satu session penuh lebih efisien untuk fitur kecil yang saling terkait.
11.14 Task Breakdown di Sprint Planning
Task breakdown yang sudah ada bisa langsung digunakan di sprint planning. Skenario berikut menunjukkan cara memetakan estimasi task ke kapasitas sprint.
1Sprint Planning Scenario:
2Tim melakukan breakdown fitur cancel order sebelum sprint.
3
4Task 1-3: 80 menit total → Masuk Sprint N (sudah ada kapasitas)
5Task 4-6: 240 menit total → Masuk Sprint N (memanfaatkan sisa kapasitas)
6Task 7-9: 105 menit total → Masuk Sprint N+1 (jika tidak muat di Sprint N)
7
8Dengan estimasi yang sudah ada (dari task breakdown),
9velocity planning jadi lebih accurate.Karena estimasi sudah tersedia di level task, planning berhenti menebak “fitur ini berapa poin” dan berpindah ke penjumlahan yang jauh lebih akurat.
11.15 Validasi Task Breakdown dengan Claude Code
Setelah membuat task breakdown, breakdown itu sendiri bisa divalidasi dengan Claude. Prompt berikut meminta pengecekan dependency, ukuran task, dan cakupan AC/EC.
1Ini task breakdown untuk fitur cancel order:
2[paste task list]
3
4Tolong validasi:
51. Apakah ada dependency yang terlewat antar task?
62. Apakah ada task yang terlalu besar (> 90 menit) yang perlu dipecah?
73. Apakah semua AC dan EC dari spec ter-cover dalam task-task ini?
84. Apakah ada potential issue yang tidak ter-capture dalam task breakdown?
9
10Spec yang diimplementasikan: specs/order/cancel-order.md v1.3Validasi ini menutup celah paling berbahaya: AC yang tidak punya task sama sekali — sesuatu yang mudah luput saat menyusun breakdown secara manual.
11.16 Task Templates untuk Task yang Umum
Beberapa task memiliki template yang reusable. Dua template berikut mempercepat pembuatan breakdown untuk usecase dan repository method yang berulang.
1## Template: New UseCase Task
2
3## Task: Implement [FeatureName]UseCase
4
5File: internal/usecase/[domain]/[feature_name].go
6
7Content:
8- Input struct: [Feature]Input { [fields] }
9- UseCase struct dengan dependencies
10- Execute(ctx, [Feature]Input) error method
11- Custom error types jika diperlukan
12
13Done when:
14- go build ./... lulus
15- Unit test untuk happy path lulus
16- Unit test untuk semua error cases lulus
17- go test -race ./internal/usecase/[domain]/... lulus
18
19Estimasi: 90 menit
20
21---
22
23## Template: New Repository Method Task
24
25## Task: Implement [MethodName] in PostgreSQL Repository
26
27File: internal/repository/postgres/[domain]_repository.go
28
29SQL Query: [SQL query yang akan digunakan]
30Index yang dibutuhkan: [jika ada index baru yang diperlukan]
31
32Done when:
33- Method terimplementasi
34- Integration test dengan test DB lulus
35- go test -race ./internal/repository/... lulus
36
37Estimasi: 45-90 menitTemplate seperti ini menstandarkan definition of done lintas task sejenis, sehingga tim tidak lagi berdebat “apa artinya usecase selesai” di setiap fitur baru.
11.17 Anti-Pattern Task Breakdown
Selain pola yang baik, penting mengenali pola yang gagal. Empat contoh berikut menyandingkan anti-pattern dengan perbaikannya.
Anti-pattern 1: Task yang terlalu bergantung pada “feeling”
1❌ "Implementasikan cancel order sampai 'terasa sudah selesai'"
2Masalah: Tidak ada objective definition of doneTanpa definition of done yang objektif, “selesai” bergeser terus dan task tidak pernah benar-benar tuntas.
Anti-pattern 2: Semua task dalam satu PR besar
1❌ Semua 9 task dalam satu PR
2Masalah: PR jadi raksasa, susah di-review, rollback sulit
3✅ Buat PR untuk setiap 2-3 task yang relatedPR raksasa membuat review dangkal dan rollback berisiko; PR kecil per beberapa task menjaga review tetap teliti.
Anti-pattern 3: Task yang tidak bisa di-build secara independen
1❌ Task 4 (repository impl) committed tanpa stub di interface dulu
2Masalah: go build gagal untuk task 4 standalone
3✅ Selalu commit dalam urutan yang menjaga buildabilityCommit yang tidak bisa di-build merusak bisect dan CI; urutan yang menjaga buildability mencegahnya.
Anti-pattern 4: Skip breakdown untuk “task kecil” yang ternyata tidak kecil
1❌ "Ini task kecil, tidak perlu breakdown"
2Kemudian: task "kecil" ini ternyata membutuhkan 2 hari
3✅ Jika tidak yakin estimasinya, selalu buat minimal high-level breakdown“Task kecil” yang membengkak adalah sumber jadwal meleset paling umum; breakdown minimal cukup untuk menangkapnya lebih awal.
11.18 Tips & Gotchas
💡 Tip 1: Task 0 adalah “baca dan pahami spec” — selalu buat task pertama untuk membaca spec secara keseluruhan sebelum mulai coding. 15-20 menit yang sering dilewatkan tapi sangat valuable.
💡 Tip 2: Test task sebaiknya bersamaan dengan implementation task — jangan pisah “implementasi” dan “tulis test” jadi dua task terpisah yang jauh. Test sebaiknya ditulis segera setelah implementasi.
💡 Tip 3: Simpan task breakdown di PR description — PR description yang berisi task breakdown memberi reviewer konteks tentang strategi implementasi. Lebih baik dari sekadar “implement cancel order.”
💡 Tip 4: Update task breakdown saat ada discovery — jika saat implementasi ditemukan task yang perlu dipecah atau ditambah, update breakdown-nya. Dokumen yang up-to-date lebih berguna dari yang akurat saat dibuat tapi outdated.
⚠️ Gotcha 1: Task breakdown bisa memakan waktu jika terlalu detail — task breakdown yang sempurna memakan lebih banyak waktu dari task itu sendiri. Temukan sweet spot: cukup detail untuk tracking, tidak perlu sampai baris kode.
⚠️ Gotcha 2: Estimasi AI tidak reliable tanpa context — “Estimasi: 45 menit” dari Claude bisa 30 menit atau 3 jam tergantung familiarity dengan codebase. Kalibrasikan berdasarkan experience tim.
⚠️ Gotcha 3: Jangan terlalu rigid dengan task order — task breakdown adalah panduan, bukan aturan kaku. Jika ada alasan teknikal untuk mengubah urutan, ubah saja dan dokumentasikan kenapa.
⚠️ Gotcha 4: Task breakdown bukan pengganti spec — task breakdown adalah tentang “bagaimana mengerjakan,” bukan “apa yang dikerjakan.” Spec tetap menjadi sumber kebenaran tentang behavior yang diharapkan.
11.19 Task Breakdown dalam Konteks Deadline
Ketika ada deadline yang ketat, task breakdown membantu prioritisasi. Skenario berikut menunjukkan cara memangkas scope secara sadar sambil mendokumentasikan technical debt.
1Deadline: Besok sore. Cancel order harus live.
2Task list: 9 tasks, estimasi total 6-8 jam.
3Waktu tersedia: 5 jam.
4
5Strategy:
61. Task 1-4: Core functionality (tanpa tests yang comprehensive) — 3 jam
72. Task 5: UseCase dasar tanpa semua error cases — 1 jam
83. Task 7: Handler minimal — 1 jam
94. Task 9: Quick smoke test — 30 menit
10Total: ~5.5 jam (bisa dicapai)
11
12Debt yang diakui:
13- Task 6 (full tests) → di-carry ke sprint berikutnya
14- Task 3 (migration/index) → scheduled untuk next maintenance window
15- EC1 (concurrent cancel test) → monitoring di production dulu
16
17Catatan di PR:
18"Deadline-driven implementation. Missing:
19- Full test coverage (tracked: JIRA-456)
20- Performance index (tracked: JIRA-457)
21- Concurrent scenario test (tracked: JIRA-458)"Kunci strategi deadline adalah memangkas scope secara eksplisit dan tercatat, bukan diam-diam: debt yang punya nomor tiket akan ditagih kembali, sedangkan debt yang tersembunyi akan menjelma jadi bug di production.
11.20 Ringkasan
Task Breakdown adalah jembatan antara implementation plan yang abstrak dan kode yang konkret. Dengan breakdown yang baik, implementasi menjadi serangkaian langkah kecil yang terukur, verifiable, dan bisa di-track.
Prinsip utama: Single responsibility per task, verifiable definition of done, independent commit, 30-90 menit per task.
Workflow yang direkomendasikan: Plan Mode → Task Breakdown → Eksekusi satu task per waktu → Commit setelah setiap task → Progress tracking.
Task breakdown di tim: Bisa dijadikan assignment planning di sprint, setiap task bisa di-assign ke developer yang berbeda dengan context yang jelas.
Anti-pattern yang harus dihindari: Task terlalu besar, tidak ada definition of done, semua task dalam satu PR raksasa, dan estimasi tanpa context yang akurat.
Di artikel berikutnya, kita masuk ke praktik inti: Generate Go Code dari Spec — teknik iteratif untuk menghasilkan kode yang sesuai spec menggunakan Claude Code.