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


164

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?

12
Saya akan mengatakan ini hanya bisa membawa jawaban berdasarkan pendapat. Pendapat saya adalah bahwa tidak ada "insinyur perangkat lunak" yang ingin dilihat sebagai peran "pendukung". Mereka ingin dilihat sama dengan semua orang di tim. Ini mungkin terkait dengan fakta, bahwa sebagian besar pengembang perangkat lunak sangat muda. Sebagian besar tim tidak memiliki siapa pun yang bisa mengklaim senioritas dan dianggap sebagai "ahli bedah" tim.
Euforia

43
Masalah potensial yang saya lihat ketika Anda dengan sengaja mencoba mengatur tim dengan cara itu adalah mengidentifikasi dengan benar siapa yang harus menjadi ahli bedah.
Bart van Ingen Schenau

9
@ Euphoric Jangan lupa beberapa manajer yang menipu diri mereka sendiri dengan berpikir bahwa mereka sudah memiliki programmer super-uber-guru-bintang-ahli bedah, jadi mengapa mempekerjakan semua petani pendukung di tempat pertama? Saya telah melihat bagian mgrs saya yang tidak menunjukkan bukti untuk memahami pengembangan perangkat lunak dan tantangan yang melekat saat "mengelola" tim perangkat lunak, atau banyak hal di luar spreadsheet excel mereka yang berwarna-warni, sayangnya (biasanya, meskipun tidak selalu, orang yang dekat dengan masa pensiun ).
code_dredd

7
Mungkin ada hubungannya dengan fakta bahwa "operasi" adalah salah satu cabang kedokteran yang paling terbelakang - memang, itu adalah lelucon terkenal di Inggris bahwa ahli bedah menghabiskan 7 tahun belajar sehingga mereka dapat disebut "dokter", dan kemudian 7 tahun lagi sehingga mereka bisa dipanggil "Tuan" atau "Nyonya" lagi! Faktanya menata ulang operasi untuk meningkatkan kinerjanya dengan mengikuti "praktik terbaik" dari industri lain dengan tingkat kesalahan yang jauh lebih rendah, dll (khususnya, penerbangan sipil) adalah upaya berkelanjutan dalam profesi medis. ...
alephzero

6
@alephzero: Itu adalah beberapa klaim lucu. Di mana tepatnya Anda melakukan operasi? Di sini, jumlah sampah yang Anda sebut "praktik terbaik" mengambil bagian utama dari waktu dokter bedah, dan itu menghasilkan manfaat nol. Orang super pintar [ironis] berusaha sangat keras untuk memperbaiki sesuatu yang tidak mereka pahami dengan menambahkan lebih banyak omong kosong birokrasi ke dalamnya hampir setiap minggu. Namun, penyebab tingkat kegagalan yang Anda sebutkan tidak diatasi. Hampir semua kegagalan adalah karena kurang tidur, kurang pendidikan, dan perkiraan berlebihan. Seringkali mereka bertiga bersama.
Damon

Jawaban:


103

"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 ...: -}


20
Jika ada orang yang membaca ini memiliki edisi Hari Jadi ke-20 buku itu, ada baiknya membaca kata pengantar baru dan bab baru 19. Sementara bahkan edisi ulang tahun ke-20 lebih dari 20 tahun pada 2017, penulis menunjukkan beberapa pernyataan di jawaban ini yang sering diabaikan dalam kesibukan meringkas seluruh buku sebagai "menambahkan insinyur ke proyek yang sudah terlambat membuatnya semakin terlambat."

1
Apa arti "UUGE"? Omong-omong, jawaban yang bagus.
Wayne Conrad

5
@WayneConrad untuk bahasa besar .
zzzzBov

1
Setelah menjadi programmer sistem IBM selama periode itu, adalah hal yang umum untuk memiliki peran yang sangat erat dalam tim, dengan spesialisasi di bagian tertentu dari OS. Orang di masing-masing peran itu diharapkan untuk mengetahui atau mempelajari segala sesuatu yang perlu diketahui tentangnya, dan bertindak sebagai staf pendukung bagi salah satu pakar lainnya. Kami pada dasarnya berakhir dengan tim bedah per anggota staf, masing-masing dengan spesialisasi mereka sendiri.
Joe McMahon

1
Menanggapi komentar Anda tentang membuat kesalahan yang sama berulang-ulang, artikel Wikipedia untuk buku ini memiliki kutipan dari penulis yang mungkin Anda sukai: Kecenderungan bagi para manajer untuk mengulangi kesalahan semacam itu dalam pengembangan proyek membuat Brooks menyindir bahwa bukunya disebut sebagai bukunya. "The Bible of Software Engineering", karena "semua orang mengutipnya, beberapa orang membacanya, dan beberapa orang mengikutinya".
Ryan

87

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.


1
Mengenai paragraf kedua hingga terakhir, saya pikir ahli bedah diharapkan bekerja dengan pena dan kertas dan petugas akan menjadi satu anggota tim dengan akses ke komputer.
Bart van Ingen Schenau

15
'Dapatkah Anda benar-benar membayangkan membayar karyawan penuh waktu untuk mencetak kode sumber, dan secara manual mengindeks dan mengarsipkannya?' Tidak, tapi saya pasti bisa membayangkan membayar karyawan penuh waktu untuk mengelola kontrol versi dan sistem pembangunan berkelanjutan, dan pada kenyataannya di perusahaan menengah atau lebih besar ini adalah norma. Bahkan, mengelola wiki, sistem manajemen dokumen dan semacamnya adalah peran yang sepenuhnya terpisah, bahkan lebih besar yang biasanya ada sepanjang waktu penulis teknis dibayar untuk melakukan penuh waktu.
Miles Rout

9
"seluruh tim akan memiliki satu komputer untuk diri mereka sendiri ... adalah sebuah peregangan" - pada awal 1980-an organisasi akan memiliki sistem berbasis komputer mini + terminal, jadi sementara itu adalah komputer yang sama, pengguna masih akan memiliki akses ke sana secara setara dasar dan kemampuan untuk menjalankan program mereka sendiri (dengan asumsi isolasi dan keamanan pengguna yang layak ada).
Dai

2
Meskipun komputer mahal pada tahun 1975, penekanan tombol cukup murah. Ketika saya pertama kali memprogram mainframe (bukan di 75, tapi 77) kami akan menulis kode di atas kertas, memasukkannya ke kartu, mengirimkannya ke gawang dan kemudian memeriksa kembali secara berkala untuk melihat apakah hasil cetakan telah dikirim kembali. (Waktu putar bisa 2 jam bagi kami dan di beberapa situs lebih dari satu hari.) Seorang pegawai akan sangat berguna untuk semua kecuali yang pertama dari tugas-tugas ini. Saya tidak melihat terminal sampai 1979 atau lebih.
Theodore Norvell

1
Re: Smalltalk - tidak hanya setiap pengembang dan setiap pengguna seharusnya memiliki komputer mereka sendiri, komputer-komputer itu juga dianggap sebagai komputer yang kuat dengan banyak memori dan GUI . Pikirkan "workstation" daripada "PC". IBM PC asli tidak memiliki tenaga kuda untuk menjalankan Smalltalk. Sayang sekali, menurut saya ...
Bob Jarvis

20

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.")


5
Saya kalah karena klaim yang absurd mengenai kenaikan biaya tenaga kerja. Tenaga kerja, bahkan pengetahuan teknik khusus, lebih murah saat ini daripada pada tahun 1969. Memang biaya tenaga kerja yang lebih mahal saat ini menopang seluruh jawaban ini dan itu adalah klaim yang salah.
RibaldEddie

2
@RibaldEddie sehubungan dengan apa? Jika Anda membandingkan tenaga kerja dengan biaya hidup, itu telah menurun; satu jam kerja bisa memberi Anda lebih banyak makanan / perumahan daripada yang bisa terjadi pada 1969
k_g

3
@ k_g baik itu tergantung pada lokasi. Dalam hal inflasi, di sebagian besar tempat di AS, Anda dapat menyewa pengembang dengan harga lebih murah dalam dolar yang disesuaikan dengan inflasi hari ini dibandingkan pada tahun 1969. Sebagai referensi, dalam buku ini Brooks menyarankan 20k untuk apa yang hari ini kami anggap sebagai arsitek pengembang senior dan 10k untuk menjalankan programer pabrik yang melakukan sebagian besar pekerjaan. Dalam dolar hari ini, 10k itu sekitar 65k. Hari ini memiliki sebagian besar devs di tim Anda menghasilkan 65k adalah harga yang sangat bagus.
RibaldEddie

3
Ini, pada dasarnya, gaji perangkat lunak tidak berubah dari tahun 1969. Mengingat inflasi secara keseluruhan dan biaya hidup yang lebih tinggi, pengembang secara signifikan lebih murah hari ini.
RibaldEddie

11
Memang semua manfaat dari lingkungan ekonomi modern dalam hal produktivitas dan tenaga kerja yang lebih murah semuanya beralih ke kelas eksekutif dan pemegang saham dalam bisnis. Seperti yang saya katakan, bahkan disesuaikan dengan inflasi, gaji pengembang perangkat lunak tetap sama sementara kompensasi eksekutif telah meningkat ratusan kali lebih tinggi daripada inflasi. Selain itu, banyak tempat, terutama di sepanjang pantai barat Amerika Utara, biaya hidup telah meningkat secara signifikan lebih cepat daripada inflasi (lihat real estat) dan gaji pengembang profesional hampir tidak mengimbangi inflasi.
RibaldEddie

13

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


Kutipan itu pada dasarnya adalah apa yang saya pikirkan: Kedengarannya seperti pemrograman berpasangan, di mana "ahli bedah" adalah apa yang kami sebut "driver", kecuali pada skala yang berbeda.
Izkata

7
Menurut saya ini membutuhkan pengembang perangkat lunak kompeten yang berorientasi pada orang. Semoga beruntung dengan itu.
Bob Jarvis

Datang ke sini untuk mengatakan ini; atau berbagai bentuk organisasi mandiri tim.
Marcin

2
@ BobJarvis saya tidak setuju. Saya telah sukses besar bekerja dalam tim introvert (dan saya pikir beberapa juga termasuk ekstrovert). Kuncinya adalah menciptakan ruang di mana orang merasa aman dan terbuka untuk berkontribusi, dan bersedia meregangkan kecenderungan alami mereka untuk sementara waktu demi kepentingan kelompok. Susan Cain's Quiet sangat membantu dalam memahami bagaimana bekerja dengan baik dengan temperamen yang berbeda: ted.com/talks/susan_cain_the_power_of_introverts
David Carboni

12

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.


9

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.


1
jadi pada dasarnya, tidak ada yang terjadi padanya. +
Gordy

1
@ sangat ya dan tidak. Anda akan memperhatikan bahwa dalam contoh Brook, kemungkinan besar tergantung pada manajer untuk menentukan siapa yang berada di setiap peran dalam tim, tetapi dalam konsep lincah modern, tim itu mengatur diri sendiri. Jadi peran ahli bedah atau co-pilot jatuh secara alami dari cara tim bekerja. Saya pikir itu perbedaan utama: mengatur diri sendiri vs didikte perusahaan.
RibaldEddie

Saya akan mengubah "sebagian besar" menjadi "sebagian". Itu sangat tergantung pada dinamika tim. Dan itu pasti harus tumbuh secara organik jika seorang ahli bedah didikte dari atas hasilnya akan kurang optimal sehingga +1 untuk terorganisir sendiri.
Peter

2
Ucapan dari The Tao of Software: #IV - The Tao of Teamwork: Perangkat lunak yang baik ditulis oleh tim kecil yang bekerja dengan cepat. Perangkat lunak yang buruk ditulis oleh tim besar yang bekerja lambat. Konsekuensi: - Ukuran optimal tim adalah 1; - Nilai praktis maksimum untuk ukuran tim adalah 3; - Untuk ukuran tim> 3, (mis) komunikasi menjadi masalah serius; - Untuk ukuran tim> 6, penyelesaian proyek menjadi sangat terganggu. Penyelesaian proyek pada tenggat waktu mungkin di luar jendela. Dalam kasus seperti ini, pengembang yang lebih pintar akan menggunakan pintu ... Demikianlah tertulis ... ( BWOOoooonnnggggg !!! )
Bob Jarvis

6

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.


9
Bagian yang membuat saya tersenyum (?) Adalah hal "... beberapa manajer ...". Satu manajer lebih dari cukup untuk mengurangi produktivitas. Beberapa manajer dapat mendorong pengembang untuk memikirkan bunuh diri (introvert) atau pembunuhan (ekstrovert).
Bob Jarvis

4
@ BobJvis - Saya sudah, tergantung pada proyek, sebanyak lima "manajer" simultan dengan berbagai judul. Efeknya cukup banyak seperti yang Anda bayangkan.
Rob Crawford

1
Jelas Anda seorang ekstrovert. Jadi ... pertahanan gila? Meksiko? Atau ... pembunuhan yang adil ..? :-)
Bob Jarvis

Jadi itu sebabnya saya punya lima bos di satu perusahaan. Sementara saya ada di sana, masalah apa pun, apakah itu milik saya atau milik orang lain, saya akan mendengarnya dari 5 perspektif berbeda. Saya biasanya menganalisanya dengan waktu nomor 2 datang dan itu hanya menjengkelkan untuk mendengarnya di sana lebih sering.
Robert Baron

Gagasan asli bukanlah "memiliki lima manajer berbeda yang mencoba untuk mengganggu" tetapi memberikan, misalnya, "orang yang mendapat manfaat SDM" dan "orang yang mengembangkan karier SDM" dll. Saya pikir banyak manajer akan bekerja jika Anda menagih masing-masing departemen manajer berdasarkan seberapa sering mereka menghubungi insinyur. Akan membuat gim video yang menyenangkan!
Charles Merriam

2

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

1

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.


0

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).


2
Itu jelas bukan model DevOps.
RibaldEddie

5
Sebenarnya DevOps lebih mirip model tim bedah karena Operasi Pengembang menyiratkan bahwa operasi ada dalam layanan untuk pengembangan. DevOps adalah tentang dua konsep inti: bahwa operasi harus dilihat sebagai praktik pengembangan dan oleh karena itu alat dan teknik yang digunakan dalam pengembangan, seperti kontrol sumber dan metode manajemen tangkas, harus digunakan oleh operasi dan bahwa operasi ada untuk mendukung pengembangan.
RibaldEddie

1
@RibaldEddie Menarik. Pengalaman saya dengan grup DevOps di perusahaan saya adalah bahwa mereka hanya merekrut pengembang dan mereka bertanggung jawab atas segalanya mulai dari pengembangan produk, pengujian, dokumentasi, penyebaran, dll. Kata "lintas fungsional" muncul di benak saya. Oh well, dengan 2 downvotes dan penghapusan suara dalam 15 menit, saya kira saya akan menjauh dari situs ini.
Mike Ounsworth

1
Ah, maka kita memiliki definisi berbeda "lintas fungsional". Saya menggunakannya untuk berarti bahwa setiap anggota tim mampu melakukan setiap tugas - Jiras secara rutin dilemparkan di antara orang-orang karena mereka telah menghilangkan spesialisasi. Seseorang yang mengembangkan fitur ini akan menguji atau mendokumentasikan fitur selanjutnya. Itulah "DevOps" yang saya alami.
Mike Ounsworth

1
@MikeOunsworth: itu adalah tim lintas fungsi :-D
Jörg W Mittag

0

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.

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.