Ini Semua Tentang Agile - 2: Fitur Implementasi Agile

Kami melanjutkan tentang nuansa pengembangan tangkas yang terjadi dalam praktik. Bagaimana memahami apakah Agile diterapkan dengan benar, praktik apa yang cocok untuk tugas dan industri mana, yang di perusahaan harus mentransfer pekerjaan ke “Agile-rails”? Vasile Savunov, Agile Coach ScrumTrek, terus berbagi pengalamannya dengan para editor blog Mail.Ru Cloud Solutions .

Terakhir kali, Vasily berbicara tentang apa itu Agile, metodologi apa yang dicakupnya, dan stereotip apa yang terbentuk di sekitarnya. Sekarang mari kita bicara tentang implementasinya.

Tentang Perusahaan Agile

- Apakah ada "preferensi industri" dalam metodologi yang fleksibel?

Sebagaimana studi Agile Russia , yang telah kami lakukan selama dua tahun berturut-turut, menunjukkan bahwa Scrum terutama digunakan dalam pengembangan perangkat lunak, Kanban di organisasi keuangan, dan keduanya di industri telekomunikasi.

Sebagai orang yang secara langsung menganalisis data yang dikumpulkan, dan bekerja dengan banyak responden, saya percaya bahwa keadaan ini disebabkan oleh dua alasan:

• Tingkat perubahan dalam TI secara signifikan lebih tinggi daripada di bidang keuangan. Oleh karena itu, Scrum lebih disukai di sana sebagai pendekatan yang memungkinkan, karena percobaan cepat, untuk secara fleksibel mengontrol prioritas dan mengubah arah tergantung pada perubahan dalam lingkungan eksternal dan kondisi di pintu masuk. Keuangan lebih konservatif.
• Biaya kesalahan dalam keuangan jauh lebih tinggi daripada dalam pengembangan TI. Oleh karena itu, mereka lebih dihargai Kanban, berdasarkan matematika, daripada eksperimen, dan memungkinkan melalui perubahan kecil tapi konstan untuk meningkatkan alur kerja secara keseluruhan.

Telecom Kanban juga cocok. Kalau saja karena vektor pengembangan industri adalah digitalisasi. Namun, sedikit orang yang mengerti bagaimana persisnya tampilannya. Selain itu, dalam telekomunikasi, bagian “cepat” dari pekerjaan (pengembangan perangkat lunak) berdekatan dengan bagian “lambat” (dukungan dan pengembangan infrastruktur perangkat keras). Oleh karena itu, bersama dengan eksperimen yang dilakukan pada Scrum, masuk akal untuk secara evolusioner mempercepat proses saat ini menggunakan Kanban.


Praktek pengembangan tangkas diadopsi di berbagai industri. Jumlahnya tidak sama dengan 100% karena lebih dari satu item dapat dipilih. Gambar / ScrumTrek

- Dan bagaimana dengan pengembang seluler? Apakah Agile memiliki spesifikasi khusus dalam pengembangan seluler?

Dari sudut pandang saya, kesulitan utama dalam mengembangkan aplikasi seluler adalah mengidentifikasi persyaratan aplikasi, karena sulit untuk mengidentifikasi pemangku kepentingan. Kesulitan-kesulitan ini dapat diatasi dengan menggunakan pengembangan pelanggan untuk meneliti kebutuhan pelanggan dan Scrum untuk dengan cepat menguji hipotesis produk.


Secara umum, Agile berjalan baik dengan pengembangan ponsel: membutuhkan reaksi cepat, keterlibatan, dan kerja yang terkoordinasi dari spesialis yang berbeda, kemampuan untuk dengan cepat memberikan hasil dan, jika perlu, mengubahnya.

Selain Scrum, di sini Anda dapat menggunakan fokus langsung pada pendekatan pengembangan seluler. Misalnya, Mobile-D didasarkan pada XP, Crystal dan RUP - pendekatannya cukup kuno dan mapan. Perbedaan utama antara Mobile-D dan Scrum: keberadaan fase yang jelas dan fokus utama pada sisi rekayasa pengembangan produk. Sementara Scrum lebih memperhatikan manajemen dan pengiriman produk, Mobile-D berfokus pada proses pembuatan dan mencakup praktik XP yang secara signifikan meningkatkan kualitas produk akhir. Pada saat yang sama, pengaruh RUP memengaruhi, sehingga prosesnya cukup formal.

Pendekatan lain yang paling modern untuk pengembangan ponsel adalah SLeSS , menggabungkan Scrum dan Lean Six Sigma . Pertama, dia mengimplementasikan pengaturan alur kerja Scrum, dan kemudian menerapkan pendekatan Lean Six Sigma untuk manajemen kualitas statistik. Menurut saya SLeSS menggabungkan fleksibilitas yang diperlukan dengan mekanisme pengambilan keputusan berdasarkan informasi statistik.

Pada saat yang sama, Panduan Scrum pada awalnya tidak melarang dimasukkannya pendekatan dan alat lain dalam alur kerja Scrum yang mungkin berguna untuk pengembangan produk. Oleh karena itu, semua hal di atas dapat diimplementasikan dalam kerangka Scrum "klasik".

- Seberapa fleksibel metodologi untuk memodifikasi dalam kondisi tertentu?

Itu harus dipertimbangkan secara terpisah Scrum dan Kanban.

Scrum adalah kerangka kerja, yaitu kerangka kerja, yang semua elemennya diperlukan: peristiwa, peran, dan artefak. Tidak ada yang bisa dibuang. Tetapi tidak ada persyaratan ketat tentang bagaimana tepatnya menerapkan elemen-elemen ini - lakukan seperti yang Anda inginkan. Dan Scrum tidak melarang menambahkan elemen baru: pertemuan, artefak, peran yang Anda butuhkan untuk bekerja dan membantu mempercepat proses.

Kanban adalah seperangkat alat dan metrik. Dia tidak memberikan pengaturan yang ketat tentang alat yang tepat dan dalam kombinasi apa yang digunakan, karena ia dirancang untuk perubahan evolusi yang panjang dalam sistem yang ada. Tetapi pada saat yang sama, keberhasilan Kanban ditentukan oleh pengumpulan data tentang proses kerja dan analisis rutin mereka. Jika ini tidak dilakukan, lama kelamaan semuanya akan padam dan tidak akan ada perbaikan lebih lanjut. Tapi tidak apa-apa: seperti kata Edward Deming, Anda tidak perlu berubah, bertahan hidup adalah sukarela.

- Apa kesalahan khas dalam adaptasi yang dilakukan Scrum dalam bisnis?

Kesalahan utama dalam menerapkan metodologi yang fleksibel adalah penggunaan alat tanpa memahami mengapa mereka harus digunakan secara khusus.

Misalnya, dalam organisasi besar, ketika menerapkan Scrum, mereka sering kali hanya mengganti nama manajer proyek sebagai pemilik produk, dan tim proyek menjadi tim Scrum dan mulai menuntut untuk memberikan hasil yang selesai dalam dua minggu. Tapi ini tidak berhasil, dan untuk alasan yang sangat sederhana: kondisi tidak terpenuhi di mana Scrum dapat bekerja .

• Meskipun manajer proyek telah dijuluki sebagai Pemilik Produk, ia belum menerima wewenang yang diperlukan dan karena itu tidak berhak untuk merumuskan visi produk atau mengubah prioritas implementasi. Seperti sebelumnya, ia dipaksa untuk mengoordinasikan setiap langkahnya dengan kepemimpinan dan dijepit dalam kerangka persyaratan untuk waktu dan volume pekerjaan. Jadi, kecepatan pengambilan keputusan tetap sama. Tidak ada akselerasi atau adaptasi terhadap perubahan kondisi.
• Meskipun tim proyek disebut tim Scrum, orang-orang yang termasuk di dalamnya masih dapat didaftar di setiap departemen dan melapor langsung ke manajer lini mereka. Oleh karena itu, setiap anggota tim pertama-tama melakukan apa yang manajer lini-nya, dan bukan Pemilik Produk, akan mempercayakan kepadanya. Akibatnya, tugas produk akan selalu lebih rendah dalam prioritas, yang berarti bahwa kecepatan implementasi produk, di mana tim Scrum "dirakit", tidak akan meningkat sama sekali.
• Kemungkinan besar, seperti sebelumnya, anggota tim akan sibuk dalam proyek lain. Sementara Scrum secara langsung menyatakan: anggota tim harus dialokasikan ke tim Scrum 100% dari waktu kerja mereka, dan hanya berurusan dengan produk yang dipimpin oleh Pemilik Produk mereka. Jika orang “dibagi berdasarkan persentase” antara proyek / produk, maka mereka akan beralih di antara mereka, yang secara drastis akan mengurangi keterlibatan dan efisiensi kerja pada setiap proyek / produk tertentu.

“Implementasi” yang tidak kompeten semacam itu memiliki banyak konsekuensi negatif, tetapi mereka mulai dengan upaya mereproduksi mekanik, tetapi bukan esensi Scrum. Kesalahan utama dalam implementasi Scrum dijelaskan secara rinci dalam laporan saya " Stop Signals for Agile " di konferensi CodeFest 2017.

- Bagaimana cara mengevaluasi bagaimana metodologi yang fleksibel dan kompeten diterapkan di perusahaan?

Ada tes Scrum Open , tetapi lebih berfungsi sebagai tes pengetahuan teoritis. Apa yang terjadi dalam praktik, ia tidak memungkinkan untuk mengerti. Mengingat bahwa dasar Scrum adalah kerja tim, dan prioritasnya adalah kecepatan pengiriman produk dan nilai bagi konsumen, 360 survei paling tepat. Jadi, lebih dapat diandalkan untuk menetapkan tingkat kematangan tim dan kepuasan pelanggan.

Kami menggunakan metodologi kami sendiri, yang diimplementasikan dalam layanan Alat Diagnostik ScrumTrek . Dia bekerja seperti itu. Sebuah tim dan pihak-pihak yang berkepentingan di luarnya ditanyai serangkaian pertanyaan tentang bagaimana mereka mengevaluasi tingkat interaksi tim, merencanakan pekerjaan mereka, nilai hasil yang disampaikan kepada pelanggan, interaksi dengan tim lain, dan sebagainya. Untuk setiap parameter, median pendapat dihitung dan diagram lingkaran yang rumit dibuat - Radar, yang menampilkan tampilan baik dari bagian dalam tim maupun dari luar.


Radar ScrumTrek. Kami melihat penyebaran peringkat


Radar ScrumTrek. Kami melihat median

Diagram tersebut berisi banyak informasi berguna.

• Perkiraan atom individu dan rata-rata mereka menarik dalam diri mereka sendiri, dan penjelasan tidak diperlukan di sini.
• Menyebarnya nilai dalam tim adalah hal yang menarik. Ketika itu sangat besar, ada alasan untuk menyetujui apa yang kita sebagai tim maksudkan dengan satu atau lain aspek pekerjaan kita. Apa yang kita maksud dengan "nilai pelanggan", misalnya? Dan bagaimana dengan "kecepatan pengiriman"? Spread besar menunjukkan bahwa tim belum membentuk posisi tunggal pada sejumlah masalah.

Spread kecil menunjukkan konsensus dan kerja tim yang baik.

• Peringkat dikategorikan. Anda dapat melihat bahwa semuanya baik-baik saja dengan budaya, tetapi produktivitas menurun di beberapa tempat. Jelas di mana harus "menggali."
• Perbedaan antara penilaian di dalam dan di luar tim adalah salah satu indikator paling penting, ini menunjukkan perbedaan antara harapan pelanggan dan pihak lain yang berkepentingan dari tim dan bagaimana tim memandang dirinya. Agile adalah tentang interaksi yang erat antara bisnis dan mereka yang menjual produk, sehingga perbedaan ini adalah alasan yang sangat baik untuk "memeriksa jam" antara dua bidang ini dan menyepakati cara merestrukturisasi tim.

Setelah mengumpulkan data, analisis bagan perlu dilakukan dengan melibatkan seluruh tim dan pemangku kepentingan. Semuanya untuk menunjukkan kepada mereka bagaimana pekerjaan tim terlihat dari sudut yang berbeda, dan untuk memproses hasil analisis menjadi langkah nyata untuk meningkatkan pekerjaan.

Tentang Tim Pelaksana Scrum

- Dari siapa perusahaan harus memulai penerapan metodologi pengembangan tangkas?

Implementasi scrum selalu berasal dari tujuan bisnis. Karena itu, pelanggan harus menjadi orang pertama yang memikirkan akselerasi - baik internal maupun eksternal. Maka Anda perlu memikirkan konsep produk sehingga bisa dilakukan berulang-ulang. Dan baru kemudian membentuk tim. Scrum demi Scrum tidak berfungsi. Selain itu, mungkin terlalu mahal untuk menyelesaikan masalah tertentu.

Siapa yang akan menjadi "Agile guide" di perusahaan adalah pertanyaan tanpa satu-satunya jawaban yang tepat. Saya melihat direktur teknis menjadi "penghasut" perubahan. Ada kasus ketika inisiatif datang dari bisnis, dan bahkan melihat bagaimana inisiatif tersebut muncul "dari bawah". Semuanya tergantung pada energi dan motivasi orang tersebut, apakah ia akan dapat menanamkan visinya tentang pengembangan dengan menggunakan pendekatan yang fleksibel ke dalam konteks bisnis produk atau unit.

Ideal ketika inisiatif berasal dari manajemen puncak. Kemajuan dalam arah ini terlihat di pasar Rusia.

- Peran dan fungsi baru apa yang muncul dalam suatu organisasi atau tim dengan pengenalan metodologi yang fleksibel? Yang mana dari mereka yang diperlukan, mana yang opsional?

Dalam kasus Scrum, ini adalah peran master Scrum, pemilik produk dan tim pengembangan. Semuanya diperlukan. Tim pengembangan juga dianggap sebagai "peran", karena tidak hanya menggabungkan pengembang, tetapi juga setiap orang yang membutuhkan produk untuk tampil pada prinsipnya: analis, desainer, dan sebagainya.

Scrum-master dan pemilik produk mungkin memiliki asisten yang mengambil alih sebagian tugas mereka, sementara tanggung jawab atas hasilnya tetap berada pada scrum-master atau pemilik produk.

Pemilik produk sering kali adalah orang dari bisnis. Tetapi tidak harus: katakanlah, jika kita menciptakan semacam solusi rekayasa untuk produksi, peran ini dapat dimainkan oleh chief engineer. Pada akhirnya, ini adalah orang yang mengerti yang terbaik dari semua untuk siapa konsumen kita membuat produk, masalah apa yang dipecahkan di tempat pertama, bagaimana prioritas harus dibangun ketika menciptakannya. Sangat penting bahwa pemilik produk memiliki wewenang untuk secara independen menentukan komposisi produk berdasarkan data dari pasar dan dari konsumen. Dia harus memiliki hak untuk mengatakan tidak kepada pihak yang berkepentingan dengan siapa dia berinteraksi. Ini diperlukan agar prioritas disepakati dan keputusan diambil segera.

Scrum-master adalah orang yang tugasnya menciptakan tim yang kuat, bersatu, bertanggung jawab, dan idealnya mengatur diri sendiri. Yang penting bukanlah pemimpin tim , yaitu, bukan pemimpin. Scrum-master tidak diizinkan untuk memberikan panduan atau campur tangan langsung dalam pengembangan produk. Dia adalah penyelenggara, fasilitator, pelatih dan praktisi Agile. Dalam pengalaman saya, para master Scrum terbaik berasal dari manajer proyek - asalkan mereka telah dilatih dan dikelola untuk beralih dari format arahan ke format pelatihan.


Berbicara tentang gaya komunikasi pembinaan. Ada juga pelatih Agile . Tugasnya adalah mengatur alur kerja, mendidik orang dan memberi mereka alat untuk kegiatan sehari-hari dalam Agile. Termasuk alat resolusi konflik. Segala sesuatu yang lain berada di luar jangkauannya. Idealnya, seorang pelatih Agile harus membentuk tim atau departemen sehingga semuanya bekerja sendiri dan tidak ada pelatih Agile yang dibutuhkan.

Masa transisi selalu dikaitkan dengan ketidaknyamanan. Agile-coach dirancang untuk membantu tim melewati periode ini dengan gesekan minimal dan mengembangkan metode kerja yang baru - nyaman dan efektif.

Saat melakukan penskalaan, peran tambahan dapat diperkenalkan, seperti dijelaskan, misalnya, dalam kerangka kerja SAFe , tetapi masih didasarkan pada kerangka acuan dan prinsip-prinsip kerja Scrum-master atau pemilik produk: tingkat hierarki mengenai produk hanya muncul.


- Bagaimana fungsi pemilik produk dan master Scrum “di dunia yang ideal” dibedakan?

— , , — , Scrum-. , . «» , , , . Scrum-, , , .


— , ?

- « », , .

Lean Startup, customer development .

Scrum- : , , , , , Agile. , , , .

— «» ? ?

. code review , .

«» : , , , , .

: , . , «» — . , , , ? . .

-, , , , . : « , ». , , .

-, . , , , . : , , , , . , .

-, «» . , : , «», «» . : , , .

— , - ?

• , «»: . .
• . , , .
• «» , , , , . . . , , .
• «». «» , «- ». Scrum-, «», , «» , , . , , «».

, , . , « ». , , « » . , « . - ».

Mail.Ru Cloud Solutions .