Bir Scrum Master’ın yazılım geliştirme hakkında herhangi bir şey bilmesi gerekir mi?
Günaydın.
Duyuru
(Resim:
)
Stefan Mintert, yazılım geliştirmede şirket kültürünü geliştirmek için müşterileriyle birlikte çalışıyor. Şu anda liderlikte en büyük potansiyeli görüyor; hiyerarşik seviyeden bağımsız olarak Bazı yön değişiklikleriyle bir kariyer yolunun ardından bu potansiyelden yararlanmayı kendine görev edindi. Birkaç yıllık danışmanlık deneyimine sahip bir BT geçmişinden gelen, başlangıçta kendi yazılım geliştirme şirketini kurdu. Liderliğin öğrenilmesi gerektiğini ve iyi rol modellerinin nadir olduğunu buldu. Müşterilerinin yazılım geliştirmede en büyük desteğe ihtiyacının kod üretiminde değil liderlik olduğu ortaya çıktı. Dolayısıyla Kutura şirketinin nereye doğru gittiği onun için açıktı: ürünleri geliştiren insanların gelişip büyüyebilmesi için liderliği geliştirmek. Stefan, 1994’ten bu yana iX’te uzun süredir serbest çalışan olarak Haberler için yazıyor.
Bugün bu sorunun cevabını bulmaya çalışıyorum. “Bir Scrum Master’ın yazılım geliştirme hakkında herhangi bir şey bilmesi gerekiyor mu?”
Soru sorulduğunda cevabım: Hayır. Ancak öncelikle, onun bu konuda bir şeyler bilmesi sorun yaratmaz ve ikincisi, bu sizin yazılım geliştirmeyi ne olarak düşündüğünüze bağlıdır. Bunu bir örnekle açıklayacağım.
Başarılı ekip işbirliği için iç iletişim şarttır. Yani bir Scrum Master iletişime dikkat ettiğinde ve gerekiyorsa takımla birlikte bunun üzerinde çalıştığında iyi bir iş çıkarmış olur. Bu ifadenin her okuyucunun kabul edebileceği kadar genel olduğunu varsayıyorum.
İlginç olan, bir yazılım ekibinde iletişimin nerede gerçekleştiği sorusudur. Önemsiz cevaplar arasında Günlük Scrum, İnceleme, Retrospektif, İyileştirme vb. toplantılar bulunur.
Peki ya çekme istekleri?
Çekme istekleri ekip iletişiminin önemli bir parçasıdır. Toplantılarda barışçıl ve uysal davranan, ancak çekme taleplerinde gerçek savaşlar veren ekiplerle çalıştım; tek yumruk ve bıçak yarası. “İyi” programcılara karşı “kötü” programcılar. Ders kitabını suçlama ve parmakla işaret etme. “Mükemmel”den daha azı kabul edilmedi. (Mükemmeliyetçiliğin şaşırtıcı derecede çok sayıda cehenneme giden yollardan biri olduğu gerçeği başka bir blog yazısının konusu.) Çekme istekleri bazen haftalarca sürüyordu.
Sonuç? Ekip üyeleri susturuldu ve artık bağımsız hareket edemiyorlardı. Artık üretken çalışmaya değil, kendilerini korumaya odaklandılar. Taahhütleri planlamak mı? Son derece nadirdi.
Bunun Scrum Master’la ne alakası var?
Eğer Scrum Master, şeytanın kutsal sudan kaçındığı gibi yazılım kaynak kodundan da kaçınması gerektiğine inanıyorsa, takım iletişiminin bu kısmını kaçırıyor demektir. Çekme isteğinin biraz daha korunaklı alanında (konuşmak yerine yazmak, senkronize yerine asenkron, yüz yüze değil) birini küçümsemek grup toplantılarına göre daha kolay olduğundan, bu olumsuz davranış uzun süre boyunca gelişebilir. küller. zaman. Alevler göründüğünde artık (çok) geç olmuştur ve kulübe tam anlamıyla yanmaktadır; ve Scrum Master şaşırır.
Bir yazılım ekibiyle çalışırken ara sıra bazı çekme isteklerine de bakıyorum. Yakın zamanda bunu bir müşterim için yapmak istedim ve buna erişimimin olmamasına şaşırdım. Kullanılan sistemde sadece sınırlı sayıda lisans mevcuttu ve Scrum Master için herhangi bir lisans satın alınmamıştı. Çok kısa bir düşünce.
Geliştirici olarak ne yapabilirim?
Çözümlerden biri basit: Scrum Master’ı (bazı) çekme isteklerine davet edin. Lisans ücretlerinden korkan bir şirkette çalışıyorsanız parayı harcamayı taahhüt etmelisiniz. Hangisi işe yararsa: Çekme isteklerini eş programlamada olduğu gibi Scrum Master ile birlikte işleyin.
MERHABA. Stephen
(kendim)
Haberin Sonu