Ini Semua Tentang Agile 1: Mitos Agenda Populer

Metodologi pengembangan lincah telah berakar pada TI dan non-TI, ditumbuhi pertanda, stereotip, takhayul, dan mitologi mereka. Para editor blog Mail.Ru Cloud Solutions memutuskan untuk membicarakan mitologi ini dengan Agile-coach Vasily Savunov dari ScrumTrek.

Agile adalah filosofi pengembangan lincah yang yayasannya dijelaskan dalam Manifesto Pengembangan Perangkat Lunak Agile . Konsep ini didasarkan pada empat nilai inti:

• orang dan interaksi lebih penting daripada proses dan alat;
• produk yang bekerja lebih penting daripada dokumentasi yang komprehensif;
• kerja sama dengan pelanggan lebih penting daripada perjanjian tentang ketentuan-ketentuan kontrak;
• kesiapan untuk berubah lebih penting daripada mengikuti rencana awal.

Prinsip-prinsip pendekatan Agile telah mengubah proses pengembangan dan mendapatkan rasa hormat. Dunia modern semakin cepat - puluhan layanan baru dan solusi digital muncul setiap hari. Agile memungkinkan bisnis menjadi cukup cepat ketika mengembangkan produk baru untuk mengikuti kecepatan cepat ini dan memberi pengguna dan pelanggan apa yang akan memecahkan masalah mereka sedini mungkin.

Seiring dengan popularitas di Agile datang interpretasi formal. Kami akan menganalisis mitos dan stereotip yang mencegah kita melihat esensi dari pendekatan yang fleksibel dan mendapatkan lebih banyak darinya.

Mitos 1. Agile adalah IT Only

Tidak lagi. Cukup dengan melihat daftar perusahaan yang mewakili pembicara di Agile Days dan Agile Business Conference: Gazpromneft, Rostelecom, Severstal, PTG-Group, 12Storeez. Ini dan banyak organisasi lain yang tidak terkait dengan industri TI lebih dari berhasil menggunakan pendekatan Agile.

Mitos 2. Agile - Bukan Untuk Proyek Anggaran Tetap

Dalam anggaran tetap, Anda dapat bekerja dengan sangat berbeda. Pertanyaannya adalah apa hubungan antara kontraktor dan pelanggan. Jika Anda menggunakan Agile, Anda harus fokus pada apa yang memecahkan masalah pelanggan. Dengan kata lain, jika pada awalnya pelanggan dan kontraktor melakukan perencanaan bersama dan mengidentifikasi prioritas utama produk, maka tidak ada yang akan menghentikan mereka untuk menentukan bagian produk mana yang paling berguna yang dapat dilaksanakan oleh kontraktor dalam anggaran terbatas. Dan jika Anda juga menetapkan tampilan reguler yang dibuat untuk pelanggan, sangat mungkin untuk menyesuaikan proses dalam segmen pendek dan, karenanya, menyesuaikan biaya proyek.

Mitos 3. Agile - obat mujarab untuk bisnis dan pengembangan: implementasikan, biarkan sesuatu meningkat

Sepertinya bagi saya bahwa ini adalah pandangan yang disederhanakan dan sangat berbahaya. Semua kasus dan bisnis berbeda, dan Anda perlu memilih pendekatan yang tepat yang akan membantu dalam kasus khusus ini.

Jelas, Agile tidak diperlukan di mana kunci keberhasilan mengikuti algoritma tindakan yang didefinisikan dengan baik. Misalnya, dalam pekerjaan pusat panggilan, di mana untuk layanan yang lebih baik, operator harus melakukan percakapan menggunakan "skrip", mis. skenario komunikasi yang telah ditetapkan. Tidak ada bidang untuk eksperimen, dan mereka bahkan bisa berbahaya di sini. Jadi, Agile tidak diperlukan dalam aktivitas operator call center.



Agile akan berbahaya jika biaya "pemrosesan" atau "penyempurnaan" produk tersebut sangat besar, atau bahkan mungkin melibatkan pengorbanan manusia. Katakanlah, selama pembangunan pembangkit listrik tenaga nuklir, jelas bahwa kita tidak dapat membangun iteratif-bertahap, seperti yang Agile katakan kepada kita.

Mitos 4. Scrum, Lean, Kanban tidak berpotongan.

Metodologi dan alat harus dipisahkan. Metodologi adalah suatu algoritma untuk membangun alur kerja. Alat adalah "batu bata" yang digunakan dalam algoritma ini.

Metodologi yang berbeda mungkin termasuk alat yang sama, tetapi dalam tata letak yang berbeda. Anda sering dapat melihat bagaimana, ketika mengimplementasikan Scrum, mereka menggunakan XP (pemrograman ekstrem) atau alat Kanban. Dan ini normal, karena semuanya memenuhi nilai Agile, dan memungkinkan Anda membuat alur kerja pembuatan produk fleksibel.

Jika kita berbicara tentang pendekatan Agile spesifik yang sekarang paling lazim, maka ini tentu Scrum dan Kanban. Lainnya - FDD, XP, RUP dan sebagainya, baik meninggalkan panggung atau jarang digunakan secara keseluruhan, tetapi alat individu dari arsenal mereka terlibat dalam implementasi Scrum atau Kanban.

Mitos 5. Scrum - cara membuat produk dengan cepat dan murah.

Adapun "cepat", semuanya benar, tetapi untuk "murah" - tidak. Nilailah sendiri: Anda perlu membentuk tim yang lengkap, dengan menyoroti kompetensi yang diperlukan di dalamnya 100%. Orang-orang ini hanya akan sibuk dengan pengembangan produk yang dipercayakan kepada mereka dan tidak ada yang lain, yang berarti bahwa mereka harus menyewa spesialis seperti itu atau "merobek" mereka dari beberapa departemen. Hal yang sama berlaku untuk bagian bisnis: jika Anda ingin, jika Anda tidak mau, Anda harus mengalokasikan pemilik produk yang akan mencurahkan 50-80% waktunya hanya untuk tim ini dan produknya.

Selain itu, Anda perlu menyatukan mereka semua, dalam satu ruangan, menyediakan ruang mereka sendiri, alat peraga untuk kegiatan tim, dan sebagainya. Plus, Anda harus ingat bahwa setidaknya delapan jam per sprint akan dihabiskan untuk komunikasi, karena Scrum melibatkan serangkaian pertemuan wajib yang berlangsung selama satu atau dua jam. Anda harus berinvestasi dalam hal apa pun, tetapi keuntungan akhir dalam kecepatan dan kualitas yang diberikan Scrum sangat besar.


Sprint mencakup 4 pertemuan wajib: perencanaan, implementasi, rilis, ulasan sprint dengan retrospektif. Selain itu, pertemuan singkat (stand-up meeting) diadakan setiap hari di mana anggota tim "memeriksa jam" dalam format tunggal dan mengoordinasikan tindakan mereka. Anda tidak dapat menambahkan tugas baru ke sprint terbuka - ini membiasakan tim untuk merencanakan dan memastikan terhadap terjadinya kekacauan manajerial.

Mitos 6. Kanban adalah papan dengan tugas yang diposting pada mereka.

Tidak semuanya! Papan hanyalah langkah pertama dan termudah di Kanban. Namun masalahnya tidak terbatas pada mereka . Di jantung Kanban adalah alat matematika yang kompleks berdasarkan pada data statistik. Karena itu, menyamakan Kanban dengan papan berarti tidak melihat melampaui fasadnya.

Singkatnya, poin utama Kanban adalah untuk:

• Jadikan alur kerja saat ini transparan, dan mencakup semua tahapan - mulai dari terjadinya tugas di kepala bisnis hingga implementasi dan pengiriman produk ke konsumen.
• Kelola alur kerja Anda dengan mengidentifikasi kehilangan waktu dan menghilangkannya. Dengan demikian, kami membuat alur kerja kami dapat diprediksi.
• Buat keputusan manajemen berdasarkan metrik, bukan perasaan.

Mitos 7. Scrum dan Kanban dapat ditanam di setiap proyek dan perusahaan.

Saya tidak suka kata "menanam," Agile adalah tentang bekerja dengan orang-orang. Akan lebih tepat untuk berbicara tentang "menanamkan" filosofi berpikir baru ke dalam tim.

Pada saat yang sama, algoritma pencangkokan Scrum dan Kanban berbeda.

Tingkat keberhasilan menggunakan Scrum tergantung pada budaya perusahaan dominan perusahaan. Dalam struktur hierarkis yang keras, di mana setiap orang membutuhkan selembar kertas, tidak ada upaya untuk "menumbuhkan" Scrum akan berhasil tanpa dukungan manajemen puncak. Kita harus membangun struktur paralel baru berdasarkan pendekatan tim. Semacam "cadangan Agile", yang akan melindungi salah satu manajer eselon tertinggi. Dalam kondisi seperti itu, dimungkinkan untuk menunjukkan hasil cepat dalam tiga hingga empat bulan. Tetapi akan ada tugas yang lebih sulit di depan - untuk menyebarkan budaya ini ke seluruh organisasi. Berapa banyak ini akan bertahan sangat sulit untuk dinilai. Tetapi, dalam pengalaman saya, jika pendekatan baru mencakup 30% dari perusahaan, maka itu mulai menyebar lebih jauh, dan itu tidak lagi membutuhkan perlindungan dari atas.

Implementasi Scrum umumnya membutuhkan perubahan besar, baik dalam struktur organisasi dan dalam kontrak dengan kontraktor (Anda memerlukan kontrak waktu & material ), dan dalam penganggaran (penganggaran bertahap), dan segala sesuatu lainnya.



Kanban tidak membutuhkan perubahan radikal seperti itu. Dia menawarkan: "Mulailah dengan apa yang ada, dan mulai tingkatkan secara evolusioner." Tingkat perubahan akan jauh lebih rendah daripada di Scrum, tetapi semua perubahan akan didasarkan pada statistik dan memiliki justifikasi yang jelas.

Mitos 8. Scrum dirancang hanya untuk proyek-proyek yang dibuat dari awal.

Ada beberapa kasus yang berbeda, tidak ada aturan kaku bahwa Scrum hanya ditujukan untuk pengembangan dari awal. Mentransfer proyek yang ada ke Scrum tidak hanya mungkin, tetapi seringkali sesuai. Itu semua tergantung pada kemauan pemain dan pelanggan untuk merestrukturisasi pekerjaan mereka untuk mempercepat pengembangan. Jika mereka siap, semuanya dapat dicapai.

Sebagai contoh, salah satu pencipta Scrum, Jeff Sutherland, dalam bukunya Scrum: The Art of Doing Twice the Work di Half the Time, berbicara tentang bagaimana ia menggunakan Scrum untuk mengembangkan sistem akuntansi FBI otomatis. Ketika ia mengambil proyek, pengembangan berlangsung untuk tahun keempat, tidak ada fungsi tunggal yang dirilis dan proyek tidak terlihat ujung atau ujungnya. Jeff mampu mempercepat pengembangan secara radikal dan membuatnya transparan bagi pelanggan. Enam bulan kemudian, versi kerja produk yang pertama dirilis, dan dalam waktu dua tahun pengembangannya berhasil diselesaikan.

Mitos 9. Ketika memperkenalkan metodologi yang fleksibel, konflik dengan perwakilan hierarki tradisional tidak bisa dihindari

Jika semuanya dilakukan dengan benar - untuk memisahkan tim dari hirarki tradisional, memberikan anggaran kepada pemilik produk dan menyewa Scrum-master yang benar-benar terampil, maka tidak akan ada konflik. Tetapi ini tidak selalu terjadi. Seringkali mustahil untuk menggabungkan kedua struktur ini, oleh karena itu hanya ada satu jalan keluar: untuk membangun struktur baru, diasah untuk pengambilan keputusan yang cepat dan implementasi produk.

Dan tentang siapa Scrum-master seperti itu, Anda akan belajar di seri berikutnya. Tunggu di bagian kedua dari kisah Vasily tentang penerapan metodologi pembangunan yang fleksibel: kesulitan, manfaat, jebakan dan bom waktu.

UPD Dan inilah kelanjutannya: Ini semua tentang Agile - 2: fitur penerapan pengembangan agile

Tidak ada waktu untuk menjelaskan, materi tidak tertarik dan penuh kasih sayang disiapkan oleh tim Mail.Ru Cloud Solutions .