(Küçük) bir geliştirici, geliştirme / BT ekibinde daha iyi süreçler ve uygulamalar için zorlanmalı mıdır?

Değişimi haklı çıkarabilirsem ve ekibin çalışmasını sağlamasına yardımcı olursa, ekibimin süreçlerini şekillendirmeye yardımcı olma yeteneğine sahip bir genç geliştiriciyim. Bu benim için yeni, çünkü eski şirketlerim yönetimden gelen süreçleri katı bir şekilde tanımladılar.

Ekibim oldukça küçük ve biraz yeni (<3 yaşında). Onlar eksikliği:

• iyi tanımlanmış bir yazılım geliştirme / iş yönetimi çerçevesi (scrum gibi)
• güçlü ürün sahipliği
• iyi tanımlanmış roller (örneğin işletme personeli manuel testler yapacak)
• düzenli standup toplantıları
• konsolide bir sorun takip süreci (bir aracımız var, süreç hala geliştiriliyor)
• bir birim, sistem, regresyon veya manuel test paketi veya listesi
• iş mantığı ve süreçleri ile ilgili belgeler
• iç ve müşteriye dönük ipuçlarını belgelemek için bir bilgi tabanı

Ve liste devam ediyor. Yönetim, değer haklı olduğu sürece iyileştirmelerin uygulanmasına açıktır ve en önemli işin (yani gelişimin) yapılmasına yardımcı olur. Bununla birlikte, temel varsayım, hiç kimse sizin için yapamayacağı için uygulamada sahip olmanız gerektiğidir. Ve yukarıdaki projelerden bazılarının önemsiz, şüphesiz zaman alıcı ve açıkça geliştirme çalışmaları olmadığı söylenmeden devam ediyor.

Zaman geçtikçe (küçük) bir geliştiricinin yukarıdakileri denemek ve zorlamak için harcadığı çabaya değer mi? Yoksa “şeridinde kalmak” ve gelişmeye odaklanmak, süreç tanımının ve optimizasyonun büyük kısmını yönetimde bırakmak en iyisi midir?

Şimdiye kadar iyi cevaplar, ama bütün üsleri kapsamıyorlar.

Tecrübelerime göre, üniversiteden yeni çıkmış pek çok insan fantastik teorik bilgilere sahip - benden veya on yıllarca yaşayan bir yaşam için yazılım geliştiren yaşlılardan çok daha iyi.

AMA, ve bu büyük bir AMA, bu bilgi herhangi bir pratik senaryoda temellendirilmemiştir. Gerçek dünyada, bu teorinin çoğu düz bir şekilde düşer veya en azından gerçek bir dünya senaryosunda o kadar iyi çalışmadığı için pratikte olduğu gibi büyük miktarda tuzla birlikte alınmalıdır.

Örnek olarak: Uzun zaman önce çalıştığım bir uygulama, OO prensiplerini ve teorisini T'ye uygulamak üzere tasarlanan, her yere uygulanan birçok desenle parlak bir OO teorisyeni tarafından tasarlandı.

Harika bir yazılım tasarımı parçasıydı.

Ne yazık ki, bu üretim ve bakım kabusu ile sonuçlandı. Kod tabanı o kadar geniş ve karmaşıktı ki, yer değiştirmek mümkün değildi; Özellikle kırılgan olduğu için değil, çok karmaşık olduğu için, ne olacağı korkusuyla kimse dokunmaya cesaret edemedi (asıl mimar / tasarımcı, o zamandan beri çoktan müteahhitti).

Ayrıca, tam olarak çok katmanlı desen yapısından ve tasarım gerektiren sınıf kütüphanelerinden dolayı çok zayıf bir performans sergiledi. Örneğin, veritabanına tek bir çağrı yapmak için ekrandaki bir düğmeyi tıklatmak, yüzlerce nesne başlatılması ve yöntem çağrılarıyla sonuçlanır - hepsi gevşek bağlantı sağlama ve bunun gibi şeyler adına.

Bu mimar, adına konu hakkında birkaç kitap yazan bir üniversite profesörüdür. Bir gün hiçbir zaman ticari bir projede programcı olarak çalışmadı.

Pratik deneyim geliştirme yazılımına sahip insanlar, tasarımın kaçınılmaz olarak daha pratik bir yaklaşımla sonuçlanabileceğini ve daha pragmatik bir yaklaşımla sonuçlanacağının farkına varacaklardı.

Aynı şey, yeni bir mezun olarak karşılaştığınız diğer pek çok şeye veya herhangi bir şirkette gerçekten yeni bir çalışan için de geçerli olabilir. Bunu varsaymayın, çünkü teorik tabanınız size bir şeyin yanlış ya da optimal olmadığını söyler, bu şekilde yapılması için çok iyi bir neden yoktur.

Şimdi bile, bu alanda 20 yıldan fazla deneyime sahip, birlikte çalıştığım şirketlerde işlerin nasıl yapıldığını eleştirmekten kaçınıyorum. İşlerimin, deneyimimden en uygun olandan farklı olduğunu, ancak savaşçı bir şekilde olmadığını fark ettiğimi söyleyeceğim. Bu çoğu zaman neden bu şeylerin olduğu gibi ilginç konuşmalara yol açar. Belki de değişimler olacak ve belki de değişmeyecek, değişen şeylerin değerinin maliyetten daha küçük olmasına bağlı olarak değişmeyecek.

İşlerin daha iyi yapılabileceğini önermekten korkmayın, ama her zaman her şeyi bilen sümüklü bir çocuk olarak görmeyeceğinizden emin olun, daha ziyade öğrenmeye istekli ve aynı zamanda sadece öğrenmeye istekli bir iş arkadaşı olarak Sadece teorik doğruluk değil, şirketin iyileştirilmesi için süreçlerin iyileştirilmesine yardımcı olur.

Evet ama çok özenle!

Bunu açıklığa kavuşturmama izin ver.

Yazılımın yaşanabilirliğini artırmak için çaba göstermelisiniz. Eğer kod / takım / işletme / proje / yönetime bakarsanız ve ilk müdahaleniz duş almaksa, yaşanabilir değildir. İlk cevabınız haykırmaksa evet! ... ve sonra ofis dışına çıktığınızda şikayetçi olun, o zaman evinizi daha yaşanılabilir hale getirmeniz gerekir. Bu bir his ve bunu bileceksin.

Olduğu söyleniyor, sen karmaşık bir simatez içinde çalışıyorsun . Yaptığınız her şeyin yanlış gitmesi muhtemeldir ve muhtemelen en azından kısa vadede işleri daha da kötüleştirir, çünkü basit bir değişimin dalgalanmaları vardır. Bu yüzden ilk önce mütevazı olun, bir itiraz olmak ya da işlerin kötü olması gerektiğini kabul etmek istemem, demek istediğim, sizin iyi niyetlerinizin sizi şiddetle vahşileştireceği gerçeğiyle yüzleşmek demek.

Sorun

En iyi niyetlerle geniş bir kapsamlı değişimin gerçekleşmesi gerektiğini düşünebilirsiniz ve bu durumların var olduğu konusunda hemfikir değilim, ama düşünmek için biraz zaman ayırın. Mevcut sistem çalışıyor, siz ve ekibiniz kod üretiyor, belki yavaş, belki acı veriyor, ama çalışıyor ve hepiniz bunun nasıl yapılacağı konusunda deneyime sahipsiniz. Ne bekleyeceğinizi biliyorsunuz, kısacası bu sistemde uzman profesyoneller.

Süpürme değişiminden sonra belki de uygulayıcı dışında kimse ne bekleyeceğini bilmiyor. Kısacası, sistemin bu bölümünde herkes bir neofit seviyesine getirildi. Bu iyi değil. Neofitlerin zaman alan yeni kuralları öğrenmeleri gerekir. O zamanlar neofitler hata yapıyorlar çünkü uygulanmadılar. Bu hatalar, şimdi yaşamak zorunda olduğunuz ve şimdi olduğu kadar ışıl ışıl olan bir yerde olmadığı sistemin bir parçası haline gelir.

İleri doğru bir yol

Eğik çizgi, yazma ve yeniden oluşturma işlemlerinin yapabileceğiniz en iyi zaman olduğu zamanlar vardır. Eski sistemde kimse uygulanmazsa özellikle çekicidir, çünkü kaybedilen tek şey kodlanmış bilgidir. Eğer bu bilgi tamamen anlaşılmazsa, o zaman zaten kaybolmuş ve baştan başlamak tek seçenek. Tersine, kodlama yöntemi veya nasıl kullanıldığı sorunlu ancak işleyiş ise, bu bilgiye hala erişilebilir ve belki de değer kaybetmeye değer, belki de değil - Kararı hafifçe almayın.

Diğer bir seçenek de, herkesle birlikte bir referans çerçevesine sahip olacak şekilde sistemle çalışmak, ancak sistemin küçük parçalarını değiştirmek, böylece ekipteki herkesin farkında olması veya değişimin farkında olmaması durumunda, her ikisinin de kolay olması. fark ve öğrenmesi kolay. Kaizen denilen uygulamaların temeli budur . Sunumda daha geliştirici odaklı bir formül sunulur Altın Yakayı Tıraş, izlemenizi ve düşünmenizi şiddetle tavsiye ederim.

Öyleyse, hayatınızı iyileştirecek, değiştirilebilecek küçük bir şey ve umarım diğerlerininkine sahip olacaksınız. Durumu düzeltin veya iyileştirin. Bu size değişiklikleri uygulamaya koyma konusunda pratik ve deneyim verecektir. Geri bildirim aldığınızdan emin olun: daha iyi tartışabilir miydiniz, gerçekten yararlı mıydı, sistemin başka bir bölümünü üzdü mü. Neler yapılabileceği ve nasıl yapılacağı konusundaki hislerinizi geliştirin.

Şimdi üç şey oldu:

• sistemi geliştirdin,
• sistemi nasıl değiştireceğinize dair tecrübe edindiniz
• Ekip, sistemi başarıyla değiştirdiğini gördü.

Şimdi, deneyiminiz büyüdükçe ve düşük asılma problemlerini ortadan kaldırırken, sistemdeki daha zor meselelerle yüzleşmeye başlayacaksınız ama en azından şimdi X'i değiştirmemiz gerektiğinde:

• Değişikliğin sistemi nasıl etkileyeceğini biliyorsunuz
• Hangi sorunları doğuracağını biliyorsunuz (hangi kuralların yeniden öğrenmeye ihtiyacı var)
• Değişikliğin ortaya koyacağı sorunları düzeltmek veya geliştirmek için bazı acil yollar biliyorsunuz
• Etrafınızdaki insanlar sistem hakkında bilgili olduğunuzu ve başarıyla değiştirebildiğinizi biliyor

Evet yapabilirsin. FAKAT...

Dikkatli olmalısın.

Kariyerimin başlangıcında (çok uzun zaman önce) "Junior" olarak birkaç aylık bir projeye girdiğim için şanslıydım.

İlk fark ettiğim gibi (OMG) kod deposu yoktu! Tüm kod birleştirmeleri posta yoluyla birbirlerine zip dosyaları gönderilerek elle yapıldı.

Bu yüzden (ayrıca yeni) yöneticime gittim ve bir havuza sahip olmamız gerektiğini önerdim. Cevap: Tamam, organize et ....

Yani, bir kod deposunu, yardım almadan, şirkette yeniydi, şimdi bu zor bir deneyim oldu.

Hepsini kurduğum zaman, (şok) kimse kullanmak istemedi. Bu yüzden işleri zorlamaya çalıştım ve neyse ki yöneticim bunun önemini anladı, bu yüzden destek aldım.

Ancak bu benim çok sevilmediğim ve ne yazık ki kaynak kontrol sisteminden türetilen bir takma isim almamla sonuçlandı.

Bu yüzden benim üstlenmem, önce ekip üyelerinizi hissedin, sonra ne kurmanın önemli olduğunu düşündüklerini.

Belki seninki gibi bir listesi de vardır. Belki herşeyi bir araya getirdiler ve listedeki o "şeyi" yapmak istediler. Belki onlar .... (her neyse) ....

Bütün takım aynı hizada olmalı.

Ama onlar değilse, o zaman hala profesyonelce çalışabilirsiniz. Ve düşünen insanlar gibi bulun ve nasıl yapılması gerektiğini düşündüğünüzle birlikte çalışın. Bu iyi sonuçlar getirirse, daha fazla kişi sizinle çalışacak, sonunda "süreç" olacak.

Aynı kodda olduğu gibi geliştirme süreçlerinde de aynı: sürekli iyileştirme gerekiyor.

Yani Evet, her zaman iyileştirmeyi denemelisiniz, geliştirmek mümkün olanı.

Ayrıca, birlikte çalıştığınız birçok insanı hatırlayın, zaten profesyonel olabilirsiniz ve neyin yanlış olduğunu ve neye ihtiyaç duyulduğunu bilirler.

Zaman geçtikçe (küçük) bir geliştiricinin yukarıdakileri denemek ve zorlamak için harcadığı çabaya değer mi?

Evet, işleri daha iyi hale getirmek için her zaman çaba göstermeye değer. Sonuçta hangi sorunlarla karşılaştığını en iyi sen biliyorsun.

Ancak bahsettiğiniz gibi, çözülmesi gereken çok fazla sorun var ve bu sorunların çoğu çok değerli değil. Ve pek çok yerde, başarınızın veya onları savunmak için daha iyi konumlandırılmış olan diğer insanlarınızın üstesinden gelinmeyen engeller olacaktır. Böylece her zaman o toplama anlamına gelse bile, iyi şeyler yapmak için çalışmalısınız hangi şeyler daha iyi yapmak için çalışırken zaman harcamak.

Çünkü sonuçta, çözümün bir parçası değilseniz, sorunun bir parçasısınız.

Evet. Ancak örgütsel değişim, yaşlılar için bile zordur, bu yüzden gerçekten bir fark yaratmak istiyorsanız, doğru şekilde yapın:

• İlk haftalarda değil: Bu zamanı aşağıdakiler için kullanın:

  • İyi bir ilk izlenim oluşturun. Takıma uygun olduğunu göster.
  • Kültürü ve politikayı ya da şirketinizi anlayın. Değişiklikleri zorlamak güvenli midir?
  • İş arkadaşlarınızla iyi bir ilişki kurun
  • Takımınızın süreci, kuralları ve ihtiyaçları hakkında bilgi edinin.
  • İşini öğren ve elinden gelenin en iyisini yap. Kesinlikle yeterince meşgul olacaksın.

• Savaşlarını seç. Erken zafer kazanın : Her şeyi değiştirmek için enerjiyle gelebilirsiniz, ancak bu gerçek dışıdır. Asılı meyvelere odaklan ve fikirlerinin işe yaradığını göster. Daha karmaşık gelişmelere açık olmalarını istersiniz. Ve kitaplarda işlerin daha kolay olduğunu unutmayın.

• Başkalarının imalarını göz önünde bulundurun : Çok sayıda dosyayı etkileyen refraktörler yapıyorum. Şifreyi geliştirseler bile, birleşmeleri eşek ağrısına çevirmemek için çok dikkatli olmalıyım. Bu şekilde çalışmaya devam etmelerinin nedenlerini anlamaya çalışın. Test eksikliği olduğundan ve test edilmemiş kodu sık sık üretime zorlamaktan korktuğu için Scrum'ı kullanamazlar. Gerçekleştirilebilir bir test yazmak kolay bir iş değildir. Geçerli kodun test edilmesi gerçekten zor olabilir. Ayrıca, ekip testler veya test edilebilir kodlar yazmak için kullanılamaz. Geçerli kod tabanının test edilmesi özellikle zor olabilir ve yeniden yapılandırılması gerekir. Bu sorunu değiştirmek yıllarca sürebilir, ancak en azından kök nedene odaklanabilirsiniz.

• Yargılama. Talep etmeyin. Bunu isteyin ve dikkatlice dinleyin: Bu, iletişimin kritik olduğu bir andır ve biz, programcılar, ince nüanslarda genellikle çok iyi değiliz. Yardımcı olacak teknikler var . Cevaba odaklanmak yerine fikrimizi zorlamak kolaydır. İlk önce puanlarını aldığınızı hissetmelerini sağlayın. Duyguların önemli olduğunu anlayın. Bu değişiklik onlara ne hissettiriyor? korku? insuficiency? öfke? hüsran? umut? Tembel? Aptal? (Asla insanları aptal hissetme). Elbette daha önce birçok soru sormuş olacaktınız ve bu birçok yanlış adımı önleyecektir.

• Örneğe göre : şikayet etmek kolaydır, değişiklik yaratmak zordur. Sonuçları göster ve insanlar sana inanacaktır. Test kullanmazlarsa, birim testlerinizi yazabilirsiniz. Kişiler belge vermiyorsa, bazı google doc'ları ekiple paylaşabilirsiniz. "Tamam, yap" ın mümkün olan en iyi senaryolardan biri olduğunu anlayın ve sonra bunu sunmanız gerekir. Bu durumda , hangi kaynaklara ihtiyaç duyacağınızı düşünmeniz gerekir . Örnek: bana küçük bir Amazon örneği ver ve Jenkins sunucusunun yöneticilerinden iki saat geçir

• Küçük ve Basit Tutun (ve Ucuz): Resmi bir bütçe onayını beklemek istemezsiniz veya patronlarınızın pahalı programcıların değerli zamanlarını kaybettiğinizi düşünmesini istemezsiniz. Bu kodun yazılımları incelemesi veya birkaç açık kaynaklı aracı değerlendirmesi harika olurdu, ancak şu an için repoyu kullanacağız.

• Kritik kitle edinin: Kaliteyi arttırmaya odaklanan bir grup insanı toplayın. Hatta onlarla konferanslara gidebilir, yardım veya rehberlik isteyebilirsiniz. Peopleware , takımın temeli ile "dev olguyu uyandırmak" ı tam anlamıyla verimliliği yavaşlatan bazı aptal uygulamalara karşı isyan ediyor. Bu bireysel olarak çok tehlikeli olurdu ve tavsiye etmem. Ancak tüm grup kabul ederse değişiklik daha kolaydır.

• Biraz zaman ver. Daha sonra ayaklarınızla oy verin: Birkaç aydan iki yıla kadar denemek isteyebilirsiniz. Ancak bazı şirketlerin kolay çözümleri yoktur. Bazı takımlar değişmek istemez ve teşvikleri yoktur. Ve bazı kod üsleri saf korku. Bunun dünyaya karşı olduğunu düşünüyorsanız, iş havuzunda birçok teklifin bulunduğunu unutmayın. İyi uygulamaları öğrenmek istiyorsunuz ve uzun vadede, daha az maaşla daha az ücretle ancak daha değerli hale getirecek bir tecrübe kazanmak için daha iyi olacaksınız.

Bonus: Eğer başarılı olursa CV'niz / Röportajlarınız için yazınız. Bir Junior olarak genellikle söyleyecek çok az şeyiniz vardır ve daha iyisini yapmak için bir değişiklik yaratmak her zaman büyük bir işarettir. Kişisel olarak ne yaptığınız ve başkalarından neler yapıldığı hakkında çok net ve gerçekçi bir görüşe sahip olmak istiyorsunuz. Aşağıdaki görüşme sorusunu düşünün.

• Bana takımda bir fark yarattığın zamandan bahset.
• Ben çok eski kafalı uygulamalar yaptıkları bir yerdeydim. Pek çok insan bundan memnun değildi ve üretkenlik geliştirmesi gereken büyük bir oda vardı. Bu yüzden retrospektiflerle hızlı bir deney yapmayı önerdim, X ve Y yaptık ve bunun sonucunda bu harika ölçülebilir sonuç elde ettik ".

Evet. Ama önerdiğin şeyler değil.

Listenizde Birim / Entegrasyon testleri ilerleyebileceğiniz tek öğedir.

Bunları minimum zaman yatırımıyla kendiniz eklemeye başlayabilir ve anında değer gösterebilirsiniz. Yaygın kabul görmüş faydaları olan ve başkalarının çalışma uygulamalarını etkilemeyecek teknik bir problemdir. Ayrıca kazanılırken, sonuçlar kabul edilmese bile, kod tabanına ilişkin bilgiler verilir. Kolay bir satış.

Diğerleri genellikle tüm ekibi veya hatta diğer ekipleri içeren iş süreçleridir. İyileştirmeler önerebilir, ancak küçük bir çalışanın değişmesi zor olacak ve bunları değiştirme süreci genellikle teknik olmayan ve muhtemelen normal çalışmanızla ilgisi olmayacak.

Ayrıca, CI boru hatlarının kurulması, otomatik dağıtımlar, versiyonlama, paketleme kütüphaneleri gibi saldırılar için iyi şeyler önerebilirim.

Göre değişir:

• Daha iyi uygulamalardan ne kadar kazanmayı beklediğiniz
• oraya ulaşmak için ne kadar çaba harcamak zorunda kalacaksınız
• başarı ve risk şansı nedir - basit evlat edinme başarısızlığından yeni uygulamalara kadar gerçekten korkunç, kod kalitesi düşüyor, kilit insanlar ayrılıyor, herkes senden nefret ediyor ve kimsenin ismini bilmediği farklı bir şehirde başka bir iş bulmalısın

Temel olarak: En iyi olduğunu düşündüğünüz şeyi savunmak için makul bir süre harcamak sizin sorumluluğunuzdadır - ancak karar bir ekip veya yönetim sorumluluğu olmalıdır. Daha iyi uygulamalar yapsanız bile, yabancılaşan kişilerin nadiren buna değer olduğunu unutmayın.

Scrum gibi en karmaşık şeylerle başlama. Mümkün olan en kolay adımlarla başlayın.

Kaynak kodu yönetiminden bahsetmediniz. Bazı kaynak kod deponuz var mı (git, svn, cvs, ...)? Etiketleme ve dallanma için bir strateji? Bunlar aceminin başarabileceği basit adımlardır. Bu adımların (denediğiniz) hangi sorunları çözdüğünü ve şirketinizin maliyetleri düşürmesine nasıl yardımcı olduğunu okuyun (yönetimin ilgilendiği şey budur).

Sonraki adım, geceleri veya her check-in işleminden hemen sonra, örneğin Jenkins ile otomatik hale getirilmiş olabilir. Testleri otomatik olarak da çalıştırabilirsiniz. Kod kalitesini ölçmek için bazı araçlar ekleyin (oh evet: bazı kodlama standartlarını tanımlamak da iyi bir adımdır).

Scrum gelince, "Extreme Programming" (XP) hakkında daha iyi okuyun. Scrum, XP'nin birçok fikrine dayanır ve etrafına resmi bir süreç ekler - XP'nin kavramları hala bu süreç olmadan kullanılabilir.

Bir şeyler önerin, temel bilgileri sağlayın, diğerlerini denemeye ikna etmeye, sonuçları analiz etmeye çalışın ... ama başkalarından çok fazla işbirliği beklemeyin: çoğu insan eski kötü alışkanlıklarına bağlı kalmayı tercih eder. Ama bunu denemeyince hiçbir şey gelişmeyecek

Takımın oldukça yeni olduğunu söylediniz (3 yaşında), eğer şimdi bazı iyi prensipleri uygulayamazsanız, 10 yıl sonra bunu yapmak daha zor olacaktır. Test etme ve versiyonlama sistemi gibi bahsettiğiniz şeylerden bazıları, daha önce önerebileceğinizler arasındadır, ancak bariz faydaları üzerinde durmadan ve geliştirme yığınının gerektirdiği araçları seçmeden öneride bulunma.

Başlangıçta sorular sorun

Listenizi okurken aşağıdaki soruları öneririm (nasıl oturduğunu görmek için listenize geri dönün):

• İşletme sahiplerinin hangi işi istediğini nasıl görebilirim?
• [Scrum] denedin mi?
• Bunun için ürün sahibi kim?
• Hangi roller var?
• [Bu rol] ne yapar?
• Bu etkinlikten hangi rol sorumludur?
• Günlük standup denedin mi?
• Engellerimi ekibin geri kalanına nasıl iletirim?
• Diğer takım üyelerinin ne işe yaradığını nasıl öğrenebilirim?
• [Bunu] sorun izleme aracına mı koymalıyız?
• Sorun izleme aracına [bunu] nasıl yazmalıyız?
• [Bu] olduğunda, sorun izleme aracına [bu] olarak koymalı mıyız?
• Nasıl test ederiz?
• Testlerimizi başkalarının tekrar kullanması için nasıl kaydederiz?
• [JUnit] denedin mi?
• [Bu] nerede belgelenmiştir?
• [MediaWiki] denediniz mi?

Soruların önceliklerinize uygun olması veya uygun olması için [parantez] içindeki şeyleri uygun şekilde değiştirin. İfadelerim tarzınıza uymuyorsa, yeniden yazmayı düşünün.

Bunu zaten yapmaya başlamış olabilirsin. Grup konuşmaları yerine bire bir konuşmaları tercih edin. Çünkü bire bir, diğer kişinin ne düşündüğünü daha iyi okuyabilirsiniz. Bu değişiklik için o kişi mi? Buna karşı? Weakly? Rabidly?

Yeni olduğunuzda, soru sormak pratikte ücretsizdir. İnsanlar sizden soru sormanızı beklemelidir. Sorularınız dolaylı olarak karşı çıktıkları bir pozisyonu savunsalar bile, sinirlenmemeliler. Bu pozisyona neden karşı olduklarını açıklamalıdırlar. Onlarla tartışmaya karşı tavsiye ederim. Tartışma, pozisyonları ikna ettiğinden daha fazla sertleştirme eğilimindedir. Kimin hangi pozisyonda olduğunu ve devam ettiğini unutmayın.

Sonra, adım at

Sizin ve muhtemelen başkalarının (daha önce sizinle aynı fikirde olduğunuzu belirttiğiniz notların) istediğiniz değişiklikleri başlatabildiğiniz yolları arayın. Herkes standup istemiyor mu? Neden olmasın? Belki bir tanesini isteyenler, kendi haklarına sahip olabilirler. Tüm ekip kadar etkili değil, şimdi sahip olduğun kadar.

Bir engeliniz olduğunda (ve bir standup paylaşmayacağınızı varsayarsak), yardım için takıma e-posta gönderin.

Rollerin ne olması gerektiğini, muhtemelen sizinle aynı fikirde olan başkalarının desteğiyle tanımlayın. İş, sizin (muhtemelen bir grup) sizin olması gerektiğini düşündüğü rolü içerdiğinde sürekli olarak insanlara gitmeye başlayın. Geri çekilirlerse, bu rolün kime ait olduğunu belirlemelerini isteyin.

Ürün sahiplerinden (tanımladığınız) ürünlerinin şimdi ve gelecekte nasıl çalışması gerektiğini düşündüklerinin açıklamalarını yazmalarını isteyin.

Bir test çerçevesi kurun (eğer diğerleri bunu destekliyorsa, hangi çerçeveye ilişkin ortak bir karar verin) ve bunu projeleriniz için kullanın. Hataları düzeltirken testler yaz. Bunu sorun izleyicideki hata raporunda belgeleyin ([konumda] depolanan hatayı gösteren testi yazdı). Diğerlerini, değişiklik yaptıklarında testleri çalıştırmaya teşvik edin. Olmazsa, testleri kendiniz yapın ve gerektiğinde sorunları izleyiciye gönderin.

Yönetim desteği alabiliyorsanız, wiki yazılımı veya benzerlerini kurun ve eşyalarınızı belgelemeye başlayın. İnsanlar size belgeleri okumadıklarını gösteren sorular sorarsa, ilgili sayfalara yönlendirin. Dokümantasyonu anlamadıkları takdirde daha fazla soru sormalarını teşvik edin. Dokümantasyonda yer alan soruları sormaya devam ediyorlarsa, cevap verirken dokümantasyondan alıntı yapın. Sorunun okumaktan ziyade yapısal olduğunu düşünüyorsanız, wiki'yi güncellemelerini teşvik edin.

Bir seferde sadece bir göreve konsantre olmayı önerebilirim. Ve kesinlikle sadece bir seferde bir tane itin. Zorlama. Bu grubun istediğinden daha sert itme örneğine bakın . Davranışlarınızı değiştirmek için onlarınkinden daha fazla konsantre olun. Yolunuz doğru yolsa, sizi gözlemleyen insanlar için açık olması gerekir. Eylemler sözlerden daha yüksek sesle konuşur. Dürtme yaparken aynı kişiyle kendinizi tekrar etmemeye çalışın. Atı suya soktuğunuzda, ne zaman ya da diğerine ne içip içilmeyeceği seçimini bırakın.

Sonunda kıdemli olacaksın

Zamanla, ekibin yeni insanları işe alacak. Yeni işe alım olmayı bırakacak ve konumlarınızı yeni insanlarla savunabileceksiniz. Değişiklik yapmak için onlarla çalışın. Ayrıca mevcut takım arkadaşlarınızla da ilerleme kaydettiğinizi görebilirsiniz. Ya da işe yaramazsa, daha iyi uygulamaları olan yeni bir iş arayın. Acelem yok. Bir işin var. Bir süre daha iyi bir iş sahibi olmak için, daha iyisini ya da daha iyisini bularak bekleyebilirsiniz.

Kısa cevap : Hayır, diğer cevaplarda belirtilen tüm nedenlerden dolayı. Orta veya üst düzey bir geliştirici bile olsa, yeni bir takıma katılırken ilk önce bunu anlamak daha iyi olur .

Önerilen bir çözüm :

1) Geliştirilmesi gereken bir şeyi gördüğünüzde, not alın! (not defterinde, dijital notta ...)

2) 6 ay sonra notlarınıza geri dönün ve kontrol edin. Kaç fikir şimdi anlamsız ve yetersiz hissediyor? Büyük olasılıkla, kendinize biraz utanç verdiniz. Bazı fikirler hala geçerliyse, şimdi ilk önce kendinizi test ederek mümkünse bunları tanıtmak için iyi bir zaman olabilir.

Geç cevap ve diğer cevaplarda birçok iyi içerik üzerinde anlaşın.

Bence burada kilit bir konunun spesifik uygulamalar değil, genel takım kültürü olduğunu belirtmesi gerekiyor.

• Kültürel değişim yaratmak zor .
• Dahası "junior" olarak gördüyseniz

Sürekli iyileştirme sağlamanın bir yolu varsa, her şey takip edebilir .

Bunu başarma yaklaşımım:

• Belgelenmiş süreçler ve prosedürler
• İşlemleri süreç dokümantasyonunda değişiklik gösteren ekibin retrospektifleri.

Sanırım sprintleriniz yoksa, henüz düzenli retrosanız yok. İhtiyacınız olan tek şey ekiple bir konuşma yapmak ve sonra bunu yapmak.

Sen kolayca süreçlerini belgeleyen başlayabilirsiniz. “Ben yeni çocuğum, bu hakkım var mı? Bunu yazmama izin verin.” O zaman süreci kendiniz takip etmeniz ya da kırıldığı yeri aramaya çalışmanız önemlidir.

Belki de bu tür konuşmaların geçici olmasıyla başlıyorsunuz ve ardından düzenli ritüeller öneriyorsunuz.

Bu yaklaşımı kullanmak, artan, yumuşak bir şekilde yumuşak bir yaklaşıma izin verir. Her şeyi bilen bir genç olarak görünmekten kaçınabilir ve bunun yerine ekibin değişmesi için kolaylaştırıcı olmaya çalışabilirsiniz.

Bazı düşünceler:

• Bazı takımların kötü bir süreci var ama aslında bunu zaten biliyor. Değişmek istiyorlar ve bunu katalize edecek bir şeye ihtiyaçları var. Diğer takımlar gerçekten yollarına saplandı ve değişmesi çok daha zor oldu.
• Aynı bireyler için de geçerli.
• Buna duyarlı olmanız ve takımda kimin değişime açık olduğunu ve kimin olmadığını anlamak zorundasınız. Nedenini anlamak.
• Kolay kazancı bulun.
• Değişiklikleri takıma hoş geldiniz: Kişisel acı noktalarını bulun ve düzeltmeye yardımcı olun.