Günaydın.
Duyuru
(Resim:
Stefan Mintert
)
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.
Geliştirme ekipleriyle yaptığım çalışmalarda Jira'nın amaçladığı şekilde çalıştığımızda çevik çalıştığımız görüşüne rastladım. Katılmıyorum. Bu bağlamda şu söz benim için geçerli: Elinde alet olan bir aptal yine de aptaldır.
Tek bir aracın bir takımı çevik hale getirebileceğini düşünmüyorum. Ancak araçların nasıl kullanıldığı ekibin çeviklik düzeyine dair ipuçları sağlayabilir. Bu aynı zamanda bir çevik koçun veya Scrum Master'ın sıklıkla dikkat etmediği araçlar için de geçerlidir; Bu özellikle teknik geçmişi olmayan Scrum Master'lar için geçerlidir. Böyle zamanlarda geliştiricilerin ekibin daha da gelişebilmesi için inisiyatif alması gerekir. Bununla ne demek istediğimi gerçek bir örnekle açıklayayım.
Birlikte çalıştığım bir takımda hedefe ulaşma ve sprint kararlılığı iyi değildi. Çoğu zaman takım sprint başında planladıklarını tamamlayamadı. Biletler bir sprintten diğerine taşındı. Döngü süresi yüksekti. Olağandışı bir sorun yok; Çevik fikirde görülecek pek bir şey yoktu.
Sebepler çok olmasına rağmen Git merkezi bir rol oynadı. Ekibin Git'i kullanma konusundaki uzmanlık düzeyinin büyük ölçüde farklılık gösterdiği yavaş yavaş ortaya çıktı. Her zaman Git ile çalışan genç geliştiriciler vardı ve Git ile temasa geçmeden önce CVS veya Subversion gibi sistemlerle çalışmış daha yaşlı geliştiriciler vardı.
İkincisi Git ile hiçbir zaman yoğun bir şekilde ilgilenmemiş ve büyük ölçüde eski araçlara alıştıkları şekilde çalışmaya çalışmışlardır. Özellikle Git, birleştirme çakışmalarını önlemek için ödeme kilitleme işlevinden yoksundu. Sendikal anlaşmazlıkları çözmede iyi değillerdi. Bunlar ortaya çıktığında geliştiriciler anlaşmazlığı çözmekten kaçındılar ve bir sonraki destek talebi üzerinde çalışmaya başladılar. Daha sonra ortaya çıktığı üzere, bunun arkasındaki fikir şuydu: “Bu hoş olmayan işi daha sonra tüm biletlerle tek seferde yapacağım.”
Son sprintte çok fazla bilet var
Bir etki gözle görülmedi: Birisi sprint'e katılmak için ne kadar uzun süre beklerse, çatışma da o kadar büyük oluyordu. Doğal olarak ana şube gelişmeye devam etti. Sprintin bitiminden kısa bir süre önce birleşme noktasına gelindiğinde görev o kadar büyük hale gelmişti ki takım artık sprintteki biletlerin çoğunu tamamlayamıyordu. Bitirilmemiş biletlerin bir sonraki sprint'e geçmesi normal kabul edildiğinden (“bunu her zaman yaparız”), konuyu sorgulamak için herhangi bir neden yoktu.
Jira'daki teslimat sürelerinin analizi sorunun nedenini kolayca ortaya çıkaramadı. Bu yüzden
Sonunda, bazı takım arkadaşlarının Git'i kullanma konusunda ciddi eksiklikleri olduğunu ve bu nedenle biletlerin uzun süre ortalıkta kaldığını fark eden kişi “anadili Git olanlardan” biri oldu. Meslektaşlarına birkaç saatlik ikili programlama teklif etti. Hangi teknik bilginin eksik olduğunu gördü. Sorun belirlendikten sonra çözüm bulmak nispeten kolaydı.
Ekip düzenli Git egzersizleri yapmaya karar verdi. Gerçekte sorunun ortadan kalkması için bir sprint yeterliydi. Bu mümkün oldu çünkü “Git gençleri” “Git yaşlılarından” birleşme konusunda yardım istedi; Dikkate değer çünkü gençler yaşlılara göre yazılım geliştirmeye daha fazla zaman harcıyor. Deneyimin tek boyutlu olmadığı ve mutlaka yaşla ilgili olmadığı ortaya çıktı. Ekipte çeşitlilik ve tanınma önemlidir, ancak bunlar başka bir blog yazısının konularıdır.
Çözüm
Çevik çalışmaya geçiş Scrum Master'ın veya koçun görevi değil, takımın ancak birlikte başarabileceği bir değişimdir. Geliştiriciler liderlik rollerini benimsediklerinde Scrum Master'ın kolay kapsamının ötesinde bazı iyileştirmeler başarabilirler.
MERHABA. Stephen
(kendim)
Haberin Sonu
Duyuru
(Resim:
Stefan Mintert
)
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.
Geliştirme ekipleriyle yaptığım çalışmalarda Jira'nın amaçladığı şekilde çalıştığımızda çevik çalıştığımız görüşüne rastladım. Katılmıyorum. Bu bağlamda şu söz benim için geçerli: Elinde alet olan bir aptal yine de aptaldır.
Tek bir aracın bir takımı çevik hale getirebileceğini düşünmüyorum. Ancak araçların nasıl kullanıldığı ekibin çeviklik düzeyine dair ipuçları sağlayabilir. Bu aynı zamanda bir çevik koçun veya Scrum Master'ın sıklıkla dikkat etmediği araçlar için de geçerlidir; Bu özellikle teknik geçmişi olmayan Scrum Master'lar için geçerlidir. Böyle zamanlarda geliştiricilerin ekibin daha da gelişebilmesi için inisiyatif alması gerekir. Bununla ne demek istediğimi gerçek bir örnekle açıklayayım.
Birlikte çalıştığım bir takımda hedefe ulaşma ve sprint kararlılığı iyi değildi. Çoğu zaman takım sprint başında planladıklarını tamamlayamadı. Biletler bir sprintten diğerine taşındı. Döngü süresi yüksekti. Olağandışı bir sorun yok; Çevik fikirde görülecek pek bir şey yoktu.
Sebepler çok olmasına rağmen Git merkezi bir rol oynadı. Ekibin Git'i kullanma konusundaki uzmanlık düzeyinin büyük ölçüde farklılık gösterdiği yavaş yavaş ortaya çıktı. Her zaman Git ile çalışan genç geliştiriciler vardı ve Git ile temasa geçmeden önce CVS veya Subversion gibi sistemlerle çalışmış daha yaşlı geliştiriciler vardı.
İkincisi Git ile hiçbir zaman yoğun bir şekilde ilgilenmemiş ve büyük ölçüde eski araçlara alıştıkları şekilde çalışmaya çalışmışlardır. Özellikle Git, birleştirme çakışmalarını önlemek için ödeme kilitleme işlevinden yoksundu. Sendikal anlaşmazlıkları çözmede iyi değillerdi. Bunlar ortaya çıktığında geliştiriciler anlaşmazlığı çözmekten kaçındılar ve bir sonraki destek talebi üzerinde çalışmaya başladılar. Daha sonra ortaya çıktığı üzere, bunun arkasındaki fikir şuydu: “Bu hoş olmayan işi daha sonra tüm biletlerle tek seferde yapacağım.”
Son sprintte çok fazla bilet var
Bir etki gözle görülmedi: Birisi sprint'e katılmak için ne kadar uzun süre beklerse, çatışma da o kadar büyük oluyordu. Doğal olarak ana şube gelişmeye devam etti. Sprintin bitiminden kısa bir süre önce birleşme noktasına gelindiğinde görev o kadar büyük hale gelmişti ki takım artık sprintteki biletlerin çoğunu tamamlayamıyordu. Bitirilmemiş biletlerin bir sonraki sprint'e geçmesi normal kabul edildiğinden (“bunu her zaman yaparız”), konuyu sorgulamak için herhangi bir neden yoktu.
Jira'daki teslimat sürelerinin analizi sorunun nedenini kolayca ortaya çıkaramadı. Bu yüzden
- Kullanılan durumların (tahtadaki sütunlar), uzun süredir devam eden bir biletin “nerede” sıkışıp kaldığını tespit edebilmek için yeterince farklılaştırılmadığı,
- geliştiricilerin bazen panoda etkilenen biletlere mümkün olan en az şeffaf şekilde davrandığını; muhtemelen sorunu gizlemek için, örneğin
- Jira'da alt görevlerin kullanılması sorunun nedenini daha da belirsizleştirdi. Bir yan not olarak, bu nedenle yan koşuşturmalardan hoşlanmadığımı söylemek gerekir. Alt görevler ayrıca, devam eden çalışma sınırlamaları yoluyla sorunun nedenini belirleme girişimlerini de engelledi.
Sonunda, bazı takım arkadaşlarının Git'i kullanma konusunda ciddi eksiklikleri olduğunu ve bu nedenle biletlerin uzun süre ortalıkta kaldığını fark eden kişi “anadili Git olanlardan” biri oldu. Meslektaşlarına birkaç saatlik ikili programlama teklif etti. Hangi teknik bilginin eksik olduğunu gördü. Sorun belirlendikten sonra çözüm bulmak nispeten kolaydı.
Ekip düzenli Git egzersizleri yapmaya karar verdi. Gerçekte sorunun ortadan kalkması için bir sprint yeterliydi. Bu mümkün oldu çünkü “Git gençleri” “Git yaşlılarından” birleşme konusunda yardım istedi; Dikkate değer çünkü gençler yaşlılara göre yazılım geliştirmeye daha fazla zaman harcıyor. Deneyimin tek boyutlu olmadığı ve mutlaka yaşla ilgili olmadığı ortaya çıktı. Ekipte çeşitlilik ve tanınma önemlidir, ancak bunlar başka bir blog yazısının konularıdır.
Çözüm
Çevik çalışmaya geçiş Scrum Master'ın veya koçun görevi değil, takımın ancak birlikte başarabileceği bir değişimdir. Geliştiriciler liderlik rollerini benimsediklerinde Scrum Master'ın kolay kapsamının ötesinde bazı iyileştirmeler başarabilirler.
MERHABA. Stephen
(kendim)
Haberin Sonu