Günaydın.
Duyuru
İlk bakışta yeterince basit görünse bile, birikmiş işler hakkında söylenecek çok şey var. Bu sadece bitmiş bir ürüne ulaşmak için yapılması gerekenlerin bir listesi. Birisi biletlerin listede doğru sırada olduğundan emin olmaktan sorumludur ve hepsi bu, değil mi?
(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.
Sık sık şunu gözlemliyorum: Birikmiş listede birkaç yüz bilet var. Bazıları bir yaş ve üzerindedir. Bazı biletler yeni özelliklerin geliştirilmesine yol açar; bunlara bazen hikayeler, kullanıcı hikayeleri, gereksinimler veya benzeri bir şey denir. Tabii ki hata biletleri de var ve teknik hikayeler, geliştirme hikayeleri veya benzeri diyebileceğimiz şeyler de var. Özellik istekleri ve gereksinimleri ürün sahibinden veya paydaşlardan gelirken, ikinci tür bildirim geliştiriciler tarafından yazılır.
Ve şimdi önceliklendirmeyle ilgili soru ortaya çıkıyor. Birkaç yüz biletin ardışık olarak nasıl yerleştirileceğini hala anlamıyorum. Ancak 80, 90 veya 100 adet gibi “birkaç” biletle bile özellikleri/gereksinimleri ve teknik hususları belirlemek kolay bir iş değildir. Ürün sahibi eski bir geliştirici ise teknik biletleri içerebilir; umarım bu durumda işini iyi yapabilecek kadar işi anlamıştır. Ve eğer ticari bir geçmişi varsa, mantıklı bir düzen sağlamak için birikimdeki teknik kalemleri yeterince değerlendirip değerlendiremeyeceği sorusu ortaya çıkıyor. Her halükarda bu, tek bir kişinin bile başaramayacağı kadar karmaşık bir iştir.
Sıralama problemini kontrol altında tutmak için önerim: iki biriktirme listesi kullanın. Ürün sahibi birinden (Ürün İş Listesi) sorumludur ve geliştiriciler birinden (Dev İş Listesi) sorumludur.
Evet evet biliyorum. Bu nedenle dogmatik bir bakış açısından tek bir hakikat kaynağına sahip değilim. Bu beni rahatsız etmiyor çünkü doğadaki birikmiş işler çoğunlukla tek bir hakikat kaynağı olmaktan ziyade tek bir kaos kaynağıdır.
İki ayrı biriktirme listesinin amacı nedir?
İki birikim için farklı araçlar mı var? Bunu sıklıkla tek bir yerde birlikte çalışan takımlarda gördüm: ürün birikimi için bir bilet sistemi, sprint için fiziksel bir tahta. Mekansal olarak dağıtılmış takımlar söz konusu olduğunda, Ürün ve Sprint İş Listesi için farklı araçların kullanıldığını hiç görmedim. İyi çalışıp çalışmadığını merak ediyorum. Bu konuda tecrübesi olan varsa yorum olarak yazarsa sevinirim.
(kendim)
Haberin Sonu
Duyuru
İlk bakışta yeterince basit görünse bile, birikmiş işler hakkında söylenecek çok şey var. Bu sadece bitmiş bir ürüne ulaşmak için yapılması gerekenlerin bir listesi. Birisi biletlerin listede doğru sırada olduğundan emin olmaktan sorumludur ve hepsi bu, değil mi?
(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.
Sık sık şunu gözlemliyorum: Birikmiş listede birkaç yüz bilet var. Bazıları bir yaş ve üzerindedir. Bazı biletler yeni özelliklerin geliştirilmesine yol açar; bunlara bazen hikayeler, kullanıcı hikayeleri, gereksinimler veya benzeri bir şey denir. Tabii ki hata biletleri de var ve teknik hikayeler, geliştirme hikayeleri veya benzeri diyebileceğimiz şeyler de var. Özellik istekleri ve gereksinimleri ürün sahibinden veya paydaşlardan gelirken, ikinci tür bildirim geliştiriciler tarafından yazılır.
Ve şimdi önceliklendirmeyle ilgili soru ortaya çıkıyor. Birkaç yüz biletin ardışık olarak nasıl yerleştirileceğini hala anlamıyorum. Ancak 80, 90 veya 100 adet gibi “birkaç” biletle bile özellikleri/gereksinimleri ve teknik hususları belirlemek kolay bir iş değildir. Ürün sahibi eski bir geliştirici ise teknik biletleri içerebilir; umarım bu durumda işini iyi yapabilecek kadar işi anlamıştır. Ve eğer ticari bir geçmişi varsa, mantıklı bir düzen sağlamak için birikimdeki teknik kalemleri yeterince değerlendirip değerlendiremeyeceği sorusu ortaya çıkıyor. Her halükarda bu, tek bir kişinin bile başaramayacağı kadar karmaşık bir iştir.
Sıralama problemini kontrol altında tutmak için önerim: iki biriktirme listesi kullanın. Ürün sahibi birinden (Ürün İş Listesi) sorumludur ve geliştiriciler birinden (Dev İş Listesi) sorumludur.
Evet evet biliyorum. Bu nedenle dogmatik bir bakış açısından tek bir hakikat kaynağına sahip değilim. Bu beni rahatsız etmiyor çünkü doğadaki birikmiş işler çoğunlukla tek bir hakikat kaynağı olmaktan ziyade tek bir kaos kaynağıdır.
İki ayrı biriktirme listesinin amacı nedir?
- Ürün biriktirme listesi yalnızca şirketin/ürünün vizyonunu temsil eder. Buna özellik istekleri, kullanıcı hikayeleri, gereksinimler ve hatalar dahildir. Bu nedenle işi ve ürünü anlayan herkes için anlaşılabilir bir durumdur.
- Bu nedenle ürün biriktirme listesi kaçınılmaz olarak daha kısadır. Daha az öğe olduğu için sıralama oluşturmak daha kolaydır.
- Geliştiricilerin önemli gördüğü her şey Geliştirici İş Listesi'nde bulunur. Ürün İş Listesi öğeleriyle aynı statüye sahiptir; en azından teoride.
- Günlük aktivite gerçek eşitliği belirler. Ürün İş Listesinden veya Geliştirici İş Listesinden bir bildirimin nasıl ve nasıl alınacağına kim karar verir? Bir çeşit “sprint planlaması” olduğunu varsayalım. Bu durumda PO'nun sorumlu olduğu ürün hedefleri çok önemlidir. Sprint hedefleri üzerinde etkileri vardır. Ancak Sprint İş Listesinin nasıl doldurulacağına ilişkin karar geliştiriciler olmadan verilemez.
Yalnızca bir biriktirilmiş iş listesiyle, Çizelge'de yukarıdan aşağıya biletlere kolayca bakmanız pek mümkün değildir. İki ayrı biriktirme listesiyle bu çok daha kolaydır. PO, sprint hedefleri hakkındaki fikirlerini ürün birikimindeki ana biletlere bağlayabilir. Geliştiriciler, Geliştirici İş Listesindeki en iyi destek taleplerini diyaloğa girer.
Belki Geliştirici İş Listesinin OP ile yapılan görüşmelerde bir rol oynamaması da işe yarayabilir. Ürün odaklı planlama basitleştirildi ve PO kolaylaştırıldı. Geliştiriciler gerekli geliştirme biletlerini bağımsız olarak sprint'e girerler. Bu, PO'lar ve geliştiriciler arasında güven gerektirir. Eğer bu yoksa, kesinlikle zor olacak ve hala bir blog yazısı için bir konumum var.
İki birikim için farklı araçlar mı var? Bunu sıklıkla tek bir yerde birlikte çalışan takımlarda gördüm: ürün birikimi için bir bilet sistemi, sprint için fiziksel bir tahta. Mekansal olarak dağıtılmış takımlar söz konusu olduğunda, Ürün ve Sprint İş Listesi için farklı araçların kullanıldığını hiç görmedim. İyi çalışıp çalışmadığını merak ediyorum. Bu konuda tecrübesi olan varsa yorum olarak yazarsa sevinirim.
(kendim)
Haberin Sonu