Hanya satu model mainan yang dapat dirakit dari perancang LEGO modern, misalnya, sebuah pesawat terbang. Sesuaikan? Anda dapat bertukar kursi pilot - itu saja penyesuaian. Sekitar 30 tahun yang lalu, dari perancang itu dimungkinkan untuk merakit hampir semuanya, dari pesawat terbang ke truk, dengan jumlah bagian yang sama dengan yang modern. Pencipta metodologi paling modern di masa kecil memainkan Lego lama. Mereka yang sekarang menggunakan metodologi sudah bermain di zaman modern. Perbedaan dalam praktik rekayasa sangat besar.
Di bawah
potongan, Philip Delgado (
dph ) akan berbicara tentang pendekatan teknik untuk membentuk suatu metodologi. Semua proyek dan tim berbeda, dan pemimpin adalah unik. Cocok satu metodologi untuk semua tidak akan berhasil - tidak ada sama sekali. Kita harus mengambil desainer dan membangun sesuatu yang unik darinya. Dalam menguraikan salah satu laporan
TeamLead Conf terbaik, tidak akan ada rahasia rahasia para biksu Shaolin - hanya dangkal yang diverifikasi oleh pengalaman. Kami sedang menunggu katalog detail metodologi pengembangan, apa yang harus dicari ketika merancang dan mengimplementasikannya, dan aturan untuk membangun kembali metodologi. Untuk semua ide, contoh nyata diberikan dari pengalaman Philip. Selama karirnya, ia mencoba segalanya mulai dari Visual Basic hingga SQL hardcore, mengembangkan mesin taruhan terbesar di Rusia dan Yandex.Money, dan sekarang bekerja pada proyek Java yang dimuat. Dia secara teratur memberikan presentasi di berbagai konferensi, termasuk HighLoad ++.
Tantangan
Beberapa tahun yang lalu, saya sekali lagi datang ke proyek untuk membuat sistem pembayaran dari awal. Pada awal proyek tidak ada apa-apa: tidak ada pengembang, tidak ada proses, tidak ada produksi. Di mana harus mulai bekerja jika tidak ada apa-apa? Segera memperkenalkan sesuatu itu aneh dan bahkan bodoh. Karena itu, langkah pertama adalah memahami apa yang sebenarnya dibutuhkan dari teknik tersebut.
Kent Beck, di akhir bukunya tentang SCRUM, menulis:
Semua metode didasarkan pada rasa takut. Anda mencoba mengembangkan kebiasaan yang akan membantu Anda mencegah ketakutan Anda menjadi kenyataan.
Karena itu, hal pertama yang harus dilakukan adalah
mencari tahu dari bisnis apa yang ditakutkannya .
Biasanya, bisnis takut untuk seluruh proyek:
menakutkan untuk dilakukan terlalu lama atau
tidak dilakukan sama sekali . Secara teknologi, ia takut
akan keandalan dan
keamanan . Dalam kasus kami, ketakutan ini dibenarkan: sistem pembayarannya adalah rekanan, uang, dan kewajiban serius.
Ketakutan yang berbeda menyebabkan metodologi yang berbeda.
Takut membayar lebih mengarah ke mempekerjakan pengembang murah yang mudah diubah - itu SCRUM.
Ketakutan akan kesalahan mengarah ke GOST atau RUP dengan banyak dokumen resmi.
Pengembang juga memiliki ketakutan mereka sendiri:
untuk menulis yang tidak didukung atau
melakukan yang buruk . Sayangnya, hampir tidak ada yang mengembangkan metodologi di bawah ketakutan pengembang. Hanya XP yang menyebutkan secara singkat bahwa pengembang takut melakukan hal yang buruk, mari kita coba membantu mereka melakukan pekerjaan dengan baik.
Selain ketakutan, bisnis memiliki
keinginan untuk tujuan apa untuk mengoptimalkan proses:
- cepat
- murah;
- bisa ditebak;
- secara terkendali;
- secara kualitatif;
- scalable
- HYIPOVO.
Pilih salah satu opsi, dan mungkin, mungkin, suatu hari nanti, mungkin, jika tidak ada yang terjadi dan Mars bertemu dengan Bulan di Capricorn, Anda akan berhasil. Sebagian besar keinginan untuk optimasi juga tentang rasa takut, tetapi dalam kata-kata yang berbeda: murah - tentang rasa takut membayar lebih, dikendalikan - tentang rasa takut, jangan lakukan itu, dapat diduga - tentang rasa takut tidak ada waktu.
Biasanya sebuah bisnis menginginkan semuanya sekaligus . Saat mengumpulkan persyaratan, patuhi anggapan "pasien selalu berbohong." Ketika sebuah bisnis menginginkan segalanya, dia berbohong. Cobalah untuk memahami apa yang
benar-benar diinginkan bisnis dan cobalah untuk menjualnya kepadanya. Ini bukan set keterampilan paling standar untuk seorang pemimpin tim. Tetapi jika Anda tidak tahu bagaimana mencari tahu persyaratan sebenarnya dari sebuah bisnis, maka Anda perlu mencari orang yang bisa.
Selain keinginan bisnis, Anda perlu mengetahui
batasan yang signifikan.
- Tenggat waktu yang ketat . Dalam kasus saya, tidak ada tenggat waktu yang sulit, misalnya, Olimpiade, ketika hanya ada dua pilihan: apakah tepat waktu atau tidak.
- Kontrak yang ketat . Jika Anda bekerja dengan perusahaan milik negara, maka kontrak itu adalah sesuatu yang tidak boleh dilanggar. Segala sesuatu yang lain dapat dilakukan sesuai keinginan. Ini sangat mempengaruhi tekniknya.
- Pengiriman reguler . Anda harus terus-menerus meluncurkan fitur baru, ini penting untuk bisnis.
- Sertifikasi: CB, PCI DSS . Ini adalah batasan utama dari desain sistem pembayaran. Risiko dan kekhawatiran terbesar terkait dengan sertifikasi sekuritas, PCI DSS, dan lainnya.
Ini adalah batasan penting yang membedakan, misalnya, proses FixPrice dari proses Waktu & Bahan.
Dalam proyek kami tentang sistem pembayaran, ternyata, terlalu menakutkan untuk dilakukan terlalu lama dan tidak perlu ditakuti, menakutkan untuk keandalan dan keamanan, tetapi disarankan untuk melakukan semuanya dengan cepat. Pada saat yang sama, tidak ada produksi di awal pekerjaan, tidak ada pengembang, tetapi ada spesialis di bidang subjek (misalnya, saya). Hanya yang besar dan cukup independen dari masing-masing blok yang jelas: pemrosesan, klien, integrasi, back office, dan front office.
Setelah mengetahui tujuan dan batasannya, Anda dapat mulai membangun metodologi, untuk memahami dengan tepat bagaimana kami akan mengembangkan sistem yang diinginkan - setidaknya pada tahap pertama.
Kami sedang membangun metodologi untuk memulai proyek
Tapi apa itu teknik? Apa yang ingin kita bangun secara umum? Jawaban atas pertanyaan-pertanyaan tersebut adalah gambar
Alistair Cowber yang indah dengan banyak poin.
Tiga hal penting bagi kita dari gambaran ini di tempat pertama:
orang - orang yang melakukannya;
proses - bagaimana mereka melakukannya; dan
artefak - apa yang perlu dilakukan. Kami belum memiliki orang dan proses, jadi kami akan mencari tahu artefak apa yang kami butuhkan.
Dimulai dengan artefak adalah pola yang baik saat merancang teknik
, bahkan jika orang dan proses sudah ada. Dianjurkan untuk memulai desain artefak "dari akhir", dengan nilai yang dikirim, dari artefak yang akan ditata pada penjualan atau dikirim ke klien. Mengapa lebih baik begini - pertanyaan terpisah untuk artikel terpisah. Jika Anda tahu jawabannya - tulis di komentar.
Memilih Artefak
Kami mengambil ketakutan dan memahami artefak apa yang ketakutan dekat.
Rasa takut “terlalu lama mengerjakan proyek” diselamatkan oleh
rencana jangka panjang dan
fakta tonggak sejarah . Dari ketakutan untuk keandalan -
protes . Karena takut "tidak melakukan" - angkat pendirian "hampir bertempur". Kami akan
menunjukkan kemajuan bisnis untuk itu . Jadi, Anda dapat segera melihat apa itu dan apa yang berhasil, dan dalam keadaan darurat, kami akan memposting setidaknya beberapa hasil.
Kami membentuk proses
Kami berada di awal pengembangan, jadi tidak ada waktu dan alasan untuk menciptakan proses formal yang rumit. Jadi kami
menyederhanakan semua proses dan fokus pada
memfasilitasi komunikasi .
Akibatnya, ada dua proses: untuk
mencari tahu tugas besar - untuk memikirkan solusi, dan
memeriksa apa yang telah selesai . Proses-proses ini panjang, penelitian, dan sedikit terhubung satu sama lain, yang mengarah pada praktik pembangunan yang tepat.
Untuk membuatnya cepat - kami mempekerjakan karyawan yang keren . Tetapi spesialis keren tidak pergi ke sistem pembayaran yang tidak diketahui siapa pun di pasar. Entah bagaimana itu berhasil, tetapi solusi untuk masalah ini adalah diskusi terpisah. Ngomong-ngomong, tulis di komentar bagaimana Anda menyelesaikannya di rumah dan apakah Anda memutuskan sama sekali?
Retret: tentang perekrutan
Saat merekrut, mereka biasanya melihat deskripsi pekerjaan standar dan gradasi biasa dari tingkat kandidat, menggambar tentang peta peran di tim:
Tetapi deskripsi standar tidak memungkinkan kita untuk memahami kebutuhan orang tertentu dalam suatu proyek. Saya biasanya mencoba menyimpan beberapa peta yang berbeda di kepala saya untuk proyek yang berbeda, menyoroti peran dan kompetensi yang berbeda yang penting untuk proyek. Misalnya
teknologi .
Pemecah masalah . Ini adalah orang yang dapat menyelam ke kode lama dengan beberapa jenis bug tanpa dokumentasi dan tes selama 2 hari, dan muncul dengan frasa: "Pada baris ini, ganti + dengan - dan itu akan berhasil."
Dan itu akan berhasil. Orang-orang seperti semanggi empat daun jarang. Sayangnya, pasar tidak menghargai orang-orang seperti itu, sulit untuk menjelaskan kepada bisnis bahwa pemecah masalah sangat dibutuhkan dan pantas dihormati dan mendapat gaji besar. Akibatnya, sebagian besar dari mereka pergi ke pemimpin tim, dan sumber daya ini habis. Tetap hanya untuk mempromosikan kegunaan spesialis seperti itu, dan mungkin setelah beberapa waktu situasinya akan berubah.
Integrator Ini adalah orang yang tahu cara membuat sesuatu yang tidak terpisahkan dari beberapa komponen, perpustakaan, modul yang berbeda. Dia bukan lagi seorang programmer XML, tetapi orang yang mengerti struktur internal. Ini adalah keterampilan yang sangat langka, yang biasanya sangat diminati dalam pengembangan nyata.
Guru: Kerangka Kerja, Keamanan, Basis Data, DevOps . Semuanya jelas tentang guru - ini adalah orang-orang yang dapat dihubungi dengan pertanyaan tentang topik yang relevan.
Selain itu, ada juga
peran "non-teknologi", peta peran sosial.
Generator ide adalah orang yang dapat menghasilkan sesuatu.
Kritik - yang bisa mengkritik secara konstruktif.
Berpengalaman - orang yang berpengalaman yang dapat mengatakan: "Kami mencobanya dan ternyata omong kosong."
Seorang perfeksionis adalah orang yang ingin semuanya menjadi baik. Ini adalah peran penting. Jika tidak ada, biasanya semuanya dengan cepat membusuk, karena tidak ada orang yang memberi tahu Anda: "Anda mendapatkannya lagi, semuanya salah - mari kita perbaiki!"
Jika beberapa peran dalam peta peran untuk proyek spesifik Anda tidak diisi, maka tim harus memenuhinya.
Karena itu, pikirkan tentang siapa yang harus diambil, dan perlu diingat bahwa
wawancara yang
berbeda cocok untuk peran dan posisi yang berbeda . Dengan senior yang berpengalaman, wawancara akan cepat - cari tahu apa yang dia lakukan. Anda biasanya harus berbicara dengan junior untuk waktu yang lama, memberikan tugas tes, dan mencari tahu apa yang bisa dia lakukan.
Semakin tinggi level kandidat, semakin pendek wawancara.
Apa yang orang lain butuhkan?Seorang ekstrovert adalah orang yang ingin dan dapat secara aktif berkomunikasi di luar pembangunan. Kami tidak memiliki produksi yang tepat, jadi kami membutuhkan beberapa orang yang dapat memahami pengguna akhir, termasuk yang internal, misalnya, akuntan kami. Seorang ekstrovert tidak takut untuk berbicara, mencari tahu kebutuhan "non-programmer" yang tidak biasa - dan ada beberapa orang seperti itu.
Critic - Saya pertama-tama membutuhkan kritik dari saya. Ini adalah orang yang akan mengkritik keputusan saya. Tanpa kritik, saya takut membawa omong kosong. Ketika mereka mengkritik saya, saya harus serius memikirkan argumen, dan ternyata ini tidak sepenuhnya omong kosong.
Spesialis dalam masalah monoton : laporan, integrasi. Saya tahu pasti bahwa kami akan memiliki sejumlah besar laporan dalam proyek ini. Enam bulan untuk menulis laporan akuntansi dan tidak menjadi gila - keterampilan yang langka. Menghamburkan fungsi ini di antara orang-orang yang berbeda juga tidak nyaman, jadi saya membutuhkan seorang spesialis dalam masalah-masalah yang monoton.
Tidak peduli Ini adalah orang yang tidak peduli dengan tugas apa yang harus dilakukan, jika hanya membayar. Peran ini sangat penting untuk proyek, karena ada tugas yang berbeda: monoton, tetapi rumit, sangat menarik atau tidak terkait dengan pengalaman kami sebelumnya sama sekali karena persyaratan eksternal yang merambah.
Mari kita kembali ke proyek kita. Kami tidak perlu Pemecah Masalah, karena warisan belum ada di sana. Kami membutuhkan Integrator dan satu set guru. Guru Keamanan sebenarnya tumbuh di dalam.
Database Guru telah berhasil di-outsourcing-kan. Saya sangat menyukai gagasan "mengambil kompetensi dalam basis data di suatu tempat di luar" - untuk menemukan orang seperti itu pada staf biasanya tidak realistis jika Anda belum memiliki perusahaan besar, dan setidaknya 5 orang diminta untuk mendukung database 24 * 7 yang penting. Kami juga pertama-tama mengalihdayakan DevOps Guru, tetapi tidak begitu berhasil, peran ini lebih sulit bagi pemain eksternal.
Peran sosial juga diisi (dan bahkan ada beberapa kritik).
Berlatih
Jadi, kami menemukan artefak yang diperlukan, menemukan apa yang dibutuhkan orang dan persyaratan proses apa. Apa yang terjadi, bagaimana tepatnya kita mengatur pengembangan:
- Kami merencanakan pukulan besar. Kami tidak memiliki produksi, jadi tidak mungkin merencanakan dengan lebih akurat. Ada kebutuhan untuk membuat akun pribadi dalam tiga bulan - dan itu saja. Kami melaksanakan rencana dalam Confluence.
- Masing-masing sedikit analis . Tidak ada produksi dan kompetensi normal di bidang subjek dipegang oleh orang-orang yang tidak tahu bagaimana menulis produksi. Tidak ada yang mengajari mereka, Anda perlu menghapus informasi ini dari mereka. Tetapi kita memiliki "ekstrovert."
- Pelacak tidak diperlukan . Kami hanya memiliki 20 tugas utama untuk proyek - mengapa memulai pelacak.
- Satu cabang di VCS. Pada tahap awal, pekerjaan kompleks dengan kontrol versi tidak diperlukan.
- Prosesnya adalah perkiraan . Masih ada beberapa orang, tidak ada komunikasi dan masalah, dan proyek itu sendiri tidak stabil. Tidak perlu menjelaskan apa pun secara detail.
Ketika orang berbicara tentang metode yang sama, tidak terlalu diformalkan, mereka seringkali hanya mengatakan: "
Kami tangkas."Kami juga mendapat klasik "Kami punya Agile." Tetapi saya jelas mengerti mengapa teknik seperti itu dan mengapa itu "gesit", dan bukan sesuatu yang lebih spesifik dan kompleks. Dan saya (dan bisnis), teknik ini sangat cocok.
Pembaca yang penuh perhatian akan memperhatikan bahwa ketika merancang metodologi, kita melupakan dua ketakutan penting:
ketakutan akan keselamatan dan
kebutuhan akan sertifikasi . Mari kita coba mencari cara untuk menghadapinya.
Digresi: Matriks Cowburn
Pada 1980,
Alistair Cowbern menggambarkan
matriks kompleksitas proyek .
Vertikal - kekritisan proyek . Apa yang bisa hilang jika terjadi kesalahan signifikan: mulai dari kehilangan kenyamanan oleh pengguna hingga hilangnya nyawa pengguna, misalnya, jika kami merancang perangkat lunak untuk pembangkit nuklir.
Horizontal - ukuran tim . Ukuran mempengaruhi jumlah komunikasi. Kekritisan ada pada detail komunikasi ini. Semuanya mempengaruhi kompleksitas proses.
Alistair berpendapat bahwa bergerak ke kanan atau ke atas di setiap kotak sangat menyulitkan dan meningkatkan biaya pengembangan. Ini logis - lebih banyak orang memerlukan lebih banyak biaya komunikasi. Jika diperlukan hubungan yang lebih formal, maka lebih banyak biaya komunikasi diperlukan. Yaitu semakin jauh, semakin banyak sumber daya dihabiskan untuk tugas dan kerugian yang tidak produktif.
Ngomong-ngomong, sebagai sumbu ketiga, Alistair menggambar optimasi untuk keinginan bisnis yang berbeda.
Mari kita coba letakkan sistem pembayaran kami pada matriks ini. Matriks ini sangat nyaman sebagai model untuk memahami perkiraan kerumitan proyek Anda, sistem Anda.
Kami memiliki sistem pembayaran, yang berarti bahwa dalam keadaan darurat kami akan kehilangan sejumlah uang pengguna. Ini, tentu saja, tidak menyenangkan, tetapi tidak mengarah pada peningkatan kompleksitas yang tajam.
Tetapi kami memiliki hampir sebuah bank, dan dalam beberapa kasus, dalam kasus pelanggaran terhadap standar atau persyaratan Bank Sentral, lisensi dapat diambil dari bank. Ini sudah kehilangan banyak uang, hampir menutup bisnis, sangat sedih.
Kami memiliki tim yang terdiri dari sekitar 20 orang, jadi kami masuk ke alun-alun
E30 . Ini buruk, karena contoh yang baik dari teknik di alun-alun ini akan menjadi
Proses Terpadu Rasional lengkap - proses formal, banyak dokumen, pernyataan yang jelas. 20-30 orang tidak bisa mengatasi ini. Anda harus menyewa 50, dan kesulitan akan tumbuh seperti bola salju. Sistem serupa dalam metodologi semacam itu biasanya ditulis oleh ratusan orang atau lebih.
Apa yang harus dilakukan Kesulitan? Tidak,
tidak seluruh proyek sama pentingnya . Kami hanya memiliki beberapa bagian penting.
- Pemeriksaan pencucian uang - yang membuat Bank Sentral terpukul keras.
- Bekerja dengan kartu bank - yang membuat sistem pembayaran dunia sangat terpukul.
- Penyimpanan data pribadi - untuk ini, negara mengalami kesulitan besar.
Mari kita
sorot masing-masing modul penting . Kami akan menulis untuk mereka praktik khusus untuk bekerja secara khusus dengan bagian-bagian proyek kami ini:
Audit PCI DSS lengkap
untuk setiap komitmen , dokumentasi yang baik, Peninjauan Kode ganda, proses perhitungan khusus, dan banyak lagi. Biarkan hanya pengembang senior yang menulis bagian proyek ini.
Tetapi bagian seperti itu sedikit. Oleh karena itu, matriks Cowbern untuk proyek adalah sebagai berikut.
Untuk bagian proyek yang berbeda akan ada kompleksitas metodologi yang berbeda, serangkaian praktik yang berbeda.
Yang paling sulit dan mengerikan adalah tiga orang . Logika pembayaran - orang 8. Tugas lain yang kurang penting, yang paling penting, seperti sistem bantuan atau tata letak situs untuk back office, di mana kesalahannya tidak mendasar, ditangani terutama oleh orang-orang. Tetapi ada proses yang paling mudah dan tidak resmi.
Proyek kompleks besar dapat menggunakan serangkaian praktik berbeda untuk berbagai komponennya.
Ini adalah salah satu keuntungan besar dari arsitektur layanan mikro - kemampuan untuk meresepkan gambar di mana layanan yang berbeda tidak menanggapi banyak teknik yang berbeda, tetapi untuk praktik yang berbeda dalam teknik yang sama. Pada saat yang sama, hal-hal penting tetap umum: perencanaan, artefak, pendekatan umum untuk interaksi.
Untuk meringkas
Kami menemukan
persyaratan untuk metodologi : tujuan dan batasan.
Mengidentifikasi elemen-elemen dasar : proses, artefak dan manusia.
Mereka menggambarkan praktik : bagaimana menerapkan proses, persyaratan untuk artefak, orang macam apa yang dibutuhkan.
Ini adalah skema desain teknik klasik: kami memiliki persyaratan, lalu kami menentukan arsitekturnya, dan kemudian memprogramnya.
Metode perancangan adalah praktik rekayasa, proses rekayasa yang tidak berbeda dari pemrograman modul.
Praktek Tahap Satu
Sedikit latihan untuk mengalihkan perhatian dari teori ke realitas.
Hak untuk "Mengapa?"
Ini adalah latihan favorit saya.
Setiap karyawan memiliki hak untuk bertanya tentang tugas apa pun: mengapa melakukannya, mengapa melakukannya dengan cara ini, dan siapa yang membutuhkannya sama sekali?
Orang takut untuk bertanya "mengapa" - mungkin karena di masa kecil mereka masih belum menjawab pertanyaan seperti itu. Jika Anda telah secara eksplisit menulis dan mengulangi "bisa dan harus" berkali-kali, orang melakukannya. Segera setelah Anda mulai bertanya "mengapa" di semua tingkatan, termasuk bisnis, volume tugas menurun berkali-kali dan motivasi juga meningkat. Orang-orang mengerti arti pekerjaan dan melakukannya lebih cepat dan lebih ekonomis, memotong sudut.
Jangan menggeneralisasi menjadi tiga
, . , , .
— , , . — — , . , , .
IDE Driven Development
JetBrains — ! , IDE.
, IDE.
. , IDE , . IDE — . IDE — : , , , . : , , .
, , IDE call stack . .
IDE — .
, , . . : « ?» , . , - . , .
3–4 . .
, . , . , , , .
. — , , .
- , . .
— .
: « , , , ».
— , , .
. — , , , .
. , - . .
, — , . : , ,
, :
. . .
- . , , .
- . , , , , - .
- . 3 -, , , , . , .
- . , . , - — .
,
SCRUM , SCRUM . , , , .
.
20 . SCRUM , , , - . .
.
- — , 3 .
- .
- : PCI DSS , ( ., ), - .
. « , », . , 1 —
, - . , . shit happens , — , . , , , ,
.
, , , — , , .
— . .
. - , , — .
—
. , «» , - bus factor — , .
. , , .
.
, .
, , .
, , , .
Style guides code review , - , .
, - . ?
Planning poker . «
» — . , , . Planning poker
, .
. :
, , , — ? , 2 10% . ?
, Planning poker — , , ? ,
—
. . planning poker , , .
:
,
,
. Agile — , . , .
, Agile, SCRUM XP .
,
, , ,
, , . , - , — ? ?
. : , , , . , ?
, Planning poker , , Planning poker :
— , , !Planning poker .
. .
:
.
: , , .
Jira , « » ? - -? ?
, ,
. , junior product manager — , ,
, .
, — . . , . — !
Tinjau sebelum kode. Saya secara teratur mendengar bagaimana seseorang diberi tanggung jawab untuk fitur besar, tetapi dia melakukan kesalahan dan perlu diperbaiki.
Mari kita tinjau kode sebelum kita menulisnya . Sebelum menulis kode, seorang karyawan di Jira menjelaskan rencana untuk menyelesaikan masalah dalam dua baris atau dua paragraf teks. Meninjau dua paragraf ini cepat dan mudah, tetapi kesalahan global diketahui sejak awal, terutama jika Anda memiliki pemimpin tim atau arsitek.
Selain itu, praktik ini memungkinkan pemimpin tim atau arsitek untuk menyadari semua perubahan dalam proyek besar. Dia membaca bukan kode bengkok, tetapi dua paragraf tentang apa yang umumnya terjadi dalam sistem, dan dengan cepat menangkap orang. Ini terutama berlaku untuk bagian-bagian penting dari suatu produk, seperti logika pembayaran.
Bagaimana mengubah metodologi dan tidak membunuh proyek
Jadi, dalam 9 bulan kami mengubah 3 metode: "Kami memiliki Agile", SCRUM satu hari dan Kanban. Bagaimana memastikan bahwa Anda tidak kehilangan sumber daya? Bagaimana mengubah metodologi sama sekali, dan tidak membunuh proyek pada saat yang bersamaan?
Kami berhasil mengubah metode sehingga beberapa pengembang tidak melihat perubahan sama sekali. Tidak ada yang memberi tahu mereka tentang ini, mereka bekerja, dan metodologinya berbeda!
Hal utama adalah memahami kapan harus berubah.
Jika kamu mengerti kenapa. Seringkali metode diubah, karena direktur teknis baru telah datang yang ingin mengulang semuanya. Ini alasan yang buruk. Lebih baik ambil yang lama dan ganti namanya - semuanya, tekniknya berbeda, lebih baik. Jika Anda tidak bisa menjawab pertanyaan mengapa, lebih baik tidak berubah. Saya biasanya suka bertanya mengapa.
Jika Anda berpikir "bagaimana." Jika Anda mengerti bagaimana Anda akan datang dari titik A ke titik B, maka ubah. Sampai Anda datang dengan - tidak perlu.
Jika puas "berapa banyak." Mengubah teknik
hampir selalu merupakan prosedur yang mahal . Jika Anda melakukannya dengan baik, penggantiannya akan memakan biaya beberapa bulan dari biaya pemimpin tim, SDM, penyesuai Jira. Jika buruk, beberapa bulan seluruh perusahaan bekerja. Saya sering melihat transisi dari Kanban ke SCRUM, lalu kembali, yang masing-masing menghabiskan satu bulan kerja selama pengembangan. Jika Anda belum siap dengan biaya seperti itu - jangan mulai.
Persiapan
Kami mulai di muka. Untuk tim kecil, persiapan dimulai sebulan sebelum shift.
Kami menggambar Cerita Pengguna. Pendekatan yang sama seperti dalam desain aplikasi. Anda menggunakan Cerita Pengguna saat menjelaskan persyaratan, saya harap?
Sebagai contoh:
- Kisah Pengguna : sebagai pengembang, saya ingin menemukan tugas saya selanjutnya dan melanjutkan implementasinya.
- Kriteria Penerimaan : sebagai pengembang, saya dapat melihat semua tugas saya saat ini dan mengevaluasi urgensi dan prioritas tugas.
- Pengecualian: jika tidak ada tugas, maka pengembang tahu siapa yang harus ditanyakan.
- Tautan: skenario untuk mempersiapkan rencana jangka pendek, yang menunjukkan di mana harus mendapatkan tugas berikutnya.
Dengan cara ini, pergi melalui semua kegiatan utama Anda yang muncul dalam metodologi Anda dan menulis Cerita Pengguna.
Bagaimana manajer dapat melihat keefektifan rencana? Bagaimana seorang manajer puncak memahami bahwa semuanya baik-baik saja? Tulis Cerita Pengguna, lalu tambahkan spesifik: buat dasbor untuk pengguna dan untuk manajer puncak - Lewat Kriteria Penerimaan, semuanya baik-baik saja.
Ketika Anda sudah memiliki Cerita Pengguna, Anda dapat mulai mengubahnya menjadi praktik.
Ganti semua peran dengan orang sungguhan . Seseorang yang nyata selalu tahu lebih dari sekadar peran. Maka Anda akan segera menemukan bottleneck. Misalnya, semua Cerita Pengguna Anda menggunakan satu orang tertentu, meskipun ia hanya memakai topi yang berbeda, dalam peran yang berbeda. Ini buruk - cari tahu cara menurunkannya.
Kurangi artefak dan komunikasi . Jika jumlah mereka terlalu banyak - masing-masing Kisah Pengguna menyarankan artefak dan komunikasinya sendiri - sesuatu harus dilakukan dengan ini.
Carilah kemacetan . Ketika ada peta cerita seperti itu, Anda dapat mulai melakukan sesuatu dengannya.
Memilih Alat
Alat mengidentifikasi fitur . Ada pendapat umum bahwa alat tidak penting, atau alat apa pun cocok - ini omong kosong.
Jika alat tidak nyaman digunakan, mereka tidak akan digunakan.
Apalagi vendor selalu berbohong. Jika mereka mengatakan bahwa alat mereka dapat melakukan “1, 2 dan 3”, maka kemungkinan besar mereka tidak dapat melakukan “1”, “2” kadang-kadang, dan “3” melakukannya, tetapi ini sangat buruk. Pastikan untuk memeriksa semuanya.
Kami sedang aktif berdiskusi
Tanpa diskusi aktif tentang teknik ini, Anda dapat melupakan beberapa fungsi penting, Cerita Pengguna yang penting, dan menyinggung seseorang.
Orang yang tersinggung akan menyabotase implementasi metodologi : dia awalnya tersinggung, dilupakan, tidak ada yang berbicara kepadanya apa yang dia butuhkan.
Pada tahap ini, orang mungkin menunjukkan pengalaman negatif sebelumnya dari pengenalan teknik lain.
- Ah, omong kosong! Kami sudah memiliki ini dan tidak ada hasilnya.Untuk menghindari ini, kumpulkan rasa sakit orang, tanyakan apa yang salah. Catat dan tunjukkan dengan akurat apa yang Anda rekam - sehingga orang tersebut akan mengerti bahwa mereka mendengarnya.
Jangan ulangi pengalaman negatif . Retrospektif tidak pergi? Sekarang ini adalah "kue Jumat". Standup jam 7 pagi tidak pergi? Sekarang ini "pengisian daya."
Memberikan nama yang berbeda untuk praktik yang sama sehingga orang tidak mengaitkan pengalaman negatif masa lalu mereka dengan mereka sering membantu.
Sayangnya, tidak ada solusi universal. Bangun situasi Anda.
Implementasi
Nilai utama dalam manajemen TI adalah rasa hormat.
Kami menghemat waktu orang lain . Jika Anda perlu mentransfer tugas dari satu sistem pelacak ke sistem pelacak lainnya - tulis skrip, pekerjakan Mechanical Turk untuk melakukannya untuk Anda. Selesaikan masalah ini sehingga pengembang tidak mengalihkan semua tugasnya dari satu sistem ke sistem lain selama seminggu - ini adalah wujud penghargaan.
Kami membantu dengan transisi . Jika kami memperkenalkan praktik baru, kami duduk di sebelah seseorang dan membantunya memahami sistem baru. Kami menyiapkan instruksi terlebih dahulu.
Kami menggambarkan tindakan spesifik. Kami membuat dokumentasi yang sangat spesifik, hanya berdasarkan Kisah Pengguna kami: “Kami perlu mengambil tugas baru. Cara melakukannya ditulis dalam dokumentasi - Anda membuka halaman ini dan itu di wiki, di dalamnya Anda membaca ini-dan-begitu. ”
Kami memperkenalkan secara bertahap - tidak semua praktik sekaligus . Pengembang kami tidak melihat perubahan dalam metode, karena kami tidak menerapkan semua praktik pada saat yang sama. Ketika kami ingin dengan lancar beralih dari SCRUM satu hari ke sesuatu yang lain, saya tidak melakukan retrospektif setiap hari, tugas-tugas itu tampak sedikit lebih lama, rapat-rapat harian pagi dengan tenang bermigrasi ke stand-up yang lebih standar. Tampaknya bagi orang-orang bahwa semuanya berjalan secara bertahap. Kemudian praktiknya berubah cukup signifikan. Tentang beberapa hal, tentu saja, saya memberi tahu mereka: "Sekarang kita akan sedikit mengubah proses bekerja dengan Jira - sekarang akan seperti itu."
Jalan menginjak-injak sendiri . Jangan segera meresepkan alur kerja keras - biarkan orang menemukan jalurnya sendiri. Lebih mudah bagi mereka untuk mentransfer tugas di pelacak dari negara bagian ke negara, bahkan jika mereka mentransfernya, dan kemudian Anda akan memperbaikinya. Segera untuk memprediksi apa yang akan nyaman itu sulit, dan untuk melarang transisi yang diminta mudah. Tetapi kemudian Anda harus menderita untuk waktu yang lama untuk mendapatkan semuanya kembali.
CIUMAN . Sederhanakan, setidaknya di awal. Jangan terlalu rumit.
Dukungan
Kami memesan sumber daya di muka untuk proses transisi, karena itu mahal . Transisi dari satu teknik ke teknik lainnya adalah banyak uang. Cadangan waktu dan waktu Anda untuk orang-orang yang akan mengedit bug di pelacak Anda, dalam alur kerja Anda, dalam prosedur perhitungan. Jika tidak ada sumber daya, dan pada saat yang sama semacam terburu-buru, semuanya akan berubah menjadi buruk.
Kami memperbaiki kesalahan secepat mungkin .
Kesimpulan
Proyek berbeda, orang juga - semua orang membutuhkan teknik yang sama sekali berbeda ! Semua keluarga yang bahagia sama-sama bahagia, semua tidak bahagia - dengan cara mereka sendiri. Sama dengan proyek - tidak ada dua yang identik.
Membuat teknik adalah tugas rekayasa. Persis sama dengan pemrograman dan perancangan modul sistem. Begitulah cara Anda mendekatinya. Anda tahu bagaimana menyelesaikan masalah teknik dengan baik - jadi gunakan semua pengetahuan Anda dalam praktik baru ini.
Perubahan metodologi adalah proyek SMART klasik . Gunakan semua yang Anda ketahui tentang manajemen proyek: tentukan kriteria keberhasilan, periksa di akhir kepatuhan dengan tugas yang ditetapkan, ingat waktu yang terbatas, dll.
Manifes pribadi saya
Orang lebih penting daripada proses , karena proses harus dilakukan untuk orang. Jika perusahaan memiliki usia rata-rata 50 tahun, dan mereka berasal dari militer, dan Anda mencoba untuk segera menerapkan Kanban segera, kemungkinan besar itu tidak akan lepas landas. Orang-orang hanya terbiasa dengan hal lain.
Keuntungan utama seorang programmer adalah kemalasannya. Bangun proses sehingga orang menghabiskan lebih sedikit waktu untuk mereka, dan pengembang adalah yang pertama kali menjalankan untuk mengimplementasikannya. Jika orang tidak berusaha menerapkan proses, maka mereka tidak mengerti mengapa.
Kebetulan beberapa praktik sulit diimplementasikan, karena sulit dipahami. Terkadang lebih mudah untuk mengubah praktik, mungkin itu tidak sesuai dengan tugas Anda atau orang-orang Anda. Sebagai pilihan terakhir - ganti orang, tapi lebih mahal daripada mengubah praktik.
Hasilnya lebih penting daripada kebiasaan . Kebiasaan paling mengerikan adalah kebiasaan mendengar tentang alat baru, membawanya pulang dan segera menggunakannya. Kultus kargo adalah kebiasaan buruk untuk dilawan. Tetapi ketakutan untuk mengubah semacam latihan karena "kami selalu melakukan itu" walaupun itu sudah tidak efektif juga berbahaya.
Dan kadang-kadang secara umum tugasnya sangat beragam sehingga kebiasaan menjadi berbahaya. Misalnya, ketika berkomunikasi dengan orang yang hidup.
Persuasi lebih efektif daripada pesanan . Motivasi terbaik adalah untuk memahami arti dari pekerjaan Anda dan membagikannya. Pengembang suka membuat hidup lebih mudah bagi pengguna, menghemat uang perusahaan dan menyederhanakan hidup mereka - jadi beri tahu mereka tentang tujuan tindakan mereka. Belajar meyakinkan.
Ketiga prinsip itu adalah gambaran pribadi saya tentang dunia. Jika Anda memiliki anggapan lain, Anda mungkin perlu metodologi berbeda untuk membangun teknik.
Dalam komite program TeamLead Conf , kami juga lebih akrab dengan Lego lama, jadi kami memilih kubus ke dalam program yang darinya Anda sendiri dapat membangun proses yang sesuai dengan Anda. Untuk konferensi musim gugur di St. Petersburg, satu set 15 bagian telah dikumpulkan, tetapi kami masih menerima aplikasi untuk laporan - tulis .