Scrum'ın tanımlanmış rolleri olan bir takım için nasıl çalışmasını sağlamak gerekir?

Bazı arka plan bilgileri

Kurum içi yazılım geliştirme ekibinin bir parçasıyım. Bu oluşmaktadır

• 5 geliştirici (2 ila 5 yıl arasında değişen deneyimlerle, onlardan biriyim)
• 3 uygulama personeli (yazılım dağıtımını ve eğitimini yaparlar)
• ve 1 proje yöneticisi.

Çok sayıda küçük ve orta ölçekli proje geliştiriyoruz ve zaman çizelgeleri genellikle çakışıyor. Gelişim şöyle gider:

1. "Müşteri" bize bir dizi başlangıç ​​gereksinimi verir
2. Sistemi belirtilen spesifikasyona göre geliştiriyoruz
3. Söz konusu sistemi "istemciye" sunmak
4. "Müşteri", söz konusu sunuma dayalı olarak bize ek gereksinimler sağlar
5. "İstemci" yeni gereksinimler tükenene veya dağıtım hedef tarihi kapanana kadar 2-4'ü tekrarlayın
6. Sistemi kurma ve dağıtma

Bu, çoğu zaman teslim tarihlerini işleyen "müşteri" olmasının yanı sıra (burada Programcılar ve PM.SE'de gördüğüm kırmızı bayraktır) ve kesin bir geliştirme metodolojisi yol açmıyoruz kovboy kodlama, neredeyse sürdürülemeyen kod ve üretimden geçen hatalar, diğer şeylerin yanı sıra. Bu yüzden Scrum gibi Çevik tabanlı bir metodoloji benimsemeyi seçtik.

Neden Scrum?

Bu bizim yöneticimizin inisiyatifiydi ve mevcut durumumuz göz önüne alındığında herkes bu konuda hemfikir görünüyor.

Scrum ile ilgili sorun

Scrum'ın bazı unsurları, özellikle Agile geliştiricilerinin "all-all-trades" niteliği ile kolayca ele alamadığımız mevcut düzenimizle çatışıyor. Dağıtım ekibi nasıl programlanacağını bilmiyor ve geliştiricilerin ortalamanın altında iletişim ve eğitim becerileri var. Ve bu kadro yakında hiçbir zaman değişmeyecek.

Soru

Scrum'ın bir metodoloji olarak etkinliğini etkiler mi? Telafi etmek için başka değişikliklerin yapılması gerekir mi? Yoksa düşünceyi tamamen terk etmek ve farklı bir metodoloji düşünmek daha mı iyi olur?

Aslında, şu anki çalışma şekliniz düşündüğünüz kadar Scrum'dan o kadar uzak değil.

Scrum'da ayrıca bir başlangıç ​​gereksinimleri seti alırsınız, bunları uygular ve sonucu gösterirsiniz ve gösteriye dayanarak size yeni gereksinimler verilebilir veya paydaşlar ürünün daha fazla geliştirmeye gerek olmayacak kadar iyi olduğuna karar verebilir.
Sizin durumunuzda, bahsettiğiniz "müşteriye" Scrum'da Ürün Sahibinin rolü verilebilir (proje içindeki öncelikleri belirleyerek ve ne zaman kullanıma hazır hale getirileceğine karar vererek bu rolü zaten doldurmuş gibi görünüyorlar).
Büyük bir değişiklik, bir yinelemenin uzunluğu olabilir. Scrum'da, bir yineleme 1 ila 4 hafta arasında bir yerde sürmelidir.

Takım kompozisyonu ve gelince becerikli kimse yanılgı: Scrum yok değil bir becerikli kimse olmaya herkesi gerektirir. Scrum, ekibin bir bütün olarak ürünü bir gereksinimler listesinden dağıtılan / dağıtılabilecek bir şeye götürmek için gerekli tüm yetkinliklere sahip olmasını gerektirir.
Sizin durumunuzda, proje başına bir veya daha fazla geliştiriciden (çoğunlukla uygulama ve test çalışmasını yapan) ve "uygulama personelinin" üyelerinden oluşan ve çoğunlukla özellikler için kılavuzlar ve eğitim materyali oluşturmaya odaklanan bir ekibi kolayca görebiliyordum. geliştiriciler şimdi uyguluyorlar.

Müşteri / Ürün Sahibi dağıtım için yeşil ışık verdikten sonra, scrum ekibinin işi çoğunlukla yapılacaktır, böylece geliştiriciler başka bir projeye gidebilir (ve yalnızca dağıtım sonrası sorunların düzeltilmesi için talep üzerine kullanılabilir) ve uygulama personel eğitimin gerçekleştirilmesine ve sunumun desteklenmesine geçebilir.

Son sürümün olması, bu sürümde hangi işlevsellikte olması gerektiği konusunda yeterli esneklik olduğu sürece gerçek bir sorun değildir.

Alternatif istersiniz, bu yüzden eXtreme Programming (XP) diyeceğim. Özellikle çift programlamanın burada size yardımcı olabileceğini düşünüyorum.

Farklı becerilere sahip insanları bir araya getirerek, hangi yeteneğin önemli olduğu önemli değildir: kahve yapma, test etme, eğitim vb. Becerileri takımın etrafına yayabilirsiniz.

Ama dürüst olmak gerekirse, SCRUM sizin için bu kadar uzakta gibi görünmüyor. SCRUM'un bir kısmı esnek olmak ve ekibiniz için en iyisini bulmaktır. XP'nin bir kısmı ekibinize saygı duyuyor ve uyum sağlıyor. Belki 100 yıllık bir sürede, zor ve hızlı kurallarla daha gelişmiş bir mesleğe sahip olabiliriz (şüphe etmeme rağmen) ama şimdilik, sizin için işe yarayan şeyi yapmak bizim elimizde. Önemli olan geri bildirim döngülerine sahip olmaktır. Bir şey işe yaramazsa, ekibin bunu tartışması ve işe yarayan bir şey bulana kadar yeni şeyler denemesi gerekir.

Scrum'ın tanımlanmış rolleri olan bir takım için nasıl çalışmasını sağlamak gerekir?

Sadece yap. Scrum rehberine göre, herkes bir geliştirici ama burada dünya gezegeninde, farklı insanlar masaya farklı şeyler getirecek. Ben neredeyse linç var diğerleri yazılım yazarken bazı insanlar test gerçekten olduğunu ileri sürdü zaman.

Ele almak isteyebileceğiniz bazı şeyler:

sprint

Görünüşe göre ilk gelişim aşamasına ve ardından görünüşte sprint olan bir seriye sahipsin. Bunu parçalamayı düşünün. Müşteri sadece bir şeyi erken görmeyecek, aynı zamanda gelişim aşamaları hakkında daha iyi bir fikir edineceksiniz.

Sabit son tarihler

Bu zaman zaman tekrar ortaya çıkıyor ve aslında şu anda çalıştığım devs tarafında kalıcı bir diken. Scrum sprint için tahminleri belirler - başka bir şey değildir. Evet, bir dizi sprintten sonra hedefe vurabilirsiniz, ancak müşterinin ilk sürümlerini gördükten sonra kapsamın önemli ölçüde kayması muhtemeldir. Bu kendi başına bir sorun değildir, ancak müşteri daha sonraki çalışmalarda daha fazla çalışmanın yapılacağı ve bilinen gereksinimlerin üzerinde ve üstünde olacağının farkında olmalıdır.

Durumunuz Kanban için daha iyi bir eşleşme olabilir, çünkü oradan başlayabilir ve oradan tekrarlayabilirsiniz. Bu, mevcut projelerinizi bozan büyük bir patlama tanıtımına sahip olmayacağınız anlamına gelir - sadece bir tahtadaki görevleri görselleştirerek ve retrospektifler ve günlük toplantılar gibi bazı uygulamaları benimseyerek başlayın.

Scrum'a göre biraz daha dikkatli olmalısın çünkü o kadar kuralcı değil: bu yüzden uygun bir çevik zihniyet aşılamak yerine daha önce gitmiş olanlara geri dönme eğilimi var.

Scrum, üst üste binen ayrı projelerle iyi çalışmaz, çünkü tüm sprint için bir proje üzerinde çalışan istikrarlı bir insan grubunuz yoktur. Bu yüzden ayrıntı düzeyi gibi kavramlar sadece sizi üzüyor.

Ancak önce müşteriye en iyi maliyeti / faydayı veren hikayeyi almak ve tam otomatik test de dahil olmak üzere, bir sonraki hikaye üzerinde çalışmadan önce konuşlandırılacak kadar iyi bir kaliteye uygulamak faydalı bir kavramdır. Benzer şekilde, bir öykü için yazılan tüm kodların öykü "tamamlanma" olarak değerlendirilmeden önce başka bir geliştirici tarafından incelenmesini gerektirir.

Uygulama personelinizin eğitim ve referans belgeleri yazması gerektiğini düşünüyorum, kod yazılmadan önce her hikaye için yazılabilir (ilk taslak) ve böylece kabul testleri haline gelebilir.

Uygulama personelinin girdisinin geliştiricilere en fazla yardımcı olacağı her projenin başında, bir önceki projenin dağıtımına% 100 bağlı olduklarını göreceksiniz. Bu nedenle, geliştiriciler mevcut projenin kodunu yazarken, uygulama personelinin bir sonraki proje için hikayeleri ve kullanıcı belgelerini yazmaya çalışıp çalışmadığını düşünün.

Testlerde kullanılan örneği yazan uygulama personeli ile “davranış odaklı gelişim” işe yarayabilir.

Bu yüzden size yardımcı olacak biraz Scrum var, ama Scrum'ı kullanmak yerine Scrum'dan eğilmeye çalışın.