Scrum ile Eş Programlama


10

Şu anda Scrum kullanan bir takımdayım ve ekibin çapraz fonksiyonel becerilerini geliştirmek ve "iki kafa birden iyidir" felsefesi ile hataları azaltmaya yardımcı olmak için çift programlama eklemeyi düşünüyoruz.

Ekibimizde, her ekip üyesi tipik olarak sprint planlama sırasında tam bir iş yükü için kaydolur ("tam" haftada 40 saatten az bir sayıdır, toplantılara, işbirliğine vb. İzin verir) ve her bir görev. Bunun Scrum takımlarında oldukça yaygın olduğuna inanıyorum, ancak kitapta olmayabilir.

Özellikle, ekip üyelerinin eşleşmekte tereddüt ettikleri bir durumdan kaçınmak istiyorum, çünkü üzerinde çalışmak için kendi görevleri var, korkarım ki ekip eşleştirme için zaman ayırmadan kendi kendine organize olursa .

Bu göz önüne alındığında, eşleştirme senaryosunda çaba / saat / hikaye puanlarını hesaba katmanın ve eşleştirme için uygun zaman ayırdığımızdan emin olmanın en iyi yolu nedir?

Dikkate alınan bazı seçenekler şunlardır:

  1. İki kişinin her bir göreve kaydolmasına izin verin ve (kabaca) tahmini saat sayısını iki katına çıkarın
  2. Her görev için yalnızca "klavyede eller" ekip üyesi kaydolur ve bu da o kişinin tahmini saatine göre tahmin edilir. Takımda eşleştirmeyi destekleyecek herkes eşleştirmeyi desteklemek için zaman tanımak üzere sprint'te daha az görev için kaydolacaktır.

Yanıtlar:


4

Scrum içinde çift programlama uygulandığında gördüğüm en yaygın seçenek, geliştirme tahminlerini ikiye katlamaktır.

Yani, görevin bir kişi için 3 saat süreceği tahmin edilirse, çift için ayrılan süre 6 saat olacaktır.

Daha temiz hissettirirseniz, puanlar için saatleri değiştirin;)


Teşekkürler Oded. Bu cevap en açık şekilde kendi sorumu yanıtladı. Bununla birlikte, süreçten daha fazla insanın temel nedenini belirlemeye yardımcı olan DXM'ye büyük bir teşekkür. Keşke birden fazla yanıtı kabul edebilseydim.
Cliff

15

Sanırım başkaları zaten iyi cevaplar verdi ama benimkini ekleyeceğim, çünkü takımınızın Scrum'a yeni geçtiğini düşünüyorum ve şimdi siz başladığımızda çok benzer bir konumdasınız.

Öncelikle, Agile ve daha spesifik olarak Scrum'a girişimiz çok düzgün değildi. Temel olarak yönetim çöktü ve bu günden itibaren Scrum'ı yapacağınızı söyledi ve bu hepinizin izleyeceği bir süreç. Süreçteki İnsanlar için çok fazla .

Başlangıçta takip ettiğimiz süreç (körü körüne ekleyebilirim), tarif ettiğiniz şekilde çok benzerdi. İnsanlar görevlendiriliyor, herkes rezerve ediliyor ve hepimiz masalarımıza geri dönüp takılıyoruz. Sonra her gün sıkıcı bir stand-up toplantımız var.

Fark etmenin anahtarı Agile ve Scrum'ın aslında insanlar hakkında olduğudur. Ekip yineleme planına girdiğinde, Scrum ustanızın (muhtemelen yöneticiniz olan) size saat, hikaye ve görev atamasına izin vermeyin. Tamamen EKİBİ KADAR. Bence bir çok insan için bu çok zor bir kavram. Scrum'a dalarlar, ancak herkes (scrum ustasının kendisi dahil) aynı modda çalışmaya devam eder.

Bir gün bundan bıkacaksınız, böylece kitap, blog okumaya başlayacak ve yığın alışverişinde böyle sorular sormaya devam edeceksiniz. Alacağınız farkındalık, geliştirici ve takım arkadaşlarınız olarak hikayelere bağlılık ve görevler vermenin arkasındaki itici güç olmanızdır. Eğer çift programlamadan faydalanacağınızı düşünüyorsanız, her bir mühendis için 2 görev oluşturun ve her ikisine de saat verin. Scrum master'ın yapması gereken tek şey, önceki yinelemede TAKIM OLARAK teslim ettiğiniz tamamlanmış hikayelere karşı hızı ölçmektir.

Ayrıca boktan beni rahatsız eden başka bir şey, insanların kapasitelerinin HER ZAMAN toplam saatlerin% 75'i olduğu söylendiğidir, bu yüzden taahhüt ederler ve daha sonra tüm tekrarlama süresi boyunca şikayet ederler. size yardımcı olurlar ya da b) doğru şeyi yapamazlar çünkü çok fazla saat atandılar. İnsanlara kaç saat taahhüt edileceği söylenmemeli ve scrum ustası böyle bir şey çekmeye çalışıyorsa kesinlikle geri itmeliler! Herkes tam olarak neyin rahat olduğunu taahhüt etmelidir. Örneğin, ben bir takım lideriyim ve sık sık rastgele planlanmamış bir tasarım tartışmasına ya da kodlu birine ya da garip şeyleri gidermeye yardımcı oluyorum, bu yüzden kapasitem asla% 50'nin üzerinde değil.

Bahsettiğim şeyleri yapmamayı öğrenmek için ekibimize 4 serbest bırakma döngüsü geldi ve kesinlikle iyileşmiş olsak da, uzmanlara sorarsanız bile yarı çevik değiliz. Yani hâlâ yapılacak çok şey var.

Güncelleme 1: Cliff'in yorumuna yanıt Kulaklarınızı teklif ettiniz, işte burada ...

Haklısınız, kültürel değişim anahtardır, ancak bu değişikliğin yönetici düzeyinde gerçekleşmesi gerekmez. Kendi grup yöneticiniz, ekibinizdeki kültürü değiştirebilir ve sizi ilgilenmesi gereken kurumsal BS'den ayırabilir. Açıkladığınız şey, 2007'den 2010'a kadar TAMAMEN bize oldu. Ekibimiz (ve diğer ekipler de) serbest bırakıldıktan sonra serbest bırakıldı. Yönetimin "çevik olma sürecini" kullanan sürümlerden birinde 9 kişinin genellikle tek bir kişi tarafından yapılacak işi üretmesini sağlamayı başardık ve bu bizi iki katına çıkardı. Çok fazla boş zamanım vardı, özgeçmişimi bile güncelledim.

Sonra, patronumla bir görüşme yaptım ve tüm bunları ona insanlar hakkında ne kadar çevik olduğunu açıkladım ve ürünü önemsememizi istiyorsanız, ürün üzerinde nasıl çalıştığımızı ve teslim ettiğimizi etkileyen kararlar verelim. Bence bunu bir deney yapmaya karar verdi, her değişikliği biz yaptık ... çoğunlukla kendim, ama ekibin geri kalanıyla çok konuşuyorum, dolayısıyla% 50 kapasite :) ... önerdi. İstediğimiz tüm değişiklikleri yaparsa ve hala başarısız olursak, muzaffer bir "Sana söyledim" ile geri döneceğini düşünmüş olabilir.

Son 12 ayda çok komik olan aptallığı ortadan kaldırdık. Stand-up toplantılarımız aslında mantıklı çünkü tek başına değil birlikte çalışıyoruz. Hâlâ ürünün belirli parçalarının (en azından şimdilik) sahipliğimiz var, ancak birbirlerinin kodlarına da çok sık geçiyoruz. Kod incelemelerini sürekli olarak yapıyoruz, böylece sadece ekip üyeleri diğer kodları öğrenmekle kalmıyor, aynı zamanda daha iyi kodlama ve tasarım tekniklerini de öğreniyorlar. Monolitik, dev "çevik" ekibi 3 farklı takıma ayırdık, bu yüzden planlama ve diğer toplantılar çok daha kısadır ve insanlar aslında onları önemsiyorlar, çünkü etrafta oturup umursadıkları şeyleri dinlemiyorlar. BEN' 5 kişiden 4'ünün (ekiplerden biri) gece 11'de çevrimiçi olacağı ve hiç kimsenin bize çok çalışmak zorunda olduğumuzu veya 40 saatin üzerinde çalışmak için baskı yaptığımızı söylediği geceleri gördük. Yarım yıl önce daha az umursamayan insanlar, aniden yaptıkları iş hakkında meşgul ve heyecanlılar. Yöneticimizin yapması gereken tek şey, "siz neyin doğru olduğuna siz karar vermeniz ve ne yapmanız gerektiğini yaparsanız kurumsal BS'yi ekibimden olabildiğince uzak tutacağım" demekti.

Deney olarak başladı (şüphem bana bunu asla söylemedi), ama şimdi grubumuz bölümdeki diğer geliştirme gruplarına kıyasla popo tekmeliyor ve hatta şimdi gelip bize katılmaya çalışan başka geliştiricilerimiz var.

Bu değişimin gerçekleşmesinden bu yana bizim için en büyük engel (ve bugün hala bir sorun), normal kurumsal ortamdaki mühendislerin bir kafesdeki deney fareleri gibi olmasıydı. Yöneticiniz gerçekten "çevik" olmaya karar verdiğinde ve kafesi kaldırsa bile, herkes uzun zamandır bu kafeste bulunuyor, özgür olduklarının farkında bile değiller. Böylece tüm özgürlüklerle bile, hala kısıtlanmış gibi davranmaya devam ediyorlar. Bence yardımcı olabilecek en az sayıda takımın (sizin gibi) grubun sınırları dışına çıkıp daha iyi şeyler yapmanın yollarını araması. Sonra bu gruba geri dönün ve biraz karıştırın.

Durumunuzda, takıma gelip nasıl çalışacaklarını söylemek için başka bir dış güç arıyorsanız, eşleştirilmiş programlama bir çözüm değildir. Bunun yerine, kuralları dışarı atın, yönetim olmadan oturun ve ne yapmak istediklerini sorun. Onları ne mutlu edecek? Üretken? En büyük sorunları tespit edin ve ardından TAKIM'a çözümün ne olması gerektiğini düşündüklerini sorun.


Tamamen katılıyorum. Sorunun bir kısmı, Agile felsefesinin kalkınma kültüründe iyi bir şekilde yerleşmemiş olması ve bunu, ideal olarak kültürel bir değişim yoluyla düzeltilmesi gereken süreçle düzeltmeye çalışıyoruz. Görev kayıtları olmadan, ekip üyeleri ya görevlere karşı "benim işim değil" tutumunu aldı (bir kere, takım gerçekten çapraz fonksiyonel değil, bu da eşleştirmeyi uygulamak istediğimiz nedenlerden biri) ya da kolayca dikkati dağılan. Sonuç ekip arasında iş yükünde bir dengesizlik oldu. Bu sorunları daha az süreçle nasıl çözebileceğimize dair önerilere kulak asıyorum.
Cliff

Güncelleme için teşekkürler. Yönetim aslında çok destekleyici olmuştur ve takımın "nasıl" olduğunu tanımlamasına izin verir. Ama bence asıl sorunun bir parçası takımın çapraz fonksiyonel bir zihniyetten yoksun olması. Örneğin, ekip bireysel beceri setlerine dayalı olarak hesaplanamayan / hesaplanamayan hayali duvarlar yarattı. Bir yandan, ekip üyeleri kendileri tarafından tanımlanmış işlevsel alanlarındaki özelliklerin bir kısmı için çok güçlenmiş ve sahiplik kazanırlar, ancak diğer yandan, işlevsel alanlarında yer almayan özelliklerden sorumlu değildirler (" benim işim değil ").
Cliff

Sesler zaten olumlu yönde birkaç adım attı gibi. Şimdi iyileştirilmesi gereken büyük bir alan belirlediğinize göre, bunu ekibe sundunuz ve çözüm önerilerini istediniz mi? Evetse, eşleştirilmiş programlama ile geri döndüler mi? Evet ise, elbette, aynı hikayeye birlikte çalışmak isteyenleri atayın, birden fazla görev oluşturun ve her kişinin yanına kodlama saatleri koyun. Cevabınız hayırsa, onlara fonksiyonel bir sınırı geçmek için neden bu kadar kararsız olduklarını sordunuz mu? Sonunda geçmeden daha etkili olacaklarını düşünürlerse, belki de gerçek çözüm başka bir yerdedir.
DXM

"Benim işim değil", "Umurumda değil" anlamına gelir ve bu sizin en büyük probleminizdir. Çevik, önemseyen ve sorumluluk alabilen geliştiriciler içindir. Takımın ürün sorumluluğu vardır. "Bir parça için sorumluluğum var" diye bir şey yok = ekip üyesi tüm ürünü önemsemelidir. Neden fonksiyonel alanlarınız var? Ürününüz çok büyük olduğu için mi?
Ladislav Mrnka

@ LamislavMrnka: Takımda umursamayan bazı insanlar olsa da, bence bu iyi. Bu insanlar hatalar ve saçmalıklar için iş katırları olacaklar, çünkü büyük kararlar, ürün yönü, mimari ve tasarım bunların hemen ötesine geçecek. Ama yine de teknik destekle ilgilenecek birine ihtiyacınız var :). Bence çoğumuz ne yaptığımızı önemsiyoruz. Ve eğer tüm takım "işim değil" tutumuna sahipse, bence asıl neden, seçilmesi ve ortadan kaldırılması gereken başka bir dış faktördür. Bunu yapmadan, takıma "dikkat etmelisin" imkansız olacaktır.
DXM

2

Scrum, görevlerin kişilere - görevden çok uzakta - atanmasını zorunlu kılmaz. Tamamlanacak görevlerin sorumluluğu bir bütün olarak Ekibe aittir. Takım, her bir çiftin bir görev aldığı çift programlama yapmak istiyorsa, kesinlikle yapmaları gerekir.

Gönderen Scrum Guide :

Geliştirme Ekibi genellikle sistemi ve Ürün İş Listesini çalışan bir ürün artışına dönüştürmek için gereken işi tasarlayarak başlar. İş, değişen büyüklükte veya tahmini eforda olabilir. Bununla birlikte, Sprint Planlama toplantısında Geliştirme Takımı için yaklaşmakta olan Sprint'te neler yapabileceğini düşündüğünü tahmin etmek için yeterli çalışma planlanmaktadır. Geliştirme Takımı tarafından Sprint'in ilk günleri için planlanan çalışmalar, bu toplantının sonunda bir gün veya daha kısa birimlere ayrılır. Geliştirme Takımı , hem Sprint Planlama Toplantısı sırasında hem de Sprint boyunca gerektiğinde Sprint İş Listesi'ndeki işi üstlenecek şekilde kendi kendini organize eder .


1
İlginç. Mart 2009 Scrum Kılavuzu var ve onlar aslında bu alıntı değişti. Eskiden şöyle olurdu: " Takım , Sprint Planlama toplantısında ya da Sprint sırasında tam zamanında Sprint İş Listesi'ndeki işi atamak ve üstlenmek için kendi kendine organize olur ."
Cliff

Yorumumuz, her biriktirme listesi öğesi için her zaman bir başlangıç ​​tahmini görevler kümesi oluşturmak ve sprint planlama sırasında bunları bireysel ekip üyelerine atamak olmuştur. Avantajlardan birkaçı, planlama sırasında ekip üyeleri arasındaki iş yükünü etkili bir şekilde dengelememize yardımcı olmasıdır ve her görev için atanmış bir sahiple, hiçbir şeyi kaçırmamamızı kolaylaştırır. Ayrıca metrikleri yakalamaya da yardımcı olur.
Cliff

@Cliff - Eğer böyle yapmak istiyorsan, sorun değil. Tüm söylediğim, Scrum'ın bunu bu şekilde yapmanız gerektiğini söylemediğidir. Öğeleri çiftler halinde atamayı tercih ederseniz (genellikle otobüse çarpma sigortası olarak yaparız), bu da iyidir ve çiftlere dayalı metrikleri kolayca çalıştırabilirsiniz.
Matthew Flynn

0

Toplantı planlama ile ilgili görevler vermek, sadece zaman kararlarına aykırı davranan ve ekibi güçlendiren şeydir. Sprint çevikliğine de karşıdır çünkü bir sprintteki ilk günden beri her geliştirici yapması gerekenleri tam olarak hizalamıştır. Ayrıca her görevin çok doğru bir şekilde tahmin edilmesi gerektiği anlamına gelir ki bu neredeyse hiç böyle değildir.

Imho tahmin görevleri gereksizdir. Hikayeler dizisini taahhüt ettiniz ve toplantı 2'yi planlamak, bu hikayeleri görevlere bölmek ve bu görevler için kartlar oluşturmak (veya bir sisteme doldurmak) için yeterli zamandır. Her bir görevi tahmin etmek için yeterli zaman yoktur ve bu tahmin gerçek gelişim için zaman harcamamalıdır.

Neden? Tahmin bir çöptür. Nasıl çöp olabilir? Çünkü daha fazla tahmin yapmak daha fazla iş değeri getirmeyecektir = çöptür ve gerekli minimum düzeye indirilmelidir. Minimum değer, taahhütte bulunmanıza yardımcı olan hikayeleri tahmin etmek / boyutlandırmaktır. Bir taahhütte bulunduktan sonra başka bir tahmine gerek yoktur. Sadece taahhüt ettiğiniz bir şeyi teslim etmek için sabit bir tarihiniz olduğunu biliyorsunuz. Kararlı hikayeler sunabilir ya da sunamazsınız. Görevleri tahmin etmek bu teslimatta size yardımcı olmaz.

Görev tahminini atlamak hiçbir şekilde sprint ilerlemesinin görünürlüğünü etkilemez, çünkü ilerlemenin tek gerçek ölçümü tamamlanmış öykü sayısıdır (öykü noktaları) ve yine de sprint yazma tablosunda gösterilebilir.

Sadece netleştirmek için. Bağlılık şu anlama gelir = Yapacağız . Bunu ya da başka bir şeyi yapmaya çalışmayacağız. Evet, taahhüt ettiğiniz şeyleri yerine getiremezsiniz, ancak taahhüdünüz mevcut bilginizle seçilen hikayeleri sunacağınıza olan inancınıza dayanmalıdır. Bu inanca sahipseniz, başka bir tahmine ihtiyacınız yoktur.

Scrum'ı her zaman geliştiricinin son görevini tamamladıktan sonra yeni bir görev seçtiği şekilde kullandım. Geliştiriciler genellikle stand-up toplantısında hangisini seçeceklerini söylerler. Genellikle hangi görevi seçmesi gerektiği konusunda bir kural yoktur. Bu, ekip öz-organizasyonu ve ekip üyeleri arasındaki tartışmadır (stand-up toplantısının dışında). Bu, hayali planınızı etkilemeden bazı değişikliklere ve sorunlara tepki verebileceğiniz mümkün olan en son noktaya erteleme. Görevin kendisi, birisinin tamamlaması için bazı problemleri varsa sahibini değiştirebilir - alternatif olarak bu tür bir görev çift olarak geliştirilebilir.

Çift programlama buna nasıl dahil olabilir? Kolayca. Ekip taahhüt eder ve ekip, ürünün çalışma artışını sağlamak için gereken tüm geliştirme tekniklerine yer açmasını sağlamalıdır. Bir görev veya görev geliştirme ve görev testi tahmin ediyor musunuz? İkinci yaklaşım tamamen yanlıştır. Test, geliştirmenin bir parçasıdır ve aynı şekilde, kod inceleme veya eşleştirme, gerekirse geliştirmenin bir parçasıdır.

Çift programlama yapmak, daha az miktarda hata ve daha iyi kod kalitesi ile görevi daha hızlı tamamlamanıza neden olacaktır. İki kat daha hızlı olmayacak, bu yüzden hala bir miktar ek yük olacak, ancak ara sıra eşleştirmenin bağlılık üzerindeki gerçek etkisi çok küçük olmalıdır. Bu mentorluk veya öğretim için bir durum değildir. Mentorluk veya öğretilmesi gereken böyle bir geliştiriciniz varsa, kapasitesini ürünün kod tabanını veya bazı teknolojiyi öğrendiği sprintler için hiç planlamamalısınız.

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.