Saya menemukan komik di bawah ini di sebuah grup WA. Komik itu menunjukkan bahwa seorang PM (project manager?) yang mengubah warna (antarmuka aplikasi?) tanpa tiket Jira itu lebih parah dari membunuh orang. π± Kenapa bisa seperti itu? π€
Yuk! ππ§΅
Jira adalah sebuah perangkat lunak pengelolaan tiket (isu/masalah). Bayangkan kita punya masalah dengan sebuah produk, lalu untuk melaporkan masalah, kita harus mengajukan keluhan secara tertulis. Keluhan tertulis itu bisa disebut tiket. Jira berfungsi mengelola tiket-tiket itu.
Dari pengelolaan tiket itu, Jira berubah menjadi pengelolaan task (tugas). Pekerjaan besar bisa dibagi menjadi beberapa pekerjaan kecil sampai ke tugas-tugas individu, bukan? Jira masuk di situ. Dengan skala cukup yang besar, Jira berubah menjadi perangkat pengelolaan proyek.
Apa pun tugas yang perlu dilakukan dalam sebuah proyek, Jira siap menampungnya. Mulai dari perubahan besar sampai perubahan kecil dapat dibuat "tiket"-nya di Jira. Bahkan, sesuai komik yang kita bahas, pekerjaan mengubah warna antarmuka produk juga dapat dijadikan tiket.
"Dapat dijadikan tiket" sebenarnya bermakna opsional. Sayangnya ada orang-orang yang menjadikan Jira sebagai keharusan. Apa pun pekerjaannya, masukkan ke Jira agar bisa dikelola dengan baik. Niatnya baik, tapi efeknya buruk karena memasukkan ke Jira kadang menghambat pekerjaan.
Jadi, maksud komik itu apa? Tentu saja menyindir orang-orang yang sedikit-sedikit harus lewat Jira. Di situ terlihat bahwa mengubah warna tanpa membuat tiket lewat Jira adalah kejahatan. Kenyataannya tidak begitu, bukan? Kalau benar seperti itu, tentu saja berlebihan.
Yang membuat komik itu lucu adalah Jira itu digadang-gadang sebagai perangkat Agile. Sayangnya ada orang yang begitu terobsesi dengan Jira sampai akhirnya lupa bahwa Agile tidak mementingkan proses dan perangkat. Kalau semua pekerjaan harus lewat Jira, Agile-nya ke mana?
Bagaimana dengan sifat Agile yang merangkul perubahan? Kalau semua perubahan harus lewat Jira, respons tim pengembang terhadap perubahan akan melambat. Keharusan membuat tiket mengindikasikan sifat kaku. Alih-alih merangkul perubahan, Jira justru menurunkan fleksibilitas.
Isunya bukan pada Jira, tapi pada cara menggunakan Jira. Perangkat apa pun, kalau diharuskan menjadi pintu masuknya kebutuhan, perubahan, atau pekerjaan, berisiko menurunkan fleksibilitas. Antipati berisiko meningkat, khususnya dari pengguna. Cibiran hanya efek samping.
Di sisi lain, pengelolaan pekerjaan tetap penting. Kalau perubahan diterima begitu saja, chaos akan lahir. Scope creep, kerja serabutan, dan demoralisasi hanya menunggu giliran untuk datang. Jira atau perangkat sejenis dapat digunakan untuk mengendalikan chaos itu.
Pada akhirnya, kita harus seimbang. Perangkat untuk mengelola pekerjaan tetap digunakan secara optimal, tapi tidak berlebihan sampai berbalik menjadi kontraproduktif. Jira, Trello, Wrike, atau bahkan spreadsheet sekalipun akan mendukung Agile selama digunakan sesuai manifestonya.
β’ β’ β’
Missing some Tweet in this thread? You can try to
force a refresh
Capek bahas koruptor. Lebih baik bahas #BahasaJepang saja.
Sebelumnya saya sempat membahas soal belajar tata bahasa dan menulis Hiragana/Katakana di Duolingo. Kali ini saya ingin membahas yang lebih spesifik dalam tata bahasa Jepang, yaitu partikel seperti wa, ga, no, atau ka.
Partikel, menurut saya, adalah hal kedua yang perlu dipahami dengan baik saat belajar #BahasaJepang. Kita bisa mengenal kata benda, kata kerja, kata sifat, dll., tapi tanpa partikel, kita akan kesulitan memahami struktur dan makna kalimatnya. Sebaliknya ...
... kalau kita memahami partikel dengan baik, pemahaman kita terhadap #BahasaJepang akan meningkat pesat. Paling tidak itu yang saya rasakan sendiri saat mempelajarinya.
Tiga tahun yang lalu, #Rinkas lahir. Saya dan Mas @napisoflife sedang mempersiapkan workshop penerapan Agile di pemerintah yang akan diselenggarakan di DJP. Berhubung workshop itu adalah workshop ketiga dan masih mungkin ada lanjutannya, kami memutuskan sebuah nama, Rinkas.
Rinkas, singkatan dari Pemerintah Tangkas, diharapkan menjadi bagian dari gerakan transformasi birokrasi ke arah #Agile. Workshop adalah wujud dasar gerakan itu, yaitu untuk menyebarluaskan nilai-nilai Agile. Komunitas Rinkas otomatis menjadi komunitas yang mendukung gerakan itu.
Sayangnya workshop ketiga itu adalah workshop terakhir. Perhatian DJP ke Agile mulai menurun. Dukungan untuk workshop otomatis hilang. Sempat ada seminar hasil kolaborasi antara DJP dengan Google yang mengangkat Scrum sebagai salah satu topiknya, tapi tidak ada kelanjutannya.
Sedang baca-baca tentang pathological liar. Dari situs healthline, ciri pertama (utama?) seorang pathological liar adalah "their lies seem to have no clear benefit" atau "kebohongan mereka tidak menunjukkan adanya manfaat (bagi diri mereka)".
Di situs MedicineNet justru ditekankan kalau pathological liar "... is often goal-oriented". Di situs itu juga dibedakan antara pathological liar dengan compulsive liar, tapi saya belum bisa betul-betul memahami bedanya. Membingungkan. π€
Pathological liar ini lebih lihai dalam berbohong karena kebohongannya dilakukan untuk membangun realita tersendiri. Compulsive liar justru sebaliknya. Kebohongannya cenderung tidak utuh. Akibatnya kebohongan compulsive liar lebih mudah runtuh.
Kemarin sore saya nobar Dear Evan Hansen dengan istri dan anak-anak. Saya meyakinkan keluarga untuk menonton karena ceritanya menarik, yaitu cerita tentang seorang remaja dengan masalah social anxiety yang menemukan zona nyaman lewat tragedi bunuh diri orang lain. Seru, kan?
Saya akui kalau saya bias untuk film-film bertema kesehatan mental, apalagi seputar keluarga. Film seperti itu memberikan gambaran sulitnya membesarkan anak, apalagi saat anak itu memiliki masalah mental. Dear Evan Hansen melakukan hal itu dengan cukup baik.
Hal paling menarik adalah adanya unsur kebohongan. Masalah mental sepertinya tidak lepas dari kebohongan. Entah untuk menutupi kenyataan yang pahit atau untuk membangun ilusi yang manis, ketidakjujuran adalah kunci. Runtuhnya kebohongan itu yang saya tunggu dari film ini.
Apa pun cara kerjanya, kompetensi tetap penting dan akan selalu penting. #Agile tidak terkecuali. Kolaborasi saja tidak cukup untuk membuat produk yang berkualitas. Respons juga tidak mulus tanpa adanya kompetensi yang memadai saat merespons. Itulah pentingnya "individuals".
Percaya atau tidak, masih ada yang luput melihat bahwa #Agile mengutamakan kompetensi. Padahal kompetensi adalah pernyataan pertama di dalam Manifesto Agile: "individuals and interactions". Maksud "individuals" di situ adalah kompetensi setiap orang yang terlibat.
Pengguna (atau perwakilannya) harus kompeten menyampaikan kebutuhannya. Mereka harus bisa menuangkan kebutuhannya dalam bentuk yang mudah dipahami oleh pembuat produk. Apa pun bentuknya, misalnya dokumen, video, coretan, kuncinya adalah mudah dipahami, bukan lengkap.
Orang yang meminta pelatihan memiliki kecenderungan memaksimalkan kuantitas, tapi tetap menekan ongkos. Ingin banyak materi yang dibahas, tapi tidak mau keluar uang terlalu banyak. Itu wajar. Sayangnya niat memaksimalkan itu justru berbalik meminimalkan.
Contohnya ...
... pelatihan Scrum. Tidak jarang pelatihan Scrum yang diminta itu membahas lengkap tentang pengelolaan produk, bahkan sampai scaling. Kalau semua itu dibahas dalam 1 pelatihan berdurasi standar, biaya pelatihan jelas minimal. Pertanyaannya apakah benar hasilnya maksimal?
Memadatkan materi pelatihan membuat pembahasan tidak mungkin mendalam. Akibatnya pemahaman yang terbentuk juga hanya di permukaan saja. Dengan contoh yang tadi, Scrum paham, pengelolaan produk paham, scaling paham, tapi tingkat pemahamannya rendah.