Scrum - Sprint Dışında Çalışan Geliştiriciler

12

Scrum Takımı

3 x Geliştiriciler
2 x Test Cihazı
1 x Otomasyon Test Analisti

Geliştiricilerin test etmediği ve testçilerin gelişmediği için çok fonksiyonlu bir ekip değiliz. Bu sorunun temel nedeni olduğuna inanıyorum.

Şu anda iki haftalık sprintler yapıyoruz.

Sprint başlangıcında herkes meşgul, geliştiriciler geliştirme çalışmalarına başlıyor ve testçiler test hazırlıklarını yapıyorlar (test senaryoları yazma vb.)

Test uzmanları hazırlıklarını bitirdikten sonra, geliştirme çalışmasının tamamlanmasını veya VEYA geliştirme çalışmasının tamamlanmasını bekliyorlar ve geliştiriciler geri bildirim / hatalar bekliyorlar.

Geliştiriciler burada kaşıntılı ayaklar alır ve iş yükünde mevcut sprint dışındaki öğeler üzerinde çalışmaya başlar. Bu tuhaf bir etki yarattı, böylece mevcut sprint'te her zaman sonraki sprint çalışmalarını geliştiriyoruz. Bana göre bu doğru gelmiyor.

Yönetim açısından bakıldığında, geliştiriciler masalarında hiçbir şey yapmadan oturmak yerine daha çok iş yaparlar ama aynı zamanda scrum takımının hedefinin ve odağının sadece mevcut sprint üzerinde olması gerektiğini hissediyorum. Keşke ekibimiz çok fonksiyonlu olsaydı ama maalesef ulaşılamaz. Test uzmanları geliştirme işi yapmak için gerekli becerilere sahip değildir ve geliştiricilerin çoğu testlerin altında olduğu görüşündedir.

Scrum'da bu bir sorun olarak mı görülüyor? Bunun bir çözümü var mı? Scrum sadece çok işlevli ekiplerle çalışır mı?

Mümkünse bununla ilgili diğer insanların deneyimlerini bilmek istiyorum :)

agile scrum

— fml
kaynak

3

Yönetime katılıyorum. İki haftalık keyfi bir süre yüzünden insanların etrafta oturması korkunç bir fikirdir. Belki de ekibinizin sorumlulukları çok katıdır; bu küçük takımlarda, tüm takım üyelerinin "çapraz fonksiyonel" olmaları nadir değildir, bu da mevcut sprint'te gereken yerlere atlamalarına izin verir.

— Robert Harvey

... belki de takımı iki hafta boyunca meşgul edecek kadar sprintlerinize koymuyorsunuz.

— Blrfl

3

Hibrit bir çift geliştirme / test karışımı pratik midir? Bir anlamda süreç, birim test çevrimi ile aynıdır; küçük bir test yaz biraz. Bunu resmi olarak yapmadık ama test ediciler bize doğrudan bir hata olarak gelme alışkanlığı içerisindeydiler. Resmi hata raporları aracılığıyla iletişim kurmadık. "Test cihazım" testini bitirdiğimde düzeltmeyi bitirdim. Bir web uygulaması olmak düzeltme dönüşümü verimli yaptı. Ama en azından deneme. Ve açıkçası, daha iyi veya daha kötü olmasa bile, daha az bireysel bekleme süresi algılayacaktır.

— radarbob

3

Başlangıçta bir sprint için planlanan çalışma genellikle yeterli kalitede tamamlanıyor mu? Yoksa orijinal planlamanın dışında yarı bitmiş hikayeler mi bıraktınız?

— Bart van Ingen Schenau

2

İşleminizi devam ettirebilirsiniz, ancak 'scrum' yerine 'kanban' olarak adlandırabilirsiniz ve sonra işleminizin scrum ile doğru olup olmadığı konusunda endişelenmenize gerek yoktur. / biraz alaycı, ama gerçekten değil

— Eric King

16

Bu, boru hattının neden olduğu oldukça yaygın bir sorundur . Ekip çok işlevli, ancak elbette performansı azaltan iç silolar var.

Öncelikle önemli olduğunu düşündüğüm birkaç şeye dikkat çekmek istiyorum:

Geliştiricileriniz önceden bir yineleme yapıyorsa, planlama toplantınızı önceden engelliyorlar. Ürün yöneticiniz ve ekibiniz, bir sonraki yineleme için neyin en değerli olduğunu düzgün bir şekilde tartışmalıdır. Önceliklendirme geliştiriciler tarafından etkili bir şekilde yapılmamalıdır, çünkü yapacak daha iyi bir şeyleri yoktur.
Yinelemeleri nasıl bölerseniz ve düzenlerseniz de, ekibinizin silolarda çalışan uzmanları olduğu sürece, herkesi her zaman meşgul tutamaz ve tek bir planlama toplantısı ile tek bir ekibiniz olamaz. Saf bir şelale yaklaşımıyla bile, yine de "duvarın üzerinden bir şeyler atmak" ve geri bildirim beklemek gerekir.
Ayrıca, genellikle tek bir öykünün bir geliştirme aşamasına, ardından bir test aşamasına, ardından bir hata düzeltme aşamasına, ardından da takip edilmesi gereken bir sorun vardır ... , çünkü bağlam değiştirmeleri gerekiyor.

Açıkçası bu durumun çok gerçek bir maliyeti var: ekip işbirliği yapmıyor. Bununla ilgili bir KG ekibi her zaman karşılaştım, bu yüzden farklı çözümleri denemek için biraz zamanım vardı.

Benim için çok işe yarayan şu iki araç:

İşlerin yapılmasından tüm ekibin sorumlu olduğu ilkesini vurgulayın . Geliştiriciler için "artık benim sorunum değil" demenin bir yolu olduğundan, "geliştirici" hikayeleri reddedin. Bir takım kabul ettikleri bir hikayeyi iletmezse, teslim etmeyen takımın tamamıdır.
Hem geliştiricilerin hem de KG'nin zamanını işgal etmek için eşleştirin . Bu, seçebileceğiniz uzmanlık ve alan bilgisini paylaşmanın en iyi yoludur. Geliştiriciler test uzmanlarının görevlerini otomatikleştirmelerine yardımcı olabilir. Test kullanıcıları, geliştiricilere kodu test etmenin önemli olduğunu gösterebilir çünkü kırılgan. Hem işbirliği yapın hem de daha hızlı çalışın.

Bu iki tekniği kullanarak ekip daha az sessiz ve daha iyi performans göstermelidir. Testçilerin ve geliştiricinin işleri değiştirmesi pek mümkün olmasa da, bir takım olarak çalışabilir ve birbirlerini suçlamak yerine sorunu dahili olarak çözebilirler.

— Sklivvz
kaynak

1

Cevabınız için teşekkür ederim. Geliştirici ve KG kaynağını bir araya getirme fikrini çok seviyorum. Bunu bir sonraki toplantımızda önereceğim ve umarım bunu bir sonraki sprint'te deneyebiliriz. Soruyu güncelleyeceğim ve nasıl gittiğini size bildireceğim!

— fml

@Sklivvz Bu, sadece bir KG departmanı olduğunda olduğundan daha sık görülür. KG her seferinde sadece "belirli insanların" yapabileceği bir rol olduğunda olur. "Sonraki" yüksek öncelikli görevi almak için boştaki kaynak yerine geliştirici boşta kalır, ardından KG geliştirici çıktısına sürekli tepki verirken daha fazla iş alır.

— Edwin Buck

1

Yukarıda belli değil ise, ürün birikim gelen 'değil sonraki yüksek öncelikli geliştirme görevi sevk böylece QA yığılmasını azaltmayı "bir sonraki yüksek öncelikli görevi olacaktır'.

— Edwin Buck

1

Tüm takımın sorumluluğu gibi tavsiyeler, kulağa hoş gelse de, gerçekte takıma hizmet etmez. Herkesin birbirinin yerine kullanılabileceğini ve içeri girmeyen herkesin eksik olduğunu gösteriyor. Bu yanlış. SDLC'deki her bireyin belirli bir rolü vardır ve YEARS, becerilerini geliştirmek için harcadı. Bir yazılım mühendisinden test etmesini istemek, kaliteyi test etmek için gerekli deneyime sahip olmadıkları ve muhtemelen gönülsüz bir girişimde bulunacağı için kaliteye zararlıdır. KG mühendisi onlara mentorluk yapsa bile, mentorluk testten zaman alacak ve işin daha uzun sürmesini sağlayacaktır.

— Chuck Conway

1

@ChuckConway kimse ne dediğini önermiyor. Eşleştirme ikame veya mentorluk değildir. İdeal olarak, çalışmama süresini en aza indirmenin en iyi yolunu bulması için takıma güvenirsiniz ve bu sadece insanların birbirlerinin rollerini ve ihtiyaçlarını anlamasıyla başlayabilir. En iyi, en verimli takımlar kendi kendini organize eder (doğru ya da değil, bu çevikliğin temel ilkesidir).

— Sklivvz

2

SCRUM ve sprint'lerle ilgili çalışma şeklinizle ilgili bir sorun yoktur, ancak geliştirici çalışmasının planlanandan daha kısa sürede (ve ne kadar daha az sürede) tamamlandığına dair değerlendirme zamanında kayıt altına alınacaktır. Bu, takımın bir sonraki sprint için daha fazla hikaye puanı almasına izin verecektir. Sonuçta, sprintlerin amacı planlamada daha iyi olmaktır. Açıkçası hala iyileştirme için yeriniz var.

mevcut sprint'te her zaman bir sonraki sprintler geliştiriyoruz

Oha! Bu Scrum'da teknik olarak mümkün değildir. Bir sonraki sprint'te hangi biriktirme listesi öğelerinin olacağını bilmiyorsunuz, yani bir sprint planlama oturumunda bir sonraki sprint'in başlangıcında kurulacak.

Kuruluşların Scrum'ı sabote etmek için icat ettikleri yeni yaratıcı yollar hakkında bilgi edinmek ilginç olmaya devam ediyor.

— Martin Maat
kaynak

3

"Whoa! Bu Scrum'da teknik olarak mümkün değildir" ve "... kuruluşların Scrum'ı sabote etmek için icat ettiği yeni yaratıcı yollarla" ilgili sorun, "Scrum yapmak" için doğru bir yol olduğunu ima etmeleridir. Doğru bir yol olması için Scrum'ın yasaklayıcı olması gerekir, yani süreçleri insanlardan önce koymak. Scrum yapmak için doğru bir yol varsa Scrum çevik bir süreç değildir.

— David Arno

@David Arno Güzel, temelde herhangi bir metodolojinin tanım gereği çevik olmadığını söylüyorsunuz. Çevik manifesto bile. Sadece öngörülemeyen kaos çevik olurdu. Ama bekleyin .. kim bana kaotik olmamı söylüyor? Şimdi ciddi: çevik adagium "süreç öncesi insanlar" çatışmayı çözmek için var. Eğer bir kişi seçmek zorundaysa, kuralların söylediklerini değil, mantıklı olanı yapmalıdır. Bana öyle geliyor ki OP ekibi Scrum kitabından sorunsuzca geçebilirdi. Ve belki de öyle yaparlarsa, anahtar soru ne kadar şeffaf olduklarıdır.

— Martin Maat

1

@DavidArno aslında, bu sadece Scrum'ı yapmak için belirli yanlış yollar olduğunu ima ediyor ve bu tartışmasız görünüyor. Örneğin, Çevik Manifesto ile çelişen her şey objektif olarak yanlış görünüyor.

— Sklivvz

1

Scrum, takımı değil, takımı optimize eder . Scrum'ın tamamı takımın verimli olması. Geliştiriciler mevcut sprint dışındaki şeyler üzerinde çalışmaya başlıyorlarsa, takımı bir kötülük yapıyorlar. Ayrıca, yayı doldurmak için yeterli iş planlamıyorsanız, planlama sürecinizde bir miktar başarısız olduğunuzu da gösterir.

Geliştiriciler geliştirme görevlerinin bitmişlerse, kesinlikle teste girmeli ve test uzmanlarına, teknoloji yazarlarına veya tasarımcılara - takımdaki herhangi birine yardım etmelidirler. Gerçek testler yazmak zorunda olmaları gerekmez (yine de yapmaları gerekir ), ancak yine de test sürecine katılabilirler. Testçilerin daha verimli olmasına yardımcı olan komut dosyaları yazabilirler veya test kullanıcılarıyla zorluklarının ne olduğunu tartışabilirler ve bu zorlukların üstesinden gelmelerine yardımcı olmaya devam edebilirler (örneğin: web sayfası öğelerine kimlik özellikleri ekleme, test kullanıcılarının kancalarını veya API'lerini sağlama testlerinde kullanabilir vb.).

Sorunun kalbi, geliştiricileriniz her zaman güncel sprint üzerinde çalışmıyorsa, henüz bir takım olarak çalışmıyor olmalarıdır. Scrum master'ınız dikkat etmeli ve ekibin bireylerden oluşan bir koleksiyondan ziyade bir birim olarak çalışmasını sağlamaya çalışmalıdır.

Bunun bir yönetim sorunu olduğunu da öneriyorum. Eğer geliştiriciler üzerinde meşgul kalmaları için baskı yapıyorlarsa, o zaman tam olarak benimsememişlerdir. Scrum ustasının yardımcı olabileceği başka bir şey bu. Scrum'ın nasıl çalıştığını anlamalarına yardımcı olmak için yönetim ile birlikte çalışabilirler, böylece geliştirme ekiplerini onları yıkmak yerine desteklemeye ve teşvik etmeye yardımcı olabilirler.

— Bryan Oakley
kaynak

0

Bence buradaki temel sorun şudur:

geliştiricilerin çoğunluğu testlerin altında olduğu görüşüne sahiptir.

Bunu şirketimizde ele alma şeklimiz, geliştiricilere, ispatlayamazlarsa işlerini gerçekten bitirdiklerini nasıl söyleyebileceklerini sorduk. Tabii ki, bunu kanıtlamanın tek yolu, yazdıkları kodun gerçekten işe yaradığını göstermektir ve bu test yoluyla yapılır. Onlara, teste katılmayı kabul ederlerse, testin daha hızlı yapılacağı ve ek işlevleri kodlamak için daha fazla zamanlarının olacağı belirtilmelidir (ayrıca test edilmesi gerekecektir).

Kodunuzu test etmenin geliştiriciler seviyesinin altında olmadığına dikkat edin. Geliştirme sürecinin ayrılmaz bir parçasıdır. Sadece kodlamadan ayrılamaz. Herkes kodlayabilir. Herkes kodladığı şeyin gerçekten işe yaradığını kodlayamaz ve kanıtlayamaz.

Geliştiricileri meşgul etmenin bir başka yolu, sprint'te geliştirdikleri işlevler için otomatik testlerin kodlanması üzerinde çalışmalarını sağlamaktır. Bu testler daha sonra periyodik olarak yapılacak regresyon testi için kullanılabilir.

Her iki durumda da, sprint başında planlanmamış bir şey yapmak büyük bir hayır-hayır. Hiçbir şey yapmamak, planlanmamış bir şey yapmaktan daha iyidir. Bu durumlarda yazdıkları işlevsellik büyük olasılıkla iyi test edilmediğinden, muhtemelen test edilmediğinden, DoD (Done Definition of Done) kriterlerini karşılamamaktadır, çünkü testçiler başlangıçta planlananları test ederek meşguldü. Bu, hataları tanıtmanın ve ürünün kalitesini bozmanın kesin bir yoludur, bu da ekibi gerileme, hızın azalması ve nihayet takımdan vazgeçmesi ile sonuçlanan regresyon problemleri ve bağlam anahtarının aşağı doğru bir sarmalına gönderir.

— Vladimir Stokic
kaynak

Programcıların kodu test ettiğini söyleyebilirim, sadece otomatik testler oluşturmazlar. Büyük bir fark var.

— JeffO

Bu özel durumda, bu programcıların yaptığı tek testin IDE'den bahsetmeye hazırım. Pek çok geliştirici, çözümü aslında bir kurulum paketine inşa etmez, paketi son kullanıcının yaptığı gibi sıfırdan konuşlandırır ve ardından çözümü test eder. Çoğu durumda bu yeterli değildir ve kalitenin önemli ölçüde bozulmasının bir nedenidir.

— Vladimir Stokic

0

Teoride, bir SCRUM ekibinin tüm üyeleri aynı bilgiye sahip olmalıdır, böylece her üye diğer tüm üyelerden her görevi alabilir. Değilse, bilgiyi yaymalısınız.

Ancak pratikte her zaman bir çeşit uzmanlık vardır. Yazılım karmaşık olabilir, ekip üyesi farklı becerilere sahiptir. Ekibi geliştiricilere ve test kullanıcılarına bölmek sadece bir (çok yaygın) uzmanlık örneğidir.

Bilginin yayılması yönetimin kabul etmek istediğinden daha fazla zaman alabilir.

Deneyimlerime göre, birkaç şey yapabilirsiniz:

Takımı çok küçük yapmayın. Örneğin, 4 geliştiriciniz ve 4 testçiniz varsa, bir görevi başka bir geliştiriciye veya testçiye taşımak, o zaman bu örnekte sadece 3 / 2'ye sahip olmak çok daha kolaydır.
Daha büyük görevleri bölmeye çalışın. Daha küçük görevleriniz varsa daha esnek olursunuz.
Zaman kaldıysa yapılabilecek bazı isteğe bağlı görevleri tanımlayın.

Bu öneriler% 100 SCRUM teorisi olmayabilir, ancak önce gelişimin çalışmaya devam etmesi gerekir. SCRUM sadece bir araç kutusudur.

— bernie
kaynak

0

Görünüşe göre ekibinizi senkronize etmeniz gerekiyor. Bunun gibi:

   Test.   -------s1 -----------s2
   Dev.        --------s1 -----------s2

Eğer test otomasyonu adamlarının birkaç gün erken başlaması gerektiğini anladıysam.

Ancak ekibinizde bir sorun olduğunu düşünüyorum: Geliştiricilerde kendi kodlarını test etmeyen bir sorunum var. Test adamları, kodu gözden geçirmeden testi hazırlarlarsa, muhtemelen yalnızca geliştirilmiş programın karar noktalarını dikkate almayan kara kutu testleri yapıyorlar. Yazılımınızın kalitesinden memnun musunuz?

— Lucas
kaynak