Apa cara untuk mengurangi efek Bulan Mythical Man?

Hukum Brooks: Menambahkan tenaga kerja ke proyek perangkat lunak yang terlambat membuatnya terlambat.

Dalam bukunya No Silver Bullet - Esensi dan Kecelakaan Rekayasa Perangkat Lunak Frederick Brooks mendefinisikan konsep Mythical Man Month :

Asumsi Brooks adalah bahwa proyek pemrograman yang rumit tidak dapat dengan sempurna dipartisi menjadi tugas - tugas terpisah yang dapat dikerjakan tanpa komunikasi antara pekerja dan tanpa membangun satu set hubungan timbal balik yang kompleks antara tugas dan pekerja yang melaksanakannya .

Sejak 1982 kami telah bergerak maju dan mengumpulkan lebih banyak pengalaman dalam mengurangi masalah ini. Apa saja solusi yang berhasil Anda terapkan di pekerjaan Anda untuk menambahkan sumber daya ke proyek tanpa menciptakan lebih banyak masalah.

Apa itu MMM?

Pertama saya ingin menjelaskan konteks Hukum Brook. Apa asumsi yang membuatnya kembali pada tahun 1975?

Man-month adalah unit kerja hipotetis yang mewakili pekerjaan yang dilakukan oleh satu orang dalam satu bulan; Hukum Brooks mengatakan bahwa tidak mungkin mengukur pekerjaan yang bermanfaat dalam beberapa bulan.

^{sumber: https://en.wikipedia.org/wiki/The_Mythical_Man-Month}

Kembali pada hari itu, proyek pemrograman yang kompleks akan berarti sistem monolit besar. Dan Brooks mengklaim bahwa ini tidak dapat dengan sempurna dipartisi menjadi tugas-tugas terpisah yang dapat dikerjakan tanpa komunikasi antara pengembang dan tanpa membangun satu set hubungan timbal balik yang kompleks antara tugas dan orang-orang yang melaksanakannya.

Ini sangat benar dalam monolit perangkat lunak yang sangat kohesif. Tidak peduli berapa banyak decoupling dilakukan, masih monolit besar mengamanatkan waktu yang diperlukan bagi programmer baru untuk belajar tentang monolith. Dan peningkatan overhead komunikasi yang akan mengkonsumsi kuantitas yang semakin meningkat dari waktu yang tersedia.

Tetapi apakah memang harus seperti ini? Apakah kita harus menulis monolith dan menyimpan saluran komunikasi di n(n − 1) / 2mana njumlah pengembang?

Kami tahu ada perusahaan tempat ribuan pengembang mengerjakan proyek besar ... dan ini berhasil. Jadi pasti ada sesuatu yang berubah sejak 1975.

Kemungkinan untuk mengurangi MMM

Pada 2015, PuppetLabs dan IT Revolution menerbitkan hasil State of DevOps Report 2015 . Dalam laporan itu, mereka fokus pada perbedaan antara organisasi berkinerja tinggi vs non-berkinerja tinggi.

Organisasi berkinerja tinggi menunjukkan beberapa properti yang tidak terduga. Sebagai contoh, mereka memiliki kinerja proyek yang tepat waktu dalam pengembangan. Stabilitas dan keandalan operasional terbaik dalam operasi. Serta track record keamanan dan kepatuhan terbaik.

Salah satu hal mengejutkan yang disorot dalam laporan ini adalah metrik penyebaran per hari. Tetapi tidak hanya penyebaran per hari, mereka juga mengukur penyebaran / hari / pengembang dan apa efek dari menambahkan lebih banyak pengembang di organisasi berkinerja tinggi vs non-berkinerja tinggi.

Ini adalah grafik dari laporan itu -

Sementara organisasi berkinerja rendah selaras dengan asumsi Mythical Man Month. Organisasi berkinerja tinggi dapat mengukur jumlah penggunaan / hari / pengembang secara linear dengan jumlah pengembang.

Presentasi yang sangat baik di DevOpsDays London 2016 oleh Gene Kim berbicara tentang temuan ini.

Bagaimana cara melakukannya

Pertama, bagaimana menjadi organisasi yang berkinerja tinggi? Ada beberapa buku yang membicarakan hal ini, tidak cukup ruang dalam jawaban ini jadi saya hanya akan menautkannya.

• Good to Great: Mengapa Beberapa Perusahaan Membuat Lompatan ... Dan Lainnya Tidak oleh Jim Collins
• The High-Velocity Edge: Bagaimana Pemimpin Pasar Mengungkit Keunggulan Operasional untuk Mengalahkan Persaingan oleh Steven Spear
• Ekonomi Baru untuk Industri, Pemerintah, Pendidikan oleh W. Edwards Deming

Untuk organisasi perangkat lunak dan TI, salah satu faktor penting untuk menjadi organisasi berkinerja tinggi adalah: fokus pada kualitas dan kecepatan .

Misalnya Ward Cunningham menjelaskan Utang Teknis karena semua hal yang kami izinkan tidak diperbaiki. Ini diterima oleh manajemen karena selalu datang dengan janji bahwa itu akan diperbaiki ketika ada waktu.

Tidak pernah ada cukup waktu, dan hutang teknis menjadi semakin buruk.

Apa saja hal-hal ini yang menyebabkan hutang teknis bertambah?

• Kode Warisan
• konfigurasi lingkungan manual
• pengujian manual
• penyebaran manual

Kode lama Seperti yang didefinisikan dalam Bekerja Secara Efektif dengan Kode Lama oleh Michael Feathers adalah kode apa pun yang tidak memiliki pengujian otomatis.

Setiap pintasan waktu digunakan untuk mendapatkan kode untuk produksi; operasi dibebani dengan pemeliharaan hutang ini selamanya. Maka proses penyebaran menjadi lebih lama dan lebih lama.

Gene menceritakan sebuah kisah dalam presentasinya tentang sebuah perusahaan yang memiliki penyebaran selama enam minggu. Melibatkan puluhan ribu langkah sangat rawan kesalahan, mengikat 400 orang, dan mereka akan melakukan ini empat kali setiap tahun.

Salah satu prinsip DevOps adalah keandalan datang dari melakukan penyebaran yang lebih kecil lebih sering.

Contoh

• Jon Jenkins di Velocity 2011 : Amazon melakukan 15k penyebaran / hari
• Ken Exner di AWS Summit 2015 : Amazon melakukan penyebaran 136k / hari

Dua presentasi ini menunjukkan semua hal yang dilakukan Amazon untuk mengurangi waktu yang diperlukan untuk menyebarkan kode ke produksi.

Menurut Gene, satu-satunya hal yang berubah sepanjang waktu di organisasi berkinerja tinggi ini adalah jumlah pengembang. Jadi dari contoh Amazon, Anda bisa mengatakan bahwa dalam empat tahun mereka meningkatkan penyebaran mereka sepuluh kali hanya dengan menambah lebih banyak orang.

Ini berarti bahwa dalam kondisi tertentu, dengan arsitektur yang tepat, praktik teknis yang tepat, norma budaya yang tepat, produktivitas pengembang dapat meningkat seiring dengan meningkatnya jumlah pengembang. Dan DevOps jelas berada di tengah-tengah semua ini.

Apa yang telah saya lakukan (dan ini hanya subjektif) adalah sebagai berikut:

Ketika seorang manajer memikirkan tanggal jatuh tempo ingin menambahkan orang ke dalam tim saya untuk memotong waktu yang dibutuhkan dan tampaknya di bawah MMM, saya pertama kali berdiskusi dengannya tentang mengapa ini bisa buruk. Analogi favorit saya untuk ini adalah untuk mengingatkan mereka bahwa jika seorang wanita dapat memiliki bayi dalam sembilan bulan, sembilan wanita tidak akan memiliki satu bayi dalam satu bulan, tetapi mereka akan memiliki sembilan bayi dalam sembilan bulan. Waktunya tidak dipotong, hanya saja pemrosesan paralelnya lebih baik.

Ketika keputusan dipaksakan kepada tim kami, kami biasanya mencoba untuk membagi beberapa tugas lebih lanjut, dan ketika ini tidak mungkin, kami biasanya mengandalkan pemrograman berpasangan , di mana satu programmer bertanggung jawab untuk mengetik, dan yang lainnya menentukan kode (dan beralih secara berkala) ).

Penulisan kode itu sendiri lebih lambat, tetapi ada sedikit kesalahan ketik / linting dan bug saat pengujian karena ulasan yang tak terelakkan dilakukan saat menulis. Saya merasa kualitas kode keseluruhan juga sedikit lebih baik, tetapi saya tidak punya metrik untuk mendukung klaim itu.

Berbicara secara eksklusif dari sudut pandang CI, meningkatkan jumlah pengembang yang mengerjakan proyek biasanya diterjemahkan menjadi lebih banyak orang yang bekerja di cabang yang sama.

Sistem CI tradisional memiliki masalah skalabilitas dalam hal ini: probabilitas kerusakan / regresi / penyumbatan meningkat memperlambat kecepatan integrasi dan mengundang tim kecil untuk memutuskan dan beralih ke cabang anak (yaitu perlambatan lebih lanjut). Lihat Bagaimana skala integrasi berkelanjutan untuk proyek / tim yang sangat besar? . Ini dimainkan tepat di sepanjang konsep Mythical Man Month.

Solusi yang saya sarankan dalam jawaban saya untuk pertanyaan itu, sistem CI yang sangat skalabel akan memungkinkan migrasi menuju CI - cabang tunggal / integrasi berbasis batang untuk seluruh tim yang lebih besar (bahkan dengan ukuran besar).

Dengan setiap orang pada halaman yang sama, menggunakan alat / proses otomatis yang sama dan sebagian besar verifikasi QA yang diotomatisasi di dalam sistem CI itu sendiri, menjadi lebih mudah untuk beralih peran dan fokus di antara anggota tim. Seluruh proses pengembangan menjadi lebih halus, lebih dapat diprediksi, lebih santai.

Membawa orang-orang baru di lingkungan seperti itu, menjadikan mereka produktif hanya dengan melepas tugas yang lebih sulit dari anggota tim yang lebih berpengalaman yang kemudian dapat mengambil yang lebih sulit adalah lebih mudah.

Semua ini dapat dilihat, saya percaya, sebagai efek konsep Mythical Man Month yang menenangkan.