"Tipik" bir SCRUM ekibimiz var ve bir sprint için çalışmaya ve aynı zamanda bir birikimde kalmaya kararlıyız. Son zamanlarda, grup dışı çalışma yapan bir iş tecrübesi geliştiricisinin çalışmalarını (normal çalışma saatleri / sprint dışında çalışmayı seçerek) çalışmalarına dahil etmeye çalışmakla ilgili bir sorunla karşılaştık.

Bir örnek vermek gerekirse, takım 50 çalışma puanı alırsa, sprint sonuna kadar SCRUM çerçevesinde çalışanların hepsini tamamlayacaklarını söyleyelim ve onlar ve şirket mutlu olur. Ekip üyelerinden biri kendi başına, bir backlog öğesinde, kendi boş zamanlarında çalışmaya karar verir. Bu işi kontrol etmiyorlar, ancak tasarruf ediyorlar (TFS kullanıyoruz ve bir rafta bulunuyor).

Bununla nasıl başa çıkılır? Sorunlardan birkaçı ..

• Bir sonraki sprint boyunca bu ekip üyeleri, programlama çalışmasının% 99 yapıldığını ve sadece kod incelemesi ve test edilmesi gerektiğini söylüyor. SCRUM ve çevik metodolojide bununla nasıl başa çıkıyorsunuz?
• Diğer geliştiriciler, çalışmaların bant dışı yapılmasından bu yana, bu öykülerle ilgili tasarım kararlarında yer almadığından şikayetçi.
• Ürün sahibimiz, bu "özgür" işi yapmaya caziptir ve çalışmayan üyelerin, ekibin aksi halde sprint (ler) de başaramayacağı ürüne daha fazla özellik kazandırmak için bunu muhtemelen bilerek yapmak istemektedir. Bunun "süreci" bozduğuna dair bir görüş var. Açıkçası QA, UI ve dokümantasyon işlerinin hala bu iş üzerinde yapılması gerekiyor.

SCRUM ekibini fazla mesai yapmaya zorlamama konusunda çok fazla tartışma görüyorum, peki sprintlerin planlanması ve yürütülmesi sırasında ortaya çıkan beklentilerin üstünde ve ötesinde çalışan ekibin bir üyesi ne olacak? Bu kişiyi ele geçirmek ve fazladan çalışamayacağınızı söylemek (tereddüt etmeden yakma konusunda dikkatli olmak için) tereddüt ediyorum, ama aynı zamanda ekibin bazı üyeleriyle (ama hepsiyle değil) bazı sorunlara neden oluyor gibi görünüyor.

Başarılı bir üye tarafından yapılan çalışmaları SCRUM'a ve yazılım geliştirme için çevik sürece nasıl dahil edersiniz?

Tamam, bu yüzden birisi hevesle yapılması gereken büyük kodu yazıyor, tam olarak değil. Tüm vurguyla:

BIRAK ONLARI

Scrum sprintlerinde bazı komplikasyonlara neden oluyor. İşlerin büyük düzeninde gerçekten önemli mi? Yapması gereken şeyi başarırsa, bırakıp senin için harika şeyler yapmasına izin ver.

Şirketlerden ayrılan birkaç şaşırtıcı programcı tanıyorum çünkü programcıların Scrum gibi yapay bir sistemin kısıtlamaları dışında kalmasına izin vermediler. Diğer geliştiricilerin girdiyle ilgili şikayetleri varsa (tamamen geçerli şikayetler, ekleyebilirim), en az müdahaleyle en iyi yaptıklarını yapmaları için “% 20 zaman” programı sunmak en iyisi olabilir.

Gelecekteki hikayeler yerine (diğerlerinden girdi gerektirebilecek), geliştiricinin yeni teknoloji veya özellikleri denemesine izin verin. Aksi takdirde keşfedilmeyecek yeni ve harika bir fırsat bulabilirsiniz. Eminim, bu geliştiricinin, izin vermeniz durumunda denemek istedikleri birkaç şey olduğuna eminim.

Burada düşünmeniz gereken iki şey var:

1. Birinin yaratıcı akışını engellemeyin.
   • Bir dev mesai saatleri dışında çalışmak isterse, izin verin.
2. Başkaları için iş yaratmayın.
   • Bir dev mesai saatleri dışında çalışmak isterse, başkaları için daha fazla iş yaratmamak daha iyi .

Nokta 2, diğer geliştiricilerin endişe duyduğu şey olabilir.

Bahsettiğiniz gibi, tüm takımın girişi olmadan kodun yazılmasından hoşlanmazlar. Bunun nedeni tasarım açısından yetersiz kalması olabilir. Ve alt tasarımlı kodun etrafındaki diğer kodları etkilemenin bir yolu vardır.

Ne yapabilirsin?

İddialı dev kodunu kalbinin içeriğine izin verin, ancak ders dışı kodunun kullanılacağını varsaymak için hiçbir neden olmadığını açıkça belirtin .

Sonuçta, o bir takımın parçası ve bu yüzden takım tüm kodların nasıl geliştirildiğiyle ilgilenmeli.

Bununla birlikte, çalışmaları sağlamsa ve ekibin tasarıma karar verdiğine uyuyorsa, zaten yazdıklarının çoğunu kullanabilecek (bonus!). Olmazsa, bir dahaki sefere karar vermeye karar verdiğinde tasarımı hakkında daha fazla düşünmeye zorlayacaktır.

Bu şekilde hiç kimseye HAYIR söylenmez ve kimsenin onlar için fazladan bir işi yoktur.

Onu takıma geri götür

Kendine sormalısın (veya daha iyi çalışanlar da dahil olmak üzere takımı):

Bu davranış neden bir problem?

Geliştiriciyi bir işveren olarak etiketlediğinizden beri, çalışmalarının iyi kalitede olduğunu düşünüyorum, bu yüzden bunun bir sorun olmadığını varsayacağım.

Fakat başka problemler var:

• Ekstra iş düzgün bir şekilde test edilmedi
• belgelenmemiş
• takımın geri kalanı bunu bilmiyor
• geliştirici, uygulanacak bir sonraki şeye karar verir.
• geliştirici, çalışmalarına dahil etmek için çeşitli paydaşlardan herhangi bir geri bildirim almamaktadır.

Bir sonraki neden şöyle:

Geliştirici neden yapıyor?

• Sprint sonunda yeterli iş kalmadıysa, bundan sonra ne yapılacağı hakkında bir takım kararı (PO dahil) verilmelidir. Geliştirici neden bu karardan kaçınır?

Bu soruları cevapladıktan sonra kendi sorunuzu cevaplamaya başlayabilirsiniz:

• eğer sorun değilse, onun işini yapmasına izin verin. Bazı insanlar SCRUM'u bir din olarak görse de, böyle olmamalıdır.
• Daha büyük olasılıkla takımda iki probleminiz var: Biri haydut geliştiricisinin neden olduğu ve haydut geliştiricisinin davranışını tetikleyen biri. Daha sonra çözmek için bir yol bulun ve ilk olan uzaklaşacaktır.

Karışıma ücretsiz çalışma eklemenin iyi bir şey olduğu fikrini sevdiğim kadarıyla, bu ücretsiz bir iş değil - bu tek geliştirici aynı zamanda test cihazı ve KG, yapı ustası ve tasarımcı ve diğer her şey değilse. Eğer eserleri, herhangi bir etkisi olmadan bir sonraki sprint içine sokulabilirse, o zaman ... devam et. Ama bence asla böyle olmaz. Diğer herkes, en azından ne yaptığını ve bunun üzerinde ne gibi bir etkisi olduğunu anlamalıdır. Değişikliklerinin içinde olduğunu ve çabalarını çoğaltmamak için olduğunu anlamak zorundalar - bir görevde çok çalıştıklarını söylemek, geçen hafta yaptığı haydut adamı bulmak için zor.

Yine de çevik bir ortamda çalışıyorsunuz ve çeviklik hakkında bildiğim bir şey, size karşı değil, sizin için çalışacak şekilde tasarlanması. Bu nedenle, bu tür bir müfredat dışı faaliyetin gerçekleşmesine izin vermek için çalışma şeklinizi değiştirmeniz gerekiyor. Bu, herkesin katılımını ve anlaşmasını sağlamak anlamına gelir; bunu katılımları olmadan yapamazsınız. Hayati önem taşıyor. Takım bundan hoşlanmazsa, haydut adam yapmayı bıraktı. Sonu. Yaptığı iş ne kadar iyi olursa olsun, istediği şeyi yapan tek bir erkek değil, onun takım çalışmasıdır. Takım önce gelir.

Bu yüzden herkesi bir sonraki planlama toplantısına oturtmanız ve bunu tartışmanız gerekir, tüm ekip üyelerinin buna izin vermeye veya bu tür bir etkinliği daha iyi yönetmek için sürecinizi değiştirmeye karar vermesi gerekir.

Belki de herkesin tercih ettiği projeler üzerinde çalıştığı ve onları masaya getirdiği bir çözüm elde edersiniz (teslimatınıza kaçırabileceğini hayal edersiniz :)) ilk başta onunla ilgili sorunu vurgulamaktadır) Her bir geliştiricinin, istedikleri çözümü geliştirecek bir otomominin olduğu alan, kaç tane açık kaynak projesinin çalıştığına benzer şekilde “katkıda bulundu” ya da herkese deneme için serbest zaman verebilir (eski% 20 zamanı).

Bu geliştirici testler ve temiz / katı kodlar yazıyor mu yoksa hızlı bir şekilde yapabileceklerini zorluyor mu? Şahsen, sizin tahminlerinizi mahvedeceği ve başka sorunların ortaya çıkacağına dair belirsiz saatler dışında çalışmasına izin vermem.

Ancak, işleminizde asla katı olmamalısınız. Scrum sadece bir çerçevedir, bu yüzden süreci her zaman fazladan zaman içerecek şekilde ayarlayabilirsiniz (ancak yine de birisinin yapabileceklerini planlamak zordur).

Ayrıca, projeden başka şeyler üzerinde çalışmasını da isteyebilirsiniz. Yeni teknolojiye bakmak ya da farklı şekilde yaptığı şeyler hakkında eğitim yaratmak. Alt satırda, planlı programın dışında yapılan bir şey, tahminlerini mahveder ve bunun olmasına izin vermem.

biz de aynı şeyle karşılaştık, temel olarak 20 puan gibi bir şey yaptık, ancak geçen hafta veya sprintin ortasında bile kodlama görevinden kaçtık, ancak Test ve işlemin geri kalanı nedeniyle başka bir PBI seçmek için risk almadık. programcılar backlog'a bakmak ve gelecekteki PBI'leri (sessizce!) geliştirmeye başlamak ve ekibin geri kalanını PBI'nin kod incelemesi ve test etmeye hazır olduğunu planlama konusunda bilgilendirmek oldu! aynen dediğin gibi

Aslında bizim PO'larımızdan daha fazla yetenekli olduğumuza dair endişeler uyandırdı, ancak ekibimizin potansiyelini tam anlamıyla kullanmıyoruz, ki bu kısmen doğruydu ama evet, belki programcılarımız daha fazlasını yapabilirdi ancak testçilerimiz bu hızı takip edemediler. sprint başarısız bir risk vardı. Bu konuyu düşündükten sonra, scrum hakkındaki görüşümüzü değiştirmemiz gerektiğine karar verdik ve asıl mesele, insanların bu riski almak istememeleriydi çünkü PBI'ları Taahhüt ettik, böylece ekip bu toplama riskini almak için iyi hissetmedi. ücretsiz programcımız olması durumunda yeni PBI'ler.

Sadece taahhütte bulunmak yerine PBI tahmin etmeye başladık . Temelde tahmin etmek, sprintin planlanmasında ve başlangıcında 25 puan topladığımız anlamına gelir. Ve programcı sprintin ortasında serbest kaldığında, çünkü artık kodlama işi olmaz, böylece gelecekteki PBI'lardan birini seçip Geçerli Sprint'e koyup çalışmaya başlar. PBI, tüm süreçleri (test etme, birleştirme vb.) aynı sprint içerisinde geçebiliyorsa, bu PBI nedeniyle sprint başarısızlığa uğratmaz ve kalan işi ileriye götürürsek, takım için bonus puandır ( sonraki sprint test veya meging veya vb) ve kalan iş için yeniden poker. Böylece daha kötü durum senaryosunda iki farklı süratle yapılabilir. Scrumbut gibi gelebileceğini biliyorum ama aslında çalışma şeklimizi geliştirdi. Faydalarını aşağıdaki gibi özetleyebilirim:

• Daha fazla PBI alma riski nedeniyle başarısız sprint fobisini yendi.
• Programcılarınızın ve ekibinizin ekstra çalışmalarını görünür kılar
• Takım hızını arttırır

Bununla birlikte, daha az deneyime sahip bir ekip için, belki de PBI'leri tamamlama taahhüdünün takıma verdiği gücü azaltmaktadır.

Diğer cevapların bazıları, "iş bulma" geliştiricisinin "hileli" veya "Scrum ilkelerini ihlal ettiğini" ileri sürdü. Bu yanlıştır ve bu geliştirici teşvik edilmelidir (insanlardan bu ekstra zamanda belirli bir şey üzerinde çalışmasını istememelisiniz, ancak önerilerde bulunun ve fikirlerin geliştirilmesine yardımcı olabilirsiniz).

Scrum'da insanların nasıl çalıştığını ve yaptığı hiçbir şeyin doğal olarak ekibin hızına dahil edileceğini öngörecek bir şey yok.

Çalışmaları ürün birikimine getirilmeli ve bir sonraki planlama toplantısında tahmin edilmelidir. Kalan çabanın ne olduğunu önceden tahmin edemiyorsanız, sprintin belli bir zamanını anlamaya çalışmalısınız (Spike).

Geliştiriciyi "iş bulma" olarak nitelendirmeniz ilginçtir, bunun diğer takım üyelerinden çok daha fazla değer kattığı anlamına geldiğini düşünüyorum.

Ekstra iş yapmanın güçlüğü, ekibinizde alt optimal (veya hatta işlevsiz) bir şey olduğu anlamına gelir.

Eğer durum buysa, kendinize neden biraz daha fazla çaba harcayarak, neden bu kadar çok başarı elde ettiğini sormalısınız.

Takımın geri kalanının daha fazlasını elde etmesini sağlaman mümkün mü?

Ekiplerin mikro yönetildiği, potansiyel olarak kuralcı kullanıcı öyküleri, yapılan tanımların, geliştiricilere boğucu gelen durumları gördüm. O işi bu geliştirici mı diye istiyor? Sanırım iyi kararlar veriyor. Çalışma haftasında bu şekilde çalışmak takımın geri kalanına da yardımcı olur mu?

Onların da öğretmen olmalarını sağlayın

Gruptaki en iyi ve en ileri becerilere sahip bir yıldız geliştiriciniz olması harika. Bu övgü ve iltifat ediyorum. Genellikle bu tür insanlar organizasyonları bir arada tutan “tutkal” tır.

Mücadeleyi 'daha az deneyimli geliştiricilerin en gelişmiş geliştiricinin üretkenliğine nasıl daha yakın hale getirileceği' olarak görüyorum.

Bunu yapmanın harika bir yolu yıldız geliştiricinin daha az deneyimli ve yavaş ekip üyelerine eğitim vermek, eğitim vermek ve rehberlik etmek için daha fazla zaman harcamasına odaklanmaktır. Bunu ilk olarak 1'e 1'de yıldız geliştiriciyle tartışacağım, böylece ne yaptığınızı ve neden yaptıklarını biliyorlar. Aksi takdirde gizli bir gündem / kötü yönetim olarak şüpheyle görülebilir.

Stand-up yaptığınız zaman, günde bir veya iki kez, eğer bu kişi işini bitirirse ve diğerleri hala iş yapıyorsa, küçük üyelerle eşleşebilmesi ve mükemmel bilgi ve tecrübe kazanması için çift programlamaya bakın. "Yardıma ihtiyacı olan var mı? Bir çift mi arıyorsunuz?" Sorusunu sorduğunuzdan emin olun.

Ayrıca, herkes tarafından kullanılan araç setini geliştirmek, teknik bir kitap kulübü tartışma grubu yürütmek veya diğer organizasyonel projelere dahil olmak gibi işsiz kaldıklarında en iyi geliştirici için bir takım 'yan' çalışma da bulabilirsiniz.

Farklı bir soruya cevap vereceğim. Scrum'daki bu durumla nasıl başa çıkılacağının gerçekten önemli olmadığını düşünüyorum. Scrum zaten bir rehber gibi. Bunun olmasını istiyorsan, işin zaten yapıldığını varsaymak gibi, sürecini uyarlamanın basit bir yolunu bul.

Asıl soru, bu aygıtın yaptığı şeyi yapmasını isteyip istemediğiniz. Bence bu sorunun cevabında birkaç yön var:

1. Programcı iyi çalışıyor mu?
2. İşini kendi başına yapması için herkes iyi mi (iyi ya da kötü). Sonuçta tasarım sürecinden kaçıyor!
3. Fazladan saatler ödenmiş mi değil mi?

Tüm bunlar, ürününüz için yaptığı şeyi yaptığı şeyin anlam ifade edip etmediğini etkiler. Yine, kararınızı tasarım sürecine dahil etmek gerçekten bir sorun değil. Sadece esnek ol.

Bu Scrum kiracısını ihlal ediyor çünkü takım sprintte çalışmaya karar vermiyor. Bu bir scrum takımı . Eğer disiplinin dağıtılması gerekiyorsa, ekibin bu programlayıcıyı disipline etmesi gerekir.

Bunun yarattığı bir diğer konu da takımın hızıyla çakışması. Bant dışı çalışma hıza doğru sayılmaz ve yanmaz. Böylece, bu grup dışı çalışma yapılır, takım ortalama olarak ortalama 50 puan, ancak 50'den fazla puan alır. Ürün sahibi bunu görecek ve bir sonraki sprintte daha yüksek hız talep edecektir. Mümkün olmayabilir hız.

Takımın (PO ya da Scrum Ustası değil) haydut programcısıyla bu konuyu ele alması gerekiyor.