Çevik MVP (En Değerli Oyuncu / Programcı)


9

Son zamanlarda, yönetimin ekibin bir geliştirici 'MVP' yanı sıra her sprint sonunda bir QA 'MVP' aday göstereceği fikrini ortaya çıkardığı çevik bir projeye (scrum kullanarak) katıldım. takım. MVP daha sonra küçük bir para ödülü ve ücretsiz öğle yemeği ve masasında gösterilecek bir kupa alır. Bu ödül sistemi ile şimdiye kadar iki sprintimiz oldu.

Bundan gördüğüm iyi şudur:

  • Daha fazla hata giderildi (üst yönetimin görmek istediği şey, istedikleri yönde bir sayı değişikliği)
  • Her 'takımdan' MVP tanınır ve benlik saygısı artar (ya da bir ego artışı mı?)

Böyle kötü bir şeyi (en azından bir geliştirici bakış açısından) yapmak için kötü tarafları ne düşünürdüm birkaç fark ettim:

  • Hata düzeltmelerinin kalitesinin düştüğü sayı ile ilgilenen birkaç geliştirici var. Bir alandaki düzeltmeler başka bir alandaki gerilemelere neden oluyor.
  • Kiraz sayılarını artırmak için 'daha kolay / daha hızlı' hataları toplayan birkaç geliştirici var. Sanırım burada kötü olan iyi olabilir.
  • Daha yüksek öncelik (çoğu zaman 'düzeltilmesi daha zor / daha uzun' ile ilişkilidir) kusurlar aslında daha düşük öncelik haline gelir.
  • Engelleme kusurları zamanında ele alınmaz, çünkü genellikle daha uzun sürer ve KG ile daha fazla koordinasyon gerektirir.
  • Dev ekibindeki takım yönü kayboldu. Dev ve QA'nın birlikte çalıştığı ekip yönü de iyileşmedi, ancak eskisinden çok fazla değişmedi.
  • Hata düzeltmelerinin ötesinde çalışmak veya BU numaraya doğru çalışmak kolayca tanınamaz / izlenemez.

Ekibin her birini nasıl ele aldığına bağlı olarak yukarıdaki 'kötü' her birinin bir dereceye kadar ele alınabileceğine inanıyorum.

Benim sorum, o zaman, Sprint başına bir MVP tanıdığınız böyle bir şey başarıyla çıkardı? Eğer öyleyse, bu başarıya ne katkıda bulunduğunu düşünüyorsunuz?


8
Bir şey tuhaf. Başlangıçta "takım tarafından oy kullanıldı" diyorsunuz, ancak yazının geri kalanı hatalar ve hata sayısı hakkında. Takım, hataların ve hata sayısının orada olmadığını bilmemelidir. Ve ciddi / zor hatayı çözen birinin MVP için birçok kolay hatayı çözen kişiden daha uygun olması gerektiğini?
Euphoric

2
Belki daha yüksek öncelikli hataların 2 veya 3 düşük öncelikli hataya eşdeğer olması gerekir. Rekabetçi yapma şey olduğunu edecektir rekabetin çirkin yanlarını ortaya çıkarmak. İşleri dostça ve rekabetçi tutmak (ciddi bir şekilde) zordur.
SinirliWithFormsDesigner

8
Ekibim bunu hiç yapsaydı, bu saçmalıktan vazgeçme seçeneğini tercih ederim. Arkada iki haftada bir pat istemiyorum.
Anthony Pegram

7
Bir zaman biriminde bir iş birimini bir araya getirmek için takım birimi olarak çalışmak gibi bir şey yoktur. Ve bu, bir zaman biriminde bir iş birimini bir araya getirmek için ekip birimi olarak çalışmak gibi bir şey değildir.
pdr

3
Bu, eğlenceli bir şekilde, yönetim ham metriklere aşırı bağımlı hale geldiğinde müşteri hizmetleri kuruluşlarında olanlarla aynı şeydir.
Blrfl

Yanıtlar:


32

Agile , bireylerin çabalarını değil, ekip çabalarını vurgular . Yani hayır, bu yaklaşım açıkça çevik değil.

Bu, ekip işbirliğini teşvik etmek yerine, her ekip üyesini kendi sonucuna odaklanmaya teşvik eder. Hatta üyelerin birbirlerine yardım etmekten kaçınmasına (veya daha kötüsüne) yol açabilir, bu da uzun vadede takımın daha iyi olmasını engelleyecektir.

Eğer iyi bir iş çıkarmışlarsa takımı bir bütün olarak ödüllendirmeyi öneririm.


2
Tekrar. MVP tüm takım tarafından oylanırsa, nasıl olur da bireyi vurgular? Eğer böyle bir ekipte olsaydım, projeye en çok eklendiğini düşündüğüm kişiye oy verirdim. Ve bana yardım etmek istemediğini düşündüğüm kişiye karşı olurdum.
Euphoric

@Euphoric: kabul etti, ama bu "MVP tüm takım tarafından oylanırsa". Soru bir hata sayısı ya da bir oy olup olmadığı konusunda net değil .. Eğer bir sayım ise, ben de Martin ile aynı fikirdeyim ..
rdurand

eğer tüm takım tek bir kişiye oy verirse, o zaman Tamam Aksi takdirde, önerildiği gibi, "doğru" oy verme baskınız olması dışında.
Dainius

Açıklığa kavuşturmak için, bu durumda her biri için ilk 3'e oy verdik: Dev ve QA. Bununla birlikte, günlük stand-up'larımızda, hata sayısı vurgulanan tek şeydi.
Dustin Kendall

1
Katılıyorum ve şimdi bunun uygulandığına göre, takımın çözmesi gereken başka bir sorun var; takım dinamiklerini daha da bozmadan bu ödül sisteminin nasıl ortadan kaldırılacağı; "örneğin; 'bu adil değil, sadece iki kez yaptık, bu yüzden kazanma şansım olmadı!" "
RJ Lohan

7

Bunun -bad- iyi bir örnektir olduğunu düşünüyorum gamification uygulanıyor. Sorun, programcılarınızın potansiyel olarak problem çözme ve zorluklar kazanma (zor hataları bulma ve düzeltme) konusunda gerçek motivasyona sahip olmaları ve Scrum'ı uyguladığınızdan beri bir TAKIM olarak çalışmanızdır. Başka bir deyişle, potansiyel olarak iyi bir iş yapmak istediler.

Şimdi, en azından bazıları için, bu içsel motivasyon ya da bir kısmı, oyun mekaniği genellikle parçası olan başlıklardan ("haftanın MVP'si") ve ödüllerden (parasal tutar ve ücretsiz öğle yemeği) oluşan dışsal motivasyon ile değiştirildi. oyunlaştırılmış bir süreç.

Oyunlaştırma başarılı bir şekilde iş yerinde uygulanabilir, ancak içsel / dışsal motivasyondan yararlanmaya çok dikkat etmelisiniz. Dışsal motivasyon, motivasyonun içsel olabilmesi için kendi kaderini tayin etme yetkisini güçlendirmelidir . Ancak burada tam tersi, programcılar kazanmak için "oyunu oynuyorlar" .

Bunu düzeltmek için yapabileceğiniz şey, yönetimden kuralları biraz değiştirmesini istemektir:

  • biletlerin zorluğu ve önceliği ile eşleşen puanlar verin. Bulmak / yeniden üretmek bir hata düzeltmek için çok daha ilginç, puan açısından, olun.
  • problemleri işbirliği içinde çözmek için puan verin (yine TAKIM). QA ile etkileşime girmek için daha fazla programcı bulabilirsin. Bir programcı VE bir KG tarafından işbirliği içinde çözülen bir problem için puan verin.
  • biri en çok puan, diğeri en çok bilet için farklı başlıklar verir. Bu, programcıların rekabetçi içgüdülerini tatmin etmelidir.
  • bir ekibin her üyesinin puanlarını toplayarak Dev ve QA arasında dostça bir rekabet kurmak

Bununla birlikte, regresyon hatalarının ortaya çıkma olasılığını azaltmak başka bir sorundur. Örneğin olumsuz noktalar uygulayabilirsiniz, ancak eminim iyi bir fikir değildir, çünkü bir ceza biçimi olacaktır. Daha iyi bir şey, geçen hafta hiçbir regresyon hatası tespit edilmezse birkaç puanla otomatik olarak bir sprint başlatmaktır. Regresyon hataları tespit edilirse, programcı 0 ile başlar.

Ayrıca, "oyunlaştırma" da "oyun" vardır. Ve bir oyunun temel yönü, gönüllü olarak oynamanız / katılmanızdır. Çalışma bağlamında, burada durum yönetim tarafından dayatılabilir, ancak normalde hiç kimse buna zorlanmamalıdır.

Sonuç olarak, bu MVP olayı mutlaka kötü bir fikir değildir, ancak işin (önemli hataların çözülmesi) önce gelmesini sağlamak ve bireylerden ziyade ekip çalışmasını vurgulamak için yaklaşım biraz değiştirilebilir.


5

Bir ekip üyesinin çabalarının bir çeşit grup olarak tanınması değerli bir motivasyon aracı olabilir, ancak bu durumda yanlış uygulanmış gibi görünmektedir. MVP'nin oyla seçildiğini belirtiyorsunuz, ancak sprint başına sabit sayıda hatadan bahsediliyor. Zamanınızın komik bir MVP tanımına sahip olduğu anlaşılıyor - "en değerli" unvanını hak eden kişinin, bu sprintteki yazılıma en fazla değer katan kişi olduğunu varsayarım. Bir ekip üyesi hızlı bir şekilde düzeltilebilecek hataları seçiyor, mümkün olduğunca hızlı patlatıyor ve uyanıklıklarında regresyon hatalarına ve diğer sorunlara neden oluyorsa, değer katmıyorlar, her kim için daha fazla iş yaratıyorlar bu sorunları tespit etmek ve çözmek için onları takip etmek.

Benim önerim, ekibinizin bu oylardan bir dahaki sefere sahip olması durumunda uygun bir tartışmaya başlamak olacaktır. Sadece bir el gösterisi yapmayın; önce konuş. Birisi yaptıkları çok sayıda "düzeltmeye" göre oy alıyor gibi görünüyorsa, bu düzeltmelerin gerilemelere neden olduğu (taktiksel olarak) ve belki de bu gerilemeleri düzelten kişinin diğer insanların temizliği için aday gösterilmesini önerdiğini dağınıklık. Birisi tüm sprint'i kötü bir konuda köleleştirerek geçirdiğinde, bu kişinin düzeltme sayısı bir olmasına rağmen, yazılımınızla ilgili tek başına büyük bir sorunu çözdüğünü vurgulayan ekibe işaret edin. o kadar kötü ki, hiç kimse ona dokunmak istemedi.

Kolay düzeltmeleri seçmek ve bunları acele veya gelişigüzel bir şekilde yapmak değerli değildir, bu yüzden bunu yapan geliştiriciler muhtemelen MVP adayları olarak nitelendirilmemelidir. Yeni MVP'yi seçerken, ekibi ve ekipteki insanları unutun ve yazılıma bakın. Son yazılımdan bu yana yazılımdaki en önemli değişikliği seçin. Burada bekar demek istiyorum; "çok küçük hatalar değil" büyük bir değişiklik değildir. Özellikle göze çarpan bir hata giderildi mi? Harika bir yeni özellik eklendi mi? Bu büyük değişikliğin ne olduğunu belirledikten sonra, bundan kimin sorumlu olduğunu sorun. Bu insanlardan biri muhtemelen sizin gerçek MVP'nizdir. Tek fark "çok küçük böcek" değilse , o zaman ve sadeceo zaman hata sayımı geçerli bir MVP ölçüsüdür - ve o zaman bile, neden regresyon hataları sabit hataların oranına bakmak istiyorum. Birinin neden olduğu her hata, sayısından en az 1 kesinti yapar. Aslında, 1'den fazla söyleyebilirim, çünkü kötü bir düzeltme, daha sonra bulmanız gereken bilinmeyen bir hataya neden olur , bu da zaten bulunan bilinen bir hatadan daha kötüdür . Bilinen bir hata geliştiricinin düzeltmesi için çaba harcar; bilinmeyen bir hata KG'nin bulunması ve geliştirici tarafından düzeltilmesi için çaba gerektirir ve ardından KG'nin bunu kaçırması riski vardır.

Teoride, geliştiriciler ödüle giden yolun daha az, daha büyük sorunları düzeltmek olduğunu fark ederse, zor olanları, karmaşık olanları, engelleme kusurlarını hedefleyeceklerdir. Bu, bazen etrafta dolaşmak için yeterli etli sorun olmadığından veya sorun daha fazla göz seti gerektirecek kadar zor olduğu için bazen bir araya gelmelerini gerektirecektir . Belki de bu gibi durumlarda, bir dizi insanın bir hatayı düzeltmek için daha fazla iş yaptığını hemen anlamazsa ödülün paylaşılabileceğini ve hatırlayın, iş bitti! Geliştiriciler muhtemelen bunu bilecek, ancak yönetimin dahil olduğunu söylediniz ve yönetim her zaman bu noktayı anlamıyor.

Ve hey, eğer hepsi başarısız olursa, MVP programını unutun. Scrums dışındaki geliştiricilerinizle konuşun ve MVP ödüllerinin yazılım üzerindeki olumsuz etkisine dikkat edin. Onları görmezden gelip getiremeyeceğinizi veya bu kadar büyük bir anlaşma yapamayacağınızı görün. Kupayı bir çekmecede bırakın, nakit ödülü işten sonra ekip için bir dizi içkiyle geçirin, bir grup cupcakes gibi paylaşabileceğiniz bir şey almak için ücretsiz öğle yemeğini kullanın. Agile bir takım sistemidir; bireysel performans risklerini, takımın birbirlerine karşı çekmesini vurgulamak. Birleşik sen, bölünmüş böcek dolu yazılım gemi, son tarihten sonra, aşırı bütçe.


3

Bu, belirli bir uygulamanın (MVP olarak halkın tanınması) ekibinizin davranışları üzerinde nasıl önemli ancak dolaylı bir etkisi olabileceğinin klasik bir örneğidir. Bu, teşviklerin, motivasyonların ve ödüllerin ötesine geçer ve aslında çevresel / davranışsal psikoloji ve karar mimarisindeki fikirlere değinir. Güzel şeyler.

Soru şu - bir süreci nasıl tasarlayabilirsiniz, böylece ekibiniz katı politikalar koymak veya insanları bir şey yapmaya zorlamak zorunda kalmadan doğal olarak tüm doğru şeyleri yapıyor gibi görünebilir mi?

Takımlarınız için çalışan bir süreci tasarlamak için bir mekanizma olarak ( Donald Norman'ın Günlük Şeyler Tasarımı geleneğinde) uygunlukların kullanılması hakkında yazdım . Temel fikir, bir süreçteki uygulamaların kişinin davranışını doğrudan etkilemesidir. Bu nedenle, işleminizdeki uygunluklar ekibinizin değerleri ile tam olarak hizalanmadığında sorunlar ortaya çıkar.

Bu konuda birkaç çalıştay düzenledim ve bu konu zaman zaman gruplar halinde örnek olarak ortaya çıkıyor. Sorunuzda paylaştığınız duruma uygunluk teorisini uygulamak böyle bir şeye benzeyebilir ...

Takım değerlerinizin tutarlılığını, öngörülebilirliğini ve yüksek kalite kodunu varsayalım.

Gözlemlediğiniz olumsuz davranışların bir çamaşır listesi var ve hepsi bir takım MVP seçmek için kusur metriklerini kullanmaktan kaynaklanıyor gibi görünüyor. Örneğin, takım arkadaşları doğal olarak hataları gelişip düzeltmek istiyor ve değerlerinizin üçünü de olumsuz yönde etkiliyor. (Daha önce de bir sorun olduğunu varsayıyorum ve MVP fikrine yol açan şey budur).

Hata metriklerine dayalı tek bir MVP'ye sahip olmak yerine, küçük ama önemli değişiklikler yaparak takım davranışını değiştirmeye çalışacağız.

  • Takım değerlerinizi açıkça kucaklayan herhangi bir kişiye (ve hepsine değil, herkese) "takım kudo" vermesine izin verin. Bu, takım değer sistemini örneklerle demokratikleştirecek öngörülebilirliği teşvik edecektir. (Bunu aslında ekibimizde yapıyoruz ..)
  • Tüm hata düzeltmeleri için çift programlamayı başlatın (veya "hata arkadaşları" atayın). Bu, aceleci veya yarı yamalak programlama kararlarını caydırarak kaliteyi artıracak ve tutarlılığı teşvik edecektir, çünkü arkadaşlar düzensiz davranışları azaltacaktır. (Bu fikir atölye çalışmaları sırasında yaygın olarak önerilmektedir, sezgisel görünmektedir.)

Ve bunlar sadece yaklaşımı göstermek ve başlamak için bazı örnekler ...

Bu yaklaşımın en güzel yanı, süreç değişikliklerinizi aktif olarak tasarlamanız ve yaptığınız süreç değişikliklerinin haklı nedenlerinin olmasıdır. Tıpkı nesne veya UI tasarımında olduğu gibi, işlerin işe yarayıp yaramadığını anlamak için sonuçları ölçebilirsiniz.


2

Bir MVP programı gibi bir şey sağlamak için yapılacak en kolay ayarlardan biri, ekip üyelerini ekibin başarısı için en değerli olduğu, en zor çalışan olmadığı için ödüllendirmektir.

Bunu, hatalar veya özellikler üzerinde bile çalışmayan, ancak takımdaki herkesin daha başarılı olmasını sağlayan harika bir şey yapan kişileri tanıyarak bunu başarıyla yaptık. Örneğin, takıma ve nasıl çalıştığımızı öğrenebilmeleri için takıma bir grup yeni üyeye rehberlik etme görevini üstlenen bir geliştiricimiz vardı. Hızımız arttı, çünkü bu yeni işe alımlar, ekibin geri kalanına yardım etmek için daha fazla zaman harcadığı için bireysel olarak bir geliştiricinin hızının düşmesine rağmen, sonuçları hızlı ve verimli bir şekilde sunabildik.

Ekip çalışmasını ödüllendirin ve ekip, kendi kişisel başarıları değil, önemli olan TAKIM olduğunu fark edecektir.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.