Adam Smith fullstack geliştiricileri ve DevOps'ta verimlilik mi?

Adam Smith tarafından, iş bölümü sizi 240 kat daha etkili hale getirebilir (örneğin 18 adımda iğne üreten bir pim fabrikası).

Öyleyse, eğer bu gerçekten verimliliği düşürüyorsa neden çok yetenekli roller bu kadar talep görüyor - ya da Smith yanlıştı, neden?

Google'da "fullstack geliştirici" aramaları hala Google'da eğilim gösteriyor, ancak görünüşe göre iki yıldan daha yavaş:

=====

Özetle, tam bir yığın geliştirici neredeyse tüm değer zincirini yapabilecektir (eğer yanlışsam beni düzelt):

• Müşterilerle tartışın ve işin bir parçası için uygulanabilir çevik gereksinimleri geliştirin
• Hangi mimarinin, araçların ve bileşenlerin alındığına karar verin - ona bir not defteri verin
• Cihazlar arası uyumlu olan ve fazla test gerektirmeyen veya içeren ön uç, arka uç, entegrasyon için kod yazma
• Profil ve scape verileri, gelişmiş özellikler için Cloud AI / ML API'lerini kullanın
• Gerekli IaC kodunu ve sunumunu yazın
• Hata veya satış süreçleri durumunda çağrıda bulunun
• Güvenlikle ilgili tasarım, genel yama, geçiş ve modernizasyonun farkında olun
• İşveren faturasını kolaylaştırmak için hesap zaman tablosunu programlanmış bir şekilde
• ... bir şey unuttum mu?

UPD - " uzmanlığın verimliliğine ihtiyacımız var, ancak“ aşırı işbölümü ”nin insüler dünya görüşünü istemiyoruz . (DevOps Guys, " DevOps, Adam Smith ve Generalist efsanesi " , 2013-2016)

İki tür çalışma vardır:

1. Sömürü - İyi tanımlanmış aşamalara kolayca ayrılabilen iyi tanımlanmış işler, her aşama kendi başına öğrenilebilir ve yönetilebilir ve aşamalar arasında geçiş iletişim gerektirmez.

2. Keşif - Her aşamayı gerçekleştirmek ve aşamalar arasında geçiş yapmak için öğrenme ve deneme gerektiren tanımlanmamış çalışmalar, tüm öğrenme ve projenin statüsü için büyük miktarda iletişim gerektirir.

Adam Smith kendini tamamen sömürü ile ilgilendirir, hiç keşifle değil. Endüstrinin Araştırma ve Geliştirme departmanlarında yapılan çalışma , tanımı gereği çoğunlukla keşiftir ve bu nedenle Adam Smith tarafından hiçbir şekilde ele alınmamaktadır.

Ancak, kısmen sömürücü bir çalışma olan daha sonraki sürekli iyileştirme aşamalarında, CI / CD uygulamasının üretkenlikte benzer kazanımlar getirebileceğini gördük, bu da muhtemelen bir şekilde çok yaratıcı bir kişi tarafından Adam Smith'e kadar izlenebilir.

Adam Smith'in bilgilerin bir aşamadan diğerine aktarılmasını düşünmesine gerek yoktu. Bu, herhangi bir önemli BT projesinin kritik bir parçasıdır. Yani bir fullstack geliştiricisinin önemli avantajları vardır:

• işleri yapmak için başka bir departmandaki hiç kimseyle konuşmak zorunda değiller
• diğer insanların etrafta dolaşmasını beklemek zorunda değiller
• bir katman ile başka bir katman arasındaki çeviride bir şeyin kaybolması ihtimali daha azdır

BT projelerinde geçen bilgilerin önemi hakkında daha fazla bilgi için Fred Brook'un Efsanevi Adam Ayına bakınız .

IMHO cevabının ölçek ve kaynak kullanılabilirliği ile çok ilgisi var.

Adam Smith'in teorisinin yalnızca büyük çapta - orijinal bağlamda tüm uluslar / ekonomiler veya SW kalkınma bağlamında - büyük kalkınma ekipleri içinde uygulanabileceğine inanıyorum.

Büyük bir ekipte, daha uzmanlaşmış insan kaynakları kiralamak gerçekten daha verimlidir:

• rock yıldızı değiller - bu tür büyük organizasyonlarda genellikle bir tehlike işareti olarak kabul edilirler
• genellikle daha kolay bulunurlar, daha geniş uzmanlık spektrumuna sahip olanlardan daha ucuzdur
• genellikle yıpranma riskini arttırmazlar - örneğin mutsuz olmazlar çünkü sadece yeteneklerinin bir alt kümesini kullanırlar.
• (belki garip) bir devopsi karşılaştırmasında, "büyükbaş hayvanlara karşı" ilkesi, daha büyük organizasyonlarda ve benzer nedenlerle uygulanabilir. Bu özel kaynaklar, iş açısından bakıldığında, kelimenin tam anlamıyla insan kaynakları havuzlarında sadece kişi başıdır;

Oh, ve bu tür ekipler, ancak ürünü özel kaynaklarla ele alınabilecek daha küçük, özel görevlerde bölmek için gerekli olacak yüksek kaliteli mimar kaynakları ile tamamlandıklarında işlevsel olabilirler.

Daha küçük ölçekli ve hatta tek kişilik ekiplerde (genellikle büyük organizasyonlardaki yeni başlayanlar ve hatta izole küçük ekipler) bu tür kaynakları kullanmak etkisiz veya hatta imkansızdır:

• tüm ürün geliştirmeyi kapsayacak birçok farklı özel kaynağı işe alacak bütçe / kaynaklara sahip değiller.
• aslında birden fazla şapka giyebilen ve gecikmeleri ve ek İK maliyetleri ödemeden hemen büyük esneklikle rol değiştirebilen rock yıldızlarını arar / takdir ederler.

Kendimi aşağıdaki sorumlulukların birleşimi temelinde tam bir geliştirici olarak görüyorum:

Ön uç ve arka uç programlama

Bir dereceye kadar UI değişiklikleri yapabilirim: html, css (bir web geliştiricisi olarak) yazın ve diğer yandan veritabanından UI'ye veri sağlayın, bir hizmette vb.

Testten, mimariden ayrılıyorum ve buluşanlar müşteriye çalışma tanımına eklenebilir.

Karşısında

Benim görüşümün tam tersi, UI ve arka uç adamların katı rolleri olurdu.

Sonuçlar

Tam yığını daha önce bahsettiğiniz kadar dolu görmüyorum, daha çok çevik veya bulut gibi süslü bir ifade gibi, belirli durumlarda insanların dikkatini çekmek için bahsedilmesi gerekiyor ve gerçek uygulama büyük ölçüde değişebilir. En azından scrum ve çevik hakkında, terimlerin anlamsız kaldığı birçok varyasyon gördüm.

Kısacası, Adam Smith'in yanlış olduğunu düşünmüyorum, ancak imalattaki iş bölümü modeli ile yazılım geliştirmedeki silolar arasında ciddi farklılıklar olduğunu düşünüyorum.

İlk olarak, pim fabrikası örneği (bildiğim kadarıyla) sadece varsayımsaldı; Modern imalat fabrikalarının çoğu köklerini bu işbölümüne kadar takip edebilse de, bu hipotezi bilimsel olarak gerçekten test eden herhangi bir çalışmanın farkında değilim.

İkincisi, Smith öncelikle maddi mal üretimi ile ilgiliydi; yazılım geliştirmede benzer analoglara sahip olmayan, malzeme üretimi ile ilişkili belirli somut çıktılar vardır. Örneğin, pim yapımında, fiziksel boyutlar fonksiyonel bir gereklilik olarak önemlidir; yazılımda bununla açık bir karşılaştırma yoktur. Bu önemlidir çünkü somut nesneler tam tekrarlama ile çoğaltılabilir; yazılım geliştirme asla iki kez aynı problem değildir. Geliştiriciler öngörülebilir sonuçlar üretmek için ortak yöntemler geliştirir, ancak aynı sorunu asla iki kez kodlamazsınız. Yığında geliştirilen herhangi bir bileşenin fiziksel bileşenlerin aksine karmaşıklıkları vardır ve bu karmaşıklıkların somut ölçümün ötesinde etkileşimleri vardır (boy, ağırlık, uzunluk, vb.). Bir iğne işaretçisi tel kesicinin nasıl çalıştığını umursamıyor, tel spesifikasyonlarına göre kesildiği sürece. Yazılım geliştirmede,sınırlar asla bu kadar net değildir .

Tam yığın geliştiricilerin tüm işleri kendileri yapmaları beklenmez (tek bir pin yapıcı olmaları amaçlanmaz), ancak yığının tüm öğelerini ve bu öğelerin nasıl etkileştiğini anlayabilmeleri beklenir. Tam bir yığın takımı , bir veya daha fazla alanda uzmanlaşan, ancak spektrumu anlayan (ve bir düzeyde adım atabilecek) T şeklindeki bireylerden oluşmalıdır .

Smith'in yazılım geliştirme alanındaki çalışmalarının geçerli olduğunu düşündüğüm yerde bağlam değiştirme (veya çoklu görev ) alanında; tüm geliştirme alanlarından tek bir geliştirici sorumluysa, sorumluluktan sorumluluğa geçmek zaman alır. Ölçekte, aynı ürün ekibinde farklı deneyimlere sahip ekip üyeleri arasındaki işbirliği, bağlam değiştirme ve karmaşık etkileşimleri dengeleyebilir.

Anlaşılması gereken önemli bir nokta, işbölümünün her adımda her zaman farklı bir kişi olmadığı anlamına gelir.

Bir araba fabrikasında kendi tarihimi alırdım, koltuk montaj zincirindeydim, hava yastığı, deri, baş desteği vb.İle tam bir koltuk almak için zincir 9 aşamada bölündü. 9 zincir üzerinde çalışıyorduk. Her insan bir seferde sadece bir aşama yapıyordu, ama her saat çok fazla tekrardan kaçınmak için bir sonraki aşamaya geçiyorduk. İş günü 8 saat uzunluğundaydı, bu yüzden her gün her sahneye çıkamadık.

Bu, belirli bir zamanda montajın yalnızca bir adımını gerçekleştirdiğiniz, tam montajı yapmanıza engel olmayan bir iş bölümüdür.

Diğer cevaplarda belirtildiği gibi, bu yazılım geliştirmeden biraz farklıdır, ancak bunun bir Full Stack geliştiricisinin neden işbölümü ile karşılıklı olarak özel olmadığına ışık tuttuğunu düşünüyorum, bir uygulamanın tüm yaşam döngüsünü idare etme yetenekleri olan biri her zaman yapmak için gerekli.

Genel olarak FullStack geliştiricisini duyduğumda, ön ve arka geliştirmeye karşı etkili arka uçları ve güzel kullanıcı arayüzünü aynı anda kodlayabilen birinin daha fazla olduğunu düşünüyorum.