Pengganti fleksibel
Kata "Scrum" mengacu pada setidaknya dua entitas: filsafat dan kerangka kerja.
Filsafat, atau pendekatan untuk bekerja, dijelaskan dalam buku karya Jeff Sutherland.
Kerangka kerja, yaitu algoritma tindakan yang dijelaskan dalam dokumen yang disebut Panduan Scrum.
Filsafat berubah menjadi kerangka kerja karena para pengarang filsafat ingin menghasilkan uang darinya (dengan kata-kata mereka sendiri).
Kerangka kerja ini sangat disederhanakan dibandingkan dengan filsafat. Yang utama adalah bahwa tujuannya telah disederhanakan, atau lebih tepatnya dibuang.
Tujuan filosofi: mempercepat pencapaian hasil. Apalagi kadang-kadang. Ada 8 kali contoh percepatan dalam buku ini.
Tujuan dari kerangka kerja ini adalah untuk memiliki Scrum. Dikatakan demikian: lakukan sesuai dengan instruksi - Anda memiliki Scrum, melanggar instruksi - Anda tidak memiliki Scrum.
Kerangka kerja ini tidak menyiratkan percepatan pencapaian hasil, secara umum.
Orang yang mengajar atau mengimplementasikan Scrum bekerja dengan kerangka kerja. Mereka berbicara dan menerapkan algoritma yang tidak mengarah ke hasil apa pun selain "sekarang kami memiliki Scrum".
Intinya jelas. Filsafat sangat sulit dijual. Kerangka kerjanya lebih sederhana.
Kerangka kerja adalah produk. Dia, seperti yang diharapkan, melewati "kemasan". Sederhana, dapat dimengerti, ada dukungan dan banyak spesialis. Tidak menyerupai apa pun?
Semuanya baik, kecuali hasilnya - tidak.
Jika pelanggan tidak terbiasa dengan filosofi Scrum, maka implementasi kerangka kerja akan cocok untuknya dengan sempurna.
Jika pelanggan terbiasa dengan filosofi Scrum, maka ia akan kecewa dengan implementasi kerangka kerja - tidak akan ada percepatan dalam mencapai hasil.
Ini akan keren, modis, modern, tetapi tidak ada tujuan bisnis yang akan dicapai (kecuali untuk pengembangan anggaran untuk "sesuatu yang baru").
Bagaimana menjadi Pelajari filosofi Scrum. Ini didasarkan pada filosofi Jepang tentang manajemen kualitas, esensinya adalah: pengukuran dan peningkatan tanpa akhir.
Sayangnya, di sana Anda harus berpikir, bereksperimen, mengamati, dan, sayangnya, banyak bekerja. Jika ini tidak cocok untuk Anda, ambillah kerangka itu.
habr.com/en/post/345540Lingkungan variabel
Untuk meningkatkan efisiensi tim pemrogram, Anda memerlukan lingkungan yang bisa berubah. Sudah ada semacam lingkungan dalam tim - kita perlu membuatnya berubah.
Lingkungan yang bisa berubah adalah kurangnya algoritma kerja yang resmi dan disetujui.
Programmer suka bekerja pada algoritma, karena mereka sendiri terlibat dalam pembuatan algoritma.
Lingkungan yang dapat berubah adalah jenis debugging, ini bukan algoritma program yang melakukan debugging, tetapi kerja tim.
Setujuilah dengan tim bahwa era perubahan telah dimulai. Hari ini, beberapa aturan, besok - berbeda. Bukan karena kendali jatuh di bawah ekor, tetapi karena tim perlu ditukar.
Debugging adalah peluncuran algoritme, melacak operasinya, dan membuat penyesuaian jika terjadi kesalahan seperti yang diinginkan atau yang diinginkan.
Sebagian besar proyek perubahan gagal karena kurangnya lingkungan yang dapat diubah. Sangat menakutkan untuk membuat perubahan dalam bentuk kepingan, itu menakutkan untuk memperkenalkan aturan baru setiap hari. Jauh lebih sederhana, tanpa mengubah apa pun, untuk mengembangkan Dokumen Besar, di mana Semuanya Diatur, dan memberikannya untuk dieksekusi.
Ini, secara kasar, bagaimana menulis kode program segera, tanpa permulaan. Tidak, kadang-kadang mungkin untuk bersenang-senang, tetapi pada tugas yang layak pendekatan ini tidak berhasil - Anda harus terlalu pintar. Jauh lebih mudah untuk melakukan debugging di lingkungan yang bisa berubah.
habr.com/en/post/345830Master scrum
Scrum bersih yang dijelaskan dalam buku ini, bila diterapkan dengan benar, meningkatkan efisiensi tim sebanyak 2 kali. Ini diuji dalam praktik.
Tetapi latihan orang lain menunjukkan bahwa tidak ada percepatan yang terjadi sama sekali. Karena metodologi yang dijelaskan dalam buku ini disederhanakan untuk dijual. Dialah yang digunakan - disederhanakan.
Scrum Buku melibatkan tiga tingkatan:
- Keadaan Xiu ("kepatuhan") adalah tahap pertama, melatih, ulangi, tanpa menyimpang dari aturan;
- Negara Ha ("menerobos") - kita mulai mengubah aturan, berimprovisasi;
- Keadaan Ri ("terpisah") - kita dibebaskan dari aturan dan mulai membangun.
Sebagai aturan, level pertama adalah instruksi penjualan, dan implementasi implementasinya. Untuk mendapatkan peningkatan efisiensi yang nyata, Anda harus naik ke level kedua dan ketiga. Pikirkan dengan kepala Anda sendiri, cari cara untuk mengoptimalkan, mengimplementasikannya dan memantau hasilnya.
Master scrum harus berurusan dengan akselerasi - ini adalah tanggung jawabnya. Jadi ada tertulis dalam buku ini, saya kutip: Perhatian utama Scrum-master adalah untuk memimpin tim untuk perbaikan terus-menerus dan secara teratur mencari jawaban untuk pertanyaan "Bagaimana kita bisa melakukan yang lebih baik dengan apa yang sudah kita lakukan dengan baik?".
Tapi ini level kedua dan ketiga. Dan yang pertama dijual dan diperkenalkan.
Pada tingkat pertama, scrum master memiliki tanggung jawab yang sangat berbeda. Periksa di Internet, daftarnya akan seperti ini:
Oh
- mengorganisir dan mengadakan rapat umum;
- Memantau kepatuhan terhadap prinsip-prinsip scrum;
- Menciptakan suasana kerja sama;
- Menyelesaikan konflik dan melindungi tim.
Tidak sepatah kata pun tentang meningkatkan efisiensi. Cukup ikuti instruksi.
Jika Anda berpikir secara logis, lalu bagaimana efisiensi dapat meningkat jika tim terus bekerja sesuai dengan aturan yang sama? Agar sesuatu berubah, Anda perlu mengubah sesuatu. Tetapi Anda tidak dapat melakukan ini - sesuai dengan instruksi yang tidak diizinkan. Oleh karena itu, efisiensi di tingkat pertama tidak tumbuh.
Seorang ahli scrum haruslah orang yang tertarik untuk meningkatkan efisiensi. Karya ini tidak dapat dipelajari jika tidak menarik. Anda harus banyak berpikir, membuat percobaan, menguji hipotesis, terus-menerus membuat kesalahan dan mengisi kerucut.
Jauh lebih mudah untuk mengeluarkan instruksi dan memantau implementasinya. Nah, terkadang untuk memfasilitasi (apa pun artinya itu).
Saya mencoba menempatkan orang yang berbeda sebagai master scrum, tetapi sedikit orang yang tertarik. Ini normal.
Jika Anda terbiasa dengan tes Belbin, maka Generator Ide, Analis, dan Diplomat (penyelidik sumber daya) paling cocok.
Peran master scrum sangat mirip dengan seorang programmer yang mengoptimalkan kinerja aplikasi. Hanya di sini sistemnya hidup, dari manusia.
habr.com/en/post/346158Pengiriman sistem
Hasil dari sebagian besar perubahan organisasi: gagal.
Produk sampingan: tekniknya adalah omong kosong.
Metodologi yang mendasari perubahan. Secara khusus, Scrum.
Alasannya sangat sederhana: pembangkangan sistemik.
Nah, solusinya sangat sederhana: pengiriman sistem.
Tidak sistematis, tetapi sistemik. Pengajuan sebagai sistem, sebagai prinsip.
Di negara kita, ketidaktaatan dinaikkan menjadi pemujaan - berkat sejarah negara kita yang telah berusia berabad-abad.
Ketidaktaatan sistemik mengarah pada umpan balik aneh: aturan dan hukum baru dibuat dengan mempertimbangkan fakta bahwa tidak ada yang akan mematuhinya.
Ini terutama berlaku untuk perubahan organisasi. Penulis mereka bahkan tidak mempertimbangkan opsi bahwa orang akan bekerja sesuai dengan aturan yang diusulkan. Oleh karena itu, tidak peduli tentang keberlakuan dan kecukupan aturan.
Namun, ada contoh perubahan yang berhasil diterapkan. Ambil kamera video yang sama di persimpangan.
Secara formal, hukuman untuk mengemudi ke persimpangan di mana kemacetan lalu lintas sudah lama ada. Tetapi aturan ini praktis tidak dipatuhi.
Sekarang diamati dengan sempurna di persimpangan yang terpisah. Pada mereka yang memasang kamera video capture.
Kamera baru saja menyediakan pengiriman sistem. Segera setelah orang mulai mematuhi aturan, menjadi jelas bahwa aturan itu sendiri cukup berhasil. Aturan yang sama yang digunakan untuk bersama dianggap semacam omong kosong.
Juga, aturan lain, perubahan, algoritma, teknik, atau kasus. Teknik apa pun bermanfaat.
Jika Anda berpikir sebaliknya, jika Anda mengatakan bahwa "Scrum tidak bekerja," atau "TOS tidak berfungsi," atau "Lean itu omong kosong," maka Anda adalah orang yang hebat. Hanya saja Anda tidak menerapkan teknik ini karena Anda tidak memberikan pengiriman sistem. Dan ketidakmampuannya untuk menyediakannya ditumpuk pada ketidakmampuan metode ini.
Memberikan pengajuan sistem sangat sederhana. Anda harus mulai dengan diri sendiri. Ini akan menjadi penyerahan diri sistemik.
Memperkenalkan Scrum di tim Anda? Ikuti semua aturan yang dinyatakan, tanpa pengecualian. Setiap hari, tanpa izin.
Anda akan segera melihat kelebihan dan kekurangan dari metodologi - ini, dan lainnya.
Jika ada kesuksesan, maka Anda akan menjadi alasannya. Jika ada kegagalan, maka Anda akan menjadi penyebabnya.
habr.com/en/post/346712