“Kalite kültü” nasıl yaratılır [kapalı]


21

DeMarco ve Lister (Peopleware), programlama ekibinizde bir "kalite kültü" oluşturmanızı önerir. Sinir bozucu bir şekilde, bunu nasıl yapacağınızı önermiyorlar!

Bunu nasıl başaracağına dair bir fikri olan var mı?


1
“Kalite kültünüz” ancak zamanın elverdiği kadar etkili olacaktır. Patron 'Cumaya kadar yapılması gerekiyor' dediğinde , hız için kaliteyi düşürmek zorunda kalırsınız. Açıkçası bu kodlayıcıların tercih ettiği şey değil. İdeal olarak kaliteyi sağlamak için zamanı tercih ederiz!
ters

1
@WesleyWerner: İyi nokta. Ancak, bir “kalite kültünün”, teknik borçla ilgilenmeyi de gerektirmesi gerektiğini düşünüyorum;
talonx,

@invert: Genellikle bu gibi durumlarda cevaplar, burada CAP teoremine benzer bir durum var. Kalitemiz, hızımız ve insan gücümüz var ve ikisini seçebilir.
JensG

Yanıtlar:


37

Tecrübelerim, geliştirme ekiplerinin (ancak genel olarak herhangi bir ekibin) 3 tip insandan oluşmasıdır:

  • kalite için dahili bir sürücü olanlar,
  • Sadece para için para harcayanlar (bira / kız / ne olursa olsun) ve daha az umursayamazlarsa da, onları motive etmeye çalışırsanız,
  • "vasat" olanlar (daha iyi bir kelime eksikliği için).

Son grup en büyüğü ve iktidar partisini takip etmeye meyilli. Takımda yeterli kalitede insanlar varsa, takım ruhunda ve motivasyonunda güçlü bir sarmal oluşturarak çoğunluğu kendileri ile çekebilirler. Bununla birlikte, eğer çok fazla gevşetici varsa, kolayca zıt etki yaratabilir, ölümün bir spirali.

Bu nedenle yöneticinin en önemli görevi , doğru insanları seçmek ve tutmak ve en kısa zamanda kötü olanlardan kurtulmaktır . Yine de "vasat" olanları değil - gelişmeye başlayacaklarından, başkalarının iyi fikirlerine destek verebileceklerinden etkilenebilirler ve hatta bazıları kendi başlarına bile olumlu trend belirleyicileri haline gelebilir.

[Güncelleme2] Alb'ün cevabını yansıtıyor : IMO, kalite geliştiricilerin ekip içinde açıkça çoğunlukta olmalarına gerek yok (ancak, zarar vermemiş olmasına rağmen :-). Yukarıda bir alt grubun görüş ve davranışlarının bir topluluk içinde hızlı bir şekilde "ana akım" haline gelebileceği bir "trend belirleme eşiği" vardır , bu nedenle diğer insanlar fark eder ve takip etmeye başlar. Bunu çalışmada her zaman daha geniş toplumda görebilirsiniz (örn. (Sigara içmeyen alışkanlıklar, sağlık ve diyetler, pop oyunları, organik yiyecekler). Benim çok kaba tahminim% 25-30 civarında bir yerde olabileceği, ancak birçok faktöre bağlı olduğu yönünde. Burası kötü insanların çok fazla acı çekebileceği yer. Takımınızdaki birkaç kötü insan bile bu eşiği önemli ölçüde artırabilir. [/ Update2]

Tabii ki her zaman en iyi adamları işe almak mümkün değildir. Dolayısıyla, ilk hizip işleri kendi başlarına yürütecek kadar güçlü olmadığında, yönetimin onlara yardım etmesi gerekir. Bu konuda birkaç düşünce:

  • Scrum'un ürün tanıtımlarında bunun için iyi bir fikri olduğunu düşünüyorum. Yalnızca takım arkadaşlarınızdan değil, diğer takımlardan geliştiriciler, yönetim, hatta uygulama kullanıcıları bile içeren bir kitlenin önünde uyguladığınız özelliği göstermek, büyük bir gurur kaynağı ve aynı zamanda ekibin jöle edilmesine yardımcı olacak güçlü bir faktör olabilir.

  • Bir başka şey ise, yönetimin kaliteyle ilgili geliştirici ekibi ciddi şekilde dinlemesidir. DeMarco ve Lister, dev ekiplerin üretime geçebilecekleri hakkında veto hakkı olan şirketler / bölümler olduğunu bile belirtiyorlar. Uygulamanın henüz asıl süreye hazır olmadığını düşünüyorsanız, yönetimin ne istediğinden bağımsız olarak sürümü erteleyebilirler. Şimdi bu yönetim için zor, ama takım ruhunu geliştirdiğini ve sadece kelimelerin düzeyinde değil, kalitenin gerçekten önemli olduğu mesajını güçlü bir şekilde aktardığını hayal edebiliyorum.

  • Bu, bir sonraki noktaya yol açar: "kalite kültü" oluşturmak için yönetim, en deneyimli geliştiricilerin zaten bildiklerini tam olarak anlamalıdır: bu kalite bir düşünce değildir - en baştan ürüne dahil edilmelidir. Bu yüzden insanlar , hızlı çözümler yerine , iyi çözümler için çaba göstererek uzun vadeli sürdürülebilirlik hakkında düşünmeye (ve ödüllendirilmesine!) Teşvik edilmelidir .

Güncelleştirme

Yorumunda @Machado soruyu yeni bir şekilde değiştirdi (en azından bana):

Takım üyesi olarak, yönetici değil, ekibimin kod kalitesini yükseltmek için neler yapabilirim?

Birkaç düşünce:

  • Öğrenmeye devam edin ve bilgileri dinleyen herkese yayın. Uzmanlık alanlarınızdaki en iyi uygulamaları öğrenin ve kullanın .
  • İşinle gurur duy .
  • Bu ikisi neredeyse doğal olarak diğerleri için olumlu bir rol modeli olmanıza izin verecektir - özellikle de yeni gelenler ve gençler; Bunun hakkında bilinçli olun ve tüm ekibin yararına olan rolünüzden yararlanın. Başkalarını etkilemenin en iyi yolu, olumlu örneklerdir.
  • Yalnızca koda değil, yazılım geliştirme sürecine de bakın; geliştirme sürecini optimize etmek için sorular sormaya ve geri bildirim sunmaya devam edin .

Ve son fakat en az olmayan: "En iyi erkek" olabileceğin bir yer bul . Şu anda "vasat" gruptaysanız, kendinizi geliştirmek için çabalayın - umarım yukarıdaki fikirler bu konuda yardımcı olur. Ancak eğer şu anki takımınızdaki "alt tabaka" daysanız, nedenlerini analiz etmenizi öneririm. Seni sinirlendiren nedir? Kötü çalışma şartları? Takım arkadaşları? Yönetim? Bir tür iş? Peki sizi heyecanlandıran ve ilgilendiren şey nedir? Bu konuda iş arkadaşlarınızla ve / veya patronunuzla konuşmanız gerekebilir. Veya ışıldamaya başlayabileceğiniz daha iyi bir iş - hatta yeni bir meslek - aramanız gerekebilir. Tatmin edici veya moral bozucu bir faaliyetle hayatının önemli bir bölümünü harcamaya değmez.

Ayrıca, dış etkenler (daha iyi iş fırsatlarının olmayışı, faturaları ödemeniz vb.) Nedeniyle mevcut, asgari işinizi sürdürmek zorunda kalırsınız - her zaman ve sonra olur. Bu durumda bile, bundan en iyi şekilde yararlanmaya çalışın. Kaliteli iş üretmek (şartların elverdiği kadarıyla), kendinize olan saygınızı yüksek tutmaya ve uzun vadede aklı başında tutmaya yardımcı olan, kendi başına bir ödüldür. Böylece daha iyi bir şey için bir fırsat ortaya çıktığında, onu almaya daha iyi hazır olursunuz.


4
Tehlikeli bir tavsiye. OP 2. / 3. gruba aitse? ;)

1
Harika cevap, hiç böyle düşünmemiştim, ama çok mantıklı.
Alb

9
@Gelişmiş olsaydı DeMarco ve Lister'i okumazlardı ya da soruyu burada soruyorlardı.
Alb

Sorunun ekip üyesi açısından daha yönlendirici olduğunu düşündüm. Eğer yönetim gerçekten kalite istiyorsa, üst düzey / temel geliştiricilerini dinleyeceklerdir. Takım üyesi olarak, yönetici değil, ekibimin kod kalitesini yükseltmek için neler yapabilirim?
Machado

1
@ Thorbjørn, mükemmel bir soru! Şimdiye kadar iş yerlerimin çoğunda bunu kaçırdığımı itiraf ediyorum. Kendini çok fazla rahatsız eden bir ses çıkarmamayı umarak, her zaman arayacak ve onlardan bir şeyler alacak takım arkadaşları arıyordum, ama nadiren buldum. Ben de kitaplara ve internete döndüm. Mümkün olduğunca, Martin Fowler'ta Bob Amca Martin ve ark. Ve son zamanlarda SO toplumunda! Öğrenmek için müthiş bir yer. Ayrıca güçlü bir "gerçeklik kontrolü sağlayıcısı". Birisinin bilgisinde sınırları ve boşlukları açığa çıkaran alçakgönüllü deneyimlerin alınması zor olabilir, ama benim için çok sağlıklı.
Péter Török,

2

Péter Török'in büyük cevabı , bunu yalnızca iyi insanların çoğunluğuyla yapacağınızı vurgulamak için. İyi insanlara sahip olduğunuzda, çubuk yerine havuç yaklaşımını hedeflemeniz gerekir. Geliştiricileri güçlendirin, projelere / görevlere sahip olmalarını ve kalite açısından rekabeti teşvik etmelerini sağlayın, belki de insanların projelerde kaliteyi nasıl geliştirdikleri hakkında kısa sunumlar yapmalarını sağlayın. İyi geliştiriciler, meslektaşlarını etkilemek için motive olacaktır.


+1 Motivasyon hakkında iyi noktalar. Çoğunlukla ilgili anlaşılır derecede yanlış anlaşılıyordum; Açıklığa kavuşturmak için cevabımı güncelledim.
Péter Török,

2

Peter'ın yorumlarına ek olarak (gerçekten asıl mesele olan), kalitenin daha sonra eklenen bir özellik olmadığından emin olmanız gerekir.

Daha spesifik olarak:

  • 'Daha sonra temizleyeceğiz' düşüncesiyle ilgili izleri kaldırın. Bunun yerine, çabalarını doğru şekilde yapmak için başlangıçta çaba sarfediyoruz.
  • Değişikliklerin geliştiriciden başka birisini içeren bir çeşit QA işlemi aracılığıyla incelenmesini ve çalışılmasını gerektirir.
  • Projelerin erken aşamalarında kalite ile ilgili düşünceleri zorlayın. Geliştirme sırasında "Bu işin başkaları için ne kadar kolay olabileceği" gibi şeyler odaklanın.
  • Meydana gelen hataları takip et ve rapor et. Trendler varsa, böceklerin kök nedenleriyle mücadele etmenin yollarına bakın.
  • Yazılım düşüncesini geliştirilebilecek bir zanaat ve yaratıcıların gurur duyabileceği bir şey olarak tanıtın.

1

En iyi yolun kaliteyi üretime teşvik etmek olduğunu söyleyebilirim. Bu, Yalın Yazılım hareketinin öncüllerinden biridir (Yalın Üretime dayanarak). Ne tartışırken uzun blog yazısı yazdım Yalın tüm hakkında . Size nasıl bir kalite kültürü yaratacağınızı söyleyeceğim. Çalışanlarınıza yatırım yapın ve şirketinize yatırım yapmalarını sağlayın (parasal yatırım değil, kişisel bir yatırım).

Dan Pink , TED'de bizi motive eden şey hakkında harika bir konuşma yaptı . Özel olarak referans göstermese de. Maslow'un İhtiyaçlar Hiyerarşisi gözlemlenen fenomeni mükemmel bir şekilde açıklıyor. İşveren ilk iki ihtiyaca hitap ettiği sürece (yani paranın sorun olmaması için yeterli para ödeyin) geriye kalan tek şey Ait Olma, Saygı ve Kendini Gerçekleştirme'dir.

  • Ait olmak için sağlam bir topluluk sağlayın.
  • Çalışanın hata yapmaktan çekinmediği bir ortam sağlayın, böylelikle başarı yaptıklarında saygınlık kazanacaklar.
  • Geliştiricilerinize dizginleri verin, böylece kendilerini gerçekleştirme konusunda önemli kararlar alabilirler

Kalite, dikte edilebilecek bir şey değil ... etkindir. Çalışanlarınıza en iyisini yapın ve yoldan çekilin. Sonunda onlara gitmeleri gerektiğini söylemelisin. Onlardan daha fazla saat sürmelerini istemek yerine

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.