Yazılım ekipleri için ana direktif ve bunların pratik sonuçları

Saberie

Active member
Günaydın.






Özellik Fabrikası Kaç: Stefan Minter



(Resim:

Stefan Minter

)))



Stefan Minter, yazılım geliştirmede kurum kültürünü geliştirmek için müşterileriyle birlikte çalışıyor. Liderlikte en büyük potansiyeli görür; Hiyerarşik bir seviyeden bağımsız olarak. Bazı kurs değişiklikleriyle profesyonel bir yoldan sonra bu potansiyeli kaldırma görevini verdi. Başlangıçta bilgi teknolojisinden gelen, birkaç yıllık danışmanlık deneyimi ile yazılım geliştirme şirketini kurdu. Liderliğin öğrenilmesi gerektiğini ve iyi rol modellerinin nadir olduğunu keşfetti. Yazılımın geliştirilmesinde müşterilerinden gelen maksimum destek ihtiyacının kod üretiminde değil, liderlikte olduğu açıktır. Dolayısıyla, Kutura şirketi ile yolculuğun nereye gittiği açıktı: ürün geliştiren insanların gelişebilmesi ve büyüyebilmesi için liderliği geliştirin. Haberler için Stefan, 1994'ten beri uzun süredir devam eden bir IX çalışanı olarak yazıyor.







2001 yılında Norman Kerth, “Project Retrospective” adlı kitabında retrospektifler için en iyi direktifi formüle etti:

“Ne keşfettiğimizden bağımsız olarak, o anda bilinen, becerileri, becerileri, mevcut kaynaklar ve eldeki durum göz önüne alındığında, yapacağı her işin yapacağı her işi anlamalıyız ve gerçekten inanmalıyız.”

“Ne keşfettiğimizden bağımsız olarak, herkesin bilgi, becerileri ve becerileri, mevcut kaynakları ve verilen durumları göz önüne alındığında herkesin en iyisini yaptığını anlamalıyız ve gerçekten inanmalıyız.”

En iyi direktif özellikle çevik yazılım geliştirme alanında bilinmektedir. Bu dikkat çekicidir, çünkü “Ague” veya “Scrum” kelimeleri Kerth'in kitabında gerçekleşmez.

Direktifi sık sık yeni bir ekiple yaptığım ilk retrospektife getirdim. Tepkiler takımlarda çok farklıydı. Zaten orada umutsuz bir şekilde homurdanmış biri vardı. Bu konuda sorulduğunda, bazen türün retorik bir sorusu var: “Ciddi değil misin, değil mi?” Açık bir bildirim yankılanır: Başka bir kişinin infaz edilmesi yeterli değildir.

Şu anda, başkalarının performansı üzerine bir tartışmaya katılmıyorum. Aksine, aşağıdaki soruları daha fazla zıt ifadeyle ele alıyorum:



  1. Söz konusu kişinin en iyi performanslarını sunduğunu ve sonuçtan memnun olmadığımı varsayalım. Benim için ne takip ediyorsun?
  2. Söz konusu kişinin en iyi performanslarını sunmadığını varsayalım. Nasıl yüzleşebilirim?
İkinci noktadan başlayalım: Birisi en iyi performansı gerçekleştirmez. Benim için nedenler neler?

Birincisi, meslektaşı hasta, kişisel sorunları var veya başka bir nedenden dolayı becerilerine göre çalışamıyor. “Sağlıklı” bir ekipte tepkim çok basit: Kişiye dönüyorum ve yardım sunabilirim.

İkincisi, meslektaş kasıtlı olarak kötü çalışıyor. Bunun için bir kelime var: sabotaj. Bu, yararlı disiplin tedbirlerini düşündüğüm son derece nadir durumlardan biridir.

Bununla ilk noktaya geri dönüyorum: En iyi performansınızı sunarsanız, bunun için eleştirilemezsiniz. Eleştiri neyden oluşmalıdır? Bir çocuk bisikletle gidemezse, şikayet edecek hiçbir şey yoktur. 95 yaşında bir kişi onu suçlamak isteyen bir maratonu yönetemezse (marjinal olarak: Yolu kaç tane yaratırlar?). Hasta olan veya özel sorunları olanlar yüzde 100 (teorik) karşılayamayacaklardır.



Bunun ekip sonucu üzerinde olumsuz bir etkisi varsa, tüm üyeleri bir arada kendisine karşı yapıcı bir şekilde hareket etme sorumluluğu ve yükümlülüğü olarak görüyorum. Bireysel insanlara karşı ev eleştirisi bunlardan biri değildir. Bunun yerine, aşağıdakileri makul bir kılavuz olarak görüyorum:

  • Sprint'in hedefi gibi hedeflenen bir hedefin bir geliştirici olarak tehlikede olduğunu bulduğumda, bunu fark ettiğim anda açıkça konuşuyorum.
  • Blam tahsislerinden kaçınıyorum (suçlama ve parmak puanları).
  • Örneğin, açığı tedavi etmek için tek başına becerilere sahip değilsem, bir bileşende bir programlama dilinde yazılan sorunlar olduğu için, her zaman yardımcı olur. Çiftlerin bir programlaması olabilir veya bir tartışma ortağı olarak mevcuttur.
Sonunda, her şey iki noktaya kadar uzanabilir. En iyi direktif ekipte işbirliğini takip eder:

  • Hatasız yapıyorum. Sorunun nedenlerini araştırmak, yeterli bir çözüm bulmak ve aynı tipte gelecekteki sorunlardan kaçınmak veya daha önce başa çıkabilmek için açıkça gereklidir.
  • Çözümler bulmak için yardım sunuyorum. Sorumluluk önemli değil. Bir ekip sonuçları ve hedefleri birlikte başardı veya kaçırdı.
Bir problemden sonra ya da oyunculuk kişiyi atayamadan ve bir suçlama veya parmak gibi anlayamadıktan sonra, takımların çoğu için zordur. Bu gibi durumlarda, ekibin en iyi direktifi hakkında açıkça konuşmaya yardımcı olur.

Önce oku, sonra dinle


Podcast kaçışında özellik fabrikasında, blogun seçilmiş konularını topluyorum ve (çoğunlukla) bir konukla konuşuyorum. Borsada ikinci bir bakış açısı biliyorum. En iyi direktif için iki podcast bölümüm var; İlk yazıda, başka bir yerde bir takımda engellendiğinde herkesin yalnız yapabileceğine gidiyorum; İkinci yazıda bir konukla üst direktifin derinliklerine gidiyorum. Ayrıca ilgileniyorsanız, Podcast'i Spotify, Deezer, Amazon Music, Apple Podcast ve Kutura.digital'de bulacaksınız. Blog konularına adanmış seminerler de vardır.


(RME)




Ne yazık ki, bu bağlantı artık geçerli değil.

Boşa harcanan eşyalara olan bağlantılar, 7 günlük daha büyükse veya çok sık çağrılmışsa gerçekleşmez.


Bu makaleyi okumak için bir Haberler+ paketine ihtiyacınız var. Şimdi yükümlülük olmadan bir hafta deneyin – yükümlülük olmadan!
 
Üst