Dalam model manajemen yang represif, seorang pemimpin, sebagai suatu peraturan, akan memilih karyawan yang lebih bodoh daripada dirinya sendiri, atau mereka yang dapat “dihipnotis” atau diperas dengan satu atau lain cara. Mereka mencari "anjing" yang mudah dikelola dan mudah diracuni. Instruksi idiot yang turun dari atas akan diproksi tanpa perubahan, dan mereka yang dapat mem-proxy-nya di bawah ini akan selamat, sisanya akan meledak. habr.com/post/124716
Apakah semuanya begitu buruk dengan kepemimpinan tim? Apakah akan memaksakan scrum secara formal ketika tidak ada yang memahami kebutuhannya, dan itu tidak benar-benar dirasakan, atau memperkenalkan elemen-elemennya secara bertahap, sehingga tim merasakan keefektifannya.
Konflik kepentingan adalah situasi yang sering terjadi dalam kolektif kerja dan tidak hanya pada programmer. Dan seringkali tidak ada benar dan salah, ada bentrokan pengalaman dan visi. Bagaimana melepaskan potensi semua karyawan dan mendapatkan sinergi ketika 1 + 1 = 11, bukan 2.
Terinspirasi setelah Piala Dunia sepak bola. Kisah penarikan Scrum. Semua peristiwa adalah fiktif, semua kebetulan adalah acak. Situasi umum dan sangat disederhanakan.
Jadi, tim dibentuk, analis, front-end, full-stack-back-end. Jangan scrum. Tim ini dibentuk dengan pemimpin tim yang cukup kompeten dan beragam serta berpengalaman yang memiliki kekuatan luas. Manajemen perusahaan mendelegasikan kepadanya wewenang penuh.
Sebagai analogi, bayangkan sebuah proyek adalah liga sepak bola. seluruh tim dengan kelemahan, yaitu proyek yang gagal atau berlarut-larut. Sukses dianggap sebagai produk berkualitas tinggi dan dikirimkan tepat waktu, yaitu posisi teratas tim dalam kejuaraan sesuai dengan hasil semua pertandingan. Game adalah sprint. Sprint - iterasi dalam scrum, di mana pertumbuhan perangkat lunak dibuat. Ini kaku dalam waktu, seperti pertandingan sepak bola. Sekilas pertandingan pertama (sprint), situasinya cukup nyata.
Mulai bekerja pada proyek (Babak pertama, semuanya berjalan dengan baik, skor gol 1 - 0)
Jadi peluit, dan pemain yang cukup berpengalaman secara individu, tetapi tidak bermain bersama, melakukan pekerjaan mereka dengan sangat baik. Analis menetapkan tugas, front-end membuat aplikasi pada backend mok. Pada awalnya, semuanya berjalan dengan baik, tata letak, arsitektur proyek, halaman dibuat dengan cepat, pelanggan dengan cepat menerima hasil, tim menerima umpan balik darinya. Semua orang senang.
Backend dikembangkan secara terpisah, arsitektur sedang dibangun, database diletakkan, metode perkiraan sedang dilemparkan.
Backend yang tidak berorientasi pada klien (Momen berbahaya, gol, assist buruk di zona tengah, 1 - 1)
Analis, menunjukkan kualitas individu yang sangat baik, mentransfer tugas ke tim, layar, dan deskripsi.
Front-end, menerima pass, mengeset form, menulis kode klien, meneruskan pass ke fullstack-bekender. Dan mengharapkan sesuatu seperti:
Dapatkan / beberapa / metode
Fullstek-backender (kapten tim, alias pemimpin tim) menerima umpan dan memberikan:
Sebagai aturan, tumpukan penuh memiliki pengetahuan yang dangkal di daerah (hanya karena secara fisik mereka tidak dapat menutupi semuanya secara mendalam), tetapi mereka melihat keseluruhan proyek secara keseluruhan. Mereka bagus dalam proyek-proyek kecil di mana mereka melakukan semuanya sendiri, dan tidak efektif dalam pengembangan tim.
Ada jeda dan kebingungan, ketika ditanya mengapa demikian, diam dan mengabaikan, pemimpin tim tahu apa yang dia lakukan. Dengan transmisi berulang dan pertanyaan selanjutnya, mengapa demikian. Jawab: "Percayalah, saya tahu apa yang saya lakukan, Anda tidak memiliki visi sistem secara keseluruhan." Sedangkan undiannya 1-1. Dan tidak ada yang bisa dilakukan di sini, baik untuk pelari terdepan, maupun untuk kepemimpinan.
Kerja tim yang lemah (Informasi, tujuan, 2-1 fakap lead)
Frontender berpikir dan tegang. Apa yang perlu Anda lempar ke layar? Dia bertanya lagi, tetapi interaksinya tidak tetap. Tim-leader-full-stack-beckender gugup, memberikan jawaban. "Pikirkan!" "Lebih mudah bagiku untuk melakukannya sendiri," "Kicker." Permainan tidak menempel, tim melewatkan gol kedua.
Penguatan melalui pengembangan tim (Waktu tidak berpihak pada tim, skor 2-1 sama)
Tebakan kecil front-end tender tentang parameter, belajar untuk memprediksi arah lulus, tetapi masih ada perkawinan dalam permainan. Penyedia front-end tidak menganggap segalanya dengan telinga, dan meminta alat pengembangan tim (Redmine, Jira, Trello). Kepemimpinan akan bertemu. Dimulai dengan tugas, seperti:
Salam -> ??? (bidang mana yang akan diambil dari data)
Parameter 1-> ??? (bidang mana yang akan diambil dari data)
Parameter2 -> ??? (bidang mana yang akan diambil dari data)
Demi kejelasan, data dibersihkan langsung ke kedatangan dari backend dan dalam bentuk yang dimengerti dilemparkan dalam html. Permainan telah stabil, tetapi waktu hampir habis, akunnya sama mendukung fakap.
Cidera, refactoring kode, (Tim menang kembali, tetapi ketinggalan gol 3-2)
Front-end terluka dan meninggalkan lapangan untuk sementara waktu (liburan yang direncanakan), pada saat ini back-end, merangkak ke kode depan, menghabiskan waktu refactoring, dan heroik mengurai data dari back-end langsung dalam html. Tujuan cepat, bagus! Namun sebagai tanggapan, ia menerima bug dari analis dan tugas-tugas luar biasa untuk sprint saat ini. Ya ... tim dengan cepat menerima gol balasan. Beckender masuk dalam daftar pencetak gol terbanyak. Frontender dengan cepat pulih dan kembali dalam permainan. Tetapi karena operan tidak berjalan, dan pimpinan tim mengelola sendiri, front belum banyak terlibat. Peluit akhir, pertandingan sudah berakhir. 3-2 tim kalah, tapi jelang laga berikutnya (sprint).
Sprint retrospective (Analisis pertandingan pertama, front-end di bangku cadangan)
Dalam scrum, untuk mengidentifikasi masalah pada tahap awal dan penyesuaian diri yang fleksibel dari tim, sprint dilakukan secara retrospektif oleh master scrum (pelatih tim), tetapi karena ia tidak ada di klub. Frontender memprakarsai itu. Kumpulkan semua peserta dan jelaskan kekeliruannya menolak bermain pass, karena suatu saat tidak dapat meningkatkan permainan tim sepanjang kejuaraan (akhir proyek), dan meminta semua anggota tim untuk berbicara. Sebagai tanggapan, kapten tim - pemimpin tim - tumpukan penuh, menawarkan untuk mentransfer front-end ke proyek lain, karena pendapat para pemain tidak mengganggu siapa pun. Tim diam - manajemen klub juga. Pemindahan ditunda, ujung depan melayang di bangku.
Bagaimana cara mengoperasikan manajemen klub? Pemimpin tim atau master scrum? Buka diskusi, pengungkapan pendapat atau perintah tunggal pemimpin tim. Padahal, tidak ada jawaban yang benar. Untuk memperjelas situasinya, Anda harus memasukkan tester dan melihat permainan dalam beberapa sprint lagi. Itu semua tergantung pada ukuran proyek.
Epilog (waktu telah berlalu):
Terima kasih banyak atas komentarnya!
Apa hidup kita? Gim ...
Selamat malam, di klub intelektual. Apa? Dimana? Kapan? Satu-satunya tempat di mana setiap pemirsa dapat menghasilkan uang dengan pikirannya sendiri ...
Jadi diam di aula.
Para ahli (scrama) yang terhormat. Sekali lagi, saya menarik perhatian pada fakta bahwa artikel di awal menekankan dengan jelas bahwa apa yang dilakukan tim itu bukan scrum, tetapi hanya upaya untuk menampilkan perebutan yang dijelaskan.
Scrum seperti poker, ia memiliki aturan yang sangat sederhana, tetapi sangat ketat. Tetapi pada saat yang sama, poker dan scrum adalah game yang sangat sulit.
Sekarang, perhatian adalah jawaban yang benar.
Dalam prosesnya, aturan scrum yang sangat sederhana dan mendasar dilanggar. Ada beberapa peran dalam scrum dan mereka jelas dijabarkan. Tidak ada peran yang disebut pemimpin tim. Tugas master scrum adalah memantau dengan jelas implementasi aturan ini. Dan hentikan segala upaya untuk melanggarnya. Intinya, kekacauan dari backend pergi ke depan dan proyek tersandung.
Scrum adalah kerangka pengembangan perangkat lunak yang fleksibel. Kerangka kerja ini didasarkan pada metode empiris (berdasarkan pengalaman) dan dimaksudkan untuk pengembangan produk bernilai TINGGI dalam lingkungan yang rumit. en.wikipedia.org/wiki/Scrum
Bulat. 1-0 - untuk pemirsa. Penikmat pergi istirahat musik ... Dan bersiap-siap untuk putaran berikutnya.