Yazılım ekiplerindeki operasyonel körlüğe gözlerinizi açın
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.
Siz de operasyonel olarak kör müsünüz? Aptalca bir soru, değil mi? Bunu bilseydin şirkete karşı kör olmazdın. Yani cevap yalnızca şu olabilir: Olabilir.
Yazılım ekiplerinde çalışma anlaşmaları şeklinde operasyonel körlükle karşılaşıyorum. Bunlar her ekip üyesi tarafından biliniyorsa, ideal olarak iyi belgelenmişse ve gerçekten uygulanmışsa değerli ve faydalıdırlar. Ancak öyle oldukları için böyle olan prosedürler, kurallar ve sözleşmeler de vardır. Her zaman onlar böyleydi. Veya asıl sebep unutulmuştur. Bir yerden derlenen en iyi uygulamaların düşüncesizce benimsenmesi de popülerdir.
Operasyonel körlüğüme bir örnek: 2010 yılında Vincent Driessen “Başarılı Git Dallanma Modeli” başlıklı bir makale yazdı. Önerisine gitflow adı verildi. Makaleyi yayınlandıktan kısa bir süre sonra okudum ve hemen ikna oldum. Biz o dönemde ekibimizde bu yaklaşımı benimsedik ve ilerlememize yardımcı oldu.
Bu bağlama bağlıdır
Önümüzdeki birkaç yıl boyunca orada burada gitflow'u önerdim. Bazı takımlar bunu benimsedi, bazıları ise benimsemedi. Bu normal. Ancak bir şey sıklıkla göz ardı edilir: Gerçekte hangi sorunu çözmek istiyorsunuz? Peki önerilen yaklaşım gerçekte ne kadar işe yarıyor?
Kısacası: geriye dönüp baktığımda, gitflow'un benim tavsiyem üzerine çok sık ve bazen de mantıklı bir sebep olmaksızın uygulandığından şüpheleniyorum. Bir geliştirici bana gitflow'un ekibi için iyi bir seçim olmadığını söyleyene kadar değildi çünkü… Belirli bir ortamda iyi çalışan bir şeyi yeni bağlamlarda defalarca ve düşüncesizce kullandığımı veya onu tavsiye ettiğimi fark ettim. en iyi uygulama çözümü; Bugün artık buna inanmıyorum Geliştirmek Uygulamalar.
Aynı prensibi bazı müşterilerde de gördüm. Sanırım bu insan doğasıdır ve genellikle kanıtlanmış ve başarılı uygulamalara bağlı kalmak iyi bir fikirdir. Kazanan takımı asla değiştirmeyin Bu kesinlikle bir deyim değil. Aksi takdirde her gün her şeyi sorgularsınız ve artık hiçbir şey başaramazsınız. Ne yazık ki bazen bağlam değişir ve en iyi uygulama olarak adlandırılan uygulama artık iyi uygulama bile değildir.
Soru sormak yardımcı olur
Bunun olmasını önlemek için çalışma düzenlemelerinizde biraz temizlik yapmanızı öneririm. Bu şu anlama gelir: Birkaç ay ya da belki bir yıl gibi daha uzun aralıklarla, bir ekibin bilinen ve görünmeyen çalışma düzenlemelerini sorgulaması gerekir:
- Birlikte nasıl çalışırız?
- Ekibimizde değer yaratma nasıl yapılandırılıyor?
- İhtiyaçlar, dilekler, hikayeler ve fikirler bizim yardımımızla ürüne nasıl dönüşüyor?
- Bunun arkasındaki niyetler nelerdir ve (hala) hedeflere ulaşıyor muyuz?
- Düzeltmeleri nasıl hallederiz? Neden bu şekilde? Hangi hedefe ulaşmak istiyoruz ve bunu başarabilecek miyiz? Hedefimize başka nasıl ulaşabiliriz? En iyi yol nedir?
- Beş yıldır taviz vermeden, testlerin rehberliğinde çalışıyoruz. Neden tanıttık? Çalışıyor mu? Bugün hâlâ buna ihtiyacımız var mı? Kuralı gevşetirsek ne olur?
- Analog: Hangi kodlama kurallarına sahibiz? Neden? Hangi nedenle? …
Bu soruları sormak ve çalışma düzenlerini test etmek için bir takım liderine, yöneticiye veya koça gerek yoktur. İhtiyacınız olan tek şey özel bir geliştirici ve işiniz bitti. Konuyu gazetede önerin veya takvimden randevu alın. Merak uyandıran ve hatta kışkırtıcı bir formülasyon seçerseniz (“Bir daha asla test odaklı olmayacak” veya “bundan sonra sadece test odaklı”) tepkiler ve katılım daha muhtemel olacaktır.
Öğrenilen dersler
Ekip içindeki diyalog, sabit görüşlere ve yerleşik inançlara meydan okumalıdır. Bunu yukarıda bahsettiğim operasyonel körlük örneğinden de öğrenebilirsiniz:
Gitflow zamanında çok popüler olmasına rağmen, yıllar sonra açıkça berbat olduğu düşünülüyor. Bugün terimi Google'da aratırsanız, diğer şeylerin yanı sıra, Atlassian'ın giriş kısmında şöyle yazan bir makale bulacaksınız: “Gitflow, bir zamanlar Git şubelerini yönetmek için yenilikçi ve yıkıcı bir stratejiyi temsil eden, eski bir Git iş akışıdır”.
Gitflow'un yıkıcı sıfatına layık olduğunu hiç hatırlamıyorum; Ancak kelime dağarcığı en azından küçük bir moda bingo için uygundur. Ben eski ve önceden yeni olarak sınıflandırmayı daha çok eleştiriyorum. Yaşın rolü nedir? Belki 20 yıl sonra bile gitflow ile mükemmel şekilde çalışabilecek ekipler ve görevler ortaya çıkacak. Bu eski ya da yeni meselesi değil. En iyi veya en kötü uygulama yoktur. Daha ziyade, bir şeyin bireysel kullanım durumuna ve bağlama ne kadar uygun olduğu ile ilgilidir. Her takım kendisi için daha iyi karar verebilir ve önceden yapılmış bir anlaşmayı daha geniş aralıklarla sorgulayabilir. Özellikle kararın nedenleri ve bağlamı unutulduğunda. Bahar temizliğine gidiyoruz!
Önce oku sonra dinle
Escape the Özellik Fabrikası podcast'inde blogdan seçilen konuları alıp bunları bir konukla tartışıyorum. Değişim sayesinde ikinci bir bakış açısıyla tanışıyorum. Podcast Spotify, Deezer, Amazon Music, Apple Podcasts ve kutura.digital'de mevcuttur. Burada, diğer şeylerin yanı sıra, blogun konularını ele alan atölye çalışmaları bulacaksınız.
(Ben)