Adam Smith vs. pengembang fullstack - dan produktivitas di DevOps?

Oleh Adam Smith, pembagian kerja dapat membuat Anda 240 kali lebih efektif (misalnya, pabrik pin yang memproduksi pin dalam 18 langkah).

Lalu mengapa peran multi-ketrampilan begitu diminati jika ini benar-benar mengurangi produktivitas - atau apakah Smith salah, lalu mengapa?

Pencarian untuk "pengembang fullstack" masih tren di Google, namun tampaknya lebih lambat dari dua tahun yang lalu:

=====

Singkatnya, pengembang tumpukan penuh akan dapat melakukan hampir semua rantai nilai (perbaiki saya jika saya salah):

• Diskusikan dengan pelanggan dan sempurnakan persyaratan lincah yang bisa diterapkan untuk bagian pekerjaannya
• Tentukan arsitektur, perkakas dan komponen mana yang diambil - cukup beri dia buku catatan
• Tulis kode untuk frontend, backend, ingration, yang kompatibel lintas perangkat dan tidak memerlukan banyak pengujian, atau memasukkannya
• Profil dan data scape, gunakan Cloud AI / ML APIs untuk fitur-fitur canggih
• Menulis kode dan rollout IaC diperlukan
• Jadilah panggilan jika terjadi kesalahan atau proses penjualan
• Waspadai keamanan desain yang relevan, penambalan keseluruhan, migrasi dan modernisasi
• Akun tabel waktu dengan cara scroutinized untuk memudahkan faktur majikan
• ... apakah saya lupa sesuatu?

UPD - " kita memerlukan produktivitas spesialisasi tetapi kami tidak ingin pandangan dunia yang picik tentang" pembagian kerja yang ekstrem "(DevOps Guys, " DevOps, Adam Smith dan legenda Generalis " , 2013-2016)

Ada dua jenis pekerjaan:

1. Eksploitasi - Pekerjaan yang terdefinisi dengan baik yang dapat dengan mudah dibagi menjadi tahap-tahap yang terdefinisi dengan baik, di mana setiap tahap dapat dipelajari dan dikuasai sendiri dan penyerahan antar tahap tidak memerlukan komunikasi.

2. Eksplorasi - Pekerjaan tidak terdefinisi, yang membutuhkan pembelajaran dan eksperimen untuk menyelesaikan setiap tahap dan penyerahan antar tahap membutuhkan komunikasi yang sangat besar dari semua pembelajaran dan status proyek.

Adam Smith prihatin sepenuhnya dengan eksploitasi dan tidak sama sekali dengan eksplorasi. Pekerjaan yang dilakukan di departemen Penelitian & Pengembangan industri menurut definisi sebagian besar eksplorasi dan sehingga tidak tercakup dalam cara apa pun oleh Adam Smith.

Tetapi kita telah melihat bahwa pada tahap peningkatan berkesinambungan selanjutnya, yang sebagian merupakan pekerjaan eksploitatif, penerapan CI / CD dapat membawa keuntungan serupa dalam produktivitas, yang dalam beberapa cara mungkin dapat ditelusuri ke Adam Smith oleh seseorang yang sangat imajinatif.

Adam Smith tidak perlu mempertimbangkan untuk meneruskan informasi dari satu tahap ke tahap lainnya. Ini adalah bagian penting dari setiap proyek TI yang signifikan. Jadi pengembang fullstack memiliki keuntungan signifikan yaitu:

• mereka tidak perlu berbicara dengan siapa pun di departemen lain untuk menyelesaikan sesuatu
• mereka tidak harus menunggu orang-orang lain untuk melakukannya
• ada sedikit kemungkinan bahwa sesuatu akan hilang dalam terjemahan antara satu layer dengan yang lainnya

Untuk lebih lanjut tentang pentingnya menyampaikan informasi dalam proyek-proyek TI, lihat Bulan Man Mythical Fred Brook .

IMHO jawabannya ada banyak hubungannya dengan skala dan ketersediaan sumber daya.

Saya percaya teori Adam Smith hanya dapat diterapkan pada skala besar - seluruh negara / ekonomi dalam konteks asli, atau, dalam konteks pengembangan SW - tim pengembangan besar.

Dalam tim besar, memang, lebih efisien untuk mempekerjakan sumber daya manusia yang lebih khusus:

• mereka bukan bintang rock - sering dianggap sebagai tanda bahaya dalam organisasi besar seperti itu
• mereka biasanya lebih mudah ditemukan, lebih murah daripada mereka yang memiliki spektrum keahlian yang lebih luas
• mereka biasanya tidak meningkatkan risiko gesekan - misalnya mereka tidak akan bahagia karena mereka hanya menggunakan sebagian keterampilan mereka.
• dalam perbandingan (mungkin aneh) perbandingan prinsip "ternak vs hewan peliharaan" dapat diterapkan dalam organisasi yang lebih besar, dan untuk alasan yang hampir sama. Sumber daya khusus ini, dari perspektif bisnis, secara harfiah hanya kapita dalam kumpulan sumber daya manusia, yang ukurannya dapat dengan cepat disesuaikan sesuai kebutuhan, biasanya dengan mempekerjakan / memecat.

Oh, dan tim semacam itu hanya dapat berfungsi jika dilengkapi dengan sumber daya arsitek berkualitas tinggi yang akan diperlukan untuk membagi produk menjadi tugas-tugas khusus yang lebih kecil yang dapat diatasi dengan sumber daya khusus.

Dalam skala yang lebih kecil atau bahkan tim satu orang (biasanya startup atau bahkan tim kecil yang terisolasi di organisasi yang lebih besar) tidak efektif atau bahkan tidak mungkin untuk menggunakan sumber daya seperti itu dan masih menyelesaikan pekerjaan:

• mereka tidak memiliki anggaran / sumber daya untuk menyewa banyak sumber daya khusus yang berbeda yang diperlukan untuk menutupi seluruh pengembangan produk
• mereka benar-benar mencari / menghargai rockstars yang dapat memakai banyak topi dan segera berganti peran dengan fleksibilitas tinggi, tanpa menimbulkan penundaan dan biaya SDM tambahan

Saya menganggap diri saya sebagai pengembang fullstack berdasarkan kombinasi tanggung jawab berikut:

Pemrograman ujung depan dan ujung belakang

Saya dapat melakukan perubahan UI sampai batas tertentu: menulis html, css (sebagai pengembang web) dan di sisi lain beberapa memperluas memberikan data ke UI dari database, menyediakannya dalam layanan dll.

Saya meninggalkan pengujian, arsitektur, dan yang lainnya, bertemu dengan pelanggan dapat ditambahkan ke deskripsi kerja.

Seberang

Kebalikan dari sudut pandang saya adalah peran ketat dari pengguna UI dan pengguna akhir.

Kesimpulan

Saya tidak melihat tumpukan penuh benar-benar penuh seperti yang Anda sebutkan, lebih seperti ekspresi mewah seperti lincah atau awan yang dalam kondisi tertentu hanya perlu disebutkan untuk menarik perhatian orang dan implementasi nyata mungkin sangat bervariasi. Setidaknya tentang scrum dan gesit, saya telah melihat begitu banyak variasi sehingga istilah-istilahnya sudah habis artinya.

Singkatnya, saya tidak berpikir Adam Smith salah, tetapi saya pikir ada beberapa perbedaan serius antara model pembagian kerja di bidang manufaktur dan silo dalam pengembangan perangkat lunak.

Pertama, contoh pabrik pin (sejauh yang saya tahu) hanyalah hipotetis; walaupun sebagian besar pabrik manufaktur modern dapat melacak akarnya hingga ke pembagian kerja ini, saya tidak mengetahui adanya studi yang benar-benar menguji hipotesis ini secara ilmiah.

Kedua, Smith terutama berkaitan dengan pembuatan barang-barang material; ada keluaran nyata tertentu yang terkait dengan produksi material yang tidak memiliki analog serupa dalam pengembangan perangkat lunak. Misalnya, dalam pembuatan pin, dimensi fisik penting sebagai persyaratan fungsional; tidak ada perbandingan yang jelas untuk itu dalam perangkat lunak. Ini penting karena objek berwujud dapat direplikasi melalui pengulangan yang tepat; pengembangan perangkat lunak tidak pernah menjadi masalah yang sama dua kali. Pengembang mengembangkan metode umum untuk menghasilkan hasil yang dapat diprediksi, tetapi Anda tidak pernah membuat kode masalah yang sama dua kali. Setiap komponen yang dikembangkan dalam tumpukan memiliki seluk-beluk tidak seperti komponen fisik, dan seluk-beluk tersebut memiliki interaksi di luar pengukuran nyata (tinggi, berat, panjang, dll.). Pin pointer tidak peduli bagaimana pemotong kawat bekerja, selama kawat akan dipotong sesuai dengan spesifikasi. Dalam pengembangan perangkat lunak,batas-batasnya tidak pernah begitu jelas .

Pengembang stack penuh tidak diharapkan untuk melakukan semua pekerjaan itu sendiri (mereka tidak dimaksudkan untuk menjadi pembuat pin tunggal), tetapi mereka diharapkan mampu memahami semua elemen stack dan bagaimana elemen-elemen tersebut berinteraksi. Tim tumpukan penuh harus terdiri dari individu - individu berbentuk T yang berspesialisasi dalam satu atau lebih area, tetapi memahami spektrumnya (dan mungkin dapat melangkah di tingkat tertentu).

Di mana saya pikir pekerjaan Smith berlaku dalam pengembangan perangkat lunak adalah di bidang switching konteks (atau multitasking ); jika satu pengembang bertanggung jawab untuk semua bidang pengembangan, perlu waktu untuk beralih dari tanggung jawab ke tanggung jawab. Pada skala, kolaborasi antara anggota tim dengan pengalaman berbeda dalam tim produk yang sama dapat menyeimbangkan pengalihan konteks dan interaksi yang kompleks.

Poin penting untuk dipahami adalah bahwa pembagian kerja tidak selalu berarti orang yang berbeda per langkah.

Saya akan mengambil sejarah saya sendiri di pabrik mobil, saya berada di rantai perakitan kursi, untuk mendapatkan kursi penuh dengan airbag, kulit, sandaran kepala dll. Rantai itu terbagi dalam 9 tahap. Kami 9 sedang mengerjakan rantai. Setiap orang hanya melakukan satu tahap pada satu waktu, tetapi setiap jam kami bergeser ke tahap berikutnya untuk menghindari terlalu banyak pengulangan. Hari kerja panjangnya 8 jam jadi kami tidak naik di setiap panggung setiap hari.

Ini persis merupakan pembagian kerja di mana Anda hanya melakukan satu langkah perakitan pada waktu tertentu, yang tidak menghalangi Anda untuk dapat melakukan perakitan penuh.

Seperti yang telah dinyatakan dalam jawaban lain ini sedikit berbeda dari pengembangan perangkat lunak, tetapi saya pikir ini menjelaskan mengapa pengembang Full Stack tidak saling eksklusif dengan divisi tenaga kerja, seseorang dengan kemampuan untuk menangani seluruh siklus hidup suatu aplikasi tidak diminta untuk melakukannya sepanjang waktu.

Secara umum ketika saya mendengar pengembang FullStack, saya pikir lebih dari seseorang yang dapat membuat kode back-end yang efisien dan UI yang bagus pada saat yang sama, berlawanan dengan Front dan Back Dev.