- Pemrograman saat ini jauh lebih membuat stres dibandingkan era 90-an dan awal 2000-an
- Pada masa itu, pekerjaan hanya menjadi gila saat mendekati tenggat waktu, dan di waktu lain relatif tenang
- Penulis merenungkan alasan meningkatnya stres selama beberapa dekade terakhir
- Penyebabnya bukan persaingan, perubahan pasar, atau tenggat waktu yang ketat, melainkan cara kerja berbasis sprint
1. Sprint tidak berhenti
- Sprint adalah tenggat waktu beruntun yang tidak pernah berakhir
- Metode waterfall selaras dengan tenggat waktu dan peristiwa yang nyata
- Sprint adalah tenggat waktu buatan, sehingga tidak ada waktu jeda yang alami
- Stres jangka pendek bisa baik untuk kesehatan, tetapi stres jangka panjang berbahaya bagi tubuh
2. Sprint tidak bersifat sukarela
- Ini berbeda dengan tim yang secara sukarela merilis kode setiap dua minggu
- Semua aspek sprint sudah ditentukan
- Otonomi memainkan peran penting dalam pengalaman bekerja
- Pekerjaan yang dipaksakan menimbulkan stres dan ketidaknyamanan
3. Sprint mengabaikan aktivitas pendukung yang penting
- Sprint tidak menyediakan waktu untuk menyiapkan pekerjaan berikutnya
- Untuk mengerjakan sesuatu, waktu persiapan itu diperlukan
- Sprint berusaha memisahkan persiapan dan pelaksanaan, tetapi hal ini memicu stres
Scrumpol: gambaran yang nyata (dan lebih buruk)
- Sebagian besar implementasi scrum merupakan campuran waterfall dan scrum
- Tenggat waktu besar selalu ada di latar belakang
- Saat tenggat waktu besar mendekat, scrum dihentikan dan stres meningkat
Kesimpulan
- Dalam sprint tidak ada jeda, otonomi kurang, dan waktu persiapan juga kurang
- Pengembang harus bisa mengendalikan pekerjaan dan proses mereka sendiri
- Untuk itu, diperlukan upaya seperti membangun organisasi yang etis atau beralih menjadi pekerja lepas
Ringkasan GN⁺
- Artikel ini menjelaskan mengapa metode scrum memberi stres yang berkelanjutan kepada pengembang
- Tenggat waktu sprint yang terus-menerus, kurangnya otonomi, dan minimnya waktu persiapan adalah penyebab utama
- Pengembang perlu diberi kemampuan untuk mengendalikan cara mereka bekerja
- Proyek lain dengan fungsi serupa adalah metode Kanban
8 komentar
Bahkan saat menjalankan proyek seperti SI sektor publik, mereka terus mendorong tanpa henti dengan phase 1, 2, 3... seperti ini. Dan di setiap phase itu, perubahan besar terus terjadi lagi. Dengan cara seperti ini, tujuan asli scrum untuk mencapai pengembangan yang sukses sama sekali tidak mungkin tercapai. Pada akhirnya, di tengah kekacauan dan suasana yang berantakan ini, hanya para developer yang habis terkuras.
Saya PM yang sedang bekerja saat ini.
Dalam agile/scrum yang menurut saya berjalan dengan baik, setelah sprint utama selesai kami melakukan retrospektif dan diberi waktu untuk beristirahat. Baik tim pengembang maupun tim perencanaan punya momen untuk beristirahat sebelum menyiapkan hal berikutnya.
Seperti di artikel utama, dalam cara kerja yang menurut saya tidak berjalan seperti itu, di bawah deadline yang turun dengan model waterfall, metode scrum juga dijalankan bersamaan di dalam tim produk sehingga stres makin bertambah. Karena deadline itu sendiri tidak bisa diubah, kami berlari setiap minggu tanpa waktu untuk istirahat/retrospektif, dan rasanya seperti lari tanpa akhir.
Menurut saya, maksud dari waterfall adalah mengidentifikasi kebutuhan sedini mungkin dan, karena ada ketergantungan antara pekerjaan desain-implementasi-pengujian, mengerjakan semuanya secara berurutan. Sementara itu, maksud dari agile dan sprint adalah memecah pekerjaan yang terlalu besar untuk dirancang atau diimplementasikan di awal dengan pendekatan waterfall menjadi bagian-bagian kecil lalu mencobanya. Keduanya punya kelebihan dan kekurangan, jadi daripada mengejar metodologi secara dogmatis, bukankah cukup memilih hanya hal-hal yang diperlukan sesuai situasi? Seperti yang dikatakan dalam tulisan itu, tentu juga perlu ada waktu istirahat, serta waktu persiapan untuk peninjauan teknis atau membuat prototipe. Siapa pun yang menentukan urutan pekerjaan, selama memahami faktor penghambat dan menetapkan prioritas sesuai alur kerja di lapangan, saya rasa ada atau tidaknya otonomi pengembang juga tidak terlalu penting.
Apakah tulisan seperti ini muncul di blog-blog luar negeri karena di sana banyak manajer yang sama sekali tidak punya pengalaman pengembangan, tetapi secara membabi buta mencoba menerapkan prosedur metodologi pengembangan? Rasanya seperti melihat konflik antara perencana dan pengembang yang sama sekali tidak memahami praktik kerja nyata di negara kita.
Yang paling mampu menentukan prioritas secara tepat sesuai alur kerja di lapangan seharusnya adalah para developer itu sendiri. Jadi, saya rasa pendekatan yang merampas otonomi mereka lalu mendelegasikan hal itu kepada orang lain justru menjadi penyebab terjadinya pemisahan antara pekerjaan lapangan dan perencanaan tim.
Jika manajemen itu sendiri dianggap sebagai satu bidang keahlian, maka bahkan manajer yang tidak memiliki pengalaman pengembangan pun, ketika berhadapan dengan saat di mana pengelolaan resource pengembangan tidak berjalan baik, menurut saya jawaban untuk situasi itu adalah manajerlah yang harus beradaptasi atau merespons. Namun, saya terlalu sering melihat tanggung jawab ini dialihkan kepada kontributor individual...
Tanggung jawab akhir memang seharusnya ditanggung manajer. Tapi tampaknya kenyataannya tidak begitu. Mirip seperti CEO yang hanya bisa mengurus manajemen, sama sekali tidak memahami bisnis perusahaan, dan sering kali malah menghancurkan perusahaannya.
Terlalu banyak PM yang cuma lempar-lemparan saja sob sob
Komentar Hacker News
Mengutip perkataan Rich Hickey, programmer memecahkan masalah bukan seperti pelari jarak pendek, melainkan seperti menembakkan pistol start setiap 100 yard untuk memulai sprint baru
Jadi membenci proses perangkat lunak. Jika ukuran tim diatur dengan tepat dan developer diberi wewenang untuk mencapai tujuan, mereka bisa bekerja dengan baik tanpa alur produktivitas manajerial. Agile dan sejenisnya ada agar manajer bisa membenarkan gaji mereka
Penasaran apa maksud dari "sprint tidak bersifat sukarela". Tim memilih karakteristik sprint, bukan ditetapkan secara acak. Ini adalah kolaborasi antara kepemimpinan, anggota tim, dan pemangku kepentingan di luar tim. Ingin penjelasan kenapa scrum terasa terlalu kaku
Sejak scrum pertama kali muncul, rasanya tidak masuk akal jika developer terus-menerus melakukan sprint. Sprint itu seharusnya pendek dan cepat, lalu perlu istirahat setelahnya. Menjadikan semua pekerjaan sebagai sprint itu gila
Dalam praktiknya, scrum sering berubah menjadi "scrumpall" yang lebih buruk. Awalnya scrum dipakai untuk komunikasi tim jarak jauh, tetapi lama-lama berubah menjadi target yang digerakkan pemasaran dan sprint yang penuh tekanan. Burnout developer terlihat jelas
Pada awal 2000-an, tim engineer bekerja mandiri tanpa project manager. Perangkat lunak belum saling terhubung seperti sekarang, dan siklus rilis juga lebih panjang. Kini, karena CI/CD dan deployment berkelanjutan, semuanya berjalan cepat. SCRUM menimbulkan stres
Sebagian besar percakapan bisa diringkas menjadi "di tempat kerjaku scrum buruk karena X, Y, Z" dan "itu bukan scrum yang ideal"
Sudah mengembangkan perangkat lunak selama 40 tahun, dan apa pun metodenya, pekerjaan tetap harus dipecah dan kemajuan menuju tujuan harus ditunjukkan. Untuk tim kecil dengan codebase sederhana, Kanban mungkin cukup, tetapi untuk tim besar atau solusi yang kompleks, pelaporan tetap diperlukan
Tidak menggunakan Agile, Scrum, Standups, dan sejenisnya. Prioritas disetel ulang lewat rapat mingguan, dan progres dilacak dengan sistem tiket. Developer dibiarkan bekerja secara mandiri. Waktu harus lebih banyak dipakai untuk coding daripada rapat atau laporan TPS
Setelah bekerja di 8 perusahaan, pendekatan Shape Up dari Basecamp adalah yang paling sukses. Yang penting bukan bertanya "berapa hari yang dibutuhkan", melainkan "berapa banyak waktu yang akan diinvestasikan". Shape Up memberi waktu cooldown di antara siklus 6 minggu dan secara konsisten menghasilkan produk yang sukses