Fred Brooks'un “Cerrahi Ekibi” otobüs faktörünü etkin bir şekilde ele alıyor mu?

4 deneyimli geliştiriciden oluşan ekibim büyük, modüler bir Windows uygulaması (yaklaşık 200 KLoC) üzerinde çalışıyor. Projenin başlangıcından bu yana çekirdek kod tabanına odaklandım (3 yıl önce) ve takım yöneticisi olmasam da yavaş yavaş yarı lider geliştirici pozisyonuna geçtim.

Mevcut yinelememiz, üst yönetim tarafından talep edilen ve çekirdek kod tabanında yaklaşık 15 değişiklik içeren yüksek öncelikli bir kullanıcı arayüzü yenilemesidir. Yönetici tarafından sorulduğunda, 15 değişikliğin her birinin tamamlamamın dört saatten az , toplamda 7 iş gününden az süreceğini tahmin ettim . Daha sonra işi yapmak için gönüllü oldum. Bunun yerine, yönetici 15 görevi de dört geliştiriciye eşit olarak bölmeye karar verdi.

Çalışmaya başladığımızdan bu yana üç gün içinde iki şey gözlemledim:

1. Diğer deneyimsiz ekip üyeleri her biri yaklaşık 1 veya daha az görev tamamladı.

2. Brook Yasası yürürlükte: Zamanımın yaklaşık yarısını yardım sağlayarak harcadım (bileşenleri kullanma konusunda onlara koçluk yapmaya çalışarak). Sonuç olarak, beklenen 5 veya 6 yerine sadece 2 görevi kendim bitirdim.

Geç kaldığımız endişesiyle yöneticime yaklaştım ve yine kalan görevleri tamamlamamı önerdim. İsteğim nazikçe reddedildi ve yükü eşit olarak bölmenin belirtilen nedenleri iki yönlü oldu:

1. Kamyon / otobüs faktörünü sınırlayın - diğer geliştiricileri bu becerilerle şimdi artırın, böylece gelecekte sadece bana değil herkese herhangi bir iş verilebilir.
2. Bir "darboğaz" (ben) ortadan kaldırmak ve daha hızlı iş yapmak.

Açık olmak gerekirse, aşağıdakilerle ilgili hiçbir sorunum yok: a) zaman öğretimine yatırım yapmak, b) koduma dokunan insanlar veya c) iş güvenliği. Aslında, ekip liderine düzenli olarak riski azaltmak için çekirdek kod tabanının belirli yönleri hakkında diğer geliştiricileri eğitmemi öneririm.

Bu yinelemede ayrıca, yüksek öncelikli hata düzeltmeleri için geniş bir koleksiyonumuz var, bu nedenle iş yükü yeniden dağıtıldıysa daha fazla ilerleme kaydedilebilir gibi görünüyor.

Mythical-Man-Month'da Brooks ' her ekibin bir lider + alt lider (yönetici ve ben) ve bazı küçük rollerden oluştuğu bir " Cerrahi Ekip " önerir . Sanırım bu organizasyona doğal olarak düşüyoruz, ama yöneticim buna karşı çalışıyor. Otobüs faktörünün halihazırda halledildiğini hissediyorum (yönetici çekirdek kodda ustalaşmış) ve darboğaz aslında mevcut değil (daha fazla dev içeren iş daha hızlı gitmeyecek). Bence bu konuda bir Cerrahi Ekip İyi Bir Şeydir.

Bunlar benim duygularım, ama ben deneyimli bir yönetici değilim, ne de otobüs faktörü (ahşap vurmak) ile uğraşmak zorunda kaldım. Brooks haklı mıydı? Otobüs faktörünün devreye girdiği bir "Cerrahi Ekip" te çalıştınız mı? Dağıtım uzmanlığını yönetmek için daha iyi teknikler var mı?

Benzer sorular:

• Otobüs faktörü nasıl artırılır ve aynı zamanda uzmanlaşılır?
• /software/103718/always-keeping-2-people-expert-on-any-one-chunk-of-code

Aslında, "cerrahi ekip" modelini takip ettiğinizi iddia ediyorum. Şanslı!

Söz konusu modelin amacının bir kısmı, alt ekip üyelerinin yardımcı rol oynamasıdır. Ekip kalp ameliyatı yapmıyorsa, daha yavaş hareket etmek ve onlara bazı becerilerini uygulama veya sorumluluklarda çapraz eğitim yapma şansı vermek iyidir.

Zayıf noktaları arayarak ve çözerek ve en iyi geliştirici olarak ekibini incelemek ve yönetmek cerrahın görevidir. Cerrah olmayan bir kişinin (işletme yöneticisi) bunu yapamazsınız, çünkü gerekli becerileri anlamıyorlar, usta bir zanaatkar için bir çırak gibi.

Bu nedenle, yönetici, diğer amaçlarından biri üzerinde çalışmak için bu fırsattan yararlanıyor. Süre boyunca, takımda bir miktar kusur ortaya çıkarsa, bir sorun haline gelmeden önce onunla başa çıkabilir. Diyelim ki başka bir geliştirici kiralayarak.

Ya da gençler bir hata yapabilir. Bu, onların omzunun üzerinden izleyen biri olduğu için bunu yapmaları için mükemmel bir zamandır. Oscar Wilde dedi

Deneyim sadece hatalarımızı verdiğimiz isimdir.

Bu gençler bir fırsat var asla varsa için hata yapmak, o zaman onlar geliştirmek asla. Sadece deneyimli gelecekteki geliştiriciler ekibinizi soymakla kalmaz, bir anlamda, sahip olmaları gereken bir fırsattan da çıkarır.

Şirketimiz eskisi gibi çalışıyordu. Kodun kritik bir bölümünü anlayan sadece iki kişi vardı. Kodun bu bölümünde bir görev ortaya çıktığında, bir başkasını hızlandırmak için birkaç hafta harcamak yerine, görev onlara atanır çünkü birkaç gün içinde tamamlayabilirler. Bu aslında bir süre gayet iyi çalıştı.

Nihayetinde plakaları o kadar dolu hale geldi ki, bir görevi 2 gün içinde bitirebilseler bile, listelerinin en üstüne gitmek haftalar alacaktı. Yöneticilerin görevi daha acil olan sözlü savaşları olacaktır. Acil bağımlı görevler geri alınacaktır.

Sonunda yöneticiler beklemekten bıktı ve kendi takımlarını eğitmeye başladı. Evet, bir süre çok daha yavaştı, ama şimdi verimimiz çok daha iyi.

Şimdi ilk aşamada olabilirsiniz, ancak işin üstesinden gelebilirsiniz, ancak ikinci aşamaya ne zaman geçeceğinizi tahmin edemezsiniz. İşte bir ipucu: her zaman mümkün olan en rahatsız edici zamanda gerçekleşir. Yöneticiniz hala nefes alanınız varken vuruşu yapmakta haklı.

Evet, birisinin kendinizle çok daha hızlı ve kolay bir şekilde yapabileceğiniz bir şeyle mücadele etmesini izlemek sinir bozucudur. İki yaşında bir çocuğa ebeveynlik yapmayı deneyin. Bunu yaparsınız çünkü tüm ekibin gelişmesine yardımcı olur. Program hakkında endişelenmek yöneticinizin işi. Geri alınan yüksek öncelikli hatalardan endişe ediyorsanız, bunları ne kadar hızlı düzeltebileceğinizi görmek için kendinize sorun.

Şimdi bir darboğaz olmayabilir, ama sonunda tüm işi kendiniz yapmaya devam ederseniz olacaksınız. Yöneticiniz, projenizin geç kalma riskini devretmeyi öğrenmeniz için yeterince önemli olduğunun farkındadır - ona güvenin. Bırakmayı öğrendikten sonra, gençleriniz öğrenmeye ve çok daha fazlasını rehberliğiniz altında üretmeye başlayacaklar.

Mevcut olmayan veya düşündüğünüz derece için önemli olabilecek bir kısıtlama uyguluyorsunuz. Özellikle, tamamlanana kadar geçen süre konusunda endişelisiniz. Öte yandan, yöneticiniz algılanan zaman kısıtlamaları ile ilgili olarak görünmüyor.

Teslim süresini sorunuzdan çıkarırsanız, soruyu neden ilk başta sorduğunuzu merak etmeye başlayacaksınız.

Bu, zamanın her zaman kullanılabilir olduğu anlamına gelmez ve bunun üst yönetimden gelen yüksek öncelikli bir istek olduğunu belirttiniz. Ama patronunuzun onlarla yaptığı tüm konuşmalara özel değilsiniz. Ekibin diğer üyelerini eğitmek için daha fazla zaman müzakere etmiş olabilir.

Otobüs faktörünü hissetmek ederken zaten patronun hattı iniyor sonraki isteğine arıyor olabilir, ele olmuştur olmaz kolayca onun yıldız geliştiricilerinden biri tarafından çalışma 7 gün sığacak. Ekibi, nesnel risk büyüklüğünün çok daha küçük olduğu daha küçük bir yineleme konusunda eğitmek çok daha güvenlidir.

Daha önce kritik bir darboğazım vardı; ve dürüst olmak gerekirse, bu hoş bir yer değil. Benim durumumda, BT Başkan Yardımcısı ve ben konuştuk ve sorunu kalıcı olarak düzeltmek için bir plan hazırladık. Canını yaktı, ama kamyonumdan çok daha az acı verdi.

Mümkün olan en kısa sürede nakledilmesi gereken her şeyin zihniyetine girmek kolaydır. İyi bir yönetici, daha sonra küçük bir gecikmenin (çapraz eğitim / eğitim için) önemli temettüler ödeyebileceği nadir fırsatları tespit eder.