Dunia kita sangat aneh. Dan semakin jauh Anda pergi, semakin aneh yang didapatnya. Dan Anda akan mengerti apa yang terjadi.
Ada insinyur dan programmer di dunia. Terkadang semua digulung menjadi satu. Orang yang mengerti apa itu algoritma. Apalagi orang yang membuat algoritma ini. Mereka sangat menyadari bahwa algoritma yang dibuat cocok untuk menyelesaikan satu masalah, tetapi tidak cocok untuk yang lain. Memahami bahwa jika algoritme sedikit berubah, maka itu akan dapat memecahkan masalah terkait. Jangan ragu untuk membuang setengah dari algoritma orang lain sehingga lebih baik menyelesaikan masalah saat ini.
Pemrogram membuat solusi untuk tugas, atau untuk kelas tugas. Inilah esensi dari profesi ini. Jika memungkinkan, gunakan potongan kode mereka sendiri atau orang lain yang sudah jadi. Dan semuanya baik-baik saja.
Tetapi, segera setelah membuat algoritma di luar komputer, programmer tiba-tiba kehilangan akal. Saya tidak berbicara tentang menggambar diagram algoritma di atas kertas, seperti yang terjadi pada ujian universitas - di sini kita dapat mengatasinya.
Saya berbicara tentang "implementasi teknik", "bekerja pada kerangka", "penggunaan wajib semua artefak". Tentang sekte, singkatnya.
Sedikit kebodohan
Semua orang tahu apa itu operator kondisional. Tidak ada kehidupan tanpa dia. Tidak ada algoritma yang layak yang akan berfungsi. Baik di komputer, maupun dalam kehidupan.
Sekarang bayangkan: seseorang tertentu muncul, misalnya, John, dan memperhatikan bahwa ada pernyataan bersyarat dalam BASIC. Saya mengambilnya, menemukan jawabannya, memastikan - itu berhasil, tanpa cara apa pun.
Katakanlah John bodoh. Tetapi dia memutuskan untuk menaklukkan dunia. Pergi untuk menjual BASIC. Bukan bahasa itu sendiri, tetapi semacam "teknik pengembangan perangkat lunak paling keren", tautan utamanya adalah ... Dan John tidak akan mengatakan sampai Anda menyelesaikan kursus.
Oke, tentu saja ada pecinta, terutama karena harganya tidak tinggi. Mereka datang, mendengarkan, terkesiap. Elemen utama dari metodologi pengembangan perangkat lunak paling keren adalah Operator Bersyarat. Kami banyak mendengarkan tentang pernyataan kondisional. Misalnya, cara mengubahnya menjadi operator pilihan ganda. Mereka terkesiap lagi - sungguh Operator Bersyarat yang kuat.
Setengah dari hadirin adalah programmer. Neighing, pulang. Seperempat lainnya adalah manajer. Mereka menjadi bijaksana, mengajukan pertanyaan, seseorang memutuskan untuk menerapkan teknik keren ini di rumah mereka. Kuartal terakhir sama dengan John. Mereka membujuk orang itu untuk membuat waralaba, Komunitas, Otoritas Sertifikasi dan Universitas Kontinjensi.
Programer dari kursus kembali bekerja, tidak lagi mengingat Operator Bersyarat. Tetapi satu jam kemudian, manajer datang dan mengumumkan bahwa sekarang pengembangan perangkat lunak akan dilakukan sesuai dengan metode paling keren. Ya, yaitu tentang Operator Bersyarat. Secara umum, lebih baik menulis dalam bahasa dasar.
Si pemalu, jika tidak keberatan si pemalu diabaikan. Frasa seperti "sialan itu adalah operator bersyarat, ada di mana-mana" dianggap sebagai upaya untuk pamer. Roda berputar.
Dan John dengan cepat menyadari bahwa hanya satu Operator Bersyarat saja tidak cukup. Seharusnya juga ada Loop, Subroutine, Variable, Array, dll. Kita entah bagaimana harus memanggil semuanya ... Singkatnya ... Oh, biarlah itu Artefak! Tidak lebih, tidak kurang!
Hal utama yang tetap: untuk menambah klausa metodologi bahwa metodologi pengembangan perangkat lunak paling keren adalah holistik, pengetahuan holistik. Jadi, tidak ada satupun yang bisa terlempar keluar. Dan Anda tidak dapat menambahkan apa pun ke dalamnya - itu akan berhenti bekerja. Seperti ada tertulis, demikian juga.
Berkat antusiasme John dan teman-temannya, sekarang seluruh dunia menggunakan bukan operator bersyarat, tetapi Operator Bersyarat, bukan siklus, tapi Siklus, dll., Sesuai daftar. Mereka yang mengerti kebodohan situasi telah lama pensiun atau tutup mulut. Mereka yang datang baru-baru ini sangat percaya bahwa Operator Bersyarat adalah bagian dari teknik pengembangan perangkat lunak paling keren yang dibuat oleh John. Dan semua operator bersyarat lainnya adalah kemiripan yang menyedihkan, salinan yang pudar dan sepotong Pengetahuan yang keluar dari konteks.
Siapa pun yang berani memberikan suara di Internet (atau, dilarang Tuhan, di dalam tim) akan dikenai kutukan sengit dan minuskulasi kemarahan - Anda, boot, tidak melihat manfaat dari Operator Bersyarat! Dan jika orang yang malang meminta untuk menjelaskan apa arti dan perbedaan dari operator bersyarat dalam C ++, javascript atau bahkan 1C, ia akan mendapatkan jawaban "tidak mungkin untuk menjelaskan", "Anda tidak mengerti", atau "baca panduan ini".
Alat dan Algoritma
Semua orang mengerti apa itu operator kondisional, dan bagaimana menggunakannya dalam algoritma. Dengan cara yang sama, semua orang mengerti apa, misalnya, stiker dengan tugas yang direkam. Stiker muncul sebelum scrum, dan tinggal di luarnya. Lihatlah komputer seorang akuntan, pemasok, atau penjual. Mereka belum menghilangkan kebiasaan menggantung seikat stiker dengan tugas mendesak di monitor. Kata sandi akan ditulis di salah satu stiker.
Setiap teknik dapat dengan mudah dibongkar menjadi alat, prinsip, dan hubungan. Sama seperti algoritma apa pun dibongkar menjadi angka bentuk dan tujuan yang berbeda - awal dan akhir dari algoritma, tindakan, kondisi, subrutin.
Setiap teknik memiliki ruang lingkup. Tidak semuanya benar-benar ada - ada lingkungan yang lebih cocok, ada yang kurang. Sama seperti algoritma.
Teknik apa pun bisa dimodifikasi. Buang potongan, tambahkan yang baru, modifikasi alat khusus. Sama seperti algoritma.
Setiap teknik dapat dicampur, seluruhnya atau dalam potongan. Ambil setengah dari satu, seperempat dari yang lain, seperempat lagi - menemukan diri Anda sendiri. Ketika Anda membuat aplikasi atau layanan, jelas bagi Anda.
Benar, pertanyaannya tetap - akankah metodologi menjadi metodologi, jika diubah?
Berikut ini cara menjawab pertanyaan ini, misalnya, Panduan Scrum yang terkenal:
“Peran, artefak, aturan, dan peristiwa Scrum tidak dapat berubah. Meskipun penggunaan elemen individual dari kerangka kerja ini dapat diterima, hasilnya tidak dapat disebut Scrum. Scrum hanya ada sebagai keseluruhan kerangka kerja, tetapi dapat mengakomodasi teknik, metodologi, dan praktik lainnya. ”
Agak seperti John dan Operator Bersyaratnya, bukan? Sepertinya, ubah jika Anda mau, hanya saja itu tidak akan menjadi scrum. Dan apa hasilnya nanti - neraka tahu. Untuk jaga-jaga, mereka mencatat bahwa Anda dapat mencoba untuk mendorong sesuatu di dalam. Tetapi tulang punggung harus tetap ada. Kalau tidak ... Itu bahkan menakutkan untuk dibayangkan.
Apakah ini menakutkan? Apa yang akan terjadi jika beberapa artefak dibuang atau diganti? Lagi pula, apa gunanya? Dari mana mereka berasal? Mengapa dipercaya bahwa mereka hanya bekerja dalam kombinasi seperti itu, seperti yang penulis putuskan?
Mari kita coba mencari tahu bagian-bagiannya.
Sprint dan Sprint Backlog
Omong-omong, alat yang hebat. Diciptakan, mungkin, seribu tahun yang lalu. Itu selalu disebut berbeda, tetapi yang paling umum, mungkin, adalah "Rencana". Dan secara manusiawi - "untuk melakukan sejumlah pekerjaan untuk jangka waktu tertentu."
Bagi saya, sebagai 1Sniku, itu lebih dikenal sebagai perencanaan ruang-kalender (OKP). Ini banyak digunakan dalam perencanaan produksi dan penjualan. Misalnya, rencana penjualan manajer sebesar 1 juta rubel per bulan adalah jaminan simpanan dan sprint. Kadang-kadang angka cukup, kadang-kadang ada gangguan berdasarkan kelompok produk, atau pembatasan di pasar, atau bahkan ada daftar item tertentu, jika diperlukan oleh strategi perusahaan.
Produksi lebih mudah. Busing - 1000 pcs., Poros - 2000 pcs., Rotors - 500 pcs. Ini, katakanlah, rencana mingguan. Dia adalah simpanan dari sprint mingguan di lokasi produksi. Benar, para pekerja tidak dapat dijelaskan bahwa ini bukan rencana, tetapi berlari.
Alat ini baik dibandingkan dengan manajemen waktu yang tersebar luas, ketika kumpulan tugas programmer diperkirakan berdasarkan biaya tenaga kerja, disortir berdasarkan beberapa kriteria, dan setiap tugas memiliki tenggat waktu. Dalam produksi, ini disebut perencanaan shift, atau perencanaan bengkel, dari mana tugas-tugas produksi kemudian dibuat yang berisi daftar bagian dan produk setengah jadi, operasi teknis, bahan, input dan output (di mana untuk mendapatkan apa dan di mana untuk mentransfer hasil).
Untuk programmer, perencanaan lokakarya tidak berfungsi dengan baik, dan tidak ada yang perlu didiskusikan di sini. Waktu pemrosesan bagian pada model mesin tertentu telah dikenal sejak lama dan cukup akurat. Frekuensi layanan - juga. Kecukupan bahan dievaluasi. Ambil dan lakukan. Variasi yang mengganggu implementasi rencana dalam produksi massal biasanya tidak memiliki pengaruh yang signifikan. Dan jika mereka melakukannya, ada metode yang sangat baik untuk menganalisis dan menghilangkannya.
Variasi pemrogram jauh lebih kuat. Dia bukan alat mesin, karena beberapa manajer yang datang ke TI dari penjualan atau produksi tidak akan suka. Oleh karena itu, perencanaan lokakarya (tugas + tenggat waktu) tidak cocok untuk seorang programmer. Jadi orang yang masuk akal datang dengan - Anda harus naik ke tingkat yang lebih tinggi, tidak menjadwalkan kinerja dalam hitungan menit, tetapi memberikan volume untuk suatu periode. Hanya mereka yang datang dengan nama lain - sprint dan backlog.
Mengisi rencana produksi kalender-volumetrik didasarkan pada prinsip-prinsip yang mirip dengan pembentukan tumpukan sprint. Bahkan ada hal seperti itu - "pilih rencana." Ada kebutuhan departemen penjualan yang sama (= simpanan besar), ada throughput produksi (= kemampuan tim dalam jumlah), ditambah ada kriteria seleksi yang jelas - jumlah penjualan, profitabilitas setiap posisi, parameter pelanggan (misalnya, syarat pembayaran). Mencetak rencana produksi - dan segera melihat perkiraan hasil keuangan yang Anda peroleh. Ini bukan "rilis" sesaat.
Apakah ada kekurangan pada alat ini? Tentu saja, seperti yang lainnya.
Jika Anda mengerti, sprint backlog adalah perencanaan lokakarya yang sama, hanya tanpa urutan pemecahan masalah yang terorganisir dengan baik. Oleh karena itu, semua tugas memiliki satu tenggat waktu - akhir sprint. Setelah tugas memiliki satu tenggat waktu, efek yang tidak menyenangkan muncul - di awal sprint, aktivitas dapat secara signifikan lebih rendah daripada di akhir.
Inilah cara kerja psikologi manusia. Anda selalu ingin berkeliaran di awal periode eksekusi, apakah itu satu tugas, atau jaminan. Beristirahatlah dari masa lalu, terutama - dari bagian terakhirnya, ketika itu perlu untuk memberikan hasil "besar". Tentu saja, ada orang yang stabil dan berirama, bekerja sepanjang minggu dengan kecepatan yang sama, tetapi sebagian besar mulai "bekerja secara normal" di suatu tempat pada hari Rabu.
Apakah mungkin dilakukan tanpa sprint dan jaminannya? Mudah
Misalnya, menerapkan alat "sesegera mungkin." Secara umum, ini bukan perilaku Praporsky, tetapi cukup strategi normal untuk perencanaan lokakarya yang sama (As Soon As Possible, ASAP). Ini berarti bahwa masalah akan "menempel" pada awal interval waktu, yaitu Pada hari Senin, bukan hari Jumat, seperti strategi “As Last Possible, ALAP”.
Perencanaan seperti itu tidak diperlukan dalam kasus ini. Ada jaminan produk, ada prioritas, ada aturan "secepat mungkin." Anda ambil yang pertama dan lakukan itu. Selesai - Anda ambil yang kedua. Dan - dari pagar untuk makan malam. Sprint, atau lebih tepatnya, esensinya, mis. lamanya waktu yang Anda bisa tinggalkan untuk memahami dan menganalisis produktivitas (minggu ke minggu, bulan ke bulan, dll.).
Apakah ada kekurangan dalam strategi "sesegera mungkin"? Tentu saja, sejuta. Pertama-tama, seseorang bisa cepat lelah. Kedua, dia akan merasa seperti alat mesin. Ketiga, ia kemungkinan besar akan melarikan diri - ke tempat sprint biasa dengan backlog digunakan. Atau mereka hanya mengatur tugas dan menunggu hasilnya. Secara umum, di tempat yang lebih tenang. Tetapi praktik menunjukkan bahwa "sesegera mungkin" sangat mungkin untuk hidup selama bertahun-tahun, jika masuk akal bahwa ini adalah strategi perencanaan, dan bukan keringat.
Apakah mungkin untuk melempar sprint dan jaminannya? Tidak. Bukan karena ini adalah gagasan unik dari scrum yang sama, tetapi karena ini adalah metode perencanaan alami yang digunakan semua orang, dalam satu atau lain bentuk. Ada banyak variasi, satu prinsip - Anda perlu melakukan sejumlah pekerjaan untuk jangka waktu tertentu.
Apakah alat seperti sprint merupakan elemen kunci dan unik dari suatu teknik? Tidak. Ini sama dengan mengatakan bahwa mengetik kode pada keyboard adalah gagasan unik dari beberapa teknik. Hampir semua teks diketik di keyboard.
Papan scrum
Secara formal, papan bukan artefak atau aturan, tapi saya pikir layak untuk membicarakannya juga, karena ada pola yang cukup jelas di antara orang-orang: scrum adalah papan dengan stiker.
Di sini, secara umum, Anda sendiri memahami segalanya. Papan dengan stiker tempat tugas ditulis tidak unik. Secara umum, ini adalah alat lintas platform. Istri saya di kulkas kadang-kadang memahat stiker dengan daftar tugas, meskipun dia tidak tahu apa-apa tentang scrum.
Apakah alat ini bagus? Itu tergantung pada apa yang harus dibandingkan. Ya, mungkin yang bagus.
Misalnya, ini memungkinkan Anda untuk dengan cepat mengevaluasi, melihat-lihat kumpulan tugas. Di komputer, atau perangkat elektronik lainnya, tugas harus dibalik - semuanya biasanya tidak muat di satu layar. Karena itu, dalam satu pandangan - juga.
Kelebihan penting lainnya adalah ketersediaan keseluruhan untuk tim. Kapan saja, Anda bisa datang dan melihat, tidak masuk ke sistem apa pun, mencari, membuat pilihan, dll.
Banyak orang menyukai papan non-virtual. Lagipula, semuanya virtual di komputer, Anda tidak menyentuhnya dengan tangan. Dan di sini - tolong, setidaknya jilat. Beberapa, dalam hal ini, suka papan gabus. Perbedaannya adalah antara kertas dan e-book.
Khusus untuk papan scrum, orang dapat mencatat keuntungan seperti pemisahan menjadi dua bagian - ini dilakukan dalam pekerjaan. Penanganan stiker rumah tangga melibatkan membuang yang sudah selesai - tidak terlalu bagus, karena kemajuan terlihat lebih buruk.
Apakah ada kelemahan papan scrum? Tentu saja Seperti papan apa pun.
Untuk mulai dengan rumah tangga - draft, stiker berkualitas rendah, tulisan tangan yang buruk, sabotase. Akibatnya, kehilangan tugas dan kebingungan dalam manajemen.
Di papan tulis, kemajuan tidak terlalu terlihat. Secara umum, untuk sprint - ya. Hari ini, kemarin - tidak. Karena itu perlunya diskusi harian.
Secara khusus, status tugas tidak terlihat di papan scrum, jika hidup lebih rumit daripada yang "direncanakan" - "selesai". Papan Kanban terlihat lebih disukai.
Dewan tidak mengizinkan pekerjaan normal jika tim didistribusikan secara geografis. Karena itu, papan elektronik muncul.
Papan elektronik, menurut saya, adalah tanda pasti sektarianisme. Dia kehilangan semua manfaat dari yang biasa, tetapi, untuk beberapa alasan yang tidak diketahui, dia terus menggunakannya. Mungkin hanya karena papan. Bagian dari Metodologi.
Secara umum, alat seperti alat. Dalam situasi tertentu - bagus. Dalam beberapa hal itu mengerikan.
Akankah scrum bekerja tanpa papan? Mudah Dan dibuktikan dengan latihan. Dan sepertinya, karena dewan bukan artefak wajib, akan mungkin untuk terus memanggil scrum - scrum.
Master scrum
Siapa peran mukjizat ini? Seperti apa itu?
Ada banyak pilihan. Sebagai contoh, master scrum seperti pelatih dalam olahraga. Ada, katakanlah, sebuah klub sepakbola. Pemilik produk ada manajer yang mendefinisikan tujuan tim. Pelatih adalah pelatih yang membantu tim mencapai tujuan-tujuan ini.
Dalam lingkungan produksi yang biasa, tidak ada pelatih - jika klub sepak bola bekerja seperti itu, bos hanya akan datang ke ruang ganti sebelum pertandingan dan berkata: "pergi dan menang." Dan ketika mereka kalah, dia akan senang dengan penipuan itu. Dia mengusir seseorang, mengancam seseorang, dll. Seperti pabrik.
Dan pelatih, seperti master scrum, berfungsi sebagai penyedia antara tim dan manajer. Tentu saja, sang pelatih memiliki kekuatan lebih - dia bukan pelayan pemimpin. Tetapi hasilnya juga diperlukan darinya lebih cepat dan lebih dimengerti - tidak ada yang akan menunggu sampai dia memfasilitasi seseorang di sana. Pelatih, seperti master scrum, memahami bagaimana tim harus berfungsi, yaitu dia hanya mengatur tugas, dan menjelaskan bagaimana menyelesaikannya. Membangun koneksi, memotivasi, menciptakan dan memelihara atmosfer, dll.
Analogi lain adalah komandan pleton, beberapa pasukan khusus. Ini adalah pelatih permainan. Melanjutkan tugas bersama dengan bawahan, menyelesaikan misi tempur dengan cara yang sama. Di waktu luangnya, ia mengawasi persiapan dan peningkatan keterampilan, pengembangan peralatan baru, dan pelatihan fisik. Tentu saja, ia terus-menerus bekerja dengan tim dalam hal psikologi - memotivasi, mendukung, membantu. Dengan metode yang aneh, tentu saja, kadang-kadang, tetapi tujuannya adalah satu - efektivitas tempur maksimum peleton.
Scrum master, dibandingkan dengan orang-orang ini, seorang freeloader. Untuk hasilnya tidak terlalu bertanggung jawab. Kurangnya otoritas formal, tampaknya, dianggap sebagai keuntungan - dia adalah hamba pemimpin, tetapi pada kenyataannya dia dapat berkembang menjadi tidak bertanggung jawab. Bisakah seseorang tanpa henti memfasilitasi, tanpa memberikan pengaruh pada hasilnya? Dan ketika mereka mengusir mereka, mencari tim lain untuk memfasilitasi di sana.
Apakah mungkin untuk mengubah atau menghapus peran master scrum? Tentu saja Misalnya, gabungkan peran ini dengan pemilik produk. Saya tahu bahwa dalam Metodologi tertulis bahwa lebih baik tidak melakukan ini - ini akan mencegah master dari memfasilitasi. Tetapi, di sisi lain, itu akan menambah tujuan dan tanggung jawab yang jelas. Ketika tujuan dapat dipahami dan diukur, maka fasilitasi berubah dari omong kosong opsional dan tidak dapat dipahami menjadi tugas yang sangat spesifik dan nyata yang secara langsung mempengaruhi hasilnya. Seperti seorang pelatih atau pasukan.
Benar, maka makna memanggilnya master scrum hilang. Ini mungkin akan menjadi pemimpin tim - jangan lupa bahwa "pemimpin" adalah pemimpin. Seorang pemimpin tidak hanya bendera di tangannya, tetapi juga bekerja dengan motivasi, tujuan, kemampuan untuk membawa serta, memperkenalkan metode kerja baru, kompetensi pelatihan, dll. Sopir perintah, singkatnya. Dan dalam arti pengembangan internal, dan dalam arti mencapai hasil.
Jika Anda mengganti master dengan timlida di scrum, apa yang akan terjadi? Ini tidak lagi dapat disebut scrum - salah satu peran kunci telah dibuang. Dan bagaimana pengaruhnya terhadap hasilnya? Dan jika sama sekali tanpa master scrum? Jika fungsinya rusak pada perintah, bagaimana Belbin direkomendasikan?
Yang satu memfasilitasi, yang lain memotivasi, yang ketiga memonitor implementasi aturan. Sangat mungkin bagi Anda untuk hidup seperti itu.Total
Nah, semuanya, maka prinsipnya jelas. Scrum, seperti teknik lainnya, adalah algoritma yang dijalin dari komponen, atau alat. Siapa yang menenunnya? Baiklah, katakanlah Jeff Sutherland dan Ken Schwaber.Bayangkan bahwa dua orang, Jeff dan Ken, menciptakan komponen yang membawa manfaat baik dalam pengembangan aplikasi web. Anda menggalinya di github, memasangnya, mencobanya - wow, keren! Itu berhasil! Dan sungguh, ini lebih baik!Dan kemudian, pada titik tertentu, sesuatu mulai mengganggu Anda dalam komponen ini. Misalnya, memanggil metodenya tampaknya tidak cukup polimorfik. Anda masuk ke kode sumber dan temukan ...Apa yang bisa kamu temukan di sana? Ya apa saja. Misalnya, meminjam yang tidak Anda sukai. Atau komponen yang dipinjam akan benar, tetapi digunakan secara bengkok. Atau versi spesifik dari komponen yang baik ditunjukkan secara langsung, tetapi itu berkembang dengan baik dan telah menjadi jauh lebih dingin sejak lama, tetapi pengembang tidak ingin mengadaptasi komponen tingkat yang lebih tinggi. Atau Anda menemukan dalam algoritme sepotong ukuran yang layak yang makan sumber daya dengan baik, tetapi tidak membawa manfaat khusus untuk proyek Anda.Apa yang akan kamu lakukan Setiap orang akan menjawab sesuatu yang berbeda, tentu saja. Seseorang bahkan tidak akan masuk. Seseorang akan memotong dan memperbaiki apa yang tidak mereka sukai. Tentu saja, itu akan mendapatkan beberapa masalah dengan pembaruan. Meskipun, bukan fakta - hal-hal seperti scrum tidak berubah selama bertahun-tahun. Seseorang akan menulis kepada pengembang. Saya tidak tahu apa yang akan mereka jawab.Seseorang hanya mengambil komponen sumber, dan menyusunnya kembali dengan caranya sendiri - seperti yang dibutuhkan dalam proyek atau produk tertentu.Anda dapat melakukan hal yang sama dengan teknik apa pun. Saya ingin menulis "itu mungkin dan perlu", tetapi tidak memaksakan pendapat saya - setelah semua orang memutuskan.Saya ingin menyelesaikannya dengan kutipan Goldratt. Ini mungkin satu-satunya tokoh yang mengembangkan beberapa metode, jujur berbicara tentang perlunya perubahan, adaptasi, tata letak dan, yang paling penting, pemahaman prinsip-prinsip fungsi., . , – . , , . – ( — ) . , , . , .