Scrum - Bir sprint sırasında takım üyeleriyle meşgul olanlar

Bu yüzden, bir scrum sprint, belirli bir özellik setinin uygulanması gereken belli bir süredir. Ve bir scrum takımı bu özellikleri sunmaya kararlı olan tüm insanlardan oluşur, bunların çoğu genellikle geliştiriciler ve testçilerdir.

Bu kuralları belirledikten sonra, tüm bu sprint boyunca bu insanların hepsini nasıl meşgul tutacağı merak edilebilir. Sprintin başında henüz test edilecek bir şey yok ve sprintin sonunda genellikle geliştirmek / düzeltmek için hiçbir şey kalmadı veya çok az kaldı.

Bununla başa çıkmak için 2 yaklaşım gördüm, ancak hiçbiri sorunu doğru şekilde çözmedi.

1) Ekip üyelerinin görevlerinin dışında kaldıklarında ne yapacaklarına karar vermelerini sağlayın.

Eksileri:

• Yaptıkları ayrıntılı bir şekilde planlanmamışsa (yani büyük yeniden düzenleme, yeni test çerçevesine geçme), çalışmaları işe yaramaz hale gelebilir veya yarı yolda sıkışıp kalabilir
• Öte yandan, bu tür işlerin planlanması çok zaman alabilir ve müşteri, ekibin derhal değer getirmeyen bir şey için zamanını boşa harcadığı için hayal kırıklığına uğrayabilir.
• Bu tür görevler genellikle tam olarak tahmin edilemez, bu nedenle ilke sahip olmayan işçilerin zamanlarını scrum tahtasına veya başka bir yere yansıtılmadan YouTube kedilerini izleyerek geçirmeleri oldukça kolaydır.

2) Sadece gelişim için sprintte yer açın ve sprint bittikten sonra test etmeye başlayın (geliştiriciler bir sonraki sprintin özellikleri üzerinde çalışmaya başladığında)

Eksileri:

• Mevcut sprint için özellikler geliştirilirken, geliştiriciler öncekinden böcekleri düzelterek dikkatleri dağıtır ve mevcut sprint sırasında yapılması tahmin edilen iş miktarını yerine getiremezler.
• İki scrum panosuna ihtiyaç duyulur: biri geçerli sprint özellikleri için ve diğeri önceki sprint hataları için

Öyleyse sorum şu: hiç kimse işte aşırı yüklenmeyecek veya herhangi bir noktada görev yapmadan bitmeyecek şekilde sprint sırasında çalışmayı geliştiriciler ve test yapanlar arasında nasıl doğru bir şekilde dağıtmalı? Yukarıda açıklanan yaklaşımları iyileştirmenin yolları var mı? Yoksa daha iyi bir yaklaşım var mı?

Sprint başlangıcında henüz test edilecek bir şey yok.

Gerçekten mi? Doğrulamak için gereksiniminiz yok mu? Müşterinizle görüşmeniz mümkün değil mi? Değerlendirilecek tel çerçeve yok mu? Düşünecek test planı yok mu?

sprint sonunda genellikle geliştirmek / düzeltmek için hiçbir şey veya çok az kalmış

Daha önce hiç bu projede bulunmadım. Daha fazla iş yok mu? Her zaman bir şey vardır. Tüm testleriniz tamamen otomatik mi? CI nasıl görünüyor? Veritabanı erişim katmanı daha basit olacak şekilde yeniden yapılandırılabilir mi? Ve hiçbir zaman boş bir hata listesi ve biriktirme listesi olan hiçbir şey üzerinde çalışmamıştım. Geliştiricileriniz bir şelale test aşamasında neler yapardı?

Bazı insanların 'SCRUM' nedir ve ne olmadığı konusunda çok dinlendiklerini biliyorum. Daha az umursayamazdım. Ama burada iki sorunun olduğunu düşünüyorum:

1. Doğru şeyi oluşturmanın yanı sıra doğru bir şekilde oluşturduğunuzdan emin olmak için müşteriler ve geliştiricilerle çalışmak yerine, geliştiriciler tarafından bir kez kod tamamlandığında test yapan 'geleneksel' QA departmanı. Lisa Crispin'in çevik test kadranlarına bir göz atın . En iyi test cihazları, yazılım geliştirme yaşam döngüsünün her aşamasında yer alır ve en iyi geliştiriciler kendi testlerini yazar.

2. Tek bir sprint içinde kısa bir sürede tamamlanması kolay olan görevlere bölünmüş öncelikli ve büyüklükteki bir birikim olmadan, 1 hafta / 2 haftalık sprintlerin SCRUM zaman çizelgesine çok yakın kalmaya çalışmak . Eğer buna sahip olsaydın, baş etmek için her zaman daha fazla iş olur. Belki de bu sprint içinde üzerinde çalıştığınız son özellik bu sprint sürümüne girmiyor, ama her zaman bir sonrakine geçebilir.

Kenara. Küçük bir uyumlu ekibiniz varsa, o zaman roller daha az önemlidir. Üretim test kodu yazmasına izin verilmeyen bir etiket test cihazına sahip biri veya testin üstünde olduğunu düşünen bir geliştiriciyi etiketli biri yerine, herkes ne zaman korkunç proje yönetimi görevleri de dahil olmak üzere ekibin başarılı olması için ne gerekiyorsa yapmalıdır. Onlar gerekli, buna çapraz fonksiyonel bir takım denir.

Yorumlarda @Cort Ammon tarafından getirilen ilave bir nokta. Çevik manifesto sözleşmeli müzakere konusunda müşteri işbirliğinden bahsediyor. Bunu sen söyledin:

Müşteri, ekibin derhal değer getirmeyen bir şey için zaman harcadığını görmekten hayal kırıklığına uğramış

Açıklamak zor olabilir ve müşterilerin zaman zaman çok zor olabileceğini biliyorum ama bu benim için büyük bir kırmızı bayrak olacaktır. Kaynak kodları / müşteri ilişkileri / iş / onlar için geliştirdiğiniz her şeyle size güveniyorlar. Profesyonel olarak en iyi çıkarları doğrultusunda hareket etmenize güvenemezlerse, o zaman bir sorununuz olur ya da yaparsınız.

Yazılım geliştiricilerden bahseden, profesyonel olarak kabul edilmeyen bir yazı yazdım . Profesyonel bir doktor, avukat, inşaat mühendisi, müşterileriyle ilgili gereksinimleri yarı yolda değiştiren bir müşteriyle karşı karşıya kalması sadece kalitesini düşürmekle kalmaz. Müşterilerine bunun bir sorun olacağını söylerlerdi. Eğer müşteri ittiyse, o zaman bir profesyonel kör bir şekilde tehlikeli bir düşük standarda yapmaz, çünkü sorumludurlar. Profesyonel giriş sınavlarına girmiyoruz ve bu nedenle sorumluluk kabul etmiyoruz. Bu, daha iyi olmaya çalışmamamız gerektiği anlamına gelmez.

Özetle, bir sprintin başında ve sonunda insanların daha verimli olmalarını sağlamaya çalışmaktan çok endişelenmem, daha ziyade bunu takımın içindeki daha geniş bir sorunun belirtisi olarak görmem gerekir. Duydunuz eXtreme Programlama (XP) . XP'nin burada uygulayacağı prensiplerin iletişim ve saygı olduğunu söyleyebilirim:

• Takımınıza en iyi olduğunu düşündüğü şeyi yapmaya saygı gösterin. Çok fazla kedi videosu izliyorsanız, o zaman ya zayıf geliştiricilere sahip olursunuz ya da onlara kötü davranıyorsunuzdur.
• İletişim. Eğer geliştiricileriniz birbirleriyle, testçilerle, yönetimle, müşteriyle konuşuyorsa, o zaman herkes muhtemelen bir sonraki şeyin ne olduğuna dair iyi bir fikir sahibi olmalıdır ve eğer istemiyorlarsa, sadece sorabilirler.

İlk nokta, Scrum'un her bireyi değil takımı geliştirmekle ilgili olduğu . Eğer takım verimli ve verimli ise, bir kişinin görevin başında veya sonunda boşta kalması önemli değildir.

Ancak, bulunduğum her takımda her zaman bolca iş var. Özel endişelerinden birkaçını ele alalım:

Sprint başlangıcında henüz test edilecek bir şey yok.

Bu kelimenin tam anlamıyla doğru olsa da, bir sınayıcının tek işinin "sınamak" olduğunu düşündüğünüz anlamına gelir. Teste başlamadan önce yapılabilecek çok şey var. İlk olarak, gereksinimleri tam olarak anlamak için ürün sahibi ve geliştiricileriyle buluşabilirler. Bir test planı üzerinde çalışmakla, test verilerini toplamakla vb. Meşgul olabilirler. İyi bir çerçeve lüksüne sahiplerse, önceden otomatik testler yazmaya başlayabilirler.

sprint sonunda genellikle geliştirmek / düzeltmek için hiçbir şey veya çok az kalmış

Henüz düzeltmem gereken işleri biten bir geliştirme ekibi görmedim. Ancak, sprint sonunda yapmaları gereken şey bu değil. Sprintin sonuna doğru test uzmanlarının ürünü test etmelerine yardımcı olmaları gerekir. Otomatik testler yazmaya yardımcı olabilirler, test uzmanları tarafından yazılmış testler ve fikstürler / anahtar kelimeler / vb. İşlerini tamamlamalarına yardımcı olmak için dokümantasyon ekibiyle birlikte çalışabilirler.

Bununla başa çıkmak için 2 yaklaşım gördüm ... 1) Ekip üyelerinin görevlerini ne zaman yaptıkları konusunda ne yapacaklarına karar vermelerini sağlayın.

Düşüncelerindeki kusur, bireylerin görevlerinin bitmesidir. Görevler bir bütün olarak takıma aittir. Mevcut sprintte takım için geriye kalan herhangi bir hikaye veya görev olduğu sürece başka işler yapmamalıdırlar .

Sprint içinde sadece gelişim için yer açın,

Bu yaklaşım geleneksel scrum veya agile tanımında değildir. Çevikliğin tüm noktası, tüm ekibin ortak bir hedefe doğru çalışmaya dahil olmasıdır. Bu, bir hikayeyi bitirmek için gereken tüm çalışmaların bir sprint - tasarım, geliştirme, test, dokümantasyon vb. İle temsil edilmesi gerektiği anlamına gelir .

Son olarak, diğer uygulanabilir tek çözüm bu değildir. Gerçek çözümü ihmal edersiniz; bu, her takım üyesinin bir sprint içerisindeki hikayeleri bitirmek için gerektiği gibi girmesi gerektiğidir.

Amaç bir takım hedefidir, ancak her bir bireyin bireysel hedefleri varmış gibi yazıyorsunuz ("görevlerimi bitir"). Birisinin yapacak bir şeyi yoksa, şu anda üzerinde çalışılmakta olan şeyi görebilir ve yardım etmeyi önerebilir. Veya bir sonraki görevi veya hikayeyi alabilir ve üzerinde çalışmaya başlayabilirler.

Çalıştığım tüm çevik dükkanlarda, testçiler tavuk olarak kabul edilir, bu yüzden geliştiriciler gibi sprint içinde zaman çizelgesi olmadığından. Yazılımın ellerine geçmeden önce, test uzmanları planlarını yazmalı ve ortamları yazılımı almak için doğru şekilde kurulduğundan emin olmalıdır. Bunun bir parçası olarak, onlar gibi tasarım belgelerini gözetlemeliler.

Daha sonra, sprint doldurmak için arıyor olmalı. Tahminler iyiyse, elbette tahmin siyah bir sanat olsa da, nadiren tam olarak dolduğu için sprint sonunda boş zaman olmamalıdır .

Bir geliştiricinin sprint sonunda boş vakti varsa, değer kattığından emin olmak için bu süre hala izlenmelidir (yeni bir çerçeve öğrenmek, analiz yapmak, daha ileri testler vb.).

Hata tespiti bir sprint içine koymak için mükemmel kabul edilebilir bir faaliyettir. Bir özelliğe katkıda bulunur ve bu nedenle değer katar. Bu, bir sonraki süratten çalınan zaman olarak görülmemelidir - bir özelliği daha düzgün bir şekilde bitirmek.

İdeal bir dünyada, ekibiniz çapraz fonksiyonel olur . Herkesin kendi uzmanlığı vardır, fakat herkes başka bir uzmanlık olarak da çalışabilir. Eğer testçileriniz en basit görevleri kodlayamıyorlarsa, çapraz işlevli bir ekibiniz yoktur.

SCRUM yolu, ekibinizin çapraz fonksiyonel olmasını sağlamak olacaktır . Test cihazlarınız yine de test otomasyonu için becerilere sahip olmalıdır, bu daha az karmaşık olan şeylerin bazılarını kodlamak için kısa bir adımdır.