Bagaimana ketidaknyamanan membantu kita meningkatkan proses pengembangan.

Saya seorang pemimpin tim dan tugas saya adalah memastikan kerja tim yang produktif. Ini tidak mudah, karena tidak ada resep yang sudah jadi untuk sukses. Tentu saja, ada metodologi yang dikenal: Agile , Lean , Value Stream Mapping . Mereka memberikan pedoman umum dan nilai-nilai, yang sudah baik, tetapi ini hanyalah pedoman. Dan dengan solusi spesifik, berbaik hatilah, balikkan diri Anda. Itu sebabnya Anda dan pemimpin tim.

Dalam artikel ini saya akan memberi tahu bagaimana tim dan saya secara bertahap terbentuk dan sekarang secara teratur memperbaiki pendekatan untuk pekerjaan yang efektif. Poin kuncinya adalah bahwa alat yang dipilih benar-benar diterima oleh seluruh tim dan telah berakar dalam pekerjaan. Ini memberi harapan bahwa pendekatan itu bermanfaat.

Sedikit konteks

Di True Engineering, kami terlibat dalam pengembangan perusahaan. Kami membuat produk multi-tahun yang besar di mana banyak tim berpartisipasi. Secara khusus, tim kami terdiri dari tujuh orang: empat pengembang, satu pemimpin tim-teknologi (menulis kode dan banyak), satu QA, satu PM. Produk yang dikerjakan tim berusia dua tahun. Kondisi teknis - oleh upaya seluruh tim - dekat dengan teladan.

Ketidaknyamanan sebagai alat diagnostik

Untuk menemukan dan mengenali masalah dalam tim, kami menggunakan alat yang cukup sederhana - ketidaknyamanan para peserta.

Ini, tentu saja, bukan tentang situasi di mana satu orang ber-AC dan yang lainnya panas. Saya berbicara tentang kegagalan dalam aliran kerja normal.

Misalnya, rilis itu bengkok, meskipun masing-masing secara individual melakukan tugasnya dengan baik. Atau stabilisasi telah berlangsung selama dua minggu dan tim merobek, meskipun kami sendiri membuat perkiraan dan tidak ada yang mengganggu kami untuk melakukannya dengan baik. Atau bisnisnya tidak mendapatkan apa yang diharapkan.

Cara bertindak dalam situasi yang sama:

1. Hentikan panik dan sadari mengapa kita tidak nyaman saat ini.
2. Dapatkan ke bagian bawah penyebab root. Misalnya, menggunakan teknik Lima Mengapa atau hanya akal sehat.
3. Putuskan bagaimana cara mengatasi masalah tersebut. Pedoman untuk memilih solusi yang tepat akan dibahas di akhir artikel. Di sini saya perhatikan poin penting yang mendasar: kita menggunakan ketidaknyamanan untuk mendiagnosis masalah, tetapi ini tidak berarti bahwa pedoman untuk memilih solusi adalah untuk mencapai kenyamanan. Ingat alasan utama Anda ada sebagai tim adalah nilai bisnis. Tidak ada yang membutuhkan tim yang bahagia yang tidak membawa hasil.
4. Setelah beberapa saat, lakukan retrospektif. Jika keputusan itu tidak membantu, kami kembali ke paragraf 1 dengan pemahaman baru. Jika ini membantu, kami mengotomatiskan atau menambah daftar prinsip untuk pemula di masa mendatang. Tidak ada kontrol yang diperlukan lagi, para peserta sendiri akan mengambil pendekatan untuk bekerja jika itu benar-benar bagus.

Algoritma yang dijelaskan sederhana, tetapi spesifiknya tidak cukup. Selanjutnya, saya akan menjelaskan prinsip-prinsip yang telah kami simpulkan menggunakan pendekatan ini. Agar artikel tersebut tidak berubah menjadi memoar, saya hanya akan menggambarkan hasil yang diperoleh, dan bukan keseluruhan cerita dari kesadaran akan rasa sakit hingga eliminasi.

Prinsip-prinsip yang menjadi dasar kami membangun proses

1. Kami terus-menerus membuat dan mempersingkat putaran umpan balik

Semua interaksi manusia dengan dunia luar dibangun berdasarkan umpan balik, tanpa itu tidak mungkin untuk memverifikasi kebenaran tindakan yang dilakukan. Bayangkan seperti apa hidup kita jika kita tidak merasakan sakit melompat dari ketinggian empat meter atau meraih teko merah panas.

Dalam pengembangan, penyelesaian kode dapat berfungsi sebagai contoh loop umpan balik pendek yang baik - ini memberi tahu kita tentang tindakan yang benar pada saat entri kode.

Sekarang adalah contoh dari tidak adanya loop umpan balik: kami tahu tentang masalah dengan pengguna, tetapi kami tidak dapat mereproduksinya, kami tidak memiliki log, tidak ada cara untuk dengan cepat meluncurkan perbaikan dan kami bahkan tidak tahu versi mana yang saat ini ada di prod. Anda tidak akan berharap musuh.

Setiap tindakan dalam proses pengembangan dapat dan harus memberikan umpan balik: membangun, menyisir, lulus tes mandiri, tes yang dilakukan, sesi uji coba dengan bisnis, penyebaran yang sukses, pemantauan produk - semua ini adalah cara untuk mendeteksi kesalahan dan menyesuaikan tindakan selanjutnya.

Perlu juga dicatat bahwa biaya kesalahan meningkat saat Anda bergerak maju. Jika kami merilis bug produksi pada produksi yang merusak data, maka tugasnya tidak hanya memperbaikinya, tetapi juga memulihkan data (jika memungkinkan). Biaya keterlambatan penghapusan kesalahan seperti itu sangat tinggi, belum lagi konsekuensi untuk bisnis.

Oleh karena itu, keberadaan sejumlah besar putaran umpan balik yang cepat dan informatif sangat penting.

Di bawah ini adalah loop yang secara sadar kami dukung dan perpendek jika memungkinkan. Saya kira sebagian besar dari Anda tahu. Tetapi apakah Anda benar-benar memilikinya dan bekerja?

• Kemampuan untuk menjalankan dan menjalankan proyek secara lokal.
• Dirancang untuk Gagal Cepat .
• Pembangunan CI yang cepat dan informatif.
• Tinjauan kode konstan dan bekerja dengan kode melalui permintaan tarik.
• Ketersediaan autotest. Tes adalah pesan kesalahan yang cepat, stabil, informatif.
• Penyebaran otomatis, karena manual akan dilakukan lebih jarang.
• Rilis yang sering alih-alih mengumpulkan dan merilis versi seminggu setelah menyelesaikan tugas.
• Log informatif, pemantauan, alat diagnostik. Akses ke mereka dari seluruh tim.
• Kemampuan untuk memfilter dan visualisasi grafis log.
• Pemantauan berkelanjutan terhadap indikator teknis dan fungsional sistem sebagai bagian dari pekerjaan sehari-hari.
• Studi empiris sistem - Google Analytics, analisis data yang terakumulasi dalam sistem.
• Menyimpan riwayat perubahan data alih-alih kondisi akhir, jika berlaku.
• Ketat, kerja sama Dev, Ops, QA, bisnis alih-alih “melemparkan pagar” dari hasil tahap sebelumnya.
• Melakukan retrospektif secara teratur baik di dalam tim dan dengan bisnis.
• Umpan balik teratur dari bisnis. Yang lebih baik adalah umpan balik dari pengguna akhir.
• Kemampuan untuk mengamati pekerjaan pengguna "di bidang."
• Kemampuan untuk mengamati pengguna yang melihat sistem Anda untuk pertama kalinya.

Secara umum, umpan balik itu sendiri harus menarik. Seperti, misalnya, bangunan yang rusak.

Yang perlu diperhatikan, terkadang perubahan yang sangat kecil sudah cukup untuk perbaikan yang radikal.

Misalnya, Anda menulis log di ELK . Mereka terstruktur, dianalisis, tersedia untuk umum - semuanya baik-baik saja. Tetapi seberapa sering pengembang mampir saat debugging? Kemungkinan besar tidak.

Jika pesan tingkat peringatan dan lebih tinggi ditampilkan secara langsung di IDE, maka ada kemungkinan untuk memperhatikan, misalnya, waktu eksekusi permintaan menurun. Bahkan jika itu tidak terkait dengan tugas saat ini. Ada kemungkinan untuk memperhatikan masalah sebelumnya, dan biaya untuk memperbaikinya akan lebih rendah.

2. Aktivitas apa pun meninggalkan artefak publik

Artefak harus persis publik. Dan bermanfaat.

Berkat prinsip ini, kami meminimalkan faktor bus , memberikan pemahaman terpadu tentang situasi, pekerjaan (dan fakapim) secara sadar, terus membuat kesimpulan.

Beberapa praktik sudah jelas dan diterima secara umum: pesan informatif tentang komitmen, hubungan komit dengan tugas, deskripsi Cara Menguji, Definisi Selesai.

Ada beberapa poin yang kurang jelas:

• Anda tidak bisa "hanya mengacaukannya", kegagalan harus diwujudkan. Jika analisis mengungkapkan persyaratan yang dipikirkan dengan buruk, maka penyempurnaan yang disengaja akan menjadi artefak untuk semua. Jika masalahnya adalah dalam arsitektur sistem, artefak akan menjadi tugas teknis yang dijelaskan dengan istilah yang jelas untuk mulai bekerja.
• Jumlah pengetahuan dalam surat, pesan instan, kepala harus minimal. Semua penyempurnaan tercermin di basis pengetahuan atau di pelacak tugas. Jadi, ketika tester menerima tugas, perubahan persyaratan untuknya tidak akan menjadi berita. Ketika bisnis menerima hasil, semua orang mengerti apa yang seharusnya mereka dapatkan. Status ini mengubah pekerjaan menjadi aliran berkelanjutan. Berikan (cari tahu perinciannya, perbarui basis pengetahuan dan deskripsi tugas) - tugas masing-masing peserta dalam proses.
• Hasil tes tidak hanya "Saya memeriksa, semuanya baik-baik saja", tetapi daftar kasus uji lulus yang tersedia untuk umum, yang disusun dan dibahas sebelum pengujian, dan tidak selama atau setelah. Daftar dapat dipelajari dan ditambah oleh masing-masing peserta dalam proses.

3. Kami saling menghormati hak satu sama lain untuk pekerjaan yang terkonsentrasi

Pentingnya bekerja dalam arus dan konsekuensi gangguan , saya percaya, sudah terkenal. Karena itu, saya tidak akan membahas masalah secara rinci, tetapi segera beralih ke praktik kami.

• Headphone hanya dianjurkan.
• Komunikasi yang bekerja tidak sinkron. Jangan mengalihkan perhatian kolega Anda dengan pertanyaan kecil, tanyakan padanya di pelacak tugas (lihat bagian artefak yang tersedia untuk umum).
• Kadang-kadang terjadi hal-hal yang mengganggu mode operasi normal: kecelakaan di prod, persyaratan yang tidak bisa dimengerti untuk tugas yang sudah mulai bekerja. Sebuah sinyal dapat menjadi diskusi yang berisik di kantor, di mana tiga orang atau lebih berpartisipasi. Jika situasi ini tidak teratasi dalam beberapa menit, saya akan menunjuk satu orang untuk mengklarifikasi detailnya. Sisanya akan kembali ke operasi normal sampai orang yang bertanggung jawab memberikan informasi untuk analisis lebih lanjut.

4. Kami menghindari multitasking

Karena multitasking tidak berfungsi . Dia hanya melelahkan, menyemprotkan perhatian, dan menunda menerima hasilnya.

Praktik apa yang membantu:

• Bekerja Dalam Batas Kemajuan .
• Berfokus pada aliran nilai, bukan sumber daya. Misalnya, pengembang pertama dapat melakukan tugas dalam sehari, dan yang kedua dalam tiga. Tetapi yang pertama akan dirilis hanya setelah seminggu. Jadi, yang kedua mengambil tugas untuk bekerja. Kami akan menghabiskan lebih banyak waktu untuk implementasi, tetapi kami akan memberikan hasilnya lebih cepat (tiga hari, bukan satu minggu dan satu hari) dan beralih ke tugas berikutnya. Pada saat yang sama, kami tidak berusaha untuk “mendorong yang tidak dapat dipaksakan” ke pengembang pertama dan tidak terganggu oleh pekerjaan yang “menggantung” dalam harapannya.
• Jika beberapa orang terlibat dalam satu tugas dan pekerjaannya selesai 90%, maka tujuan nomor satu bagi tim adalah melakukan segalanya untuk menyelesaikan 10% terakhir. Baru setelah itu kita melanjutkan.

5. Kami membuat keputusan arsitektur selambat mungkin

Ini bukan keahlian kami, tetapi salah satu prinsip dasar lean manufacturing .

Keputusan yang dibuat dan diterapkan membatasi kemungkinan perubahan lebih lanjut. Dan jika keputusan dibuat dalam kondisi informasi yang tidak lengkap (dan ini hampir selalu terjadi), maka kemungkinan membuat keputusan yang salah secara signifikan lebih tinggi.

Jika kegagalan untuk membuat keputusan tidak menghalangi pekerjaan dan tidak mengarah pada pertumbuhan hutang teknis yang eksponensial, itu harus ditunda, membuat sistem siap untuk keputusan apa pun di masa depan, ketika kita memiliki lebih banyak informasi.

Ini adalah dasar pengembangan - kami tidak membangun arsitektur "besar" sebelum dimulainya proyek. Sebagai gantinya, kami membuat proses refactoring aman (lihat bagian tentang loop umpan balik) dan mengubahnya menjadi bagian alami dari proses.

Demikian pula, kami tidak mencoba menebak persyaratan masa depan untuk sistem atau membangun solusi universal. Kemampuan refactor yang aman lebih universal karena memungkinkan untuk melakukan perubahan di masa depan.

6. Kode ini operasional pada waktu tertentu.

Tentu saja, keadaan ini tidak dapat dicapai secara absolut, sistem akan rusak secara berkala setelah melakukan perubahan. Tetapi ini tidak berarti bahwa karakteristik ini tidak harus dicari.

Ketika gangguan adalah situasi yang tidak normal, dan bukan norma kehidupan, maka penyebabnya mudah ditemukan. Ini biasanya merupakan komit terakhir. Oleh karena itu, orang yang bertanggung jawab dapat dimengerti, langkah-langkah untuk menghilangkan dapat dimengerti, jelas ketika kita kembali ke keadaan stabil.

Kepercayaan yang dihasilkan dalam pengoperasian sistem memberikan peluang berharga untuk dirilis kapan saja.

Nilai kedua adalah bahwa kami lebih percaya diri dalam membuat janji ketersediaan. Jika kita membagi pekerjaan menjadi dua fase: "pengembangan" dan "stabilisasi", maka sulit untuk memberikan janji yang konkret, karena "stabilisasi" bekerja dengan masalah yang belum kita ketahui. Karenanya, kami tidak dapat secara akurat mengevaluasinya.

Jika stabilisasi berjalan tidak terpisahkan dengan pengembangan dan ada semua alat yang diperlukan untuk ini, maka situasinya lebih dapat diprediksi.

Cara kami mempertahankan kinerja berkelanjutan:

• Jelas: ulasan kode, autotes, tanda fitur.
• Setiap perubahan segera dikerahkan ke lingkungan pengujian. Jika rusak, maka Anda tidak akan dapat memperbaikinya nanti - QA diblokir.
• Pengujian dalam aliran kontinu segera setelah penyelesaian tugas, sementara pengembang mengingat tugas dan kode dan dengan cepat melakukan koreksi.
• Kami tidak melakukan pekerjaan di bagian. Jika diperlukan dua orang untuk implementasi, maka mereka bekerja berpasangan, dalam satu cabang, mengunggah kode ke cabang utama ketika sudah benar-benar siap dan tercakup dalam tes.
• Otomatisasi pengiriman dan artefak pengiriman tetap yang tidak perlu "diselesaikan" secara manual.
• Setiap anggota tim tahu alat diagnostik, tahu cara bekerja dengannya, dan tahu cara membuat rilis.

7. Kami adalah tim, bukan grup pengembangan.

Apa yang dimaksud dengan "tim":

• Semua kode ditinjau oleh setidaknya satu orang. Jika masalah serius ditemukan, maka mereka didorong untuk duduk bersama dan melakukan pemrograman berpasangan. Untuk berbagi buku, artikel, penjelasan terperinci alih-alih menyiarkan pendapat pribadi sangat berharga.
• Alih-alih berkembang berkeping-keping dengan integrasi menyakitkan hasil selanjutnya, kami bekerja erat berpasangan bila diperlukan.
• Kami tidak mengubah resensi menjadi alat untuk memeriksa kesalahan ketik, kami membawa permintaan bersih, kecil, tarik ke ulasan.
• Kami tidak membuang tugas "melalui pagar", tapi dengan hati-hati menyerahkan pekerjaan QA, memeriksa sendiri jalan yang bahagia. Kami membantu QA memahami apa dan bagaimana menguji, kami membantu dalam melewati skenario perbatasan (misalnya, merusak sistem secara artifisial).
• QA, pada gilirannya, mempelajari struktur internal sistem, tahu bagaimana mengumpulkan semua detail yang diperlukan (log, status data) dan mendapatkan bug yang sangat informatif.

8. Kami memotong ekor

Untuk memaksimalkan efisiensi dan konsentrasi pekerjaan saat ini, kami menghilangkan "hutang" yang terkait dengan pekerjaan yang sudah dilakukan:

• Tugas dibawa ke penjualan secepat mungkin. Baru setelah itu kami menganggap mereka selesai.
• Kami terus-menerus menghilangkan utang teknis sehingga tidak tumbuh dengan biaya perbaikan yang tinggi (seminggu) dan tidak menghalangi pekerjaan, merusak rencana pengiriman fungsi bisnis.
• Kami tidak memulai tugas yang akan kami lakukan "suatu hari nanti," tetapi kami menghapus tugas yang berumur panjang. Sebuah bisnis pasti akan datang untuk suatu tugas ketika (jika) waktu untuk melakukannya benar-benar datang. Dan untuk berjaga-jaga, di pelacak tugas, Anda dapat mengembalikan tugas yang dihapus. Tetapi fungsi ini tidak pernah berguna bagi kita.
• Cabang-cabang berumur panjang, kode komentar, To-do-shki - semua ini adalah kode mati, yang tempatnya ada di keranjang.
• Tes yang tidak stabil segera diperbaiki atau dihapus dan diganti dengan yang lebih rendah.
• Kami melacak tugas "merayap".

Poin terakhir patut mendapat penjelasan terpisah.

Maksud saya tugas "merayap" dengan biaya tenaga kerja awalnya kecil, tetapi bertahan dalam Kemajuan selama beberapa hari atau minggu.

Mengapa ini bisa terjadi:

1. Tugas ini awalnya dirancang dengan buruk, sudah membutuhkan banyak penyempurnaan, klarifikasi yang kontradiktif atau tidak lengkap. Jadi, kita berhenti membuang-buang waktu, berhenti mengerjakan tugas dan kembali ke pernyataan.
2. Tugasnya adalah dalam keadaan menunggu hasil dari seseorang. Misalnya, layanan dari tim lain atau penyempurnaan dari bisnis. Kami menyimpan tugas seperti itu di atas pensil dan tidak membiarkannya berjalan sendiri.

Sulit untuk mematuhi poin ini. Pertama-tama, "merayap" harus diwujudkan. Maka Anda perlu membuat keputusan yang berkemauan keras dan mengambil langkah mundur ke detail. Ini sulit dilakukan pengembang karena waktu telah dihabiskan. Dan tentu saja, keputusan seperti itu akan memenuhi perlawanan bisnis. Tetapi praktik menunjukkan bahwa ini mengurangi kemungkinan menghasilkan hasil yang tidak akan diterima oleh tim, bisnis, maupun pengguna.

Grafik waktu siklus membantu dalam mencari tugas-tugas tersebut. Ini menunjukkan waktu dari saat mulai bekerja hingga selesai. Jika tugasnya "di luar kerumunan," maka ini adalah kandidat untuk pemeriksaan dekat.

Bagaimana memilih solusi yang bermanfaat

Sayangnya, saya tidak punya resep siap pakai. Efektivitas tim adalah tugas heuristik, yang berarti tidak memiliki solusi yang terjamin.

Tetapi masih ada beberapa daftar periksa. Ini dia:

• Saya menulis tentang ini di awal artikel dan saya ulangi di sini: fakta bahwa kita menggunakan ketidaknyamanan untuk mendiagnosis masalah tidak berarti bahwa kita berusaha untuk kenyamanan ketika membuat keputusan. Ingat tujuan utama - meningkatkan nilai bisnis.
• Saat menganalisis masalah, ingatlah bahwa semua peserta memiliki niat baik . Jika pemikiran Anda didasarkan pada kepercayaan paranoid bahwa seseorang dengan sengaja merugikan Anda, maka membuat keputusan yang baik sangat sulit.
• Jangan mencoba untuk menghancurkan segalanya dan membangun kembali. Bergeraklah dalam langkah-langkah kecil, lakukan perubahan secara bertahap. Tunggu sampai perubahan yang dilakukan membawa hasil, dan baru kemudian memperkenalkan yang baru.
• Jika tidak ada solusi yang jelas, gerakkan langkah-langkah kecil, terus-menerus mengevaluasi hasilnya dan mencoba berbagai opsi. Putaran umpan balik yang jelas dan refleksi konstan adalah alat pengembangan yang tidak ada habisnya untuk Anda dan tim.
• Tempa setrika selagi panas. Jangan menunda analisis sampai retrospektif - tim sudah akan melupakan apa yang terjadi. Lebih baik datang ke retrospektif dengan masalah yang sudah diakui dan solusi siap pakai yang tetap harus ditimbang dengan tim dan memilih yang terbaik.
• Keputusan harus dibuat oleh seluruh tim. Tidak ada penanaman dari atas yang akan berhasil, dan upaya untuk mengendalikan hanyalah ilusi.
• Jangan menanamkan dalam tugas-tugas orang yang tidak biasa untuk kegiatan sehari-hari mereka. Anda akan menemukan ribuan penjelasan yang masuk akal mengapa janji itu tidak dibuat, tetapi Anda tidak akan mendapatkan hasilnya.
• Efek dari keputusan harus nyata. Anda jarang akan berhasil merumuskan keputusan tentang karakteristik SMART , tetapi beberapa cara sadar untuk mengevaluasi hasilnya harus ada. Paling tidak atas dasar "sekarang ini jarang terjadi."
• Cobalah untuk secara teratur mencatat apa yang paling menyakitkan sekarang. Jika setelah setengah tahun Anda membaca kembali rekaman dengan tersenyum, berpikir "ada kaleng," maka Anda berada di jalur yang benar.

Kesimpulan

Sebagai kesimpulan, mari kita bahas kelemahan dari pendekatan tersebut.

Pertama-tama, pendekatan ini bekerja untuk mencari optimasi lokal, tidak mungkin untuk membangun strategi pengembangan untuk produk dan seluruh perusahaan yang mengikutinya. Tentu saja, kesadaran akan masalah lebih baik daripada omong kosong dan terbakar di tempat kerja, tetapi ini hanya langkah pertama.

Saya juga bertanya kepada Anda, jangan mengambil daftar prinsip yang sudah jadi, ambil alat yang dengannya ia dibuat. Inilah alasannya:

Daftar kami tidak lengkap. Ini hanya berisi apa yang telah kami terapkan dalam pekerjaan sehari-hari.
Tim tidak mengambil prinsip-prinsip dasar, yang penting yang dia sendiri tidak sadari, melalui rasa sakit ketidakhadiran mereka. Alih-alih bekerja ide, Anda akan mendapatkan hantu yang semua orang akan membawa sekitar kantor untuk beberapa waktu, dan kemudian meletakkan debu di sudut.

Daftar kami spesifik. Misalnya, jika utang teknis pada proyek telah diabaikan selama lima tahun dan sebanding dengan utang publik AS, maka akan sangat sulit untuk mendapatkan manfaat dari prinsip pemusnahan konstan utang teknis. Adalah adil untuk mengakui: hutang sebesar ini tidak akan pernah dilunasi. Dan fokus pada solusi yang benar-benar membantu membuat situasi menjadi lebih baik.
Bagaimana Anda meningkatkan proses? Dan prinsip apa yang telah Anda adopsi dalam pekerjaan Anda?