Memperlambat untuk mendorong pengembangan

Dari penerjemah:
Awal tahun adalah waktu yang tepat untuk mengevaluasi tahun lalu dengan cermat. Lihatlah apa yang terjadi dan pahami bagaimana menjadikan 2019 tahun yang lebih baik, lebih tenang, dan lebih produktif. Dalam hal ini, kami menemukan artikel Cara Memperlambat untuk Menjadi Lebih Cepat dari Sebelumnya dalam Pengembangan Perangkat Lunak yang ditulis oleh Lemi Orhan Ergin bermanfaat . Dan kami menerbitkan terjemahannya di bawah.

Poin-poin penting:

• Tergesa-gesa tidak membuat kita lebih cepat atau lebih efisien; itu meningkatkan stres dan membuatnya tidak mungkin untuk fokus. Alih-alih bergegas, Anda membutuhkan pendekatan kreatif, efisiensi dan fokus.
• Pekerjakan spesialis yang paling berbakat, bekerja bersama, berlatih dan belajar bersama. Ini akan meningkatkan profesionalisme dan menciptakan budaya keunggulan di perusahaan.
• Bangun fleksibilitas tim dan efisiensi proses dengan membuat rencana dan secara teratur memeriksanya. Temukan, analisis, dan hilangkan sumber-sumber pemborosan waktu.
• Anda tidak dapat fleksibel tanpa basis kode berkualitas. Hilangkan cacat, lepaskan versi lebih sering, tulis tes sebelum menulis kode utama, lakukan refactoring, fokus pada desain sederhana.
• Menjalankan perangkat lunak tidak berarti dirancang dengan baik. Hanya profesional sejati yang dapat membuat perangkat lunak berkualitas tinggi yang akan memungkinkan Anda untuk mengembangkan secepat mungkin.

Eksekusi tugas tercepat yang mungkin bisa menjadi musuh Anda jika Anda terlibat dalam pengembangan yang tidak terkendali. Ada tiga area penting untuk diperlambat: orang, proses, dan produk. Sebelum masuk ke detailnya, izinkan saya menceritakan sebuah kisah.

Sejauh yang saya ingat, itu tahun 2011. Saya bergabung dengan tim yang menciptakan platform untuk pemasaran online. Tugas utama saya adalah menambahkan fitur baru secepat mungkin. Saya adalah pengembang senior. Kami menyebut pengembang "senior" ketika mereka berkembang lebih cepat daripada yang lain, kan? Namun, ketika saya mulai bekerja, kami memperhatikan bahwa hampir tidak mungkin untuk bekerja dengan cepat karena hutang teknis dan kekurangan dalam desain sistem. Kami juga memperhatikan bahwa dengan setiap upaya untuk mempercepat, kami meningkatkan kompleksitas dan merusak kualitas. Saya sampai pada kesimpulan bahwa satu-satunya cara untuk mempercepat adalah menulis ulang sistem dari awal.

Saya ingat bagaimana selama percakapan telepon dengan manajer produk saya mengatakan bahwa kami perlu menulis ulang seluruh sistem. Setelah 30 detik hening, manajer bertanya: "Anda mengatakan bahwa tim Anda telah mengembangkan produk dengan kualitas buruk sehingga sekarang tim yang sama ini harus menulis ulang produk yang sama lagi, tetapi kali ini lebih baik melakukannya. Benar? Maaf, tapi ini tidak bisa diterima. Anda seharusnya menulisnya lebih baik segera. "

Perangkat lunak zombie perlu menulis ulang, berulang kali

Menurut Chaos Report Standish Group , 94% proyek diperbaiki dari awal lebih dari sekali. Ini adalah jumlah yang sangat besar. Mengingat proyek yang saya kerjakan, saya mengerti bahwa hampir semuanya ditulis ulang dari awal menggunakan teknologi baru, dengan arsitektur dan desain baru. Menyalin dari awal adalah hal yang biasa terjadi di industri kami sehingga perusahaan sering melihatnya sebagai satu-satunya cara untuk mengembangkan dan mengelola proyek. Pertama kita menulis, dan kemudian kita menulis ulang dan menulis ulang, lagi dan lagi.

Kita perlu tahu musuh utama kita. Kecepatan adalah kualitas vital dalam pengembangan perangkat lunak. Penting tidak hanya untuk memasuki pasar terlebih dahulu, tetapi juga dengan cepat menanggapi ulasan pelanggan, menambahkan fitur, dan memperbaiki bug sehingga pengguna puas dengan produk tersebut.

Tetapi kita semua memiliki masalah dengan konsep "kecepatan." Kami percaya bahwa tindakan cepat dan masuk akal serta efektif entah bagaimana terkait dengan pengaturan tenggat waktu. Kami berpikir bahwa hasilnya akan tercapai lebih cepat jika Anda bekerja lebih keras atau menarik lebih banyak orang. Sebagai hasilnya, kami menambahkan orang baru ke proyek atau bekerja lembur untuk mempercepat pekerjaan. Tergesa-gesa tidak membuat kita lebih cepat atau lebih produktif. Tergesa-gesa menciptakan suasana yang penuh tekanan, membuat kita kehilangan kesempatan untuk fokus pada pekerjaan dan menghancurkan produktivitas. Yang dibutuhkan adalah kreativitas, efisiensi dan konsentrasi.

Pengembangan perangkat lunak adalah hal yang sangat rumit. Kami tidak dapat menghilangkan kompleksitas ini. Karena itu, kita perlu hidup bersamanya. Persyaratan untuk bekerja dengan cepat menciptakan suasana yang tidak stabil dan bergejolak, menjerumuskan kita ke dalam stres, dan membuatnya tidak mungkin untuk bekerja secara produktif dan penuh perhatian. Pendekatan ini tidak berhasil.

Produktivitas tim (kapasitas), rencana induk, perkiraan biaya tenaga kerja, jam kerja tetap, tenggat waktu dan kecepatan tim (kecepatan tim) - semua ini ilusi. Ketidakmampuan itu nyata. Kecepatan pengiriman secara langsung tergantung pada profesionalisme orang, efisiensi proses dan kualitas pekerjaan yang dilakukan. Lebih sering daripada tidak, pengembang sendiri menetapkan tenggat waktu internal untuk diri mereka sendiri, bahkan jika ini tidak perlu.

Akibatnya, kami mendapatkan sistem warisan. Tekanan tenggat waktu dikombinasikan dengan ketidakmampuan mengarah ke kode warisan - jalan buntu untuk pengembangan sistem lebih lanjut. Saya dulu menggunakan nama lain untuk sistem warisan - perangkat lunak zombie. Definisi ini berfungsi lebih baik, karena warisan secara harfiah adalah perangkat lunak mati, tetapi yang terlihat bekerja pada produksi. Ini bekerja dan bahkan menghasilkan uang, tetapi membutuhkan darah, kehidupan, dan energi dari pengembang untuk dapat bekerja. Pengembang takut menyentuh kode yang berfungsi, tidak ada yang mau mengembangkannya.

Robert C. Martin berbicara banyak tentang sistem warisan di twitternya : "Jika perangkat lunak Anda semakin sulit untuk dikembangkan, Anda melakukan sesuatu yang salah." Bekerja dengan tergesa-gesa, kami sangat mengurangi kualitas sehingga dengan setiap langkah, pekerjaan semakin melambat. Saya yakin bahwa satu-satunya cara untuk berkembang lebih cepat adalah memperlambat proses sampai kita mencapai stabilitas.

Ketertinggalan dalam pengembangan perangkat lunak itu jahat

Dalam seri CleanCoders, Robert C. Martin mengatakan : "Nilai utama dari perangkat lunak adalah kemampuan sistem untuk beradaptasi dengan perubahan di masa depan dan menyederhanakan implementasinya." Terburu-buru jahat dalam pengembangan perangkat lunak. Setiap upaya untuk terburu-buru akan menyebabkan penurunan serius dalam produktivitas, fokus, efektivitas orang, kemampuan beradaptasi terhadap perubahan dan fleksibilitas perangkat lunak.

Misalnya, kami selalu punya waktu untuk memperbaiki bug, tetapi tidak ada waktu untuk menulis tes. Kami tidak menolak atau menulis tes karena kami memiliki sedikit waktu. Tapi kami selalu punya waktu untuk debug, mengemudi di kruk dan memperbaiki bug.

Kami sangat fokus pada proses yang sering kami lupakan yang paling berharga untuk pengembangan perangkat lunak - orang-orang. Proses membantu orang membuat produk yang lebih baik, meningkatkan motivasi dan memupuk lingkungan kerja yang sehat. Pada akhirnya, efisiensi proses itu penting, tetapi tidak ada yang lebih berharga daripada manusia.

Anda harus mengerti bahwa tidak ada seorang pun dan tidak ada yang sempurna. Pelanggan, eksekutif, manajer, anggota tim, perwakilan bisnis, bahkan Anda, tidak semuanya sempurna. Persyaratan, dokumentasi, alat, kode, sistem yang dikembangkan dan desainnya juga tidak akan pernah ideal. Jadi, kita harus berhenti dengan tergesa-gesa dan mempercepat pengembangan. Satu-satunya cara untuk bergerak lebih cepat dengan kecepatan tetap adalah dengan memperlambat ke tiga arah penting:

• Orang - meningkatkan profesionalisme dan keterampilan,
• Proses ini meningkatkan fleksibilitas dan efisiensi,
• Peningkatan kualitas dan otomatisasi produk.

Di mana melambat ketika datang ke orang-orang

Proses dan alat tidak menciptakan produk. Orang-orang melakukannya. Patut diakui bahwa "mempekerjakan bakat" adalah tugas terpenting perusahaan, yang memiliki dampak langsung pada masa depan perusahaan secara keseluruhan dan produk yang diciptakan secara khusus.

Pekerjakan yang paling berbakat di organisasi Anda. Mengatakan "yang paling", maksud saya bukan yang paling cerdas dan paling berpengalaman. Saya mencari setidaknya antusias, disiplin dan motivasi. Jika seseorang memiliki tiga kualitas ini, ia akan dengan mudah mengembangkan bakatnya.

Mempekerjakan harus bermanfaat bagi kedua belah pihak. Karena itu, perlambat proses perekrutan dan luangkan waktu untuk memperbaikinya. Orang bergabung dengan perusahaan yang mereka percayai. Simulasikan orang seperti apa yang Anda harapkan untuk dilihat di tim Anda. Dan buat orang-orang berbakat percaya pada Anda, melihat budaya Anda, ide Anda tentang masa depan dan karyawan Anda.

Ego adalah racun yang perlahan membunuh organisasi Anda. Jangan biarkan itu menyusup ke organisasi Anda. Mulai dari orang bodoh yang menyenangkan dalam komunikasi dan diakhiri dengan orang-orang idiot yang brilian - jangan biarkan ekstrem menjadi bagian dari tim Anda. Jangan mempekerjakan orang dengan ego kembung. Dengan mereka, Anda tidak akan pernah menciptakan budaya perusahaan yang akan menyenangkan orang lain.

Berhentilah bekerja sendirian, bekerja bersama. Jangan izinkan fragmentasi dalam tim. Penyendiri dan pengembang pahlawan adalah tanda organisasi yang disfungsional. Duduk dekat. Tetapkan standar dengan seluruh tim. Bekerja berpasangan atau dalam kelompok; tinjau bersama. Biarkan semua peserta dalam proses bertanggung jawab atas hasilnya.

Berlatih bersama adalah cara paling efektif untuk meningkatkan keterampilan Anda. Dengan berinteraksi, kita tidak hanya menginspirasi orang lain, tetapi juga belajar dari satu sama lain. Jalankan kode secara teratur, kodekan dojo, dan randori dengan seluruh tim Anda. Habiskan 30 menit setiap hari hanya berlatih.

Biarkan pengetahuan tersebar di antara orang-orang. Belajar bersama. Saya mengadakan sesi Brown Bag / Lunch & Learn dengan semua tim tempat saya bekerja sejak 2010. Dua kali saya mendengar dari rekan-rekan saya: "Berpartisipasi dalam sesi pada hari Rabu memungkinkan saya untuk memompa, dan ini sangat memotivasi saya." Ini jelas mencerminkan manfaat dari mengadakan mitaps internal biasa.

Kumpulkan umpan balik dan berikan kepada orang lain. Untuk mengumpulkan umpan balik kolektif, atur Retrospektif Hebat. Saya telah melakukan ini selama lebih dari setahun. Ngomong-ngomong, ini adalah cara yang bagus untuk melibatkan diri dalam pemecahan masalah dengan sekelompok 20 orang atau lebih.

Mengajar orang lain dan berbagi pengetahuan adalah cara terbaik untuk mencapai penguasaan. Berbicara di depan umum dan berkontribusi pada komunitas.

Secara umum diterima bahwa pengembang benci menulis dokumentasi. Tetapi kenyataannya mengatakan sebaliknya. Hasil apa pun yang dibaca orang lain adalah dokumentasi. Mulai dari kode sistem dan diakhiri dengan kode uji, dari pesan hingga komit ke grafik komit dalam repositori, dari pesan log ke pesan kesalahan, pengembang membuat banyak dokumentasi tanpa menyadarinya. Dan, apa pun yang Anda dokumentasikan, jika orang membacanya - dokumentasikan sebaik mungkin.

Anda bukan anak-anak. Organisasi bukan orang tua Anda. Setiap orang harus secara mandiri mengelola karier mereka dan berinvestasi dalam diri mereka sendiri. Jika kontribusi Anda melibatkan membuang-buang waktu atau uang, lakukanlah sendiri.

Cara memperlambat dan meningkatkan proses

Setiap hari kita dihadapkan dengan tantangan baru. Ini bukan hanya kebutuhan pasar dan persyaratan produk baru. Tantangan teknis juga memengaruhi kemajuan kita.

Perencanaan bukanlah apa-apa, tetapi perencanaan adalah segalanya. Buat rencana dan terus-menerus memeriksanya. Terutama pada tahap awal proyek ketika fleksibilitas maksimum diperlukan. Rekonsiliasi harian dengan rencana seperti scrum harian atau standup harian tidak cukup. Penting untuk berinteraksi lebih dekat dalam tim, bekerja berpasangan, dan lebih sering berkonsultasi dengan rencana. Pertahankan panjang iterasi minimum hingga satu minggu. Atur beberapa saluran umpan balik dengan ulasan reguler dan sesi demo.

Tetapkan tujuan jangka pendek dan panjang. Tujuan jangka pendek menetapkan fokus bagi tim, tujuan jangka panjang mencegah kehilangannya.

Jika Anda ingin memahami mengapa ada sesuatu yang salah, visualisasikan alur kerja, baik dari sudut pandang teknis maupun organisasi. Visualisasikan kesalahan dan kegagalan untuk memaksimalkan pembelajaran langsung.

Jangan pernah membuat keputusan berdasarkan perasaan. Selalu kumpulkan data, analisis, dan buat keputusan berdasarkan data tersebut. Penting juga untuk memberikan setiap pengembang akses ke metrik produk dan teknis. Ini meningkatkan keterlibatan dan pemahaman produk yang sedang dikembangkan.

Limbah adalah semua yang Anda habiskan, tetapi itu tidak memiliki nilai untuk bisnis. Temukan dan hilangkan pemborosan di kantor, dalam kode, dan dalam proses bisnis.

Pramuka meninggalkan tempat parkir lebih bersih daripada saat mereka tiba. Filosofi yang sama berlaku untuk pengembangan perangkat lunak. Ikuti aturan scout dan jaga kebersihan kode setelah setiap perubahan. Jika Anda akan menambahkan fungsionalitas baru dan melihat kekurangan pada file yang dapat diperbaiki, lakukan tanpa meminta izin. Ingatlah untuk menulis tes terlebih dahulu. Ini akan memberi Anda kepercayaan diri dalam melakukan perubahan.

Anda dapat menemukan pemborosan kapan saja dalam siklus pengembangan sistem. Ikuti kriteria kesiapan yang didefinisikan dengan jelas (definisi selesai) dan hilangkan tugas dengan semangat "90% selesai, 90% tersisa."

Jangan biarkan munculnya cabang berumur panjang - mereka dianggap jahat. Jangan periksa kode Anda secara manual. Dengan pengujian manual, Anda cenderung memverifikasi skrip eksekusi yang sukses. Semua skrip lain hanya dapat diverifikasi menggunakan kode. Karena itu, perhatikan masalah ini dengan serius.

Bagaimana perlambatan dapat meningkatkan kualitas produk

Satu hal yang pasti - tanpa basis kode berkualitas tinggi, Anda tidak bisa fleksibel, maaf. Hal pertama yang harus dilakukan adalah menghilangkan utang teknis dan memperbaiki kesalahan. Jika perlu, hentikan sementara pengembangan fitur baru dan fokus untuk memperbaiki bug.

Pendekatan "Saya akan memperbaikinya dengan cepat, maka saya akan memperbaikinya" tidak berfungsi dalam kenyataan saat ini, karena terlalu berisiko. Saat menghilangkan kesalahan, dibutuhkan pendekatan yang lebih disiplin. Pertama-tama, tulis tes yang mereproduksi masalah. Setelah itu, perbaiki bug dan pastikan tes lulus sekarang. Sekarang Anda dapat dengan aman mengirim tambalan ke produksi.

Saya bekerja dalam tim yang menghabiskan hampir seluruh waktu mereka memperbaiki bug dan memelihara proyek. Alasan penderitaan mereka adalah pekerjaan yang tidak stabil dalam produksi. Untuk terus mengembangkan fungsionalitas baru, sambil memperbaiki kesalahan, Anda harus membagi tim menjadi tim virtual. Misalnya, dalam setiap iterasi, kami memilih dua orang yang terlibat dalam mendukung dan memperbaiki bug. Kami memanggil mereka Batman dan Robin. Apa pun fungsionalitas Anda yang terburu-buru untuk diselesaikan, bug diperbaiki tanpa gangguan dari pengembangan utama.

Pengembang sering menggunakan salah satu praktik deselerasi untuk mempercepat permintaan tarikan lebih lanjut. Mereka menghentikan pengembangan yang sedang berlangsung, melakukan pemeriksaan, dan melakukan tinjauan kode untuk meningkatkan kualitas kode. Kode yang tidak diverifikasi tidak akan pernah mencapai produksi.

Tujuan akhir kami haruslah transisi ke Pengiriman Berkelanjutan dan rilis yang sering. Dimulai dengan menggunakan cabang git dan diakhiri dengan strategi penyebaran, dari cara untuk memberikan umpan balik hingga praktik pengujian otomatis - semua ini memerlukan pendekatan khusus.

Praktik yang Anda gunakan pada berbagai tahap siklus pengembangan perangkat lunak menunjukkan seberapa cepat Anda berkembang. Saat bekerja dengan cabang, gunakan pendekatan "komit awal, komit sering, sempurnakan nanti, terbitkan sekali". Jika bekerja tanpa cabang, gunakan Toggles Fitur. Ini akan menghilangkan pemborosan waktu.

Saya telah menggunakan TDD selama bertahun-tahun. Seringkali orang mengeluh kepada saya bahwa TDD secara negatif mempengaruhi kecepatan pengembangan. Joe Rainsberger membagikan pemikirannya di TDD di twitter : “ Apakah Anda khawatir TDD akan memperlambat programmer Anda? Tidak perlu Mereka mungkin perlu melambat. ”

TDD lebih refactoring daripada pengujian; lebih banyak pemikiran daripada coding; lebih simplicity daripada keanggunan. Inilah sebabnya mengapa TDD mengarah ke kualitas yang lebih tinggi. Saat menggunakan TDD, Anda hanya akan memiliki jumlah tes minimum yang memadai dan desain sederhana.

Pernahkah Anda mencapai 100% cakupan kode dengan tes? Saya mencapainya dalam proyek tiga bulan, mencakup setiap baris kode produksi dengan tes. Pada saat itu, saya merasa seperti pahlawan dengan kekuatan super. Tetapi ketika kami menggunakan sistem untuk praproduksi untuk pengujian penerimaan, kami memperhatikan bahwa keempat fungsi tidak bekerja. Saya menulis tes integrasi dan fungsional untuk menemukan dan memperbaiki kesalahan. Pada saat itu, saya menyadari bahwa unit test tidak menjamin desain dan fungsionalitas fungsional yang baik. Berhenti menghitung persentase cakupan kode sebagai tes. Metrik ini tidak menunjukkan apa pun.

Perbaiki kesalahan dengan segera jika butuh 30 menit atau kurang. Selain itu, gunakan 20% dari waktu untuk menghilangkan utang teknis.

Sebagai aturan, kami menulis kode tanpa bermaksud mengubahnya di masa mendatang. Saat merancang sistem, kami juga memilih teknologi dan alat, yang berencana untuk tidak mengubahnya di masa mendatang. Tapi kami salah. Refactoring harus dimungkinkan pada setiap tahap proyek. Seperti yang dikatakan Kent Beck, kita perlu membuat perubahan mudah agar perubahan lebih lanjut mudah. Untuk memungkinkan ini, kami menyimpan kode dari semua layanan microser kami dalam repositori mono. Ini membuat refactoring mudah, dan sangat diperlukan.

Setiap keputusan dalam desain salah jika dibuat lebih awal dari yang diperlukan. Anda harus menunggu saat terakhir yang dapat diterima untuk membuat keputusan. Kami menggunakan arsitektur "Ports and Adapters" untuk mencapai kopling rendah dan kohesi tinggi pada tingkat desain seluruh sistem. Karena ini, kami mendapatkan monolit yang dirancang dengan sempurna.

Monolit bukanlah kejahatan, kejahatan adalah desain yang buruk. Kami selalu memulai dengan pengembangan monolit, dan berkat arsitektur “port and adapter”, kami mengekstraksi bagian dari fungsionalitas ke dalam layanan-layanan microser. Seperti yang dikatakan Martin Fowler dalam artikel Monolith First : “Memulai dengan arsitektur layanan mikro segera berisiko, Anda sebaiknya mulai dengan monolith. Bagilah menjadi layanan-layanan mikro hanya jika dan jika perlu. ”

Memperlambat untuk mempercepat sebagai pendekatan untuk kehidupan

Andreas Möller membagikan perasaannya tentang pengembangan perangkat lunak melalui tweet : “Saya tidak ingin menulis kode yang hanya berfungsi. Saya ingin menulis kode yang bersih, dapat dipelihara, mudah dimengerti, dan teruji dengan baik. ”

Untuk mencapai ini, kita harus fokus pada tiga bidang: orang, proses dan produk. Memperlambat pekerjaan orang, kami berusaha untuk meningkatkan profesionalisme dan keterampilan. Dengan memperlambat proses, kami berusaha untuk meningkatkan fleksibilitas dan efisiensi. Dan dengan memperlambat pekerjaan pada produk, kami berusaha untuk meningkatkan tingkat otomatisasi dan tingkat kualitas. Ketika kita fokus pada tiga bidang ini, kita mulai menumbuhkan budaya yang memungkinkan pengembangan cepat.

Kita harus ingat yang berikut ini:

• Sistem kerja belum tentu ditulis dengan baik
• Hanya profesional sejati yang dapat membuat sistem yang dirancang dengan baik
• Hanya sistem yang dirancang dengan baik yang akan memungkinkan Anda untuk merilis fungsionalitas baru secepat mungkin

Tentang penulis

Lemi Orhan Ergin adalah penyihir pengembangan perangkat lunak yang berupaya meningkatkan tingkat keunggulan dalam industrinya dan berbagi pengalamannya dengan masyarakat. Co-founder Craftbase dan pendiri Komunitas Pengerjaan Perangkat Lunak Turki . Telah terlibat dalam pengembangan perangkat lunak sejak tahun 2001. Dia aktif mempraktikkan dan mentor di berbagai bidang seperti Scrum, pemrograman ekstrim, metodologi pengembangan, dan teknologi web.