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.
Kullanıcı hikayelerinin ayrıntılandırılmasıyla ilgili rastgele bölümde şu soruyu yanıtlıyorum:
Bölünmeye kim karışıyor ve bu ne zaman oluyor?
Temelde, bence ortadan kaldırılması gereken iki anti-örüntü gözlemledim:
“Çok erken” ne anlama geliyor ve sorun nedir? Çok erken, geliştiricilerin dahil olmadığı anlamına gelir. Bölünmenin sonucu “iyi” olsa bile geliştiricileri dışlamak iyi değil.
Aksi takdirde kaçınılabilir teknik borç yaratma riskiyle karşı karşıya kalırsınız; yani, bölünmeden kaynaklanan daha küçük kullanıcı hikayesinin kapsamı, küçük hikayedeki daha büyük (ve bazı insanlar tarafından bilinen) bağlamın artık görülemeyeceği kadar küçük olduğunda. Ortaya çıkan hasar (orijinal anlamda teknik borç), bölünmeden sonra ortaya çıkan hikayelerin tutarlı bir şekilde tartışılmasıyla (örneğin iyileştirmede) ve sprint uygulaması/planlaması sırasında bağlantıları dikkate alarak önlenebilir. Ancak geliştiriciler genellikle bunu başlatamazlar çünkü şu anda izledikleri hikayenin daha geniş bir bağlamı olduğunu bilmeleri gerekir. Ancak bu, bölünme nedeniyle gizlenmiş olabilir. Bağlam olmadan, geliştiriciler bir özellik fabrikasında yalnızca dolaylı aracılar haline gelir. Olaydan sonra onlara bağlamı açıklamak yerine, teknik bilginin masaya yatırılması için onları bölünmeye dahil etmenin çok daha mantıklı olduğunu düşünüyorum.
Bileşen ekiplerinde özel bir durum çalışmaktadır. Geliştirme ekiplerinin orijinal kullanıcı hikayesini hiç görmeme olasılığı yüksektir. Bu, tüm bileşen ekiplerinin paylaşıma uygun şekilde dahil edilmesiyle önlenebilir. LeSS'e (Büyük Ölçekli Scrum) dayalı bir iyileştirme süreciyle ilgili iyi deneyimlerim oldu.
(Resim: Ruben Juarez/Unsplash)
Kısa Hikaye Bölme serisi dört bölümden oluşuyor:
(kendim)
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.
Kullanıcı hikayelerinin ayrıntılandırılmasıyla ilgili rastgele bölümde şu soruyu yanıtlıyorum:
Bölünmeye kim karışıyor ve bu ne zaman oluyor?
Temelde, bence ortadan kaldırılması gereken iki anti-örüntü gözlemledim:
- iş analisti, ürün sahibi, ürün yöneticisi veya benzer unvana göre çok erken bölünme;
- çok geç bölün, yani asla.
“Çok erken” ne anlama geliyor ve sorun nedir? Çok erken, geliştiricilerin dahil olmadığı anlamına gelir. Bölünmenin sonucu “iyi” olsa bile geliştiricileri dışlamak iyi değil.
Aksi takdirde kaçınılabilir teknik borç yaratma riskiyle karşı karşıya kalırsınız; yani, bölünmeden kaynaklanan daha küçük kullanıcı hikayesinin kapsamı, küçük hikayedeki daha büyük (ve bazı insanlar tarafından bilinen) bağlamın artık görülemeyeceği kadar küçük olduğunda. Ortaya çıkan hasar (orijinal anlamda teknik borç), bölünmeden sonra ortaya çıkan hikayelerin tutarlı bir şekilde tartışılmasıyla (örneğin iyileştirmede) ve sprint uygulaması/planlaması sırasında bağlantıları dikkate alarak önlenebilir. Ancak geliştiriciler genellikle bunu başlatamazlar çünkü şu anda izledikleri hikayenin daha geniş bir bağlamı olduğunu bilmeleri gerekir. Ancak bu, bölünme nedeniyle gizlenmiş olabilir. Bağlam olmadan, geliştiriciler bir özellik fabrikasında yalnızca dolaylı aracılar haline gelir. Olaydan sonra onlara bağlamı açıklamak yerine, teknik bilginin masaya yatırılması için onları bölünmeye dahil etmenin çok daha mantıklı olduğunu düşünüyorum.
Bileşen ekiplerinde özel bir durum çalışmaktadır. Geliştirme ekiplerinin orijinal kullanıcı hikayesini hiç görmeme olasılığı yüksektir. Bu, tüm bileşen ekiplerinin paylaşıma uygun şekilde dahil edilmesiyle önlenebilir. LeSS'e (Büyük Ölçekli Scrum) dayalı bir iyileştirme süreciyle ilgili iyi deneyimlerim oldu.
(Resim: Ruben Juarez/Unsplash)
Kısa Hikaye Bölme serisi dört bölümden oluşuyor:
- Bu bir sanat ve bunun için geliştiricilere ihtiyacımız var
- Bileşenlere ayırma?
- Geliştiricilerim olmadan olmaz
- Plansız şelale
(kendim)