Apa yang terjadi pada pola "Tim Bedah" dari "The Mythical Man-Month"?

Bertahun-tahun yang lalu, ketika saya membaca The Mythical Man-Month, saya menemukan banyak hal yang sudah saya ketahui dari sumber lain. Namun, ada juga hal-hal baru di sana, meskipun buku itu dari tahun 1975. Salah satunya adalah:

Tim Bedah

Mills mengusulkan agar setiap segmen pekerjaan besar ditangani tim, tetapi tim tersebut diorganisir seperti tim bedah daripada tim pembantaian babi. Artinya, alih-alih setiap anggota memotong masalah, yang satu memotong dan yang lain memberinya setiap dukungan yang akan meningkatkan efektivitas dan produktivitasnya.

Ini adalah pola yang sangat menarik untuk mengatur tim pengembangan perangkat lunak, tetapi saya tidak pernah menemukannya dijelaskan dalam buku Rekayasa Perangkat Lunak lainnya, bahkan tidak disebutkan di mana pun.

Mengapa demikian?

• Apakah "Tim Bedah" bahkan tidak biasa saat itu?
• Atau, sudahkah dicoba dan gagal?
  • Jika demikian, bagaimana itu gagal?
  • Jika tidak, mengapa kita tidak melihat pola itu diimplementasikan dalam proyek perangkat lunak saat ini?

"The Mythical Man-Month" keluar tahun aku mulai kuliah dan, untuk menggunakan bahasa daerah saat ini, UUUGE! :-) Yang perlu Anda pahami adalah perbedaan dalam bagaimana perangkat lunak dikembangkan KEMUDIAN vs. SEKARANG. Back In The Day (tm) cukup banyak semua pengkodean dilakukan di atas kertas terlebih dahulu, kemudian ditekan ke (Anda menebaknya) kartu berlubang, kemudian dibaca, dikompilasi, dihubungkan, dieksekusi, hasil diperoleh, dan proses diulang. Waktu CPU itu mahaldan sumber daya yang terbatas dan Anda tidak ingin menyia-nyiakannya. Ditto dan juga ruang disk, waktu tape drive, dll, bla. Menghabiskan waktu CPU yang sangat baik pada sebuah kompilasi yang menghasilkan kesalahan (kejutan dan horor!) Adalah ... well, buang-buang waktu CPU yang sangat baik. Dan ini pada tahun 1975. Pada saat itu Fred Brooks sedang mengembangkan ide-idenya, yang merupakan waktu CPU pertengahan hingga akhir 1960-an bahkan lebihmahal, memori / disk / apa pun yang bahkan LEBIH terbatas, dll, dll. Gagasan di balik Tim Bedah adalah untuk memastikan bahwa Pengembang One Super Great Rockstar tidak perlu membuang waktu HIS untuk tugas-tugas duniawi seperti kode pemeriksaan meja, menekan tombol, mengirimkan pekerjaan, menunggu (kadang-kadang berjam-jam) untuk hasilnya. Pria Pengembang Rockstar Dude akan menjadi KODE PENULISAN. Legiunnya yang terdiri dari para pengembang groupies / panitera / junior seharusnya melakukan hal-hal duniawi.

Masalahnya adalah bahwa dalam 2 tahun setelah buku Brooks diterbitkan, ide-ide dasar di balik The Surgical Team mogok:

1. Terminal CRT dan file disk mulai menggantikan keypunches dan deck kartu. Waktu komputer menjadi lebih murah, banyak komputer menjadi tersedia, dan waktu penyelesaian pekerjaan menurun secara dramatis. Ketika saya sampai di perguruan tinggi (Universitas Miami, Oxford, Ohio, kelas '79, terima kasih sudah bertanya) bagusperputaran pekerjaan sekitar satu jam. Selama minggu final - empat jam, mungkin, kadang enam. (Kami bersaing untuk waktu CPU dengan sekelompok perusahaan komersial dan universitas - dan pengguna komersial mendapat prioritas pertama). Selama tahun senior saya, di mana Miami telah keluar dari pengaturan "komputer bersama" mereka, memiliki IBM 370/145 mereka sendiri diinstal di kampus, dan memiliki mini HP bagus yang saya kerjakan yang bertindak sebagai stasiun RJE kita bisa mengubah mainframe pekerjaan sekitar dalam lima menit atau kurang. Sekarang bermanfaat untuk memasukkan kode Anda ke HP, mengirimkannya dari HP ke mainframe, memutar-mutar ibu jari Anda / merokok, dan mendapatkan hasil Anda kembali jauh sebelum Anda bisa selesai memeriksa meja kode Anda.

2. The Surgical Team memiliki dasar pemikiran bahwa Anda (atau "manajemen", tuhan membantu kami semua) dapat mengidentifikasi The Rockstar Surgical Developer Dude. Bahkan, saya ragu itu mungkin. Ada yang pengembang rockstar, semua orang tahu itu - penelitian telah menunjukkan perbedaan produktivitas antara yang terbaik dan terburuk pengembang sebanyak 2000% - tapi mengidentifikasi orang itu tanpa mereka menulis kode selama jangka waktu yang panjangkemungkinan besar tidak mungkin. Satu-satunya cara untuk mengetahui apakah seseorang adalah pengembang rockstar adalah dengan membuat mereka benar-benar mengembangkan kode - tetapi jika mereka BUKAN Pengembang Bedah Rockstar, mereka akan melakukan hal-hal menarik seperti mengecek kodenya, menekannya ke kartu, dan schlepping kotak kartu yang dilubangi ke bagian Job Entry, kemudian berdiri menunggu hasil sehingga mereka dapat schlep kembali ke Mr Rockstar Surgical Developer Dude daripada belajar kode satu-satunya cara yang benar-benar bekerja - dengan menulis kode, kode debug, dan lain-lain. Back In The Day (tm) tidak ada kontes pemrograman, tidak ada Stack Overflow, Anda tidak memiliki PC Anda dapat menulis kode kapan pun Anda suka, tidak ada buku Algoritma Untuk Idiot - satu-satunya cara untuk belajar pemrograman adalah pergi ke sekolah dan mengambil jurusan di mana Anda harus melakukan sedikit pemrograman. Tapi pemrogramanper se tidak ditanggapi dengan serius, dan dianggap sebagai sesuatu yang tidak ingin dilakukan orang . Dalam kursus kuliah pertama saya (SAN151 - Pengantar Analisis Sistem, Dr. Tom Schaber - terima kasih, Tom :-) kami diberitahu oleh instruktur bahwa "... kami hanya harus menghadapi kenyataan bahwa kami harus mengeluarkan biaya beberapa tahun sebagai programmer sebelum kita bisa menjadi analis sistem ". "Dua tahun?", Pikirku. "AKU HANYA AKAN MELAKUKAN INI UNTUK DUA TAHUN?!?". Saya benar - benar kecewa. Syukurlah dia salah dan saya sudah mengkode sejak itu. :-)

3. Tim Bedah mengasumsikan bahwa programmer adalah sumber daya yang relatif langka. Sebenarnya butuh beberapa tahun lagi, tetapi dengan munculnya PC di pemrograman awal 80-an menjadi sesuatu yang bisa melibatkan setiap geek. Harga komputer mulai turun, harga alat pengembangan mulai turun, dan itu semua hail Turbo Pascal - menurut standar sekarang ini tidak banyak tetapi pada saat itu itu adalah IDE Pascal lengkap untuk sekitar 40 dolar, yang benar-benar gila! Sekarang SIAPA SAJA bisa masuk ke pemrograman - jika Anda mampu membeli komputer, dan ketika IBM memutuskan untuk meletakkan PCjr (ya, PC pertama saya adalah salah satu kesalahan terbesar IBM :-) dijual seharga sekitar $ 500 untuk menyingkirkan kalkun, uang tunai Geeks yang terikat di mana-mana melewatkan pembayaran sewa selama sebulan ("Ya, eh, saya tahu, tapi saya, uh ... merusak uuvula saya dan harus menjalani operasi dan .. ... ya, minggu depan, tidak masalah, terima kasih, kawan ...) dan menghisapnya dengan harga jual yang murah. Kemudian menghabiskan lebih dari yang kami bayarkan untuk komputer untuk add-on agar dapat digunakan. ("Ya, bung, minggu depan, pasti, mungkin ..." :-).

Apa yang membuat saya benar-benar sedih adalah bahwa bahkan hari ini, jika Anda bertanya kepada orang-orang apakah mereka pernah membaca "The Mythical Man-Month" atau memahami pelajaran utamanya ("Menambahkan sumber daya ke proyek yang terlambat membuatnya nanti") mereka memberi Anda sebuah blank tatap - dan kemudian lanjutkan untuk membuat kesalahan yang sama persis seperti yang dibuat All Years Years Ago selama pengembangan OS / 360. Semua yang lama adalah baru lagi ...: -}

Ada beberapa aspek dari konsep itu yang terkadang diimplementasikan saat ini, ada aspek lain yang dihindari .

Menjaga tim tetap kecil adalah salah satu fitur dasar dari Metode Agile, tetapi juga dipraktikkan di luar Agile.

Tim lintas fungsi juga merupakan bahan pokok Agile, tetapi juga umum di luar Agile.

Peran Panitera Program sebagian besar digolongkan oleh sistem terkomputerisasi seperti Sistem Kontrol Versi, Sistem Manajemen Konfigurasi Perangkat Lunak, Sistem Manajemen Perubahan, Sistem Manajemen Dokumen, Wiki, Sistem Pembangunan Berkelanjutan dengan Gudang Artefak, dan sebagainya. Maksud saya, dapatkah Anda membayangkan membayar karyawan penuh waktu untuk mencetak kode sumber, dan secara manual mengindeks dan mengarsipkannya?

Demikian pula, peran Administrator Sistem (bukan bagian dari Tim Bedah Mills, tetapi bagian dari tim lintas fungsi khas tahun-tahun terakhir) sedang dihancurkan oleh konsep-konsep seperti DevOps (menyerap peran Sysadmin ke peran Insinyur Perangkat Lunak) , Platform-sebagai-Layanan-, Infrastruktur-sebagai-Layanan, dan Komputasi Utilitas (menjadikan peran Sysadmin sebagai "masalah orang lain"), atau Infrastruktur-sebagai-Kode (mengubah Administrasi Sistem menjadi Rekayasa Perangkat Lunak).

Salah satu aspek yang kami coba hindari hari ini, adalah bahwa paling banyak dua orang memahami sistem. Hanya ahli bedah dijamin untuk memahami sistem sepenuhnya, co-pilot mungkin atau mungkin tidak. Ini memberikan faktor bus antara 1 dan 2. Jika ahli bedah sakit, proyek sudah mati. Titik. Jawaban Agile untuk itu adalah Kepemilikan Kode Kolektif, yang merupakan kebalikan dari model itu: tidak ada yang bertanggung jawab secara tunggal atas bagian mana pun dari sistem. Sebagai gantinya, semua orang bertanggung jawab untuk semuanya sebagai kelompok .

Terakhir, ada beberapa asumsi yang dimasukkan ke dalam konsep itu, yang sudah ketinggalan zaman. Misalnya, meskipun tidak dinyatakan secara eksplisit, tim diatur sedemikian rupa sehingga hanya satu orang dalam tim (ahli bedah) yang benar-benar memiliki komputer. Itu, tentu saja, karena pada saat artikel itu ditulis, bahkan gagasan bahwa seluruh tim akan memiliki satu komputer untuk diri mereka sendiri, apalagi satu orang dalam tim, adalah peregangan. (Bahkan pada 1980, ketika Smalltalk dirilis, salah satu hal yang berkontribusi terhadap kegagalannya adalah kenyataan bahwa sistemnya diatur sedemikian rupa sehingga setiap pengembang dan setiap pengguna memiliki komputer mereka sendiri - benar-benar tidak terpikirkan pada saat itu.)

Jadi, singkatnya: Saya tidak berpikir konsep tersebut telah dilaksanakan persis seperti yang dijelaskan, tetapi beberapa aspek itu pasti yang dilaksanakan, beberapa aspek dilihat sebagai tidak diinginkan dan secara aktif dihindari, beberapa yang usang, dan beberapa Mungkin Ide Baik ™, tapi tidak ada yang melakukannya.

Dulu, pendidikan perguruan tinggi adalah sesuatu yang unik, dan insinyur adalah di antara beberapa yang dipilih. Komputer mahal, dan tim mengerjakan proyek dengan RoI bisnis yang ditentukan. Ini tidak terlalu umum.

Apa yang terjadi adalah komputer mikro, pendidikan sarjana di mana-mana, dan sistem komputer yang bahkan tidak memerlukan gelar sarjana untuk maju. Juga, yang terjadi adalah pergeseran ekonomi dan meningkatnya biaya tenaga kerja.

Ekonomi dukungan 8: 2: rasio insinyur tidak masuk akal lagi. Insinyur harus menjadi dukungan mereka sendiri. Manusia modern dengan pendidikan dan keterampilan yang cukup untuk menjadi efektif melekat pada tim pengembangan terlalu mahal untuk tidak melakukan semacam pengembangan mereka sendiri.

(Istilah ekonomi terkait adalah "penyakit biaya sektor jasa.")

Bagi saya, pola ini sangat mirip dengan pemrograman Mob:

Seluruh grup (QA, pengembang dan bahkan Pemilik Produk jika diperlukan) bekerja pada saat yang sama dalam masalah yang sama. Tidak berdiri, komunikasi tinggi, langsung dikerahkan ke live.

Dari http://codebetter.com/marcushammarberg/2013/08/06/mob-programming/

Konsep dasar pemrograman mafia sederhana: seluruh tim bekerja sebagai satu tim bersama dalam satu tugas pada saat itu. Yaitu: satu tim - satu keyboard (aktif) - satu layar (tentu saja proyektor). Ini seperti melakukan pemrograman pasangan tim penuh.

Lihat beraksi di sini: https://www.youtube.com/watch?v=dVqUcNKVbYg

Model tim ini disebutkan lagi dalam Rapid Development - Taming Wild Software Schedule oleh Steve McConnell di halaman 305. Di sana disebut Tim Ketua Programmer.

Model ini muncul karena ada jenius di tim dan sumber daya komputasi terbatas. Itu tidak disukai karena genius jarang terjadi, dan dengan komputer di mana-mana dan kontrol versi terdistribusi kami memiliki ruang untuk banyak tangan di meja operasi.

Referensi lain:

Baker, F. Terry. "Kepala Tim Programmer Manajemen Pemrograman Produksi," IBM Systems Journal, vol. 11, tidak. 1, 1972, hlm. 56-73.

Baker, F. Terry dan Harlan D. Mills. "Ketua Tim Programmer." Datamation, Volume 19, Number 12 (Desember 1973), hlm. 58-61.

Dugaan saya adalah bahwa sebagian besar tim yang mengatur diri sendiri akan cenderung menjadi model tim bedah de-facto.

Dua tim terakhir yang saya ikuti cenderung terdiri dari tiga atau empat orang, biasanya satu senior (ahli bedah), perantara (co-pilot) dan beberapa junior / spesialis. Beberapa peran dalam tim bedah seperti yang disebutkan oleh Brooks saat ini diisi oleh para master Scrum dan sysadmin atau penyedia cloud. Ingat bahwa kontrol sumber hampir tidak ada pada saat itu, apalagi sesuatu yang sekuat git.

Pikirkan aturan dua pizza Bezo. Itu tim bedah yang mengatur diri sendiri di sana.

Ada kertas dari HP yang menyarankan sesuatu yang serupa:

• Setiap insinyur perangkat lunak akan membutuhkan banyak manajer dan banyak orang pendukung.
• Harus ada penulis teknis, penguji, manajer bangunan, dan pembuat alat untuk setiap insinyur.

Koran itu di masa pra-web, dan dibesarkan dari waktu ke waktu sebagai lucu. Setiap tahun dibesarkan, komentar bergerak sedikit lebih dari "sangat konyol itu lucu" menjadi "mungkin kita harus melakukan itu".

Tes yang sebenarnya sangat sulit untuk dirancang, jadi itu mungkin masih pendapat. Mungkin ada beberapa survei proyek dan tingkat penyelesaiannya.

Saya bertanya-tanya berapa banyak kebutuhan untuk tim bedah telah menjadi mubazir karena munculnya Internet, lingkungan pengembangan terintegrasi dan kit pengembangan perangkat lunak , yang dapat mengambil banyak fungsi yang dikaitkan Fred Brooks dengan tim bedah, termasuk:

• Ahli bedah: seorang programmer
• Co-pilot: memasangkan programmer , rekan kerja, komunitas online seperti StackExchange atau IRC
• Administrator: peran yang biasanya diambil oleh manajer proyek perangkat lunak
• Editor: IDE mengintegrasikan generator dokumentasi seperti Javadoc atau Doxygen; dokumentasi dari kit pengembangan perangkat lunak
• Sekretaris: klien email, alat manajemen proyek seperti pelacak isu dan permintaan tarik, ruang obrolan perusahaan dan milis
• Petugas program: IDE menyimpan informasi tentang desain proyek, dengan kemampuan tambahan untuk memperbaiki kode; dokumentasi dan contoh-contoh dari kit pengembangan perangkat lunak
• Toolsmith: seluruh komunitas sumber terbuka
• Penguji: secara langsung, ruang uji dan perpustakaan pengujian. Tetapi tentu saja proses QA yang terpisah diperlukan untuk kode produksi.
• Pengacara bahasa: dokumentasi online, StackExchange

Saya pikir Anda perlu melihat premis The Mythical Man Month. Mempekerjakan lebih banyak programmer hanya membuat proyek perangkat lunak yang bermasalah / terlambat menjadi lebih buruk. Masalahnya adalah dalam komunikasi dan mendapatkan programmer baru ditambahkan ke kecepatan pada proyek (membutuhkan waktu dari pengembangan yang ada), teknologi dan kadang-kadang domain itu sendiri.

Satu programmer yang didukung dengan baik menghilangkan banyak waktu komunikasi dan koordinasi. Katakanlah Anda menyewa seorang konsultan untuk Technology X. Daripada membawa konsultan ini dengan kecepatan yang cukup pada proyek di mana orang ini dapat melakukan semua pengkodean di bidang itu, ia hanya melatih pengembang yang ada ke titik di mana ia dapat membangun sesuatu. dengan beberapa pengawasan.

Salah satu alasan Anda tidak melihat banyak dari ini adalah karena sebagian besar perangkat lunak ditulis oleh satu orang. Tim membagi pekerjaan dan semua orang pergi dan melakukan pekerjaan mereka. Memasangkan pemrograman, ulasan, dan apa pun yang berbau manajemen mikro disukai. Banyak yang tidak melihat pemrograman sebagai olahraga tim. Satu orang menyelesaikan masalah tertentu dengan beberapa pertimbangan untuk semua kendala.

Saya berpendapat bahwa semakin kita memisahkan desain, implementasi, pengujian, dokumentasi, build, penyebaran, operasi, dll ke dalam peran unik yang dilakukan oleh spesialis, semakin kita mengikuti filosofi "tim bedah" (meskipun mungkin tidak persis dengan cara yang dijelaskan ).

Dalam pengalaman saya, filosofi para penggemar bahwa setiap orang harus mampu melakukan setiap tugas adalah kembali ke model pemotongan babi (tidak mengatakan bahwa itu buruk, hanya berbeda).

Sebagai seorang programmer yang sering mengisi peran DevOps dan Build Master saya merasa bahwa saya sering berakhir pada posisi itu sebagai tim bedah .. err ... orang dalam tim. Sebagai seorang build master, saya memiliki gambaran umum tentang seluruh kode dan merupakan baris pertama ketika gagal. Seringkali saya hanya memperbaikinya sendiri.
Saya sering menjadi orang yang menulis sistem metrik ini dan mengukur hotpoint dalam kode, bagian yang akan lebih sering gagal, yang paling menarik laporan bug, dll. Saya tidak hanya mempublikasikan hasilnya ke tim, saya akan menganalisisnya juga, menemukan kekusutan yang menyebabkan masalah dan solusi yang diusulkan dan perubahan arsitektur untuk mengatasi ini.

Sebagai seorang DevOps, saya akan mengotomatisasi sejumlah besar proses dan overhead. Saya akan meriset teknologi dan alat yang akan membuat hidup lebih mudah di tim, seluruh tim, dari pengembang, penguji QA. Peran saya adalah untuk memahami prosesnya, ya; tetapi dengan menjaga mata saya tertuju pada tim (manusia yang sebenarnya) menggunakan (menderita melalui) proses itu saya bisa menyaringnya ke titik membuatnya benar-benar transparan sambil masih mendapatkan petak data yang berguna untuk mendapatkan pandangan objektif tentang itu "gambaran besar" yang sulit dipahami.

Ini adalah posisi yang tidak tahu berterima kasih untuk dimiliki dan kemungkinan besar mengapa hal itu dijauhi begitu banyak. Saya tahu saya melakukan pekerjaan saya dengan baik ketika tidak ada yang memperhatikan proses itu, ketika tidak ada yang memikirkan pipa penyusunnya. Jadi ya, mesin yang diminyaki dengan baik cepat diterima begitu saja. Tetapi saya tahu, pada kenyataannya saya mengukur, dampak multiplikasi dari pekerjaan ini terhadap produktivitas tim dan layak investasi.

Jadi ya, saya pikir peran itu masih sangat hidup sampai hari ini, meskipun diakui itu memang berevolusi dari apa yang dulu.