SCRUM, ekip üyelerinin paylaşıldığı bir çevreyi nasıl yönetir?

Peki, sorular kendi kendine söyledi. Benim işyerimde bu vakalar oluyor, ama aynı zamanda birçok Agile kitabı aynı işyerinde çalışmayı ve mevcut projede çalışma hızında daha hızlı olmak için yoğunlaşmayı teşvik ediyor.

Belki konu hakkında o kadar bilgili değilim, belki de o kadar katı değil ama, bu yüzden Agile'ın bu gibi durumlarda ne önerdiğini bilmek istedim.

Bir kimse?

Scrum metodolojisinde sadece tahmini etkiler.

Her bir projeye zaman ayırmasına bağlı olarak o kişi için odak faktörü atayacaksınız.

Dolayısıyla, Proje A ve Proje B üzerinde eşit olarak çalışıyorsam, Proje A aşağıdaki gibi kaynakları hesaplardı:

Proje A -% 70
Sam - 10 gün takım odak faktörü,% 100 tahsis (odak faktörünün 7 sonra)
Joe - 10 gün,% 100 tahsis (odak faktörünün 7 sonra)
Me - 10 gün,% 50 tahsis (odak faktörünün ardından 3.5 )
Toplam: 25 gün *% 70 odak faktörü = 17,5 öngörülen hız

Ayrıca , bölme projelerinin verimliliğinin azalması nedeniyle, tam zamanlı ekip üyeleri için ve tüm ekip için bir kez yerine yarı zamanlı ekip üyeleri için odak faktörünü ayrı olarak hesaplayabilirsiniz . Bu durumda, % 50 proje odak faktörü kullanacak ve % 25 veya% 2,5 öngörülen hız için% 50 kişisel tahsisat ile çarpacaksınız .

Bunun pratikte ne kadar iyi çalıştığı, paylaşılan bir kaynağın her bir proje için ne kadar zaman harcayacağını ve Scrum'ın sizin için başka şekillerde ne kadar iyi çalıştığını önceden bildiğiniz bir faktör olacaktır.

Scrum'daki tecrübelerime göre, hız ancak proje ve ekip aynı ve adanmış kaldığında tahmin edilebilir. Bunlardan herhangi biri değişirse, tahmininizi yapmak için önceki sprintlerden gelen hız hesaplamalarını gerçekten kullanamazsınız. Deneyebilirsiniz, ancak normalde olduğundan çok daha fazla kapalı olacaksınız.

Genel olarak, takımı mümkünse, bir sprint boyunca LEAST'ta aynı ve adanmış tutmaya çalışmalısınız.

Bence bu tüm projeleri çok kötü etkileyecek. Bu sadece tahmin ya da planlama meselesi değildir. Evet, eğer ekip üyeleri üç projeye tahsis edilmişse ve her projeye% 33 tahsisi varsa, ihtiyacınız olan her şeyi bildiğinizi ve bitirdiğinizi söyleyebilirsiniz, ancak bu doğru değildir.

Bağlam değiştirme çok pahalıdır. Ayrıca, birden fazla paralel projeye tam bağlılık sağlamak imkansızdır, bu nedenle geliştirici zamanının% 33'ü, geliştirici yalnızca tek bir projeye atandığında% 33'ten çok uzaktır.

Bunun tamamen başarısız olduğu bir başka yer de iletişimdir. Şu anda A projesinde çalışan bir ekip üyesinin dün A projesinde çalışan ancak şu anda B projesinde çalışan bir ekip üyesiyle bir şeyler iletmesi gerekiyorsa ne olur? Bu ikisi için bir engeldir, çünkü ilki bilgiye ihtiyaç duyar, ancak ikincisi tamamen farklı bir projeye odaklanır ve A projesi için herhangi bir soru onu rahatsız eder. A projesinden Scrum ustası geliştiricisinin olabildiğince hızlı bilgi almasını istiyor ve B projesinden Scrum ustası, takım üyesinin B projesiyle ilgili olmayan bir şeyden rahatsız olmasını istemiyor. ekibin geliştiricileri aynı projede aynı gün içinde çalışacaklar - bu, tüm planlama süreci için büyük bir zorluk ve tamamen kaçınılması gereken bir şey.

Ayrıca tüm toplantıları çarpışmayacak şekilde planlamanız gerekir. Toplantının aslında israf olduğunu da anlamanız gerekir ve bu nedenle süreç üzerinde kontrolü hala elinde tutabilmek için mümkün olan en az sayıda toplantı olması gerekir. Ancak, üç projede çalışan ekip üyeniz varsa, bu üç proje için tüm toplantılara katılmalıdır => Geliştiricinin herhangi bir iş değeri üretmediği üç kat daha fazla toplantı.

Sonuç çeviklik aynı zamanda atıkların azaltılması (evet Yalın yaklaşımdan) ve ekiplerin ekipler arasında paylaşılması, atıkların getirilmesi ve verimliliğin azaltılması açısından en kötü başarısızlıklardan biridir. Tek bir projeye% 33 tahsisi için verilen işletme değerinin, tam zamanlı tahsinin% 10-16'sından sağlanan işletme değerine eşit olacağını tahmin ediyorum. Bu, geliştiricinin projeye yalnızca 1/3 kez katılmayacağı, aynı zamanda verimliliğinin 1/3 ila 1/2 arasında olacağı anlamına gelir.

SCRUM, paylaşılan üyeleri olmayan kararlı bir ekibe sahip olmayı temel alır;

Bize = = yanlış yapmamız gerektiği söylendiğine göre, nasıl x yaparız

SCRUM değilse, SCRUM demeyin!

Kilit soru, ekip üyesinin projeye bağlılığıyla ilgilidir. İdeal olarak, bir ekip üyesi projenin başarısına tamamen bağlı olmalıdır. Bu, zamanının tamamen projeye adanmış olduğu anlamına gelmez, ancak proje üzerinde çalışırken proje için gerekli olan her şeyi yapabileceği anlamına gelir.

Genellikle bir projede sadece yarı zamanlı çalışan personel ile, sadece sınırlı bir taahhüt kapsamı içindedir. Örneğin, yalnızca veritabanı optimizasyonu yapan bir kişiniz olabilir.

Bu durumda, genellikle bu kişiye ekip üyesi yerine "kaynak" muamelesi yapmak en iyisidir. Takım, belirli bir Sprint'te bu kaynağın ne kadarını isteyeceklerine karar verir ve onlara Sprint için tamamlamaları gereken çok özel görevleri verir. Bazen Takımın bu kaynaktan sorumlu belirli bir ekip üyesi olması en iyisidir ve günlük Scrum'da bu kaynak için durum güncellemeleri ve engel raporlaması yaparlar.

Scrum'ın temel yönlerinden birinin ekibi bir kerede tek bir şeye odaklı tutmak olduğuna inanıyorum (bir proje, bir hikaye, bir görev ...)

Kaynakları bir projeye tahsis edemediğiniz durumda "Agile ne öneriyor" diye sordunuz ... Birini denemeyi düşünebilirsiniz:

• Birden fazla projeyi kapsayan büyük bir Kanban panosu tutun. Bir projeye ihtiyaç duyulduğundan, insanlar kapasiteye sahip olduklarından, ana hikayeleri çeker. Sorun, tüm projelerin birlikte yönetilmesidir, bu da herhangi bir proje için genel öngörülebilirliği azaltır. Bununla birlikte, bireysel hikaye / Kanban unsurları odaklanmış bir kişi veya ekip tarafından çekilecek ve geliştirilecektir. (Kanban panosundan çekmek için daha küçük 4-5 kişilik ekipler oluşturmayı deneyebilirsiniz
• Yalnızca taahhütlü kaynaklar atayın. Bir proje için özel kaynaklardan oluşan bir havuz bulundurun. Bunlar bir takım olarak korunur ve kesintiler sıfıra yakın tutulur. Ayrıca biriktirme listesi olmayan ve proje / ürün odağı olmayan bir "hızlı müdahale ekibi" bulundurun. Kesintiler ortaya çıktıkça, hızlı müdahale ekibi kesintileri ele alır. Kesintileri olmadığında, derleme sistemini geliştirmeye, otomasyon test çerçevesine vb. Eklemeye odaklanabilirler. Ayrıca, kod incelemelerine / tasarım incelemelerine ve ortaya çıkan zor / kötü hataların giderilmesine yardımcı olabilirler. Gelişimi bu ekip yokmuş gibi yönetin. Tek yapabilecekleri teslimatta çekmek. İnsanları "taze tutmak" için bu ekipte döndürün (hızlı yanıt ekibinde olmaktan hoşlanıyor / nefret ediyor gibi görünüyor ...)

Bu yardımcı olur umarım!