Ide utama dari kerangka Scrum adalah untuk mengatur proses pengembangan untuk pelaksanaan pekerjaan yang lebih cepat di berbagai tahapan siklus hidup proyek. Tetapi apakah pendekatan ini selalu mendorong pengembang ke arah perilaku yang benar? Banyak pengguna yang bergabung dalam pembahasan pertanyaan di atasdi Stack Overflow, pernah mengalami hal serupa ketika pengembang mengambil jalan pintas, terlalu menekankan pada skor tinggi yang diberikan ke tiket mereka, atau bahkan berpura-pura menjadi karyawan berkinerja tinggi di depan manajer. Bagaimana bahaya ini dapat dihindari? Pertanyaan yang dimaksud telah berpindah dari tempat kerja.stackexchange.com ke softwareengineering.stackexchange.com . Hal ini menunjukkan bahwa pemrogram memandang pertimbangan seputar Scrum dan keefektifannya sebagai sesuatu yang cukup serius untuk melampaui pengelolaan siklus pengembangan perangkat lunak. Mereka merasakan dampak dari metode manajemen proyek ini terhadap lingkungan kerja secara keseluruhan.
Apakah Scrum adalah penyebab dari praktik pengembangan yang buruk, atau itu hanya alasan untuk masalah ini?
Banyak kontroversi telah memicu spekulasi tentang dampak Scrum pada tim dan pengembang individu, dan batasan yang diberlakukan oleh kerangka kerja pada mereka yang menggunakannya. Sementara banyak yang menyalahkan Scrum atas kegagalan tim, yang lain percaya bahwa ini adalah kesalahan atribusi dan akar masalah dalam tim pengembangan jauh lebih dalam.
Pendukung scrum melihat manajemen yang buruk sebagai akar masalah. Inilah yang dikatakan pengguna Llewellyn, menyimpulkan: “Manajemen, pada kenyataannya, mengabaikan para pengembang. Ada tenggat waktu tetap yang harus dipenuhi untuk mencapai hasil yang telah ditentukan. Pekerjaan dilakukan bukan oleh tim yang berfokus pada pencapaian tujuan yang sama, tetapi oleh sekelompok orang di mana setiap orang hanya peduli pada diri mereka sendiri. Merencanakan ke depan dan berpikir di luar kebiasaan tidak disarankan. Dalam kondisi seperti itu, programmer, sebagai akibatnya, menyerah pada keadaan dan menemukan keselamatan dalam pelaksanaan tugas yang diberikan kepadanya. Saya telah bekerja dalam kondisi seperti itu. Tapi jangan salahkan Scrum untuk itu. "
Pengguna DJClayworth mengungkapkan sentimen dari banyak komentar, mengatakan programmer yang merasa berada di bawah tekanan akan berkinerja buruk dengan metodologi manajemen pengembangan apa pun.
Pendapat yang berlawanan tentang masalah ini paling baik diungkapkan oleh pengguna Martin Maat , yang menarik perhatian audiens pada fakta bahwa fakta bahwa begitu banyak orang merasa perlu untuk berbicara tentang masalah ini menunjukkan rasa frustrasi yang disebabkan oleh Scrum.
Apa masalah umum dalam menggunakan Scrum?
Beberapa perangkap Scrum yang umum telah muncul di komentar, baik karena frameworknya disalahgunakan atau karena faktanya itu adalah masalah yang melekat pada Scrum. Berikut ini hampir selusin masalah seperti ini yang telah menarik perhatian kami.
▍1. Rapat harian adalah untuk manajer
Kritik pertama terhadap Scrum terkait dengan fakta bahwa dalam pertemuan harian (stand-up) muncul kecenderungan yang tidak diinginkan. Salah satu argumen yang mendukung gagasan ini adalah bahwa stand-up dapat menurunkan keadaan acara, yang pesertanya hanya melakukan apa yang mereka katakan tentang produktivitas mereka. Apalagi jika pengelola hadir di acara semacam itu. Oleh karena itu, pengguna Matthew Gaiser (dia sudah menulis untuk kami, tetapi kami tidak sengaja menemukan komentarnya) yang disebut acara stand-up yang bertujuan untuk memberi tahu manajer tentang situasi saat ini ( manajemen pembaruan). Dia percaya bahwa presentasi pengembang di acara semacam itu hanya mendorong manajer untuk mengamati apa yang mereka kerjakan, tetapi tidak membawa manfaat apa pun. Ini bahkan lebih benar untuk tim terdistribusi, ketika masing-masing anggota tim bekerja dalam mode mereka sendiri.
▍2. Menyelesaikan tugas memainkan peran utama
Ide lain yang muncul dalam komentar adalah bahwa setiap metodologi pengembangan yang membagi tugas-tugas besar menjadi tugas-tugas yang lebih kecil dan memantau kemajuan tugas tersebut mengarah, baik sengaja atau tidak, ke pendekatan baru untuk mengevaluasi pekerjaan. Jika Anda baru mulai menerapkan beberapa metrik, itu akan mempengaruhi perilaku orang-orang yang kinerjanya dinilai sesuai dengan metrik tersebut.
Banyak komentator mengatakan ini berarti pengembang dapat "mengambil jalan pintas" untuk menyelesaikan apa yang perlu dilakukan dalam sprint saat ini. Masalah tersebut ditunjukkan oleh pengguna Gaiserdan pengguna lain, adalah tiket terpisah yang sedang dikerjakan, dan yang, selama sprint, ditransfer ke kategori "siap", ini adalah "kotak hitam". Apapun yang ada di dalam "kotak hitam" ini, tidak akan mempengaruhi hasil evaluasi kecepatan kerja. Pengguna Gaiser menulis bahwa implementasi berkualitas buruk yang melalui departemen QA dan implementasi yang teruji dan dirancang dengan sempurna tidak berbeda satu sama lain. Akibatnya, ternyata penghitungan jumlah tiket tertutup merupakan indikator produktivitas tenaga kerja yang tidak dapat diandalkan.
▍3. Pengembang yang sangat produktif yang tidak bekerja sebagai tim
Utas lain membahas ketegangan antara pemrogram solo hebat dan tim hebat. Ketika semua orang mengikuti metodologi Scrum, beberapa pengembang bisa menjadi sangat produktif, tapi kemudian "tim" bisa dilupakan. Pengguna Gaiser mengatakan bahwa tanpa insentif yang tepat, pengorganisasian mandiri adalah tujuan yang tidak dapat dicapai: “Anggota tim akan menyelesaikan masalah sesuai keinginan mereka, atau sesuai petunjuk. Jika itu tidak membantu membangun tim, akan ada banyak yang tersisa dan anggota tim hanya akan bergerak maju dalam kekacauan. "
Dia melanjutkan: "Selain itu, mengizinkan setiap pengembang untuk memilih metode mereka sendiri untuk memecahkan masalah, itu berarti lebih sulit untuk men-debug kode."
▍4. Tugas yang sulit ditunda untuk nanti
Gaiser, dengan nada yang sama, terus mengkritik ilusi produktivitas. Ia mengatakan bahwa saat menerapkan Scrum, fokus utamanya adalah mendapatkan tiket ke status "Siap". Berpikir secara mendalam tentang tugas pada saat yang sama tampaknya tidak terlalu produktif. Oleh karena itu, pengembang mungkin cenderung mengambil tugas yang mudah dan menghindari tugas yang lebih kompleks. Di sini, sekali lagi, kata-kata dari pengguna Gaiser: "Scrum mendorong para pengembang untuk melakukan tugas-tugas mudah yang membutuhkan sedikit waktu untuk diselesaikan, yang memungkinkan para pengembang untuk menunjukkan kinerja tinggi secara konsisten." Alhasil, ternyata pilihan tugas harian dan laporan kerja harian mendorong pilihan tugas yang membutuhkan waktu satu hari untuk diselesaikan.
▍5. Fitur produk lebih penting daripada kualitas kode
Semua sama, Gaiser percaya bahwa penggunaan kerangka kerja Scrum menyebabkan penurunan kualitas produk: “Seberapa baik seorang pengembang biasanya ditentukan oleh kemampuannya untuk mengembangkan kode yang dapat diandalkan. Scrum, kecuali jika pemilik produk memahami pemrograman dan mengkaji kode, secara serius merendahkan karakteristik proyek ini. " Dia menekankan di sini bahwa "kesiapan" tiket seringkali ditentukan bukan setelah memeriksa kualitas kode, tetapi hanya setelah fitur yang sesuai diterapkan.
▍6. Kurangnya waktu untuk mendiskusikan masalah pekerjaan dengan rekan kerja
Jika kecepatan perkembangan adalah satu-satunya indikator efektivitas tim, itu berarti anggota tim tidak lagi punya waktu untuk membahas beberapa masalah satu sama lain, untuk mendapatkan pendapat orang lain, atau untuk menguji ide mereka untuk seseorang. membicarakan mereka. Dan itulah yang membuat sebuah tim menjadi sebuah tim. Di sini, sekali lagi, kata-kata dari pengguna Gaiser: “Pengembang hebat sering berkonsultasi dengan pengembang lain dan mencari alternatif untuk pendapat mereka. Tetapi kelas semacam itu menghabiskan waktu yang diperlukan untuk menutup tiket, dan ini memperlambat kecepatan pengembangan. "
▍7. Bug yang baru diidentifikasi harus menunggu giliran
Perilaku buruk Scrum lainnya adalah bahwa "bug ditemukan setelah sprint dan dianggap sebagai tugas baru." Hal ini dapat mendorong pengembang untuk merilis kode berkualitas rendah, karena tugas tambahan tidak dapat disertakan dalam sprint saat ini.
▍8. Arsitektur Berbasis Tiket
Sistem tiket tidak hanya berdasarkan pada tugas yang dipilih pengembang untuk mereka sendiri. Pengguna Gaiser juga mengatakan bahwa menggunakan Scrum, secara tidak sengaja, mengarah pada arsitektur proyek yang membingungkan, karena pengembang mengerjakan tiket sesuai urutan kemunculannya dan secara independen satu sama lain. Akibatnya, "arsitektur dengan cepat menjadi cerminan tiket."
▍9. Metodologi manajemen pengembangan yang mempengaruhi segalanya secara mutlak
Membaca diskusi, Anda dapat memperhatikan komentar, yang penulisnya perhatikan bahwa akar dari semua masalah terletak pada kurangnya kepatuhan yang ketat terhadap aturan Scrum. Namun, mungkin klaim anti-Scrum terkuat dari pengguna Gaiser adalah bahwa ia mendominasi segalanya. Ini bisa menghancurkan tim yang kuat. "[Scrum] mendistorsi dan menghancurkan mekanisme manajemen pembangunan lainnya, kerangka kerja ini menjadi fenomena yang mencakup semua di mana tidak ada selain melakukan ritual yang dilakukan secara seragam, dan melakukan ritual ini menciptakan ilusi kesuksesan."
Kami telah membahas daftar masalah yang agak panjang yang mungkin disebabkan oleh penggunaan Scrum, dan, mungkin, hanya menjadi lebih terlihat karena penggunaan kerangka kerja ini. Namun dalam diskusi yang kami teliti, Anda dapat menemukan banyak ide tentang bagaimana pengembang dapat hidup dalam kedamaian dan harmoni dengan mengikuti aturan Scrum .
Bagaimana cara mendapatkan hasil maksimal dari Scrum?
Banyak tanggapan atas komentar Gaiser yang mendapat banyak penilaian positif adalah bahwa yang ia bicarakan bukanlah Scrum. Inilah yang ditulis oleh pengguna Stephen Byrne tentang ini: “Saya pikir ini adalah jawaban yang bagus dengan beberapa wawasan berharga, tetapi saya harus setuju dengan banyak komentator lain bahwa apa yang dijelaskan di sini jelas bukan Scrum, meskipun dan dilihat dengan kedok Scrum. " Tetapi banyak yang secara terbuka membenci Scrum, atau setuju dengan pengguna Gaiser bahwa jika terjadi kesalahan saat menggunakan Scrum, itu berarti kerangka kerja ini tidak digunakan dengan benar.
Bagaimana cara menggunakan Scrum dengan benar?
▍1. Pertemuan harian tidak sama dengan mengambil tiket baru setiap hari
Banyak orang mengatakan bahwa pertemuan harian memaksa pengembang untuk menutup tiket setiap hari. Namun, seperti dicatat oleh DJClayworth , Anda juga tidak dapat melakukannya tanpa memprioritaskan tugas. Dan jika prioritas tidak diatur secara alami, maka tugas ini harus diambil alih oleh Scrum Master: “Kita perlu memprioritaskan tugas dalam sprint, tugas yang lebih besar perlu diberi prioritas lebih tinggi, jadi seseorang harus mengambil tugas yang sulit di hari pertama sprint. Bagaimanapun, jika pada hari kedua tidak ada yang mengambil tugas besar dan kompleks, Scrum Master harus mengatakan sesuatu seperti: “Saya melihat tidak ada yang mengambil tugas mengompresi database. Dan ini adalah tugas besar. Jika kami ingin menyelesaikan sprint, kami harus mulai mengerjakan tugas ini sekarang. "
▍2. ,
Semua tugas yang diselesaikan dalam sprint harus dipecah menjadi beberapa bagian kecil. Ini tidak bisa disangkal. Tetapi kerangka kerja Scrum tidak mengatakan bahwa pengembang harus terobsesi dengan metrik yang menunjukkan hasil. Scrum tidak menyarankan mengadu domba pengembang satu sama lain. Pengguna Gaiser mengusulkan untuk sepenuhnya mengabaikan pertimbangan poin programmer individu. Dia menunjukkan bahwa banyak manajer mungkin perlu memeriksa kembali aturan Scrum: “Beri tahu manajer bahwa saat mereka memuji pengembang atau memberi mereka promosi berdasarkan tiket tertutup menjadi saat mereka mengubah perilaku tim secara radikal. ".
Pengguna DJClayworthsetuju bahwa dengan sengaja mengabaikan metrik yang terkait dengan tiket individu harus menjadi bagian dari tugas Scrum Master yang baik: “Perhatian harus difokuskan untuk memastikan bahwa tim mencapai tujuannya sebagai sebuah tim. Scrum Master harus tetap berpegang pada perilaku ini dan menghindari diskusi atau metrik apa pun berdasarkan berapa banyak cerita pengguna yang dipromosikan oleh setiap anggota tim. "
▍3. Anda perlu mengambil langkah kecil untuk mencapai tujuan besar, tetapi dengan pendekatan ini Anda tidak boleh melupakan tujuan tersebut.
Berikut ide lain untuk memecahkan masalah besar menjadi potongan-potongan kecil: "Jika Anda mengerjakan bagian kecil dari teka-teki, itu tidak berarti Anda harus melupakan keseluruhan teka-teki."
Pengguna Llewellyn menunjukkan bahwa menggunakan Scrum bukanlah alasan untuk sepenuhnya mengabaikan prinsip-prinsip pengembangan perangkat lunak yang berkualitas: “Anda harus memiliki gagasan yang baik tentang tujuan proyek. Pengetahuan ini dapat digunakan untuk merencanakan arsitektur proyek, terlibat dalam perencanaan bahkan dalam sprint saat ini. "
Scrum tidak membebaskan pemrogram dari kebutuhan untuk melakukan pekerjaan mereka, mencurahkan semua pengetahuan dan pengalaman mereka ke dalamnya. Oleh karena itu, panggilan Llewellyn ditujukan kepada pemrogram yang termasuk di antara pembaca komentar: “Anda ada di rapat, Anda dapat melihat backlog, Anda tahu apa visi keseluruhan proyek dalam organisasi. Anda berusaha untuk menghindari keharusan menghabiskan waktu yang lama untuk sesuatu dari masa depan yang jauh. Tetapi tidak ada yang salah dengan meletakkan dasar untuk sistem modular yang dapat diperluas yang cocok untuk memecahkan masalah saat ini dan akan memungkinkan Anda menciptakan peluang tambahan yang telah direncanakan tanpa masalah di masa mendatang. "
▍4. Anda perlu memutuskan apa artinya "Selesai"
Salah satu topik yang kami angkat dalam diskusi yang kami diskusikan berkaitan dengan kriteria Definisi Selesai (DoD), dan bagaimana mendefinisikan kriteria ini membantu pemrogram individu untuk mematuhi standar kualitas tertentu dan tetap mendapat informasi tentang apa yang diharapkan dari mereka. Pertanyaan yang paling mendesak di sini adalah siapa dan kapan mengembangkan kriteria ini. Berbicara tentang " kapan ", biasanya tentang mengembangkan kriteria secepat mungkin, atau tentang bagaimana kriteria tersebut harus dikembangkan selama perencanaan sprint.
Jawaban pertanyaan siapa yang memproduksi DoD ditulis oleh pengguna SpoonerNZ berupa jawaban pertanyaan lain.di situs Rekayasa Perangkat Lunak. “Kriteria kesiapan dibuat oleh tim, tetapi proses ini mungkin membutuhkan kehadiran seorang Scrum Master. Hal ini diperlukan untuk menetapkan batasan kualitas, jika tim tidak memiliki standar pengembangan yang jelas. Misalnya, sebuah tim mungkin tidak ingin mengacaukan tinjauan kode atau pengujian unit, yang akan mengakibatkan semua ini ditambahkan ke DoD oleh ScrumMaster untuk memastikan pengembangan berkualitas tinggi. Dalam situasi yang ideal, tim, setelah memahami kekuatan dari apa yang ditawarkan, akan dengan senang hati menerimanya, tetapi dunia nyata tidak selalu ideal. "
Siapa yang harus bekerja sambil mematuhi DoD? Tujuan alami (dan menantang) adalah untuk memastikan bahwa pernyataan DoD diterapkan dalam satu tim, dan didukung oleh semua anggota tim tersebut. Tetapi ada alasan bagus untuk memperluas pengaruh Departemen Pertahanan ke banyak tim. Atau bahkan seluruh organisasi. Inilah yang ditulis oleh pengguna Alan Larimer tentangnya: “Kurangnya definisi DoD yang diakui secara universal untuk suatu produk berdampak negatif pada kualitas dan transparansi hasil kerja. Tingkat organisasi dari DoD harus minimal, teknis, dan terkadang khusus organisasi, yang dapat memberikan penerapan kriteria kesiapsiagaan secara universal. Organisasi dapat mengusulkan standar untuk pengkodean. Sebuah organisasi mungkin memerlukan pembuatan rakitan otomatis, memberikan sumber daya untuk membuat dan memelihara rakitan untuk setiap produk. Setiap bagian dari DoD, baik yang dibuat oleh organisasi atau oleh pengembang individu, harus membawa sesuatu yang bernilai ke kriteria kesiapan. "
▍5. Manajer harus berperan sebagai pengamat diam
Sementara apa yang ada di heading pada bagian ini sudah diabadikan dalam manual resmi Scrum, analisis pembahasan menunjukkan bahwa aturan ini, sayangnya, sering dilanggar dalam rapat harian yang dihadiri oleh manajer. Karena itu, programmer merasa perlu menjelaskan mengapa pengerjaan tiket memakan waktu lebih lama dari yang direncanakan. Jika hanya ada programmer yang menghadiri rapat, penjelasan semacam itu tidak perlu. Inilah yang dikatakan manual Scrum tentangnya: “Scrum harian adalah pertemuan internal tim pengembang. Jika ada orang lain yang hadir, Scrum Master akan memastikan bahwa mereka tidak mengganggu rapat. "
▍6. Orang harus lebih penting daripada proses
Jika Anda memerlukan panduan tentang cara menerapkan aturan Scrum, bacalah kata-kata yang ditulis oleh Frank Hopkins untuk mengingatkan Anda tentang satu prinsip klasik: "Orang lebih penting daripada proses." Di sini ia menambahkan yang berikut: "Tim yang baik harus mendefinisikan prosesnya, proses yang didefinisikan secara kaku tidak berkontribusi pada pembentukan tim yang baik."
Pengguna lain, meriton , menunjukkan bahwa penggunaan Scrum bergantung pada pemrogram individu: “Scrum tidak menyediakan fakta bahwa para pengembang bekerja secara independen satu sama lain. Scrum menetapkan bahwa tim pengembangan mengatur dirinya sendiri, yaitu tim membuat keputusan tentang bagaimana anggotanya berinteraksi. " Catatan
nvoigt penggunabahwa tim di Scrum mengatur dirinya sendiri karena fakta bahwa mereka datang ke proyek dengan misi yang ditentukan: “Kerangka kerja Scrum didasarkan pada fakta bahwa Anda adalah sebuah tim. Tidak masalah di tim apakah tiket ditutup kemarin oleh programmer tertentu. Siapapun yang bekerja dalam tim memahami tujuan (yaitu DoD) dan berusaha untuk mencapainya bersama dengan anggota tim lainnya. "
▍7. Bangun tim untuk bekerja seperti Scrum, tetapi jangan berharap Scrum akan membuat tim
Pengguna nvoigtmenerapkan metafora olahraga: “Bayangkan 11 orang menerima manual sepak bola tercetak. Mereka diberitahu bahwa mereka perlu berlatih sekitar jam 10 pagi setiap hari di Ruang Konferensi 5, masing-masing menghabiskan waktu 15 menit. Apakah menurut Anda hasilnya akan menjadi tim sepak bola yang bagus? Bagaimana jika 11 orang ini adalah pesepakbola profesional yang baik? Bukankah perintahnya akan tetap berfungsi? Ya, tidak. Hanya saja tim sepak bola tidak diciptakan seperti itu. Seperti olahraga tim lainnya, Scrum membutuhkan mereka yang menggunakan kerangka ini untuk menjadi sebuah tim. Jika hanya sekelompok orang yang masing-masing hanya ingin mendapatkan poin untuk diri mereka sendiri dengan menunjukkan berapa banyak poin dalam cerita pengguna yang telah mereka liput, atau berapa banyak tujuan yang telah mereka capai, maka kelompok ini akan selalu kalah dari tim yang anggotanya bermain bersama, dan tidak bersebelahan. teman,atau melawan satu sama lain. "
Hasil
Pengguna nvoigt ingin mengakui bahwa Scrum "tidak cocok untuk semua orang atau tim." Dan, seperti yang ditunjukkan oleh ketertarikan komunitas pada masalah yang kita diskusikan di sini, menerapkan seperangkat aturan yang mungkin didorong untuk dikembangkan oleh Scrum dapat mengarah pada lingkungan kerja yang jauh dari apa yang ingin mereka bangun.
Kami ingin meringkas hasil dari materi ini dengan kata-kata dari pengguna Seth R.... Dia mengatakan tidak perlu mengharapkan keajaiban dari ritual tangkas. Terlalu banyak yang diinginkan oleh mereka yang mencari dengan bantuan mereka, seolah-olah dengan sihir, untuk memperbaiki kekurangan tim pengembangan. Inilah cara dia melihat situasi: “Ini semua tentang mempercepat umpan balik. Hasilnya, tim memiliki kesempatan untuk meninjau sendiri dan membuat keputusan tentang cara bekerja untuk hasil terbaik. Scrum tidak akan membantu Anda menciptakan produk yang lebih baik, tetapi jika Anda serius melakukan pengujian mandiri, itu dapat membantu Anda membangun tim yang lebih baik. Hal ini, pada gilirannya, mengarah pada pengembangan produk yang lebih baik. "
Banyak orang membandingkan kerangka ini dengan demokrasi. Jadi mungkin Scrum adalah bentuk manajemen pengembangan terburuk, selain dari yang lain?
Atau mungkin, seperti yang dikatakan oleh panduan resmi , kerangka kerja yang mudah dipahami tetapi sulit untuk dikuasai dengan sempurna.
Bagaimana Anda menjawab pertanyaan dalam judul artikel ini?
