“Efsanevi Adam Ayı” ndaki “Ameliyat Ekibi” modeline ne oldu?

Yıllar önce, Efsanevi Adam-Ay'ı okuduğumda, diğer kaynaklardan zaten bildiğim birçok şey buldum. Ancak, kitabın 1975'ten kalma olmasına rağmen, orada da yeni şeyler vardı. Bunlardan biri:

Ameliyat Ekibi

Mills, büyük bir işin her bölümünün bir takımla mücadele edilmesini, ancak ekibin domuz-kasaplık ekibinden ziyade cerrahi bir ekip olarak organize edilmesini önerir. Yani, her üye sorunu ortadan kaldırmak yerine, biri kesim yapar, diğeri ise ona etkinliğini ve verimliliğini artıracak her türlü desteği verir.

Bu, bir yazılım geliştirme ekibini organize etmek için çok ilginç bir kalıptır, ancak hiçbir yerde bahsetmediğim hiçbir Yazılım Mühendisliği kitabında açıkladım.

Neden?

• "Ameliyat Ekibi" o zamanlar sıra dışı bile miydi?
• Veya, denendi ve başarısız oldu mu?
  • Eğer öyleyse, nasıl başarısız oldu?
  • Olmazsa, neden bugünün yazılım projelerinde bu modeli uygulamıyoruz?

"Efsanevi Adam Ayı", üniversiteye başladığım yıl çıktı ve şu anki yerel UUUGE! :-) Anlamanız gereken şey, yazılımın THEN ile NOW arasında nasıl geliştirildiğindeki fark. Geri Günde (tm) hemen hemen tüm kodlamalar ilk önce kağıda yapıldı, daha sonra delikli kartlara bastırıldı, sonra okundu, derlendi, bağlandı, yapıldı, sonuçlar alındı ​​ve süreç tekrarlandı. CPU zamanı pahalıydıve sınırlı kaynak ve onu israf etmek istemediniz. Aynen ve aynı şekilde disk alanı, teyp sürüş süresi vb. Bir derleme üzerinde mükemmel derecede CPU zamanını boşa harcayan (şok ve dehşet!) Hatalarla sonuçlanan ... iyi bir CPU zamanı kaybı. Ve bu 1975’te oldu. Fred Brooks’un fikirlerini geliştirdiği sırada, 1960’ların ortalarından sonundaki CPU zamanı daha da fazlaydı.pahalı, bellek / disk / hatta her ne ise DAHA sınırlıydı, vb. vb. Ameliyat Ekibinin arkasındaki fikir, Bir Süper Büyük Rockstar Geliştiricisinin, HIS zamanını masa kontrol kodu, anahtar teslimi kodlama gibi sıradan görevlerde harcamak zorunda kalmamasını sağlamaktı. işleri göndermek, sonuçlar için beklemek (bazen saatlerce). Rockstar Dude Geliştirici Adam YAZI KODU olacaktı. Onun leğen grupları / katip / genç geliştiricileri sıradan şeyler yapmak gerekiyordu.

Sorun, Brooks'un kitabının yayınlanmasından sonraki 2 yıl içinde, Cerrahi Ekip'in arkasındaki temel fikirlerin yıkılmasıydı:

1. CRT terminalleri ve disk dosyaları, anahtar delikleri ve kart destelerinin yerini almaya başladı. Bilgisayar süresi daha ucuz hale geldi, birden fazla bilgisayar kullanıldı ve işe dönüş süresi önemli ölçüde azaldı. Üniversiteye gittiğimde (Miami Üniversitesi, Oxford, Ohio, '79 sınıfı, sorduğun için teşekkürler) iyiiş geri dönüşü yaklaşık bir saat sürdü. Finaller haftasında - dört saat, belki, bazen altı. (Bir sürü ticari şirket ve üniversiteyle CPU zamanı için rekabet ettik - ve ticari kullanıcılar birinci önceliğe sahipti). Miami’nin “paylaşılan bilgisayar” düzenlemesinden çıkmış olduğu son sınıfımda kampüste kendi IBM 370/145’i kurdu ve ana bilgisayarı açabileceğimiz bir RJE istasyonu olarak çalıştığım güzel bir HP mini vardı. Beş dakika veya daha kısa sürede işlerde Kodunuzu HP'ye yerleştirmeniz, HP'den ana bilgisayara göndermeniz, parmaklarınızı sallamanız / bir sigara içmeniz ve kodunuzu kontrol etmeyi bitirmeden önce çıktınızı almanızın faydası oldu.

2. Cerrahi Ekip, temel öncül olarak sizin (veya "yönetim", tanrı hepimizin bize yardım ettiği) Rockstar Surgical Developer Dude'ı tanımlayabileceğiniz fikrine sahiptir. Aslında, bunun mümkün olduğundan şüpheliyim. Orada olan rockstar geliştiriciler, herkes bilir - çalışmalar kadar 2000 itibarıyla% iyi ve en kötü geliştiriciler arasında verimlilik farklılıkları göstermiştir - ama bu kişiyi tespit onları uzun bir süre boyunca kod yazmak zorunda kalmadanbüyük olasılıkla imkansızdır. Birisinin bir rock yıldızı geliştiricisi olup olmadığını öğrenmenin tek yolu, aslında kod geliştirmelerini sağlamaktır - ancak Rockstar Surgical Developer Dude değilse, kodunu masa başında kontrol etmek, kartlara kilitlemek gibi heyecan verici şeyler yapacaklar ve Delikli kartların kutularını İş Giriş departmanına doğru atarak, sonuçları beklemekten vazgeçerek, onları gerçekten çalışan tek yolu kodlamayı öğrenmek yerine Bay Rockstar Surgical Developer Dude'a geri koyabilirler - kod yazarak, kodları ayıklayarak, vb. Geri Gündüz (tm) hiçbir programlama yarışması yoktu, Yığın Taşması yoktu, dilediğiniz zaman kod yazabileceğiniz bir PC'niz yoktu, Aptal kitapları için Algoritmalar yoktu - programlama öğrenmenin tek yolu okula gitmek ve biraz programlama yapmanız gereken bir şeyde okumaktı. Ama programlamabaşlı başına ciddiye alınmadı ve insanların yapmak istemediği bir şey olduğu varsayıldı . İlk üniversite kursumda (SAN151 - Sistem Analizine Giriş, Dr. Tom Schaber - teşekkürler, Tom :-) bize eğitmen tarafından "... geçirmemiz gerektiği gerçeğiyle yüzleşmemiz gerektiği söylendi." Birkaç yıl önce programcı olarak sistem analisti olabilirdik ". "İki yıl mı?" Diye düşündüm. "SADECE İKİ YIL İÇİN BU ŞEYİ YAPABİLİR MİYİM?!?" Ben edildi ciddiye sinirlendirdi. Neyse ki yanılıyordu ve o zamandan beri kodlama yapıyorum. :-)

3. Cerrahi Ekip, programcıların nispeten nadir bir kaynak olduğunu varsayar. Aslında birkaç yıl daha sürdü, ancak 80'li yılların başlarında programlamanın başlamasıyla birlikte PC'lerin ortaya çıkması, herhangi bir geek'in katılabileceği bir şey haline geldi. Bilgisayarların fiyatı düşmeye başladı, geliştirme araçlarının fiyatı düşmeye başladı. Selam Turbo Pascal - bugünün standartlarına göre çok değildi ama o zamanlar kesinlikle fındık olan yaklaşık 40 dolar için tam bir Pascal IDE oldu! Şimdi HERHANGİ BİR HERHANGİ BİR Programlamaya girebilir - bir bilgisayarı karşılayabiliyorsanız ve IBM PCjr'yi koymaya karar verdiğinde (ilk bilgisayarım, bu türkiye’den kurtulmak için yaklaşık 500 $ karşılığında satışta olan IBM’in en büyük hatalarından biriydi. her yerde tıkanmış inek her ay ki kira ödemelerini atladı ("Evet, biliyorum, ama ben ... uuvulamı kırdım ve ameliyat olmak zorunda kaldım .. .uh ... evet, gelecek hafta, sorun yok, teşekkürler, dostum ...) ve onları ateş satış fiyatlarında emdi. Ardından, kullanılabilir hale getirmek için bilgisayara eklentiler için ödediğimizden daha fazla para harcadı. ("Evet, dostum, gelecek hafta, kesin, muhtemelen ..." :-).

Beni gerçekten üzen şey şu ki, bugün bile, insanlara "Efsanevi Adam Ayı" nı hiç okudular mı, yoksa temel dersini anladılar mı ("Geç bir projeye kaynak eklemek daha sonra yapar") sorarsanız, size boş bir yer verirler. bakıyorum - ve OS / 360'ın gelişimi sırasında Tüm Yıllar Önce yapılan hataların aynısını yapmaya devam edin. Eski her şey yine yeni ...: -}

Bu kavramın bazı yönleri vardır vardır bazen bugün uygulanan diğer yönleri vardır kaçınılmalıdır .

Ekipleri küçük tutmak, Çevik Yöntemlerin temel özelliklerinden biridir, ancak Çevik dışında da uygulanmaktadır.

Çapraz fonksiyonel ekipler aynı zamanda Çevik'in temel malzemesidir ancak Çevik dışında da ortaktır.

Program Görevlisinin rolü büyük ölçüde Versiyon Kontrol Sistemleri, Yazılım Konfigürasyon Yönetim Sistemleri, Değişim Yönetim Sistemleri, Doküman Yönetim Sistemleri, Viki, Artefakt Depolu Sürekli Yapı Sistemleri ve benzeri gibi bilgisayarlı sistemler tarafından üstlenilmiştir. Demek istediğim, kaynak kodu yazdırmak ve tam olarak indeksleyip dosyalamak için tam zamanlı bir çalışana ödeme yapmayı gerçekten hayal edebiliyor musunuz?

Benzer şekilde, bir Sistem Yöneticisinin rolü (Mills's Surgical Team’nin bir parçası değil, son yılların tipik bir çapraz işlevli ekibinin bir parçası) DevOps gibi kavramlar (Sysadmin’in Yazılım Mühendisi rolünü emmesi) gibi kavramlar tarafından engelleniyor. , Hizmet Olarak Platform, Hizmet Olarak Altyapı ve Yardımcı Programlama (Sysadmin'in “başkasının problemi” rolünü üstlenmesini) veya Kod Olarak Altyapısını (Sistem Yönetimini Yazılım Mühendisliğine çevirerek).

Bugün kaçınmaya çalıştığımız yönlerden biri , sistemi en çok iki kişinin anlamasıdır. Sadece cerrahın sistemi tam olarak anlaması garantilidir, yardımcı pilot olabilir veya olmayabilir. Bu, 1 ile 2 arasında bir otobüs faktörü verir . Cerrah hastalanırsa proje sona erer. Dönemi. Bunun Çevik cevabı , bu modelin tam tersi olan Kollektif Kod Mülkiyetidir : hiç kimse sistemin herhangi bir bölümünden tekil olarak sorumlu değildir . Bunun yerine, herkes bir grup olarak her şeyden sorumludur .

Son olarak, bu konsepte dahil edilmiş ve modası geçmiş bazı varsayımlar vardır. Örneğin, açıkça belirtilmediği halde, ekip, ekipteki tek bir kişinin (cerrahın) gerçekten bir bilgisayarı olduğu şekilde kurulur. Tabii ki, çünkü makale yazıldığı sırada, bir takımın kendi başına bir bilgisayarı olmasına rağmen, takımdaki bir kişinin bile uzaması gibiydi. (1980’de, Smalltalk’ın piyasaya sürüldüğü zaman bile, başarısızlığına katkıda bulunan şeylerden biri, sistemin her geliştiricinin ve her kullanıcının kendi bilgisayarına sahip olacak şekilde kurulmuş olmasıydı - o zamanlar tamamen düşünülemezdi.)

Yani, kısacası: anlatıldığı gibi sanmıyorum kavram tam olarak uygulamaya konmuştur, ama bunun bazı yönleri kesinlikle edilir uygulanan, bazı yönler istenmeyen olarak görülen ve aktif kaçınılır, bazı eski ve bazı ™ Muhtemelen İyi Fikirler vardır, ama kimse yapmaz.

Eskiden bir kolej eğitimi benzersiz bir şeydi ve mühendisler seçilen birkaç kişi arasındaydı. Bilgisayarlar pahalıydı ve ekipler tanımlanmış ticari yatırım getirisi olan projelerde çalıştılar. Bunlar çok yaygın değildi.

Olanlar, mikro bilgisayarlar, her yerde bulunan lisans eğitimi ve ilerlemek için Üniversite derecelerine bile ihtiyaç duymayan bilgisayar sistemleriydi. Ayrıca, olan şey ekonomiyi değiştirmek ve işgücü maliyetini arttırmaktı.

8: 2 desteğinin ekonomisi: mühendis oranı artık bir anlam ifade etmiyor. Mühendisler kendi destekleri olmalıdır. Bir geliştirme ekibine ekli olmak için yeterli eğitim ve beceriye sahip modern bir insan, bir tür kendi gelişimini yapmamak için çok pahalıdır.

(İlgili bir ekonomi terimi, "hizmet sektörünün maliyet hastalığıdır.")

Bu kalıplar bana Mob programlaması gibi ses çıkarıyor:

Tüm grup (KG, gerekirse geliştiriciler ve hatta Ürün Sahibi) aynı problemde aynı anda çalışıyor. Stand up, yüksek iletişim yok, doğrudan hayata geçiriliyor.

Gönderen http://codebetter.com/marcushammarberg/2013/08/06/mob-programming/

Mafya programlamanın temel konsepti basittir: takımın tamamı aynı anda bir görev üzerinde takım olarak çalışır. Yani: bir takım - bir (aktif) klavye - bir ekran (projektör elbette). Tam takım çifti programlama yapmak gibi.

Burada çalışırken görün: https://www.youtube.com/watch?v=dVqUcNKVbYg

Bu takım modeli 305. sayfada Steve McConnell tarafından Hızlı Geliştirme - Yabani Yazılım Programlarının Taminginde tekrar bahsedilmiştir. İşte Baş Programcı Ekibi.

Bu model ortaya çıktı çünkü takımda bir dahi vardı ve hesaplama kaynakları sınırlıydı. Bir şey nadir olduğu için lehine düştü ve her yerde bulunan bilgisayarlar ve dağıtılmış sürüm kontrolü ile ameliyat masasında birçok el için yerimiz var.

Diğer referanslar:

Baker, F. Terry. "Üretim Programcılığının Baş Programcı Ekibi Yönetimi", IBM Systems Journal, cilt. 11, hayır. 1, 1972, sayfa 56-73.

Baker, F. Terry ve Harlan D. Mills. "Baş Programcı Takımları." Datamation, Cilt 19, Sayı 12 (Aralık 1973), s. 58-61.

Tahminime göre, çoğu küçük kendini organize eden ekip, zaten fiili bir cerrahi ekip modeline razı olma eğiliminde olacak.

Bulunduğum son iki takım genellikle bir kıdemli (cerrah), bir ara pilot (yardımcı pilot) ve birkaç genç / uzmandan oluşan üç veya dört kişiden oluşuyor. Ameliyat ekibindeki rollerin bir kısmı Brooks tarafından bahsedildiği gibi bugünlerde Scrum ustaları ve sysadmins veya bulut sağlayıcıları tarafından doldurulur. O zamanlar kaynak kontrolünün zar zor var olduğunu, git kadar güçlü bir şeyi bıraktığını unutmayın.

Bezos'un iki pizza kuralını düşünün. İşte sizin kendi kendini organize eden cerrahi ekibiniz.

HP'den benzer bir şey öneren bir makale vardı:

• Her yazılım mühendisi birden fazla yöneticiye ve birden fazla destekçiye ihtiyaç duyacaktır.
• Her mühendis için teknik bir yazar, testçi, yapım yöneticisi ve araç üreticisi olmalıdır.

Bildiri web öncesi günlerde yapıldı ve zaman zaman komik geldi. Her yıl büyüdü, yorum biraz "çok komik, komik" den "belki de yapmalıyız" a taşındı.

Gerçek testlerin tasarlanması oldukça zordur, bu nedenle muhtemelen görüş kalır. Bazı araştırmalar ve tamamlanma oranları olabilir.

Ameliyat ekibine olan ihtiyacın ne kadarının internetin yükselmesi, entegre geliştirme ortamları ve Fred Brooks'un cerrahi ekibine atfettiği işlevsellikten büyük ölçüde faydalanabilecek yazılım geliştirme kitleri nedeniyle ne kadar gereksiz hale geldiğini merak ediyorum :

• Cerrah: bir programcı
• Yardımcı pilot: programcılar , çalışanlar, StackExchange veya IRC gibi çevrimiçi topluluklar
• Yönetici: genellikle bir yazılım proje yöneticisi tarafından üstlenilen rol
• Editör: Javadoc veya Doxygen gibi dokümantasyon-jeneratörlerini entegre eden IDE'ler; yazılım geliştirme kitlerinden dokümantasyon
• Sekreter: e-posta istemcisi, sorun izci ve çekme istekleri, şirket sohbet odaları ve posta listeleri gibi proje yönetimi araçları
• Program sorumlusu: IDE, yeniden düzenleme kodunu ekleyebilme özelliği ile proje tasarımı hakkında bilgi depolar; Yazılım geliştirme kitlerinden dokümantasyon ve örnekler
• Araçlar: tüm açık kaynak topluluğu
• Test cihazı: hemen, test süitlerini ve kütüphaneleri test etme. Fakat elbette, üretim kodu için ayrı bir KG süreci gereklidir.
• Dil avukatı: çevrimiçi belgeler, StackExchange

Efsanevi Adam Ayının öncüllerine bakman gerektiğini düşünüyorum. Daha fazla programcı işe almak, yalnızca sorunlu / gecikmiş bir yazılım projesinin daha da kötüleşmesine neden olur. Sorun iletişimde ve projeye hız kazandırmak için yeni programcıların eklenmesi (mevcut gelişmeden zaman alıyor), teknoloji ve bazen etki alanının kendisi.

İyi desteklenmiş bir programcı iletişim süresinin ve koordinasyonun çoğunu ortadan kaldırır. Diyelim ki Teknoloji X için bir danışman tutmalısınız. Bu danışmanı, bu kişinin bu alandaki tüm kodlamaları yapabileceği kadar projeyi hızlandırmak için hızlandırmak yerine, mevcut geliştiriciyi yapabileceği bir noktaya koyar. biraz nezaret ile.

Bunun çoğunu görmemenizin bir nedeni, çoğu yazılımın zaten bir kişi tarafından yazılmış olması. Takımlar işi böler ve herkes gider ve işini yapar. Çift programlama, gözden geçirme ve mikro yönetme kokan her şey kaşlarını çattı. Pek çoğu programlamayı takım sporu olarak görmüyor. Bir kişi, belli bir sorunu tüm genel kısıtlamaları dikkate alarak çözer.

Tasarım, uygulama, test, dokümantasyon, inşa, dağıtım, operasyonlar, vb. Uzmanların yaptıkları eşsiz rollere ayırdıkça, "cerrahi ekip" felsefesini daha fazla takip ettiğimizi (belki de tam olarak tanımlandığı şekilde olmasa da) savunuyorum. ).

Tecrübelerime göre, her insanın her görev için yapması gereken devOps felsefesi domuz kasaplığı modeline bir dönüşdür (kötü olduğunu söylememek, sadece farklıdır).

DevOps ve Build Master rollerini sık sık dolduran bir programcı olarak sık sık cerrahi ekip olma pozisyonunda olduğumu hissettim .. err ... takımdaki adam. Bir yapı ustası olarak kodun tamamına genel baktım ve başarısız olduğunda ilk satır oldu. Çoğu zaman sadece kendim tamir ederdim.
Ben genellikle bu metrik sistemlerini yazan ve koddaki açık noktaları, daha sık başarısız olan kısımları, en fazla hata raporunu alanları vb. Ölçenlerden biriydim. soruna neden olan ilginçlik ve buna yönelik çözümler ve mimari değişiklikler önerildi.

Bir DevOps olarak, çok büyük işlem alanlarını ve ek yükleri otomatikleştirirdim. Geliştiriciden QA test uzmanlarından BT ekibine kadar yönetime kadar tüm ekipte, tüm ekipte hayatı kolaylaştıracak teknolojileri ve araçları araştırırdım. Benim rolüm süreci anlamaktı; ama gözlerimi ekipte (gerçek insanlar) sabit tutarak (bu acıyı çekerek) bu işlemi kullanarak onu tamamen şeffaf hale getirme noktasına kadar damıtmayı başardım. hiç zor "büyük resim".

Neden bu kadar çok bıktığını ve büyük olasılıkla nankör bir pozisyon. İşimi iyi yaptığımı, hiç kimse bu işlemi farketmediğinde, hiç kimse inşaat boru hattı hakkında bir düşünce vermediğinde. Yani evet, iyi yağlanmış bir makine hızlı bir şekilde alınıyor. Fakat biliyordum ki, aslında bu çalışmanın bir ekibin üretkenliği üzerindeki çarpıcı etkisini ölçtüm ve yatırımın iyi olacağını biliyordum.

Yani evet, bugün rolün hala çok canlı olduğunu düşünüyorum, ama kuşkusuz o zamanlar ne olduğundan geldiğine rağmen.