Bagaimana cara berhenti menangkap telur dengan tergesa-gesa, secara bersamaan menjatuhkan tenggat waktu? Toolchain mana yang dipilih untuk menghancurkan beberapa tugas sekaligus? Kami akan mengungkapkan semua ini di artikel kami.

Mencoba menangkap semua telur

Pada hari-hari ketika perusahaan kami baru saja muncul di rahim kaca yang ditumbuhi sinar matahari kantor, dan tim hanya memiliki tiga orang (seorang manajer dan dua pengembang), antusias dan kaya kopi, kami sama sekali tidak memiliki metodologi manajemen proyek dan bertindak berdasarkan firasat, mendekati pekerjaan berdasarkan prinsip "satu orang - satu proyek". Pada saat yang sama, itu bahkan bukan tentang fakta bahwa pengembang, berinteraksi dalam tugas yang sama, memegang potongan kode yang terpisah di antara mereka sendiri, dan seluruh lanskap lingkungan pengembangan tergantung pada mesin pengembang. Sebagai repositori dan sistem kontrol versi, kami kemudian menggunakan SVN , yang pada waktu itu lebih mirip folder dengan pengarsip zip. Terlepas dari kenyataan bahwa SVN adalah salah satu sistem kontrol versi terbesar dan memiliki komunitas yang sesuai, fungsinya hanya cocok untuk kita dalam hal melestarikan kode, jika tidak semuanya menjadi sedikit buruk: tidak ada versi lokal dan kemampuan untuk menggabungkan kode. Oleh karena itu, kami mulai mencari sesuatu yang lebih cocok untuk selera kami - pengembangan proses kerja dimulai. Hal pertama yang perlu dibenahi adalah perencanaan dan pengaturan tugas, serta distribusinya satu sama lain, untuk melepaskan diri dari monoprojektivitas ke pengembangan bersama dan pemeliharaan tenggat waktu. Pada saat itu, satu-satunya jenis perencanaan adalah pertemuan dengan notebook. Dengan pendekatan ini, sebelum efisiensi dan efisiensi itu seperti bulan di Cossack, seseorang berhasil mencatat semuanya, seseorang lupa atau lupa. Akibatnya, orang-orang meninggalkan pertemuan tanpa pemahaman yang jelas tentang apa dan bagaimana melakukannya, dengan banyak informasi di kepala mereka dan dengan beberapa coretan di buku catatan.

Kami memilih rantai alat

Langkah pertama dalam mengurangi entropi alur kerja adalah membuat repositori normal untuk bekerja bersama pada proyek dan menghubungkan masing-masing bagian dari kode. Kami membuang SVN lama dan mengangkat GIT di mesin lokal CEO kami. Untuk melihat dan menghubungkan kode yang digunakan utilitas konsol sederhana. Itu tidak terlalu nyaman, tapi setidaknya itu memungkinkan untuk menjaga ketertiban dan transparansi perubahan dalam proyek.

Kami masih memiliki masalah dengan perencanaan, dan sebagai hasilnya, menahan tenggat waktu. Untuk melakukan ini, perlu untuk menemukan cara menguraikan tugas dan menampilkan status pelaksanaannya. Upaya untuk menyelesaikan masalah ini adalah penggunaan aplikasi manajemen proyek RedMine, dari mana pembandingan aktif dari toolchain dimulai. Utilitas ini sangat cocok untuk pengembang (kemampuan manajemen proyek, forum, pelacakan bug), tetapi sayangnya, itu sangat sulit bagi para manajer. Pengembang terus-menerus harus memproses semua informasi (merzhrekvesta, pullrekvesta, dll.) Dari SUV, dan memasukkannya ke dalam program RedMine , sehingga manajer dapat melacak tingkat penyelesaian tugas. Selain itu, tidak ada fungsi manajemen proyek tambahan yang cukup, jadi kami mulai melirik FengOffice .

Alat ini memiliki fungsionalitas yang cukup luas, memungkinkan untuk memimpikan topik menggabungkan alat komunikasi dan perencanaan seperti bagan Gantt ke dalam satu sistem kerja. Namun, dengan semua peralatan produk ini, para pengembang harus menutup tugas secara manual, sementara secara bersamaan menyusun statistik sendiri, karena tidak ada sinkronisasi otomatis dari tugas yang dilakukan. Selain itu, penerapan obrolan internal lebih seperti ICQ versi lama yang serupa daripada obrolan korporat biasa, tetapi bagi kami saat ini sangat penting.

Kami memahami bahwa agar seluruh mekanisme bekerja secara harmonis, pertemuan sederhana jelas tidak cukup. Ada kebutuhan untuk memilih alat operasional untuk membangun komunikasi singkat yang diperlukan bahkan untuk orang yang duduk bersebelahan di ruangan yang sama. Dua poin muncul di sini: yang pertama - jika Anda melakukan percakapan singkat dalam format yang biasa, maka mereka akan memakan terlalu banyak waktu kerja, yang akan berarti halo bagi runtuhnya semua tenggat waktu dan kelambatan yang parah di belakang jadwal, dan yang kedua - jika Anda membuat interaksi singkat minimum, ini akan menyebabkan kerugian komunikasi yang erat antara anggota tim, ketidakkonsistenan tindakan mereka, duplikasi kode dan masalah lainnya. Oleh karena itu, kami sampai pada solusi sederhana - untuk mentransfer rapat mikro ke obrolan tim, yang memungkinkan Anda untuk terus berkomunikasi tanpa gangguan yang kuat dari alur kerja, mengoordinasikan tindakan pengembang dan menghindari pelaksanaan berulang tugas yang sama, serta perselisihan tentang siapa yang melakukan tugas dengan lebih baik. Solusinya mungkin tampak jelas dan sepele, tetapi masalahnya bukan pada sarana interaksi, tetapi dalam pendekatan dan kualitas penggunaan alat. Pertanyaannya adalah bagaimana mengubah obrolan dari tempat untuk banjir dan pembakaran menjadi pengganti sebagian untuk pertemuan dan percakapan pribadi.

Sementara itu, GIT yang biasa tidak cukup, ada kekurangan yang kuat dari antarmuka web. Kami memiliki dua opsi pada menu: repositori pribadi di GitHub dan repositori di GitLab. GitLab gratis - dan mereka mengambilnya. Ia juga memiliki komunitas yang sejuk dan ramah. Selain itu, GitLab sudah memiliki sistem penjadwalan tugas bawaan dan menyediakan antarmuka yang nyaman untuk merzhrekvest. Jika Anda bekerja sebagai tim, maka Anda mungkin tahu betapa pentingnya untuk mendapatkan merzhrekvest yang disetujui dengan cepat. Pada akhirnya, kami menguburkan FengOffice dan menetap di GitLab. Selain itu, pada saat itu kami sudah menggunakan Slack sebagai obrolan tim, dan mengingat fakta bahwa GitLab merencanakan integrasi timbal balik dengan Slack, dan semua hal ini juga gratis, pilihan bagi kami menjadi lebih jelas dari sebelumnya.

Buku tidak berbohong

Kemudian tiba saatnya ketika perlu untuk memilih metodologi yang paling cocok untuk manajemen proyek kami yang fleksibel. Kami menetapkan dua pendekatan yang paling maju dan populer: Kanban dan Scrum. Inisiatif sepenuhnya datang dari CEO kami, Ilya Bykoni, yang, dengan api di depan matanya, berbicara kepada tim tentang perubahan yang akan datang. Tetapi yang mengejutkannya, tim itu, pada awalnya, bertemu dengan inovasi, ketika orang-orang Spartan bertemu Xerxes, dengan keras kepala yang keras dari salinan konservatif. Apa yang dapat Anda lakukan, ilusi, ilusi, karena dalam buku-buku itu mereka memperingatkan ... Sebuah fakta menarik segera diperhatikan bahwa sikap negatif terhadap pendekatan baru tidak berkorelasi dengan kecukupan dan kemampuan orang untuk bekerja. Bahkan june muda, yang seharusnya dengan mudah mengambil semua ini, menolak, dengan alasan bahwa: "mereka program yang lebih baik selama 15 menit daripada yang akan mereka habiskan pada hari berikutnya", "mengapa Anda perlu perencanaan, jika tenggat waktu tetap saja tidak dieksekusi atau dieksekusi, tetapi dengan penyimpangan "," mengapa pengembang frontend mendengarkan tentang backend ", dll. Faktanya adalah bahwa metodologi pendekatan Agile menyiratkan gaya kerja di mana tidak mungkin untuk duduk di pundak Atlantik dari pengembang yang kuat dan sampai ke proyek pada keterampilannya, karena banyak orang terbiasa bekerja, sehingga perubahan seperti itu menjadi bagi mereka menyakitkan.


Ketika kami mulai memperkenalkan Agile ke dalam pekerjaan, kami sepenuhnya merasakan nilai komunikasi singkat dan berkualitas tinggi. Sering terjadi bahwa ketika tugas serupa datang dari input departemen RnD dari beberapa sumber, manajer proyek tidak dapat menangkap duplikat. Dan di sini, interaksi jangka pendek dan aksi harian, yang sepenuhnya melindungi dari masalah seperti itu, mulai memainkan peran yang sangat penting dengan mengidentifikasi titik temu antara pengembang tim yang berbeda. Ada hal lain yang menarik - sebagian besar programmer adalah introvert, yaitu, komunikasi apa pun adalah tekanan mikro, terutama ketika menyangkut unjuk rasa dalam tim besar, di mana seseorang harus berbicara kepada khalayak luas dari beragam spesialis. Dan banyak orang, dalam ketakutan akan ketidaknyamanan seperti itu, tidak menyadari bahwa alternatif untuk pertemuan singkat seperti itu bahkan bisa lebih tidak menyenangkan daripada sehari-hari. Ini akan digantikan oleh komunikasi yang konstan sepanjang hari, dalam upaya untuk membawa pekerjaan ke proses yang terkendali. Bagi kami sendiri, kami menyimpulkan bahwa Agile memperhitungkan introversi pengembang dan mengurangi ketidaknyamanan yang terkait dengan kebutuhan komunikasi seminimal mungkin. Tentu saja, untuk karyawan muda perusahaan, dalam hal apa pun, ini akan membuat stres untuk beberapa waktu sampai dia mempelajari secara spesifik pekerjaannya dan mengenal tim lebih dekat, oleh karena itu semakin ramah dan efisien budaya Agile di perusahaan, semakin cepat proses adaptasi akan berakhir.

Satu tongkat sakit, banyak tongkat mematikan

Salah satu motivasi utama dari pendekatan yang fleksibel adalah agar orang terbiasa meminimalkan kepura-puraan dan serangga mereka. Faktanya adalah bahwa jika Anda mengambil struktur manajemen vertikal standar, maka pengembang bertanggung jawab atas kesalahannya kepada atasan langsung yang menghukum dan "memukul dengan tongkat di kepala" jika karyawan memalsukan atau "membelai kepala" jika semuanya dilakukan dengan jelas. Artinya, dalam struktur vertikal, seseorang memiliki opsi untuk bangkit karena hubungan pribadi atau "cookies lezat". Di Agile, interaksi tim dibangun secara horizontal, yang berarti seseorang harus melapor ke seluruh tim pada rapat umum harian. Dia hanya dengan bodohnya tidak memiliki cukup uang untuk begitu banyak kue. Karena itu, Anda harus terbiasa dengan fakta bahwa kesalahan Anda akan ditinjau oleh kolega Anda, dan apakah Anda akan menunggang kuda dan mereka akan menuangkan kelopak mawar pada Anda dari pujian profesionalisme Anda, atau Anda akan berada di bawah kuda ... Dalam kasus apa pun, ini adalah pemompaan yang kuat dari keterampilan pribadi seseorang, dan jika atmosfer di perusahaan cukup hangat, maka orang tersebut mulai perlahan membuka, memberikan kontribusi yang semakin besar bagi ekosistem departemennya dan perusahaan secara keseluruhan. Kami juga mengalami dari pengalaman efek penyaringan Agile, lebih dari sekali dihadapkan pada situasi di mana pengembang yang secara objektif lemah tidak tahan terhadap analisis kesalahan mereka yang terus-menerus, dan akhirnya hanya bergabung jika mereka menyadari bahwa mereka kekurangan motivasi dan kekuatan internal untuk untuk beralih dari status bagodel ke status bogacode.

Untuk meringkas

Saya harus mengatakan bahwa proses mendirikan mesin Agile ternyata cukup panjang, dan sangat menegangkan, "itu tidak mungkin dilakukan tanpa kekerasan" - pada awalnya orang-orang harus secara praktis didorong dengan tongkat ke aksi unjuk rasa dan kegiatan sehari-hari, sehingga orang-orang entah bagaimana mulai mengekspresikan posisi mereka pada tugas-tugas yang mereka selesaikan. Meskipun kita terus-menerus harus "memanjat di bawah kap" dan mengotak-atik "mesin", membuat tangan kita kotor dalam bahan bakar minyak, itu layak dilakukan ketika tim menambah kecepatan dan bergegas ke depan, mengumpulkan pos pemeriksaan untuk pos pemeriksaan. Kami tidak menghentikan evolusi kami untuk sedetik pun, kami selalu dalam status forwarder abadi, terus-menerus mempelajari yang baru dan memodifikasi model manajemen dan interaksi yang ada di antara karyawan. Satu hal yang kita pahami dengan pasti - di mana tidak ada gerakan dan perjuangan, tidak ada kehidupan. Seperti yang dikatakan oleh para biksu Zen: "Saya mencapai puncak, lanjutkan pendakian ..." Semoga beruntung untuk semua orang di pendakian Anda, dan biarkan semua orang pergi ke puncak mereka, tidak peduli apa!

PS:

Berikut adalah daftar sampel dan waktu langkah-langkah yang kami lalui:

1. Perencanaan pembentukan ~ 4 bulan
2. Bekerja dengan komunikasi singkat ~ 1 bulan
3. Cari toolchain dan pengembangan alur kerja yang cocok ~ 2 bulan
4. Pilihan metodologi ~ 2 bulan
5. Pengenalan Scrum ke alur kerja ~ 8 bulan

Dan inilah beberapa pilihan dari CEO kami:

1. Comprehending Agile - Andrew Stellman dan Jennifer Green
2. “Jalan Tuan Scrum” - Zuzan Shokhov
3. "Scrum A Metode Manajemen Proyek Revolusioner" - Jeff Sutherland
4. "Cara Alternatif Kanban ke Agile" - David Anderson
5. "Di kepala transformasi. Penerapan prinsip-prinsip Agile dan DevOps di seluruh perusahaan "- Harry Gruver dan Tommy Mauser