Uzman ekipler için Scrum

Scrum, genel üyeleri olan ekipler için en iyisidir, yani en az 2 kişinin aynı görevleri yapabileceği ekipler. Temel kaygım, uzmanlardan oluşan ekipler için scrum'a uyum sağlamak için iyi çözümler bulmak (neyi saklamak, neyi kaldırmak, neyi geliştirmek)?

5 geliştiriciden oluşan bir ekibiniz olduğunu varsayalım (gerçek değil, yalnızca örnek için):

1. C konusunda güçlü becerilere sahip bir matematikçi;
2. Bir DB geliştiricisi;
3. Bir Web Geliştiricisi;
4. Bir UX / GUI geliştiricisi;
5. Bir yazılım mimarı;

Burada hepsi uzmanlar ve kimse başka birinin yerini alamaz (böyle bir ekip oluşturma risklerini umursamıyorum, scrum'a odaklanmak istiyorum). Scrum bağlamında, düşüncelerim şöyle:

1. Yararsız bahar planları: gerçekten, matematikçi belirli bir görevin 2 puan değerinde olduğunu söylediğinde, kimse ona karşı oy kullanamaz;
2. Yararsız takım hızı metriği: herkes kendi görevlerine herhangi bir sayıda puan tahsis edebildiğinden, hesaplama hızı mantıklı değildir;
3. Günlük scrum toplantılarını haftalık (daha uzun) scrum toplantılarıyla değiştirin: ekibin her üyesi kendi görevleri üzerinde çalışırken, günlük scrum toplantıları bir "takım ruhu" tutmak için gerçekten önemli olmalıdır. Ancak günlük scrum toplantılarının yaklaşık 15 dakika sürmesi beklenmektedir. Bu açıkça diğerlerinin ne yaptığını ve yapacaklarını anlamak için yeterli değildir. Dahası, matematikçi çoğu zaman aynı şeyleri cevaplayacaktır: "Hala % & Lo (+? $$ + &) yapıyorum " ... Haftalık toplantılar daha fazla zaman verecektir. "İlk" scrum toplantıları ve "haftalık" scrum toplantıları arasında aynı toplantı süresini korumak için, her haftalık scrum toplantısı (haftada 5 gün, 4 hafta sprint ile, 4 saat süren sprint toplantıları ve 15 dakika süren günlük toplantılarla) sürmelidir: (4 * 60 + 20 * 15) / 4 =>

Yoksa scrum hala kullanılabilir mi? Belki başka bir çevik teknik kullanılmalıdır?

Scrum gümüş bir kurşun değildir. Her proje başarılı olmak için Scrum'ı kullanmak zorunda değildir. Ancak tanımladığınız durum Lean / Kanban için çok uygun. Kontrol etmek isteyebilirsiniz.

Kanban temelde sadece birkaç şey yapmanızı ister, hiçbiri sizin tanımladığınız takımla çelişmez:

• Değer akışını, yani Kanban panosunu görselleştirin. Scrum panosu bir Kanban panosunun özel bir uygulamasıdır; Uzmanlaşmaya izin vermek için uyarlamak mümkündür.
• Devam Eden İşi (WIP) sınırlayın, böylece ekibe atanan iş miktarı çalışmanın sürekli akışını sağlamak için yeterlidir - yani akışın başlangıcında (tasarım) veya sonunda (dağıtım) "tıkanma" olmaz .

Kanban hakkında bazı referanslara göz atmak isteyebilirsiniz:

• Bir gün Kanban Land
• Hazırlama Kanban (ücretsiz EBook)

Çevikliğin ne sunması gerektiğine bakmadan biraz scrum / çevik mekaniğine odaklanıyorsunuz. Eğer matematik adamı 2 puan tahmin ederse, kimsenin yanlış olduğunu söyleyemeyeceğini söylüyorsunuz. Amaç bu değil. Amaç, yaklaşmakta olan sprint için ulaşılabilir bir dizi hedef üzerinde anlaşmaya varmaktır. Bu görevdeki uzman olarak ne kadar süreceğini en iyi bilecek.

“Ya ya yalan söyler ya da yanlış yaparsa?” diyorsun. Benim tecrübelerime göre, insanlar daha fazla tahmin ediyorlar çünkü doğru bir tahmin için vurulduklarından korkuyorlar. Tahmin edilen diğerleri, her şeyi dengeleyen bir güvenlik marjı ekler ve garip tembel kişi acele etmek zorunda kalmamak için fazla tahmin yapar. Üçünden birincisi hız takibinde alınacak, ikincisi yanlış geliyor, çalışıyor ve üçüncüsü scrum dışında uğraşmanız gereken bir şey.

Günlük toplantı hâlâ fayda sağlıyor. Her biri uzman olsalar bile ekip üyeleri arasında bağımlılıklar vardır. Kullanıcı arabirimi adamı bir bildirim hatasını düzeltmek için sunucu adamını bekliyor olabilir. Sunucu adam hesaplamanın neden yanlış olduğunu anlamak için matematik adamında bekliyor olabilir. Aynı zamanda işlerinin sizi nasıl etkilediği ile ilgili değil. Bir ekip üyesi "Sebep X" nedeniyle sürekli olarak erteleniyorsa, ancak gelecekteki "Sebep X" oluşumlarını azaltmak için zaman almamışlarsa, bu zorlanabilir.

Açıkladığınız niteliklere sahip bir uzmanınız varsa, her birinin kendi görevi üzerinde çalıştığı ve nadiren diğerleriyle iletişim kurması gerektiği varsayımınız IMHO yanlıştır. Aslında, yeni bir özellik (bir "kullanıcı hikayesi") gerçekleştirmek için, genellikle

• veritabanını değiştir
• GUI veya Web arayüzünü ekleme veya değiştirme
• bunu doğru iş mantığıyla birleştirin (belki de "matematikçi" siz gelirsiniz)
• tüm bu değişikliklerin birlikte iyi çalıştığından emin olun

Bu yüzden, herkesin farklı bir uygulama / kullanıcı hikayesi üzerinde çalışabileceği ve tüm uygulama katmanlarında tüm gerekli değişiklikleri kendi başına yapabileceği bir uzman ekibinde olduğu gibi çok daha fazla iletişim kurmaları gerekeceğini tahmin ediyorum. Böylece, yukarıda listelediğiniz tüm Scrum takım aktiviteleri böyle bir takım için çok mantıklıdır.

Scrum kesinlikle durumunuz için hala uygundur, ancak diğer çerçeveler de olabilir.

Yeni özellikler sunmak için bu becerilerin tümüne veya çoğuna ihtiyacınız vardır. Ekibin birbirini etkileyen kararlar verebilmesi ve birlikte çalışabilmesi için iletişim kurması gerekir. Scrum toplantıları arasındaki süre ne kadar uzun olursa, olumsuz bir plan ekibi o kadar uzun sürebilir. Günlük olarak toplantı yaparak ekip bu durumlara hızlı bir şekilde cevap verebilir ve yeni bir plan hazırlayabilir.

Siz de gündeme getirdiğiniz bazı konulara değinmek istiyorum:

Çapraz İşlevli Takımlar Bir sürat koşusu hedefi ve / veya ürün biriktirme öğesi için gereken tüm becerilere sahipse bir ekip çapraz işlevli olarak kabul edilir. Bu mu değil her iş için 2 kişi olduğu anlamına.

Boyutlandırma Bir çözüm veya çözümün bir parçası değil, bir iş problemini veya ihtiyacını boyutlandırdığımızı hatırlamak önemlidir. Örneğin, sosyal medyayı / Twitter'ı e-ticaret sitemize entegre edin, UX, UI Tasarım, Programlama, Veritabanı ve Twitter API bilgisi gerektirir. Bir ekip bunu bir birim olarak boyutlandırmalıdır, çünkü ekip olarak bu işlevselliği sunacaktır. Bu boyut% 100 doğru olmayacak, ancak toplamda göreli boyutlandırmaya dayalı tahminlerin daha doğru olduğunu görüyoruz. Bu, bazılarının yüksek olacağı, bazılarının düşük olacağı ve birlikte hesaplanan tahminin tahmini süreden daha doğru olduğu anlamına gelir.

Yararsız bahar planları Sprint planlama, neyin üretilmesi gerektiğini ve nasıl başlanacağına dair bir plan belirlerken bir Scrum Takımı (Geliştirme Ekibi + Ürün Sahibi + Scrum Master) olarak işbirliği yapma zamanıdır. Bazı ekipler seçilen bu Ürün İş Listesi Öğelerini görevlere bölerken, diğerleri de geçmesi gereken testler gibi düşünmek için kendi ilerleme yollarını bulur (XP düşünün).

Bu iki yönlü bir işbirliği. Ekibe bir dizi PBI atamak ve "git" demek diktatörün rolüdür. Ekip, sprint'teki zamanı en üst düzeye çıkarmak için Ürün Sahibi ile görüşüyor.

Yararsız Takım Hızı Metriği Mimari / sistemden geçen ve ekibin kaç tanesinin tutarlı bir zaman kutusunda (sprint) teslim edildiğini anlatan deneyimin sorunlarını ve ihtiyaçlarını boyutlandıran ekiplerle artık bir takım tahmini sağlayabiliriz birikmiş işlerin geri kalanı için.

Yine, iki sprint aynı olmayacak ve kullandığınız Ürün İş Listesi öğelerinin örnek kümesi ne kadar küçük olursa, tahminlerdeki hata o kadar az yayılır. Bunu borsa gibi düşünün; her zaman yükseldi, ama bu aşağı yıllarımız olmadığı anlamına gelmiyor. Toplamda para kazanabilirsiniz, ancak herhangi bir ay, çeyrek, yılda yanlış tahmin edersiniz.

Günlük scrum toplantılarını haftalık (daha uzun) scrum toplantılarıyla değiştirin Daily Scrum, takıma 24 saat geri bildirim döngüsü ve gelecek 24 saat için planlama fırsatı sunmak için oradadır. Ne fazla ne eksik. "Üç Soru" bu çabayı kolaylaştırmaya yöneliktir.

5 gün boyunca herhangi bir geri bildiriminiz yoksa, görevlerinizin yeterince ince olmadığına inanıyorum. Bu sadece benim görüşüm, ama bir koç ve takım üyesi olarak deneyimlerime dayanıyor. Takımlar çabalarını daha sık konuşmalı, planlamalı ve bütünleştirmelidir.

Sonuç Scrum, öğrenmeyi ve öğrenme ile (gerçek öğrenmenin gerçekleştiği yerde) öğrenme ile dengelemeyi kolaylaştırmayı amaçlamaktadır. Süreçleriniz ve araçlarınızla zaman içinde deney yapın ve etkiyi incelemek için Scrum'ı kullanın. Günlük Scrum'lara geçmeyi deneyin ve ekiplerin doğru işlevselliği sunmalarına yardımcı olup olmadığını incitin. Bu senin için işe yarayabilir.