Baştan sona büyük parçalara kişisel olarak, bağımsız olarak sahip olmak isteyen geliştiriciler için çevikliği nasıl eğlenceli hale getirebiliriz?

Şelaleden çevredeki şelaleden çevremize geçişte kabaca yarıyoruz; teknoloji / disiplin silolarındaki büyük ekiplerden daha küçük çapraz fonksiyonel ekiplere geçtik.

Beklendiği gibi çevik değişiklik herkes için uygun değil. Çevikliğe alışmakta zorlanan bir avuç geliştirici var. Onları nişanlı, zorlu ve sonuçta her gün işe gelmekten zevk almak istiyorum. Bunlar hem kişisel hem de profesyonel düzeyde saygı duyduğum akıllı, mutlu, motive insanlar.

Temel mesele şudur: Bazı geliştiriciler, zor bir iş yapmanın, bir tasarım ile düşünmenin, olası sorunları düşünmenin, sonra problemi parça parça çözmenin, başkalarıyla en az etkileşimle, uzun bir süre boyunca çözmenin mutluluğunu temel alır. zaman aralığı. Genelde işleri yüksek kalitede ve zamanında tamamlarlar; çalışmaları sürdürülebilir ve genel mimariye uyar. Çalışmaya etkileşimi ve ortak sorumluluğu önemseyen ve işlevselliği daha kısa aralıklarla sağlayan, çok işlevli bir takıma geçiş yapan ekipler, tüm takımın bu sorunu çözdüğü şekilde gelişir. Birçok insan bunu olumlu bir değişiklik olarak görüyor; Bir problem almayı ve baştan sona bağımsız olarak sahip olmayı seven biri, bu şekilde çalışma fırsatını kaybeder.

Bu, insanların değişime açık olması ile ilgili bir sorun değildir. Kesinlikle değişimi sevmeyen birkaç kişi gördük, ancak endişelendiğim durumlarda, bireyler iyi birer oyuncu, gerçekten değişime açık, çaba sarf ediyor, takımın geri kalanının nasıl olduğunu görüyorlar. değişiyorlar ve uyum sağlamak istiyorlar. Bu, zor veya engelleyici birinin ya da en titiz çalışmayı istifade etmek isteme durumu değil. Eskiden olduğu gibi işte sevinç bulamazlar.

Eminim buna çarpışmayan tek yer biz olamayız. Diğerleri buna nasıl yaklaştı? Kişisel olarak büyük bir iş yığınını baştan sona ele alarak motive olmuş bir geliştiriciyseniz ve farklı bir çalışma biçimine adapte olduysanız, sizin için ne yaptı?

Agile'nin gerçekten bir metodoloji olarak anlamadığı nadir ayrımlara sahip olacak kadar şanslı olan çok az sayıda yazılım dükkanı olduğunu söyleyeceğim. Tüm ekibiniz, şirket ve birbirleriyle olan işin uzun ömürlülüğünü ve uzun ömürlülüğünü derinlemesine anlayan, gerçekten istisnai yazılım geliştiricilerden oluşuyorsa ve iş gereksinimleriniz ve müşteri gereksinimleriniz genellikle her zaman aynı ve nadiren ortasında serbest bıraktıktan sonra, Agile'nin muhtemelen HURT olabileceği nadir bir ortamda çalıştığınız için şanslısınız.

Kaotik ve sürekli değişen iş gereksinimleri ve müşteri ihtiyaçları, proje kaynaklarının geliştirilmesi veya değiştirilmesi ve sıkı veya değişen son tarihler arasında en etkili yaklaşım olacak şekilde tasarlanmıştır. Böyle bir ortam tipik şelale gelişimi için bazı mahkumlar yaratmaktadır, çünkü proje ortasında ekip değişikliklerine açık, değişen gereksinimlere karşı hassas ve değişen bir tarihe karşı son derece savunmasızdır.

Artık çalışmalarında neşe bulamayan değerli takım üyeleriniz için hissediyorum. Çok iyi bir şekilde yetenekleri yetenekli insanlar olabilirler; işlerinde kendilerini meşgul edecekler ancak sonunda en iyi kontrollerinin dışında kalan birçok faktör hala projeyi öldürebilir. Özellik geliştirmeye yaklaşmanın en iyi yolu, bireysel tutum ve ifadeyi yitirmeleri ve takım yaklaşımı açısından düşünmeleridir.

Bunun onlar için işe yaramayacağını görürseniz, o zaman onlar için özel bir kullanım alanı bulabilirsiniz. Son derece yetenekli ve tecrübeli iseler, mimari bir rolle ilgilenip ilgilenmeyeceklerini, üst düzey tasarımları, yaklaşımları ortaya koyabileceklerini, yeni teknolojilerle deneyimleyebileceklerini ve en iyi uygulamaları geliştireceklerini görün. Bu kişilerin tasarım belgelerini kontrol etmelerini ve gözden geçirmelerini sağlayın.

Bu hala onlara uymuyorsa, belki de ayrı bir dalda son derece karmaşık teknik yeniden yapılandırmalar, ayrı ayrı prototipler ve kavramların ispatları veya bazen yapılması gereken ancak uygun olmayan diğer trailblazlama çalışmaları için ayrı ayrı çalışmalarını sağlayın. tek bir proje veya sürümün kapsamı.

Eskiden olduğu gibi işte sevinç bulamazlar.

Doğru.

Bu yanlış yaptığınıza büyük bir semptom.

Çevik insanlara yeni kötü bir düzen getirmemelidir .

Çevik, ekibin kendisini en etkili kılacak şekilde kendi kendini organize etmesine izin vermelidir .

Öz-örgütlenme, yönetimin tuhaf kurallar getirmediği anlamına gelir. Kötü programları dayatmaz ve gereksiz etkileşime neden olmaz.

Bazı geliştiriciler, uzun bir süre boyunca, başkalarıyla minimum düzeyde etkileşimle, bir parça zor işi alma, bir tasarımı düşünme, potansiyel sorunları düşünme, sonra problemi parça parça çözme sevinciyle motive olurlar.

Neden bunu yapmaya devam edemiyorlar?

Neden onları değiştirdin?

Lütfen Çevik Manifesto'yu birkaç kez okuyun.

Çevik Manifesto diyor

Bireyler ve süreçler ve araçlar üzerindeki etkileşimler

İnsanları rahatsız edici ve verimsiz bir şekilde çalışmaya zorladığını söylemez.

İnsanları çok düşük değerli "etkileşime" zorlarsanız, o zaman çok ileri gittiniz.

Kapsamlı dokümantasyon üzerinde çalışan yazılım.

Bunu yapıyorlar mı? O zaman onları rahat bırak.

Sözleşme müzakeresinde müşteri işbirliği.

Bunu zaten yapıyor musun? O zaman değişme.

Bir planı takip etmeyi değiştirmeye cevap vermek.

Bu millet değişime cevap verebilecek durumda nerede? Eğer öyleyse, o zaman zaten Çevik idiler. Değişmeleri gerekmedi.

şirketim (ve yıllarca denedikten sonra hala denemeye çalıştı) aynı geçişi yapmaya çalıştı ve şimdiye kadar şahsen, bu konuda çok başarılı olamadım. Bu geçiş sırasında, çevik gelişim ve farklı yollar / yönler / endişeler / teknikler hakkında çok fazla kitap okudum ve kesinlikle katılıyorum ki, tüm ekip üst düzey, kaliteli insanlardan oluştuğunda saf çevik gelişimin en uygun olduğu (veya en azından aynı seviyedeki tüm insanlar).

Son sürüm, IMHO'yu her yerde beceri düzeyine sahip çok sayıda geliştirici olan ve aynı projeye dahil olan herkesi dahil etmeye çalıştıkları "çevik" bir takımdaydım. Bu bir felaketti. İşten daha fazla konuşup tartıştık ve sonunda ekibin ürettiği ortalama bir iş oldu (Peopleware ya da Mythical Man Month'ı ortalama alma hakkında okuyun). Tasarım kalıplarını unutun, düşük bağlantı veya küçük sınıflara ve yöntemlere kod kırmayı unutun. İlginç bir şey yapmaya çalışmayı unutun çünkü a) tüm ekip üyeleri tarafından (en azından zamanında değil) açıklanıp anlaşılamadı ve b) çevik olduğumuzdan beri, bu yinelemeyi başlattığım her neyse, kesinlikle anlayışı olmayan biri Bir sonraki yinelemede devam edecekti. Şahsen,

C ++ şablonlarıyla hiçbir şey yapamadığımdan ya da hayatımızı bu kadar kolaylaştıracak havalı (ama biraz karmaşık) düşük seviyeli çerçeve kitaplıklarını yazmamdan kesinlikle nefret ediyorum. Takımdaki başka hiç kimse STL başlık dosyalarını bile okuyamadığında böyle bir şey nasıl yapılabilir, fakat hepimizin aynı anda bir şey üzerinde çalışması gerekiyor. Tüm proje, özelliklere göre kaba zorlama özelliği olarak sona erdi, çünkü çevik vurgulamak gibi görünüyor.

Aynı zamanda, şirketimde yan yana çalışmayı ve kodumu paylaşmayı kesinlikle seveceğim birkaç kişi (çok az) var.

Ama şimdi bir seçeneğin var. A) Yüksek kaliteli kod üreten ve geliştirenleri kendi ekibine koyan tüm iyi, üst düzey geliştiricilerini al ve diğerlerini ayrı bir ekibe koy. Veya B) takımları dengelemeye ve iyi olmayanları iyi olanları koymaya çalışın. (A) 'da sorun, takımlarınızdan birinin düşük performans göstermesi ve iyi adamlardan iyi beceri / alışkanlıklar edinmemesidir. (B) 'de iyi adamlarınız (saf çevik ortamda) kendinizi sinirli hissedecek ve özgeçmişleri üzerinde çalışmaya başlayacaktır. Benimki güncel.

Peki sen ne yapacaksın?

Bunun doğru çözüm olup olmadığını bilmiyorum. Bana yaklaşık bir yıl sonra tekrar sorun. Ama eğer "saf çevik" yerine, bir ekip oluşturduysanız, ancak hangi kişilerin / grupların daha fazla etkiye sahip olduğunu (tasarım, kod incelemeleri ...) açıkça belirtmişseniz ve o kişinin bunu anladığından ve ekstra sorumluluk için ödüllendirildiğinden emin olmalısınız. Ekip üyeleri birlikte çalışmaya başladığında, iyi alışkanlıklar / uygulamalar toplayanları belirleyin ve onları iyi insanlarınızla aynı seviyeye yükseltin. Umarım insanlar bir veya iki kişiyi birlikte çalışarak geçirirken, diğer kişinin ne düşündüğünü ve nasıl çalıştığını öğreneceklerdir, bu nedenle aynı anda aynı kodda çalışmak için daha uyumlu olacaklardır. Ancak, bu gerçekleşene kadar, insanları bir projeye fırlatırsanız, hayal kırıklığından başka bir şey olmayacak (yine, sadece benim görüşüme göre).

Düşüncelerimden bazıları yazılımda profesyonel olarak nasıl başladığım üzerine kuruludur. Kooperatifken, akıl hocam olan biriyle çalıştım. Bana kodlama etiğinden iyi tasarıma, binlerce yazmadığınız binlerce satır kod okumaya kadar her şeyi öğretti. Başlangıçta aynı seviyeye yakın bir yerdeydik ve çevik bir takıma girip birbirlerinin kodları üzerinde çalışabileceğimizi söylesek gülünç olurdu. Fakat zamanla (birkaç yıl), benzer düşünmeye başladık. Kodunu basit bir bakışta anlayabiliyordum ve bana daha önce hiç görmediği koduma giderken, kesinlikle hiç problem yaşamadığını (ve buna şaşırdığını) söyledi. Bu yıllar sürdü, gece boyunca olan bir şey değil. Son birkaç yılda çevik ortamda afet sonrası felaket yaşadıktan sonra,

Bu gerçekten bir cevap değil, deneyimlerimi / gözlemlerimi özetliyor. Başkalarının bu konuda ne söyleyeceğini görmek istiyorum.

Çevik nedir?

Bu mu:

• Kural belirleyicilerin istediklerini elde etmek için izlemeniz gereken bir kurallar dizisi?

• Kendi güçlü yanlarınız, gereksinimleriniz ve sınırlamalarınız dahilinde işlerin yapılması için en iyi tahmin edilen bir yaklaşım mı?

Çevik'in ilk olduğunu düşünüyorsanız ve her zaman Scrum kurallarının her birini takip edersiniz ve bunu doğru yapıp yapmadığınızdan sürekli endişe duyarsanız, belki de bu bağlantı sizi biraz aydınlatacaktır.

İkincisi hakkında daha fazla düşünürseniz, tebrikler - çevik olursunuz. Herhangi bir Çevik metodoloji yalnızca işleri halletmek için nasıl gideceğinizin bir önerisi olabilir. Seçtiğiniz çevik yönteminizin herhangi bir yönü size karşı doğru gelmiyorsa, kullanmayı bırakma, değiştirme veya başka bir şekilde çevik olma göreviniz vardır.hakkında. Önemli olan bir şeyi başarmanız, yapay kısıtlamalarla geri tutulmamanızdır - yalnızca Başbakanımızın kimsenin asla istemediği belgelenmiş diyagramlar için sizi zorlayacağı eski şelale günlerimizde hepimizin bildiği ve sevdiği olanlar değil sadece "işlemin söylediği şey" olduğu için okuyunuz, fakat aynı zamanda kullandığınızın kısıtlarından da. Günlük bir scrum onun bir kısıtlama gibi hissediyorsa, o zaman göz açıp kapayıncaya kadar göz kırpmayın! Kör onlara sahip olmak, çünkü kurallar öyle diyor, eski yöntemlerden daha çevik değil.

Şimdi, sadece bir galon kola ve pizza için bir kapak olan bir odaya kilitlenerek işleri halleden bazı adamlarınız varsa, o zaman bu gerçeği kullanın. Onlara daha çok kendi kendine yeten sistemin bir kısmını ver ve onları kilitle. Tamamlandıklarında, o zaman bu işi bütünleştirmelerini sağlamalı (ya da eğer isterlerse başkasına yapmalarını) sistemin geri kalanıyla birleştirmelisiniz.

Alistair Cockburn , yöntemlerinde bunu açıkladı . "Seviye 3 uygulayıcıları" varsa, o zaman kusursuz bir çevik yöntem şu şekildedir:

“İş istasyonları ve beyaz tahtalar olan ve kullanıcılara erişimi olan bir odaya 4-6 kişi yerleştirin. Kullanıcılara her 1-2 ayda bir çalışan, test edilmiş yazılımlar sunmalarını ve aksi halde onları yalnız bırakmalarını sağlayın.

İnsanların bir karışımına sahip olduğunuz için, birlikte yapıcı bir şekilde birlikte çalışmalarını sağlamak için bir yol bulmanız gerekir ve bu, 1 büyüklüğüne uyan tüm yaklaşımların muhtemelen çok verimli olmayacağı anlamına gelir. Bu nedenle, ortak hedefin vurgulandığından emin olarak, görevleri bölmek zorundasınız. Bu adamları koda göndermek tamam, ama takımlarının çalışmalarının geri kalanının ayrılmaz bir parçası olacağının ve bunun başarısız olmasının, ürettikleri şeyin başarısızlığı olduğu konusunda farkında olmaları gerekir. . Bunu bir kez anladılarsa (yani hissettikleri her şeyi yapamazlar ve kullanılamaz bir şeyler sunarlar) işiniz biter.

Çevik herkes için değil, çevik proje için değil diyelim. Aynı zamanda çevik çok geniş bir terimdir ve Scrum, çevik bir sürecin sadece bir uygulamasıdır - bir şekilde, uygulamanın iyi bilinen adımlarla standartlaştırılmış süreç kurmaya çalışan en kısıtlı olduğunu söyleyebilirim.

Düşünülmesi gereken bir başka alan çevikliğin amacı nedir? Geliştiricilerin çalışma şekli konusunda çevik mi? Belki - bazı metodolojiler gerçekten de bu yöne gidiyor. Ancak çeviklik, kalkınmanın dışındaki alanları da kapsar. Agile, tüm süreci, bir etkileşimin nasıl çalıştığını, çalışan ürünü en önemli özelliklerle zamanında teslim etmeyi ve kaynakları nasıl kontrol ettiğinizi, şu anda projede nerede olduğunuzu görmeyi, vb.

Geliştirme sürecinizden hiçbir şeyi değiştirmeye çalışmayan metodolojiler var - Scrum değil. Tüm çevik metodolojiler sürekli iyileştirmeyi vurgular. Sürecinizde verimsiz bir adım tespit edersiniz ve onu iyileştirmeye / değiştirmeye çalışırsınız - bu çevik yoldur. Başka bir popüler çevik metodolojiyi kontrol edin - Kanban.

Siz / şirketiniz Scrum'u kullanmaya karar verdiniz ve bu bazı insanların hoşuna gitmeyip ayrılmayacağı gerçeğine yol açabilir. Geliştiricilerinizin her biriyle ayrı ayrı ilgilenmelisiniz. Her biriyle bunun hakkında konuşmalı ve tekrar işin tadını çıkarmasını sağlayacak bazı çıkarlar bulmaya çalışmalısın.

Mentor rolleri olabilir, başkalarına öğretebilir, yinelemeli çalışırken daha iyi mimariye nasıl yeniden kodlama yapabileceklerini gösterebilirler. Projeler arasında bir takım global mimari planlarını birlikte oluşturabilirler. Ayrıca, müşterilerin gereksinimlerin uygulanabilirliği hakkında düşünmeleri için sorgulama yaptıkları zaman kavramların kanıtı üzerinde çalışabilir, bilgi talebi taleplerine katılabilirler. Daha az yetenekli geliştiricileri olan çiftler halinde çalışabilir ve birlikte karmaşık bir iş yapabilirler, vb. Temel değerleri becerilerini kullanmakta ve başkalarının onlardan öğrenmelerine izin vermelidir.

Scrum ve çevik küresel olarak aslında bir şekilde bireyleri düşük tutuyor ve ekiplere öncelik veriyor - ekipler bireyler değil, uygulama sunuyor. Bu fikir, hiçbir zaman herkesin aynı beceri setine ve deneyime sahip olduğu bir ekibe sahip olamayacağınız gerçeğine dayanmaktadır.

Scrum'a geçişiniz başarılı olursa, genel sürecin düzeldiğini, teslimat sürelerinin düştüğünü, kalitenin düzeldiğini ve müşterilerin daha memnun olduğunu görmeleri gerekir. Geliştirilen uygulamaların kendilerinin daha kötü olduklarına inanmaya devam edebilirler ancak olabileceği kadarıyla nokta budur - müşteri şimdiye kadar yazılmış en iyi kodu istemiyor. Müşteriler, gereksinimlerini karşılayan en düşük / en ucuz / en hızlı geliştirilen çalışma kodunu isterler. Eğer kaba kuvvet bunun için yeterliyse o zaman olsun. Bu, yüksek vasıflı geliştiricilere sorunlara yol açabilecek bir şeydir, ancak çevikliğin başarısızlığı değil, iş taleplerinin ve mükemmeliyetçiliğin birbirine karıştığı yer.

Bazı önemli sorunlardan bazılarını alıp bunları büyük bir geliştiriciye teslim ederseniz, tüm takıma fayda sağlayacaktır. Daha sonra herkes hızlandırabilir ve süreçte bir şeyler öğrenebilir. Sadece bütün bir uygulamayı bu şekilde inşa etmeyin.

Kodu en düşük ortak paydaya su doldurmuyorsun. Deneyimsizleri daha iyi geliştiricilere ulaştırırsınız.

Neyin "çevik" olduğu veya neyin olmadığı ve burada paylaşılan çevik süreçle ilgili kişisel hisler, deneyimler ve yanlışlıklar hakkında çok fazla tartışma yapıldı, ancak sorunun cevabını gerçekten görmedim. Asıl soru, en iyi geliştiricilerinizin, saf sanat formu düzeyinde yazdıklarını kodlarını gördüklerinde ve ter ve kanlarını bir başkası tarafından saldırıya uğramış ve "bozulmuş" hale getirdiklerinde gördüklerinde nasıl motive edilmeleriydi. Çevik olsun ya da olmasın, bunun bir noktada olacağına dikkat edin, şimdi daha da görülebilir, çünkü kod üzerinde hala desteklediği tipik bir geçişi yerine diğerleriyle aynı anda çalışıyorlar. Sadece bu değişikliklerin yapıldığını görmezlerdi.

Burada anahtar olarak göreceğim şey, bu geliştiricilerin sorumluluğunu genişletmek ve odaklarını daha büyük resme dönüştürmelerine yardımcı olmak. Belki de bu, Yazılım Mimarı veya Takım Lideri veya Kıdemli Yazılım Mühendisi gibi yeni bir ünvan anlamına gelir. O zaman onlara bunun sadece bir seferde tek bir proje üzerinde değil, birden fazla projede daha büyük bir etki yaratma fırsatı olduğunu gösterin. Mülkiyet duygusu hala orada olabilir, ancak odak noktaları artık tek bir harika proje sunmak değil, TÜMÜ için çıtayı ayarlamak için yardım etmektir.projeler. Harika bir şey inşa etme konusundaki güçlü isteklerini yerine getirmelerine yardımcı olun, ancak şirketinizin yazılım mühendisliği uygulamalarını ve diğer geliştiricileri geliştirme odağını kaydırın. İş arkadaşlarının kodlarını parçalara ayırma fikrini ciddiye almak yerine, bu onların bir sonraki seviyeye geçmeleri ve takım arkadaşlarına rehberlik etmeleri ve seviyelerini yükseltmeleri için bir şans olabilir.

Diğer cevaplar tarafından ele alınmayan bazı hususları göstermeye çalışacağım ve IMO önemli.

Temel mesele şudur: Bazı geliştiriciler, zor bir iş yapmanın, bir tasarım ile düşünmenin, olası sorunları düşünmenin, sonra problemi parça parça çözmenin, başkalarıyla en az etkileşimle, uzun bir süre boyunca çözmenin mutluluğunu temel alır. zaman aralığı. Genelde işleri yüksek kalitede ve zamanında tamamlarlar; çalışmaları sürdürülebilir ve genel mimariye uyar.

Bu tür geliştiriciler çevik bir çevreye uyum sağlamayı zor bulabilir ve davranışları genellikle muhtemelen ego ya da eski moda olmakla ilgili "değişme isteksizliği" olarak reddedilir.

Genellikle göz ardı edilen şey, karmaşık sorunları çözmek için kişinin çok fazla bilgiyi ele alması gerektiği ve bunun çok fazla analize, düşünmeye, denemeye, bir çözüm çizmeye, bir kenara atmaya, başka bir deneye ihtiyaç duyabileceğidir. Böyle karmaşık bir problem bitmiş bir çözüm bulana kadar birkaç saatten birkaç haftaya kadar odaklanmış iş gerektirebilir.

Bir yaklaşım, geliştiricinin sorun belirtimini alması, odasına gitmesi ve iki / üç hafta sonra bir çözümle geri dönmesidir. Herhangi bir zamanda (gerektiğinde) geliştirici, ekibin diğer üyeleriyle veya paydaşlarla bazı etkileşimler başlatabilir (belirli konular hakkında sorular sorabilir) ancak işlerin çoğu, görevi atanan geliştirici tarafından yapılır.

Çevik bir senaryoda ne olur? Ekip, hızlı bir analizden (tımar) sonra sorunu küçük parçalara (kullanıcı hikayeleri) ayırır. Umut, kullanıcı hikayelerinin birbirinden bağımsız olmasıdır ancak çoğu zaman durum böyle değildir: karmaşık bir sorunu gerçekten bağımsız parçalara ayırmak için normalde ancak birkaç gün çalıştıktan sonra edineceğiniz bir bilgiye ihtiyacınız olacaktır. Başka bir deyişle, karmaşık bir problemi küçük bağımsız bölümlere ayırabiliyorsanız, bu sorunu temelden çözdüğünüz ve yalnızca titizlik çalışmalarınız kaldığı anlamına gelir. Örneğin, üç haftalık bir çalışma gerektiren bir sorun için, muhtemelen ikinci hafta boyunca, sprintin başlangıcında yapılan birkaç saatlik bakımdan sonra durum böyle olacaktır.

Bu yüzden, bir sprint planlandıktan sonra, takım muhtemelen aralarında bağımlı olan bir problemin farklı parçaları üzerinde çalışır. Bu, eşit derecede iyi olabilecek ancak birbirinden farklı olabilecek farklı çözümleri entegre etmeye çalışan çok sayıda iletişim yükü oluşturur. Temel olarak, deneme yanılma çalışması, ek bir iletişim ek yükü ile (dörtlü artışla) ilgili tüm ekip üyelerine dağıtılır. Bence bu sorunların bazıları Paul Graham tarafından, özellikle 7. maddede bu makalede çok iyi gösterilmiştir .

Elbette, çalışmayı ekip üyeleri arasında paylaşmak, projeden ayrılan bir ekip üyesiyle ilgili riski azaltır. Öte yandan, kod hakkındaki bilgiler başka yollarla da iletilebilir, örneğin kod incelemeleri kullanarak veya meslektaşlarına teknik sunumlar. Bu bakımdan, tüm durumlar için geçerli bir gümüş mermi olduğunu sanmıyorum: paylaşılan kod sahipliği ve çift programlaması tek seçenek değil.

Ayrıca, "çalışma işlevselliğinin daha kısa aralıklarla sağlanması", iş akışının kesintiye uğramasına neden olur. İşlevsellik öbeği bir sprint sonunda tamamlanabilecek "giriş sayfasına bir iptal düğmesi ekle" ise bu sorun yaratabilir, ancak karmaşık bir görev üzerinde çalışırken bu tür kesintileri istemezsiniz: olabildiğince hızlı bir şekilde 100 km'lik bir araba sürmeye çalışıyorum ve ne kadar yol aldığınızı kontrol etmek için her 5 dakikada bir durunuz. Bu sadece seni yavaşlatacak.

Tabii ki, sık kontrol noktalarına sahip olmak bir projeyi daha öngörülebilir hale getirmek içindir, ancak bazı durumlarda kesinti çok sinir bozucu olabilir: Birisi, durma ve bir şey sunma zamanının geldiğine ancak hız kazandırabilir.

Dolayısıyla, soruda açıklanan tutumun yalnızca ego veya değişime direnç ile ilgili olduğunu sanmıyorum. Bazı geliştiricilerin yukarıda açıklanan problem çözme yaklaşımını daha etkili olarak görmeleri de mümkündür, çünkü çözdükleri sorunları ve yazdıkları kodları daha iyi anlamalarını sağlar. Bu tür geliştiricilerin farklı şekillerde çalışmaya zorlanması üretkenliklerini azaltabilir.

Ayrıca, ekibin bazı üyelerinin belirli, zor problemlere göre yalıtılmış olarak çalışmasının çevik değerlere karşı olduğunu düşünmüyorum. Sonuçta, takımlar kendi kendilerini organize etmeli ve yıllar boyunca en etkili olduğu tespit edilen süreci kullanmalıdır.

Sadece 2 sentim.

Some developers are primarily motivated by the joy of taking a piece of difficult 
work, thinking through a design, thinking through potential issues, then solving
the problem piece by piece, with only minimal interaction with others, over an 
extended period of time

"Yalnız Rangers" gibi geliyor. Kanonik Scrum'da, bu insanlar takıma uymuyor ("etkileşim" bitini özlüyorlar).

"Yalnız Rangers" değillerse, o zaman umut vardır. Scrum'ı doğru yapıyorsanız, üzerinde çalışacakları özelliğin tasarımının bir parçası olmalıdır (Sprint Planlama sırasında). Bu, başkalarıyla etkileşime girmeleri için gereken tek zamanla ilgilidir. Bu özellikle ilgili tüm hikayeleri kendilerine "atayabilirsiniz".

Sprint sırasında, sadece günlük Scrum tarafından "rahatsız edilecekler" ... onları (eylemlerle, kelimelere göre değil) zamanlarının sadece 15 dakikası olacaklarını ve sadece her şeyin çalıştığını garanti etmek için sorunsuz. Üç soruya yakın durun, çoğu insan uymaktan vazgeçer.

Ekibimizde, sadece performans iyileştirmeleri için özel bir grubumuz var. Bunları pek görmüyoruz, sadece sprint başlangıcında yapılacak değişiklikler hakkında konuşmak ve sonunda geriye dönük olarak. Scrum Takımı ekibine rapor veren kendi "scrum liderleri" var. Size söyleyebilirim, eğleniyorlar.

Joe (Hero geliştiriciniz) biraz esnekse, bir sorun görmüyorum:

Yukarıda da belirtildiği gibi, ekibin kendi kendini organize etmesine izin ver: Eğer Joe'nun kendi başına çiğnemesine izin vererek bazı problemler en iyi şekilde ele alınırsa, açık fikirli bir kendini organize eden ekibin bu sonuca kendi başlarına ulaşmasını beklersiniz.

Scrum'un dayattığı birkaç kısıtlama içinde kalan tek zorluk:

1. Düzenli aralıklarla işlevselliği sağlamak: Eğer Joe'nun aylarca bir problemi çiğnemesine izin verirseniz, en sonuna kadar gösterecek bir şey yoksa, o zaman Joe gerçekten çevik değildir: Ürün sahibini rehin alıyor ve tekrar belirtme fırsatı vermiyor ürünün bu kısmı. Bu uygulamayla geç kalma riski vardır ve kimse farketmez. (Ancak açıklamanıza göre bu pek olası değildir). Çözüm: Joe'dan PO ile birlikte oturmak, kullanıcı öyküsünü kırmak ve tercihen (ancak zorunlu değil) kullanıcı değeriyle ara teslimatlar üzerinde hemfikir olmak istemeyecek kadar fazla olur mu?

2. Ürün sahibi tarafından belirlenen öncelikleri yerine getirmek: Eğer kod parçaları uzmanlara aitse, o zaman ürünün evriminin ticari öncelikler yerine her bir uzmanın mevcudiyeti tarafından belirlendiği bir durumu riske atarsınız: Takımın geri kalanı şunları yapabilir: daha az önemli özellikler üzerinde çalışıyor olmakla birlikte, ilk 3 özellik duraksadı çünkü "sadece Joe bunu yapabilir". Bu kötü. O anda, takım (geçici olarak) alışkanlıklarını değiştirmeli ve Joe çalışmasını daha fazla ekip üyesine bölmelidir.

Kısacası: Kahraman geliştirici Joe, PO ile her bir sprintte nasıl ilerleme göstereceğini kabul ederse, takım ona bazı hikayeler atayabilir ve onu yalnız bırakabilir. Fakat eğer PO Joe için çok fazla çalışıyorsa ve takım için yeterli değilse (ya da tam tersi), o zaman Joe ve takımın PO'ya değil adapte olması gerekir.

Çevik bir ekibin kuralları ekibe uyacak şekilde özelleştirilmelidir - bu gerçekten kişiselleştirme olabilir; Örneğin, kuralın olduğu bir takım üzerinde çalıştım:

Tüm Kod bir çift tarafından yazılmalıdır, ancak David yalnızca kod yazabilir.

David, öncelikle başkalarının kendi kodlarında kullanacakları araç üzerinde çalışan üst düzey bir geliştirici / mimardı. Yazdığı koda sahipti. Sürdürülebilir ve test edildi ve ekipteki herkes muhtemelen en iyi kodlayıcı olduğunu ve belirli çerçeve parçaları oluşturmasına ve bunları takıma eksiksiz sunmasına izin vererek ekibin en iyi şekilde hizmet edeceğini biliyordu.

Bahçe çeşitliliği içe dönükleri için bir cevabım yok, ancak istisnai içe dönükler için ekip, fayda sağlamak için farklı kurallar alacak.