Geliştiricilerin Scrum'daki iki farklı proje arasındaki zamanı nasıl koordine edilir?

Yeni kurulmuş bir ekibin scrum ustası oldum, bu da bir yazılım oluşturmaktan ve diğer konuşlandırılmış uygulamaları sürdürmekten sorumlu. Temelde her takım üyesinin geliştirme ve operasyon görevleri vardır.

Son birkaç hafta içerisinde nasıl çalıştıklarını gözlemledim ve ekibin bu görevleri koordine etmekte zorlandığını fark ettim. Bir geliştirici kodlamaya yoğunlaştığında, üretimde ortaya çıkan bir sorunu çözmek için kesintiye uğrar ve önceki görevine tekrar odaklanması zorlaşır.

İşlemlerin çalışması için geliştirici süresinin% 'sini ayırmaya çalıştım, ancak görünüşe göre bu sorunu çözmüyor. Daha önce bu duruma rastlayan aldatmaca ustalarından haber almakla ilgileniyorum, bunu nasıl başardınız ve önerileriniz neler?

Bu sorun scrum kadar eskidir. Bir çözüm var, ama hoşuna gitmeyecek.

• Biriktirme listesine yeni görevler koyun.
• Geliştiricileri bölmeyin.
• Bir sonraki sprint bekleyin.

Dev'lerinizi birden fazla iş parçacığına koymak, iki ayrı backlog'a sahip olmak ya da zamanlarının sadece bir yüzdesini atağa vermek, tüm işin zorluğuna ulaşmak için çalıştığı şeye, yani tutarlı bir iş akışına karşı çalışır.

Bu tür şeyleri denerseniz, temelde tüm ilgili sorunlarıyla birlikte “kaos” veya “JFDI” geliştirme metodolojilerine geri dönersiniz.

• Geliştirici, hareket halindeyken herhangi bir zamanda on görevi vardır. Kimse ne üzerinde çalıştıklarını ya da ne zaman biteceklerini bilmiyor.
• Projeyi bitirmek için bilinmeyen bir zaman var, çünkü diğer projelerin aynı anda ne olduğuna bağlı.
• Proje önceliği konusunda tutarlı bir görüş yok. Diğer yöneticiler, geliştiricileri evcil hayvan projelerine yönlendirir.

Elbette bu tavsiyeye verilen olağan cevap "Ama bunu yapamam! İşletmenin bu üretim hatalarının en kısa zamanda düzeltilmesi gerekiyor!"

Ama bu gerçekten doğru değil.

İşletmeyi bu ölçüde etkileyen birçok gerçek hataya sahipseniz, profesyonelleşmeniz ve testlerinizi geliştirmeniz gerekir. Hepsini düzelene kadar sadece böcekler ve otomatik testler üzerinde çalışın. Bir QA ekibi işe alın ve tüm yeni sürümlerin cehennemini test edin.

Ne daha muhtemel olsa da, aşağıdakilerden biri:

• Hatalar operasyonel problemlerdir, disk alanınız tükenir, DR, Yedek yok, yük devretme yok vb. OPS ekibi alın.

• Hatalar, kullanıcıların sistemin nasıl çalışması gerektiğini anlamayan "Bu oldu! Bir hata mı?". Bir yardım masası edinin ve kullanıcılarınızı eğitin, belgeler yazın.

• Geri alma korkusu. Yeni bir özellik başlattınız ve bir şey bozuldu, acele etmeye kalkmayın. Önceki versiyona geri dönün ve böcekleri birikim listesine yerleştirin.

Burada kutunun dışında düşünmeye çalışıyorum.

Ürün sahibine işlerin yolunda gitmesini sağlamak mümkün olmayabilir. Bekleyemeyen, geliştirici desteğine ihtiyaç duyulan müşterilerle buluşma, bir geliştiriciyi bir süre için sprint dışına çıkarmanız gereken kritik hatalar olabilir.

Neden bunu öngörmeye çalışıp avantajınız için kullanmıyorsunuz?

Belki de gerçekçi olması için 5+ bir takıma ihtiyacınız olacak.

Ancak neden bir geliştiriciyi her sprintin dışına çıkarmıyorsunuz (geliştiriciler arasında döner, her biri sırasını alır).

Büyük olasılıkla tam geliştiriciyi düzeltmelerde kullanmak için yeterli hata olmadığı için yapılabilecek başka sorunlar veya görevler vardır.

• Performans darboğazlarını veya ölçeklenebilirlik sorunlarını belirlemek için testler yapmak
• Yapı sisteminin bakımı
• Müşterilerle toplantılar
• Yeni çerçeveler / kütüphaneler araştırmak
• Kullanmak istediğiniz dil özelliklerini inceleyin
• Güvenlik konularında okuma
• Veritabanı Bakımı
• Sunucu bakımı

Takım hızı yükselebilir, stres düşebilir, yönetim ile çatışmalar düşebilir, bilginizi geliştirmek için zaman kazanırsınız.

Kullandığım gerçekten gerekli üretim sorunları için geliştirici çabalarını yönetmek için etkili bir çözüm "Batman yaklaşımı" dır.

Yeni işlevsellik geliştirirken üretimin sorumluluğunu desteklemesi, içerik değiştirmedir, bu nedenle bunu sınırlandırmayı hedeflemelisiniz.

Ekibin katılımıyla, takım üyelerinin bir listesini oluşturun ve üzerinden geçin, böylece her gün stand-up toplantısında yeni bir kişi "Batman" ilan edilir ve o gün temel üretim sorunlarına cevap verir. Takımın geri kalanı bağlam geçişi yapmak zorunda kalmadan gelişime odaklanmış kalabilir ve herkesin destek ağrısından adil bir payı vardır. 5 kişilik bir ekiple, geliştiricinin kesintiye uğrayabileceği haftada bir gün ve 4 gün kesintisiz, öngörülebilir geliştirme süresi.

Bu, ekip içinde paylaşılan bilgi / deneyim avantajına sahiptir, bu nedenle belirli sorunları çözmek ve tek bir başarısızlık noktası ve destek sorunlarının adil bir şekilde bölünmesinden sorumlu bir kişiniz yoktur.