Apa cara untuk mengurangi efek Bulan Mythical Man?


16

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.


5
Saya memberikan suara untuk menutup pertanyaan ini sebagai di luar topik karena lebih cocok di Software Engg. SE ( softwareengineering.stackexchange.com ), dan juga menyebabkannya tidak sepenuhnya khusus
Devops

2
Ini adalah pertanyaan spesifik DevOps. Ini terkait langsung dengan proses pengiriman perangkat lunak. Apakah Anda yakin benar-benar memahami apa yang dimaksud dengan DevOps?
Jiri Klouda

3
Anda terus mengatakan DevOps, saya tidak berpikir itu berarti apa yang Anda pikirkan artinya.
Jiri Klouda

3
@ Dawny33: Tolong, baca salah satu buku dasar DevOps - The Phoenix Project. Anda tidak akan menemukan penyebutan AWS, Docker, Jenkins, atau alat lainnya. Seluruh buku adalah tentang proses, hierarki dan struktur organisasi, cara untuk bekerja dalam tim. DevOps adalah cara untuk membawa ide-ide ilmiah yang meningkatkan manufaktur di Jepang dan Amerika Serikat ke proses Pengembangan Perangkat Lunak. Gagasan berdasarkan karya Edward W. Deming dan Eliyahu M. Goldratt. Apa yang Anda lihat sebagai DevOps hanyalah permukaan, alat, dan hasilnya. Bagian yang berlebihan dari itu.
Jiri Klouda

5
@ Dawny33 Pertanyaan ini tidak cocok untuk Rekayasa Perangkat Lunak. Meskipun topik umum ini adalah, pertanyaannya terlalu luas. Ini mencari pendapat daripada berusaha memecahkan masalah. Tolong jangan menyarankan komunitas lain jika Anda tidak mengerti jenis pertanyaan apa yang mereka terima. Jika pertanyaan ini diposting di Rekayasa Perangkat Lunak, pertanyaan itu akan dihapus, ditutup, dan kemungkinan dihapus dengan sangat cepat. Itu mengarah pada pengalaman pengguna yang buruk.
Thomas Owens

Jawaban:


18

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 -

Penyebaran per Hari per Pengembang

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.

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

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.


4

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.


1
Saya suka ide pemrograman pasangan. Itu sebenarnya sesuatu yang bisa membantu. Saya mungkin bisa menjelaskan mengapa nanti berdasarkan teori yang telah saya kerjakan.
Jiri Klouda

tolong lakukan, tunggu!
Peter

4

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.


Dalam organisasi berkinerja tinggi, menambah lebih banyak pengembang biasanya berarti menciptakan lebih banyak tim independen yang menulis perangkat lunak yang dipisahkan. Ini memungkinkan lebih banyak orang untuk mencapai lebih banyak dan lebih cepat. Memiliki mereka semua berkomunikasi melalui cabang integrasi tunggal adalah anti-pola dan kemungkinan besar akan memperlambat banyak hal.
Evgeny

Having them all communicate via a single integration branch is an anti-pattern- mengapa Jika mereka dipisahkan dalam arti bahwa mereka tidak perlu lagi mengintegrasikan pekerjaan mereka maka mereka akan menyentuh cabang dengan cara yang tidak tumpang tindih / tidak bertentangan. Jika pekerjaan mereka masih perlu diintegrasikan maka pergi cabang tambahan hanya akan menunda dan mempersulit integrasi dengan menyimpang dari metodologi CI dan kehilangan semua keuntungannya.
Dan Cornilescu

Saya pikir kami tidak menyetujui arti "cabang". Boleh saja memiliki satu repositori besar, dengan satu cabang tunggal (git, atau svn), dan menderita overhead semua orang yang mengerjakan yang sama. Juga baik untuk memiliki beberapa repositori di mana setiap repositori memiliki cabang yang melacak layanan tertentu yang dipisahkan. Itu tergantung pada alat, jumlah overhead yang ditambahkan ke komit dan kode checkout.
Evgeny

Ah, maaf, ya - saya sudah terbiasa dan terus lupa yang lain tidak. Dengan cabang yang saya maksudkan adalah representasi generik tingkat tinggi dari cabang SCM, tidak masalah mana yang merupakan kekhasan dari sistem SCM yang mendasarinya (as) selama mereka dikelola bersama secara monolitik . 1 repo besar dengan maincabang atau 10 repo berdampingan (modul git?) Masing-masing dengan maincabang harus cukup banyak setara dari calon CI.
Dan Cornilescu

Kemudian pernyataan saya dari komentar pertama benar. Kemandirian tidak dapat dilakukan dalam menara babel, ketika Anda memiliki monolit, ongkosnya sangat tinggi untuk semua orang - jadi setiap orang terbebani. Adalah jauh lebih baik untuk mewakili proyek yang dipisahkan sebagai sistem VCS kecil yang dipisahkan untuk dikelola. Jika Anda ingat cukup jauh, beberapa perusahaan menggunakan ClearCase dan VCS lainnya untuk mengelola SEMUA kode perusahaan - biaya overhead yang mengerikan.
Evgeny
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.