Halo, Habr! Sebelumnya, saya mengeluh tentang kehidupan di Infrastruktur sebagai paradigma kode dan tidak menawarkan apa pun untuk menyelesaikan situasi saat ini. Hari ini saya kembali untuk memberi tahu Anda pendekatan dan praktik apa yang akan membantu Anda keluar dari jurang keputusasaan dan mengarahkan situasi ke arah yang benar.
Dalam artikel sebelumnya Saya berbagi kesan saya tentang area ini, mencoba merefleksikan situasi saat ini di area ini, dan bahkan menyarankan agar praktik standar yang diketahui semua pengembang dapat membantu. Tampaknya ada banyak keluhan tentang kehidupan, tetapi tidak ada usulan jalan keluar dari situasi ini.
Siapa kita, dimana kita dan apa permasalahan kita?
Saat ini kami berada di Tim Sre Onboarding, yang terdiri dari enam programmer dan tiga insinyur infrastruktur. Kita semua mencoba menulis Infrastruktur sebagai kode (IaC). Kami melakukan ini karena pada dasarnya kami tahu cara menulis kode dan memiliki sejarah sebagai pengembang “di atas rata-rata”.
- Kami memiliki serangkaian keunggulan: latar belakang tertentu, pengetahuan tentang praktik, kemampuan menulis kode, keinginan untuk mempelajari hal-hal baru.
- Dan ada bagian yang kendur, yang juga menjadi kekurangannya: kurangnya pengetahuan tentang perangkat keras infrastruktur.
Tumpukan teknologi yang kami gunakan di IaC kami.
- Terraform untuk membuat sumber daya.
- Pengemas untuk merakit gambar. Ini adalah gambar Windows, CentOS 7.
- Jsonnet untuk membuat build yang kuat di drone.io, serta untuk menghasilkan packer json dan modul terraform kami.
- Azure.
- Mungkin saat menyiapkan gambar.
- Python untuk layanan tambahan dan skrip penyediaan.
- Dan semua ini dalam VSCode dengan plugin yang dibagikan antar anggota tim.
Kesimpulan dari saya Seperti ini: Saya mencoba menanamkan (pertama-tama pada diri saya sendiri) optimisme, saya ingin mengatakan bahwa kami akan mencoba pendekatan dan praktik yang kami ketahui untuk menghadapi kesulitan dan kompleksitas yang ada di bidang ini.
Saat ini kami sedang berjuang dengan masalah IaC berikut:
- Ketidaksempurnaan alat dan sarana untuk pengembangan kode.
- Penerapan yang lambat. Infrastruktur adalah bagian dari dunia nyata, dan hal ini bisa berjalan lambat.
- Kurangnya pendekatan dan praktik.
- Kami baru dan tidak tahu banyak.
Pemrograman Ekstrim (XP) untuk menyelamatkan
Semua pengembang sudah familiar dengan Extreme Programming (XP) dan praktik yang mendasarinya. Banyak di antara kita yang telah menggunakan pendekatan ini dan berhasil. Jadi mengapa tidak menggunakan prinsip dan praktik yang ada untuk mengatasi tantangan infrastruktur? Kami memutuskan untuk mengambil pendekatan ini dan melihat apa yang terjadi.
Memeriksa penerapan pendekatan XP pada industri AndaBerikut deskripsi lingkungan yang cocok untuk XP, dan kaitannya dengan kita:
1. Persyaratan perangkat lunak yang berubah secara dinamis. Jelas bagi kami apa tujuan akhirnya. Namun detailnya bisa berbeda-beda. Kami sendiri yang memutuskan ke mana kami perlu naik taksi, sehingga persyaratannya berubah secara berkala (terutama oleh kami sendiri). Jika kita mengambil tim SRE, yang melakukan otomatisasi sendiri, dan membatasi persyaratan dan ruang lingkup pekerjaan, maka poin ini sangat tepat.
2. Risiko yang disebabkan oleh proyek dengan waktu tetap yang menggunakan teknologi baru. Kita mungkin menghadapi risiko ketika menggunakan beberapa hal yang tidak kita ketahui. Dan ini 100% kasus kami. Keseluruhan proyek kami menggunakan teknologi yang belum sepenuhnya kami pahami. Secara umum, ini adalah masalah yang terus-menerus, karena... Ada banyak teknologi baru yang bermunculan di sektor infrastruktur setiap saat.
3,4. Tim pengembangan tambahan yang kecil dan berlokasi bersama. Teknologi otomatis yang Anda gunakan memungkinkan pengujian unit dan fungsional. Kedua poin ini kurang cocok untuk kita. Pertama, kami bukan tim yang terkoordinasi, dan kedua, kami beranggotakan sembilan orang, yang bisa dibilang tim besar. Meskipun, menurut beberapa definisi tim “besar”, sebagian besar terdiri dari 14+ orang.
Mari kita lihat beberapa praktik XP dan bagaimana pengaruhnya terhadap kecepatan dan kualitas umpan balik.
Prinsip Putaran Umpan Balik XP
Dalam pemahaman saya, umpan balik adalah jawaban atas pertanyaan, apakah saya melakukan hal yang benar, apakah kita akan mencapainya? XP memiliki skema ilahi untuk ini: putaran umpan balik waktu. Hal yang menarik adalah semakin rendah kita, semakin cepat kita bisa membuat OS menjawab pertanyaan-pertanyaan yang diperlukan.
Ini adalah topik yang cukup menarik untuk didiskusikan, bahwa di industri IT kita dimungkinkan untuk mendapatkan OS dengan cepat. Bayangkan betapa sakitnya mengerjakan sebuah proyek selama enam bulan dan baru kemudian mengetahui bahwa ada kesalahan di awal. Hal ini terjadi dalam desain dan konstruksi sistem yang kompleks.
Dalam kasus IaC, umpan balik sangat membantu kami. Saya akan segera melakukan sedikit penyesuaian pada diagram di atas: rencana rilis tidak memiliki siklus bulanan, tetapi terjadi beberapa kali sehari. Ada beberapa praktik yang terkait dengan siklus OS ini yang akan kita lihat lebih detail.
Penting: feedback dapat menjadi solusi dari semua permasalahan yang disebutkan di atas. Dikombinasikan dengan praktik XP, ini dapat menarik Anda keluar dari jurang keputusasaan.
Cara menarik diri Anda keluar dari jurang keputusasaan: tiga latihan
Uji
Pengujian disebutkan dua kali dalam putaran umpan balik XP. Bukan hanya itu saja. Mereka sangat penting untuk keseluruhan teknik Pemrograman Ekstrim.
Diasumsikan bahwa Anda memiliki tes Unit dan Penerimaan. Beberapa memberi Anda umpan balik dalam beberapa menit, yang lain dalam beberapa hari, sehingga membutuhkan waktu lebih lama untuk ditulis dan lebih jarang ditinjau.
Ada piramida pengujian klasik, yang menunjukkan bahwa harus ada lebih banyak pengujian.
Bagaimana kerangka kerja ini berlaku bagi kita dalam proyek IaC? Sebenarnya... tidak sama sekali.
- Unit test, meskipun harus banyak, tidak boleh terlalu banyak. Atau mereka sedang menguji sesuatu secara tidak langsung. Faktanya, kami dapat mengatakan bahwa kami tidak menulisnya sama sekali. Namun berikut beberapa aplikasi untuk pengujian yang dapat kami lakukan:
- Menguji kode jsonnet. Ini, misalnya, adalah jalur perakitan drone kami, yang cukup rumit. Kode jsonnet tercakup dengan baik dalam pengujian.
Kami menggunakan ini . - Pengujian untuk skrip yang dijalankan saat sumber daya dimulai. Skrip ditulis dengan Python, dan oleh karena itu pengujian dapat ditulis pada skrip tersebut.
- Menguji kode jsonnet. Ini, misalnya, adalah jalur perakitan drone kami, yang cukup rumit. Kode jsonnet tercakup dengan baik dalam pengujian.
- Dimungkinkan untuk memeriksa konfigurasi dalam pengujian, tetapi kami tidak melakukannya. Dimungkinkan juga untuk mengonfigurasi pemeriksaan aturan konfigurasi sumber daya melalui . Namun, pemeriksaan di sana terlalu mendasar untuk terraform, tetapi banyak skrip pengujian ditulis untuk AWS. Dan kami menggunakan Azure, jadi sekali lagi ini tidak berlaku.
- Tes integrasi komponen: bergantung pada cara Anda mengklasifikasikannya dan di mana Anda meletakkannya. Tapi pada dasarnya mereka berhasil.
Seperti inilah tes integrasi.
Ini adalah contoh saat membuat gambar di Drone CI. Untuk menjangkau mereka, Anda harus menunggu 30 menit hingga gambar Packer terbentuk, lalu menunggu 15 menit lagi hingga gambar tersebut lewat. Tapi mereka ada!Algoritma verifikasi gambar
- Packer harus menyiapkan gambarnya terlebih dahulu secara lengkap.
- Di sebelah pengujian terdapat terraform dengan status lokal, yang kami gunakan untuk menyebarkan gambar ini.
- Saat dibuka, modul kecil yang terletak di dekatnya digunakan untuk memudahkan pengerjaan gambar.
- Setelah VM disebarkan dari image, pemeriksaan dapat dimulai. Pada dasarnya pemeriksaan dilakukan dengan mobil. Ia memeriksa cara kerja skrip saat startup dan cara kerja daemon. Untuk melakukan ini, melalui ssh atau winrm kami masuk ke mesin yang baru dibangun dan memeriksa status konfigurasi atau apakah layanan sudah aktif.
- Situasinya serupa dengan pengujian integrasi dalam modul untuk terraform. Berikut adalah tabel singkat yang menjelaskan fitur-fitur tes tersebut.
Umpan balik pada saluran pipa berdurasi sekitar 40 menit. Semuanya terjadi dalam waktu yang sangat lama. Hal ini dapat digunakan untuk regresi, namun untuk pengembangan baru umumnya tidak realistis. Jika Anda sudah sangat-sangat siap untuk ini, siapkan skrip yang sedang berjalan, lalu Anda bisa menguranginya menjadi 10 menit. Tapi ini masih bukan tes Unit, yang menghasilkan 5 buah dalam 100 detik.
Tidak adanya pengujian Unit saat merakit gambar atau modul terraform mendorong pengalihan pekerjaan ke layanan terpisah yang dapat dijalankan melalui REST, atau ke skrip Python.
Misalnya, kami perlu memastikan bahwa ketika mesin virtual dimulai, mesin tersebut mendaftarkan dirinya ke layanan , dan ketika mesin virtual dihancurkan, mesin tersebut terhapus sendiri.
Karena kami memiliki ScaleFT sebagai layanan, kami terpaksa bekerja dengannya melalui API. Ada pembungkus tertulis di sana yang bisa Anda tarik dan katakan: “Masuk dan hapus ini dan itu.” Ini menyimpan semua pengaturan dan akses yang diperlukan.
Kita sudah dapat menulis tes normal untuk ini, karena tidak ada bedanya dengan perangkat lunak biasa: semacam apiha diolok-olok, Anda menariknya, dan lihat apa yang terjadi.
Hasil pengujian: Pengujian unit, yang seharusnya memberikan OS dalam satu menit, tidak memberikannya. Dan jenis pengujian yang berada pada tingkat yang lebih tinggi dalam piramida memang efektif, namun hanya mencakup sebagian permasalahan saja.
Pemrograman pasangan
Tesnya, tentu saja, bagus. Anda bisa menulis banyak sekali, bisa bermacam-macam jenisnya. Mereka akan bekerja pada level mereka dan memberi kami umpan balik. Namun masalah dengan pengujian Unit yang buruk, yang memberikan OS tercepat, tetap ada. Pada saat yang sama, saya tetap menginginkan OS cepat yang mudah dan menyenangkan untuk digunakan. Belum lagi kualitas solusi yang dihasilkan. Untungnya, ada teknik yang dapat memberikan umpan balik lebih cepat daripada pengujian unit. Ini adalah pemrograman berpasangan.
Saat menulis kode, Anda ingin mendapatkan masukan mengenai kualitasnya secepat mungkin. Ya, Anda dapat menulis semuanya di cabang fitur (agar tidak merusak apa pun bagi siapa pun), membuat permintaan tarik di Github, menugaskannya ke seseorang yang pendapatnya berbobot, dan menunggu tanggapan.
Tapi Anda bisa menunggu lama. Semua orang sibuk, dan jawabannya, meskipun ada, mungkin tidak memiliki kualitas terbaik. Misalkan jawabannya datang segera, pengulas langsung memahami keseluruhan gagasannya, namun jawabannya masih datang terlambat, setelah kejadiannya. Saya berharap itu terjadi lebih awal. Inilah tujuan dari pemrograman berpasangan – segera, pada saat penulisan.
Di bawah ini adalah gaya pemrograman berpasangan dan penerapannya dalam bekerja di IaC:
1. Klasik, Berpengalaman+Berpengalaman, digeser berdasarkan pengatur waktu. Dua peran – pengemudi dan navigator. Dua orang. Mereka mengerjakan kode yang sama dan berganti peran setelah jangka waktu tertentu yang telah ditentukan.
Mari pertimbangkan kompatibilitas masalah kita dengan gaya:
- Masalah: ketidaksempurnaan alat dan alat untuk pengembangan kode.
Dampak negatif: berkembang lebih lama, kita melambat, kecepatan/irama kerja menjadi hilang.
Cara kami bertarung: kami menggunakan peralatan berbeda, IDE umum, dan juga mempelajari pintasan. - Masalah: Penerapannya lambat.
Dampak negatif: meningkatkan waktu yang dibutuhkan untuk membuat kode yang berfungsi. Kita bosan saat menunggu, tangan kita terulur untuk melakukan hal lain sambil menunggu.
Cara kami bertarung: kami tidak mengatasinya. - Masalah: kurangnya pendekatan dan praktik.
Dampak negatif: tidak ada pengetahuan bagaimana melakukannya dengan baik dan bagaimana melakukannya dengan buruk. Memperpanjang penerimaan umpan balik.
Cara kami berjuang: saling bertukar pendapat dan praktik dalam kerja berpasangan hampir menyelesaikan masalah.
Masalah utama dalam menggunakan gaya ini di IaC adalah kecepatan kerja yang tidak merata. Dalam pengembangan perangkat lunak tradisional, Anda memiliki pergerakan yang sangat seragam. Anda dapat meluangkan waktu lima menit dan menulis N. Habiskan 10 menit dan menulis 2N, 15 menit - 3N. Di sini Anda dapat menghabiskan lima menit dan menulis N, lalu menghabiskan 30 menit lagi dan menulis sepersepuluh dari N. Di sini Anda tidak tahu apa-apa, Anda terjebak, bodoh. Investigasi membutuhkan waktu dan mengalihkan perhatian dari pemrograman itu sendiri.
Kesimpulan: dalam bentuknya yang murni tidak cocok untuk kita.
2. Pingpong. Pendekatan ini melibatkan satu orang yang menulis tes dan orang lain melakukan implementasinya. Mempertimbangkan fakta bahwa semuanya rumit dengan pengujian Unit, dan Anda harus menulis pengujian integrasi yang memerlukan waktu lama untuk memprogramnya, semua kemudahan ping-pong hilang.
Saya dapat mengatakan bahwa kami mencoba memisahkan tanggung jawab untuk merancang skrip pengujian dan mengimplementasikan kode untuk itu. Salah satu peserta membuat naskahnya, di bagian pekerjaan ini dia bertanggung jawab, dialah yang mengambil keputusan. Dan yang lainnya bertanggung jawab atas implementasi. Itu berhasil dengan baik. Kualitas naskah dengan pendekatan ini meningkat.
Kesimpulan: sayangnya, kecepatan kerja tidak memungkinkan penggunaan ping-pong sebagai latihan pemrograman berpasangan di IaC.
3. Gaya Kuat. . Idenya adalah bahwa salah satu peserta menjadi navigator direktif, dan peserta kedua berperan sebagai penggerak eksekusi. Dalam hal ini, hak untuk mengambil keputusan sepenuhnya berada di tangan navigator. Pengemudi hanya mencetak dan dapat mempengaruhi apa yang terjadi dengan sebuah kata. Perannya tidak berubah dalam waktu lama.
Bagus untuk belajar, tetapi membutuhkan soft skill yang kuat. Di sinilah kami tersendat. Tekniknya sulit. Dan ini bahkan bukan tentang infrastruktur.
Kesimpulan: berpotensi bisa dimanfaatkan, kita tidak pantang menyerah untuk mencoba.
4. Mobbing, mengerumuni dan semua gaya yang diketahui tetapi tidak terdaftar Kami tidak mempertimbangkannya, karena Kami belum mencobanya dan tidak mungkin membicarakannya dalam konteks pekerjaan kami.
Hasil umum penggunaan pemrograman berpasangan:
- Kami memiliki kecepatan kerja yang tidak merata, dan ini membingungkan.
- Kami mengalami soft skill yang kurang baik. Dan bidang studi tidak membantu mengatasi kekurangan kami ini.
- Pengujian yang panjang dan masalah dengan alat membuat pengembangan berpasangan menjadi sulit.
5. Meskipun demikian, terdapat keberhasilan. Kami menemukan metode kami sendiri “Konvergensi – Divergensi”. Saya akan menjelaskan secara singkat cara kerjanya.
Kami memiliki mitra tetap selama beberapa hari (kurang dari seminggu). Kami melakukan satu tugas bersama. Kami duduk bersama sebentar: yang satu menulis, yang lain duduk dan mengawasi tim pendukung. Kemudian kita bubar beberapa lama, masing-masing melakukan hal-hal yang mandiri, lalu kita berkumpul lagi, melakukan sinkronisasi dengan sangat cepat, melakukan sesuatu bersama-sama dan bubar lagi.
Perencanaan dan komunikasi
Blok praktik terakhir yang digunakan untuk memecahkan masalah OS adalah pengorganisasian kerja dengan tugas itu sendiri. Hal ini juga mencakup pertukaran pengalaman di luar kerja berpasangan. Mari kita lihat tiga praktik:
1. Tujuan melalui pohon tujuan. Kami mengatur keseluruhan manajemen proyek melalui pohon yang berjalan tanpa henti di masa depan. Secara teknis, pelacakan dilakukan di Miro. Ada satu tugas - ini adalah tujuan perantara. Dari situ muncullah tujuan-tujuan yang lebih kecil atau kelompok tugas. Tugas-tugas itu sendiri berasal dari mereka. Semua tugas dibuat dan dipelihara di forum ini.
Skema ini juga memberikan umpan balik, yang terjadi sekali sehari ketika kita melakukan sinkronisasi pada aksi unjuk rasa. Memiliki rencana bersama di depan semua orang, namun terstruktur dan sepenuhnya terbuka, memungkinkan semua orang menyadari apa yang terjadi dan seberapa jauh kemajuan kita.
Keuntungan dari visi visual tugas:
- Hubungan sebab dan akibat. Setiap tugas mengarah pada beberapa tujuan global. Tugas dikelompokkan menjadi tujuan yang lebih kecil. Domain infrastrukturnya sendiri cukup teknis. Tidak selalu jelas apa dampak spesifiknya, misalnya, menulis runbook tentang migrasi ke nginx lain terhadap bisnis. Memiliki kartu target di dekatnya membuatnya lebih jelas.
Kausalitas adalah properti penting dari masalah. Ini secara langsung menjawab pertanyaan: “Apakah saya melakukan hal yang benar?” - Paralelisme. Kami berjumlah sembilan orang, dan secara fisik mustahil untuk menugaskan semua orang pada satu tugas. Tugas dari satu bidang mungkin tidak selalu cukup. Kami terpaksa memparalelkan pekerjaan antar kelompok kerja kecil. Pada saat yang sama, kelompok duduk mengerjakan tugasnya selama beberapa waktu, mereka dapat diperkuat oleh orang lain. Kadang-kadang orang menjauh dari kelompok kerja ini. Ada yang pergi berlibur, ada yang membuat laporan untuk konferensi DevOps, ada yang menulis artikel di Habr. Mengetahui tujuan dan tugas apa saja yang bisa dilakukan secara paralel menjadi sangat penting.
2. Penggantian presenter rapat pagi. Saat stand-up, kita menghadapi masalah ini - orang melakukan banyak tugas secara paralel. Kadang-kadang tugas-tugas tidak berhubungan dengan baik dan tidak ada pemahaman tentang siapa yang melakukan apa. Dan pendapat anggota tim lainnya sangatlah penting. Ini adalah informasi tambahan yang dapat mengubah arah penyelesaian masalah. Tentu saja biasanya ada seseorang yang bersama Anda, namun nasehat dan tips selalu bermanfaat.
Untuk memperbaiki situasi ini, kami menggunakan teknik “Mengganti Stand-Up Leading”. Sekarang mereka dirotasi menurut daftar tertentu, dan ini berpengaruh. Saat tiba giliran Anda, Anda dipaksa untuk mendalami dan memahami apa yang terjadi agar pertemuan Scrum dapat berjalan dengan baik.
3. Demo internal. Bantuan penyelesaian suatu masalah dari pair programming, visualisasi pada pohon masalah dan bantuan pada pertemuan scrum di pagi hari sudah baik, namun belum ideal. Sebagai pasangan, Anda hanya dibatasi oleh pengetahuan Anda. Pohon tugas membantu memahami secara global siapa melakukan apa. Dan presenter dan rekan-rekan di pertemuan pagi tidak akan mendalami masalah Anda. Mereka pasti mungkin melewatkan sesuatu.
Solusinya ditemukan dengan mendemonstrasikan pekerjaan yang dilakukan satu sama lain dan kemudian mendiskusikannya. Kami bertemu seminggu sekali selama satu jam dan menunjukkan rincian solusi atas tugas yang telah kami lakukan selama seminggu terakhir.
Selama demonstrasi, perlu untuk mengungkapkan rincian tugas dan pastikan untuk mendemonstrasikan cara kerjanya.
Pelaporan dapat dilakukan dengan menggunakan checklist.1. Masuk ke dalam konteks. Dari mana datangnya tugas itu, mengapa itu perlu?
2. Bagaimana penyelesaian masalah sebelumnya? Misalnya, diperlukan klik mouse yang besar, atau tidak mungkin melakukan apa pun.
3. Bagaimana kita memperbaikinya. Misal: “Lihat, sekarang ada scriptosik, ini readmenya.”
4. Tunjukkan cara kerjanya. Dianjurkan untuk langsung mengimplementasikan beberapa skenario pengguna. Saya ingin X, saya melakukan Y, saya melihat Y (atau Z). Misalnya, saya menerapkan NGINX, menghisap url, dan mendapatkan 200 OK. Jika aksinya panjang, persiapkan terlebih dahulu agar bisa ditampilkan nanti. Disarankan untuk tidak merusaknya terlalu banyak satu jam sebelum demo, jika rapuh.
5. Jelaskan seberapa berhasil masalah tersebut diselesaikan, kesulitan apa yang masih ada, apa yang belum terselesaikan, perbaikan apa yang mungkin dilakukan di masa depan. Misalnya sekarang CLI, maka akan ada otomatisasi penuh di CI.
Dianjurkan bagi setiap pembicara untuk menjaga durasinya hingga 5-10 menit. Jika pidato Anda jelas penting dan akan memakan waktu lebih lama, koordinasikan hal ini terlebih dahulu di saluran sre-takeover.
Setelah bagian tatap muka selalu ada diskusi di thread. Di sinilah umpan balik yang kita perlukan pada tugas kita muncul.
Akibatnya, survei dilakukan untuk mengetahui kegunaan dari apa yang terjadi. Ini adalah umpan balik mengenai esensi pidato dan pentingnya tugas.
Kesimpulan panjang dan apa selanjutnya
Tampaknya nada artikelnya agak pesimistis. Ini salah. Dua tingkat umpan balik yang lebih rendah, yaitu tes dan pemrograman berpasangan, berfungsi. Memang tidak sesempurna pembangunan tradisional, namun ada dampak positifnya.
Pengujian, dalam bentuknya saat ini, hanya menyediakan sebagian cakupan kode. Banyak fungsi konfigurasi yang akhirnya belum teruji. Pengaruhnya terhadap pekerjaan sebenarnya saat menulis kode rendah. Namun, ada efek dari pengujian integrasi, dan pengujian ini memungkinkan Anda melakukan pemfaktoran ulang tanpa rasa takut. Ini adalah pencapaian yang luar biasa. Selain itu, dengan peralihan fokus ke pengembangan dalam bahasa tingkat tinggi (kita punya python, ayo), masalahnya hilang. Dan Anda tidak memerlukan banyak pemeriksaan untuk “lem”; pemeriksaan integrasi umum sudah cukup.
Bekerja berpasangan lebih bergantung pada orang-orang tertentu. Ada faktor tugas dan soft skill kita. Pada beberapa orang hal ini berjalan dengan baik, pada orang lain hasilnya lebih buruk. Pasti ada manfaatnya. Jelas bahwa meskipun aturan kerja berpasangan tidak dipatuhi secara memadai, fakta melakukan tugas bersama memiliki efek positif pada kualitas hasil. Secara pribadi, saya merasa bekerja berpasangan lebih mudah dan menyenangkan.
Cara tingkat tinggi untuk mempengaruhi OS - perencanaan dan pengerjaan tugas secara tepat menghasilkan efek: pertukaran pengetahuan berkualitas tinggi dan peningkatan kualitas pengembangan.
Kesimpulan singkat dalam satu baris
- Praktisi SDM bekerja di IaC, namun dengan efisiensi yang lebih rendah.
- Perkuat apa yang berhasil.
- Ciptakan mekanisme dan praktik kompensasi Anda sendiri.
Sumber: www.habr.com