Scrum? SCRUM yang mana?
Untuk pertama kalinya, pendekatan SCRUM (Bahasa Inggris
scrum "fight around the ball") dideskripsikan oleh Hirotaka Takeuchi dan Ikujiro Nonaka, yang memperhatikan bahwa tim-tim kecil (5 - 9 orang), dikelola oleh beragam spesialis, memberikan hasil yang lebih baik. Deskripsi SCRUM paling lengkap pertama kali diperkenalkan dalam bukunya oleh Jeff Sutherland. Buku itu disebut SCRUM. Jeff memulai karirnya sebagai pilot militer, selama Perang Vietnam ia menyelesaikan lebih dari seratus sorti. Kemudian Jeff terlibat dalam sains, tetapi dunia akan mengingatnya sebagai salah satu pendiri SCRUM. Buku ini dimulai dengan kisah nyata dari kehidupan FBI, yang menghabiskan jutaan dolar untuk pengembangan sistem otomatis yang dirancang untuk mencari dan melacak penjahat. Masalahnya adalah bahwa setelah proyek berakhir, kontraktor menunjukkan kepada FBI produk yang sama sekali tidak berfungsi. Ini hanya berarti satu hal - pembayar pajak Amerika telah menyia-nyiakan jutaan. Situasinya tampak tanpa harapan sampai kepemimpinan FBI beralih ke metode manajemen proyek SCRUM yang baru lahir. Metode ini dijelaskan dalam bahasa yang dapat diakses dalam buku tersebut, yang, secara kebetulan, telah diterjemahkan ke dalam bahasa Rusia. Selanjutnya, artikel ini membahas kesalahpahaman utama dan mitos yang dapat menakuti para manajer puncak yang telah memutuskan untuk mengimplementasikan SCRUM dalam proyek mereka.
1. Kontrol total yang membunuh kreativitas
Di SCRUM, tim proyek, bukan manajemen, memutuskan bagaimana mencapai tujuan bisnis. Metode ini memotivasi dan merangsang pendekatan kreatif, berbeda dengan manajemen klasik, di mana karyawan didelegasikan untuk menerapkan tindakan tingkat rendah tertentu, dan mereka, pada gilirannya, sering kali bahkan tidak mengerti mengapa ini dan bagaimana hal itu akan mempengaruhi proyek secara keseluruhan. Jadi, dalam SCRUM, manajemen tidak mengendalikan tindakan tim proyek, dan bahwa, pada gilirannya, hanya melaporkan hasil pada akhir setiap sprint (periode waktu yang telah ditentukan sebelumnya, misalnya, 2 minggu). Transparansi hanya ada di antara anggota tim proyek. Apa yang dimanifestasikan? Pertama-tama, unjuk rasa harian di mana setiap anggota tim proyek mengatakan apa yang dia lakukan kemarin, apa yang akan dia lakukan hari ini, masalah apa yang dia miliki. Praktik ini tidak dimaksudkan untuk mengontrol jumlah pekerjaan yang dilakukan oleh setiap karyawan. Stand-up unjuk rasa dirancang untuk membantu setiap anggota tim menghilangkan hambatan dalam pekerjaan mereka dan mengabdikan kolega untuk rencana mereka, sehingga semua orang mengerti ke mana proyek ini bergerak hari ini dan menyadari perannya dalam pengembangan produk. Untuk tujuan yang sama, omong-omong, papan SCRUM bersama dengan stiker, yang semua orang dapat melihat, dan ruang terbuka, yang menghilangkan hambatan untuk komunikasi gratis antara anggota tim, berfungsi.
2. SCRUM merampas hak-hak insinyur yang paling berpengalaman, karena mereka mematuhi keputusan tim
SCRUM menciptakan suatu lingkungan di mana otoritas diperoleh bukan oleh jabatan dan jabatan, tetapi oleh keterampilan dan pengalaman. Contoh mencolok dari situasi sebaliknya adalah hierarki militer, di mana kekuasaan didasarkan pada posisi dan pangkat. Kapten bisa jauh lebih berbakat dan terpelajar daripada seorang kolonel. Meskipun demikian, kapten harus patuh. Struktur kaku seperti itu ideal untuk kondisi ekstrem, seperti permusuhan, di mana keputusan harus dibuat dengan cepat, dan diskusi mereka mengarah pada penundaan, yang mengarah pada kematian orang. SCRUM tidak akan membatalkan judul. Setiap karyawan memiliki posisinya sendiri sesuai dengan pengalaman dan matriks kompetensinya. Namun demikian, dalam proses membahas keputusan tertentu, faktor dominan adalah posisi yang jelas dan masuk akal, didukung oleh pengalaman pribadi karyawan di bidang yang dibahas, dan bukan gelarnya. Bertentangan dengan mitos, SCRUM memberikan kekuatan kepada anggota tim yang dengan jelas mengartikulasikan ide-ide yang bagus. Dan seperti yang Anda tahu - dia yang berpikir jernih, ia dengan jelas merumuskan.
3. SCRUM ditujukan untuk nilai bisnis jangka pendek, dan bukan pada pengembangan jangka panjang proyek
Masalah ini, memang, relevan. Untungnya, pertanyaan "Apa yang harus dilakukan?" ada jawabannya. Itu harus dimulai dengan fakta bahwa jika proyek ini tidak berjalan lama, dengan durasi tidak lebih dari enam bulan, maka masalah ini kemungkinan besar tidak akan muncul. Hal lain adalah ketika perangkat lunak berkembang selama 2-3 tahun atau lebih. Ada banyak artikel di mana penulis mencurahkan rasa sakit mereka mengenai proyek-proyek tersebut. Pasukan Juni dan Pertengahan (sinergi, seperti yang Anda tahu, mahal dan sedikit jumlahnya) dengan penuh percaya diri melakukan pekerjaan mereka untuk dikuasai, dan pelanggan sprint mendapatkan kembali hasil cemerlang untuk sprint SCRUM. Tetapi masalahnya adalah bahwa setelah 5-10 sprint, menambahkan fitur baru menjadi bermasalah, dan semakin jauh, semakin sulit. Oleh karena itu, SCRUM bagus, tetapi Anda perlu memikirkan strategi dan arsitektur. Situasi serupa dapat dicegah. Pertama,
setidaknya 1-2 insinyur berpengalaman sebanyak mungkin akan mengerjakan proyek, yang akan melewati sendiri semua komitmen ke repositori selama tinjauan kode. Kedua, mencurahkan banyak waktu untuk pelatihan (setidaknya 3 jam seminggu) untuk insinyur menengah dan menengah dalam arsitektur perangkat lunak, pola desain, dan bagaimana ini diterapkan pada proyek yang ada. Kelas semacam itu harus disertai dengan latihan dan pekerjaan rumah yang minimal untuk pembelajaran yang lebih baik. Penugasan praktis dapat dimasukkan ke dalam tumpukan proyek sprint. Ini tidak akan terlalu menekan profitabilitas proyek, tetapi akan mempercepat proses pertumbuhan karyawan dan mencegah potensi masalah dengan arsitektur perangkat lunak. Mengadakan pertemuan berkala akan memungkinkan tim proyek untuk saling belajar, yang tidak merusak kualitas perangkat lunak yang dihasilkan.
4. SCRUM mencegah insinyur untuk berkembang
SCRUM mengasumsikan bahwa semua keputusan mengenai cara untuk mencapai tujuan bisnis didelegasikan kepada tim. Pemilik produk memutuskan apa yang perlu dilakukan, dan tim memutuskan bagaimana. Oleh karena itu tim harus cukup kompeten untuk membuat keputusan yang efektif. Oleh karena itu, landasan metodologi SCRUM adalah pelatihan. Itulah sebabnya mengapa di semua bank dan agen outsourcing terbesar, begitu banyak perhatian diberikan untuk pengembangan: pelatihan, seminar, kursus. Pertumbuhan profesional karyawan merupakan bagian integral dari SCRUM. Karena tim SCRUM relatif kecil, anggota tim harus menguasai seluruh tumpukan teknologi dalam proyek yang sedang mereka kerjakan. Pada akhir proyek, insinyur menerima keterampilan baru, yang meningkatkan nilainya di pasar tenaga kerja.
Subtotal
SCRUM, seperti metode manajemen proyek lainnya, memiliki karakteristik dan kekasarannya sendiri yang perlu diketahui dan dipertimbangkan. Meskipun demikian, ini memberikan hasil terbaik di antara metode yang dikenal saat ini.
1. Jeff Sutherland // SCRUM 2017.