Temelde kuruluşun bir bütün olarak değer vermesine ihtiyacınız var.

Birkaç ay önce sizinle birlikteydim. Artık hayal kırıklığına uğradığınız geliştiricilerden biriyim.

Gerçek şu ki, insanların akıllarında belirli zaman çizelgeleri var ve bunlar asla değişmiyor. Onlara bir şey gösteriyorsunuz ve sonra onlar "nerede? Nerede?" Ve bunu her seferinde yapacaklar. Bu, işlerin ilerlemesini sağlamakla ilgilenen insanların üstünde. Kuruluşlar ayrıca belirli şeylere değer verme eğilimindedir ve bu değerler işlerin nasıl yapılacağını yönlendirir.

Sohbet genellikle şu şekildedir:

Kişi: "Hey, dün bana gösterdiğin özellik nerede ? "

Ben:" Kod incelemesini bekliyor. "

Kişi:" Peki, bunu QA / üretim sorununu çözmemiz / sprint demosunda / müşteri için yarın buluşma "

Ben:" Sırada bana dün sorduğunuz konunun arkasında duruyor. "

Kişi:" Peki, buna QA / üretim sorununu düzeltmek için ihtiyacımız var / sprint demosunda / yarınki müşteri toplantısı için "

Ben:" Neler yapılabileceğini göreceğim. "

Kişi (bir saat sonra):" Herhangi bir güncelleme var mı? QA / üretim sorununu düzeltmek / sprint demosunda bulundurmak / yarın müşteri toplantısı için buna ihtiyacınız var. "

Bundan aylar ve aylar sonra, git push tam bir yapmak çok daha kolay. Özellikle onlar açısından acil olduğu için, onu almak için oldukça motive oluyorlar. Birçok yönden haklılar çünkü son tarihler gerçek ve kontrol edebilecekleri bir şey değil. Dolayısıyla, bir iş birimi olmanın bakış açısından bile, bu muhtemelen doğru karardır.

Süreçlerin ayakta kalması için, kuruluşun bir bütün olarak (veya en azından tüm iş birimi) bunlara değer vermesi gerekir. Örgütünüz açıkça görmüyor. Daha fazla hataya neden olur mu? Muhtemelen. Ancak yazılımın dışındaki kişiler, hataları sadece gerçekleşen bir şey olarak kabul etmeye başladılar, bu nedenle bunları önlemek çoğu zaman en önemli öncelik değildir.

Bu, hem organizasyon hem de bireysel geliştiriciler için bir değiş tokuş meselesidir.

Bunu düzeltmek istiyorsanız, temelde satışları ikna etmeniz gerekir, Scrum ustası ve ürün sahibi bu süreci atlamamakta değerlidir. Muhtemelen bürokrasi olarak görüyorlar.

Patronumuz bunu yapmamamız gerektiğini kabul ediyor, ancak sürekli olarak insanlarla kavga etmek istemiyor, bu yüzden sadece kaymasına izin veriyor ve diğer geliştiricilere geri adım atmalarını söylememi söylüyor. Kodun% 80'i artık

senden işini yapmanı istiyor. Tamamen profesyonelce değil. Bu sürekli bir mücadele olmamalı. Bu mutlak bir kanun olmalı ve savaş, bir veya iki yazılı kınamadan sonra durmalıdır.

Bu durumda yapabileceğiniz pek bir şey yok. Siz ve diğer geliştiriciler meslektaş baskısını deneyebilirsiniz, ancak bir fark yaratmak için yeterince özen göstermeniz veya (anlaşılır bir şekilde) vazgeçmemiş gibi görünüyorum.

Ben dürüstçe başka bir iş aramaya başlayın

DÜZENLEME:

Diğer bir seçenek de, patronunuzla her şeyi denediğinizi düşünüyorsanız, patronlarınızın kafasının üzerinden geçmek patronlarına ve bu konuyu zincirin daha ilerisinde ele almaya çalışın. Patronlarınızın kafasının üzerinden geçmek ciddi yankı uyandırabileceğinden, bunun dikkatlice ve muhtemelen isimsiz olarak yapılması gerekir.

Şu anda: Hiçbir şey yapmayın. Her şey yolunda, hiçbir şey kırılmadı.

Bir dahaki sefere üretimi bozan bir hata ortaya çıktığında: Yakalamak için testler yapmış olsaydık bu hatadan nasıl kaçınılabileceğine dair ciğerlerinizin tepesinden (tam anlamıyla değil) çığlık atın o. Özellikle bu tür durumlardan kaçınmak için ne kadar dikkatli test etme ve zaman ayırma anlamına geldiğini açıklayın. Şirketin ne kadar para kaybettiğini ve hizmetin, yakalanmayan ancak geliştiricilere daha dikkatli olmaları için daha fazla zaman tanınması durumunda olabilecek bir hata nedeniyle ne kadar kesinti yaşadığını ölçün.

Yönetim her zaman daha açıktır. değeri ilk elden ve hemen gördüklerinde süreçteki bir değişikliğe. Özetle, "Pekala, gerçekten test yapmalıyız, çünkü bir gün bir yerde sunucularımızı çökertebilecek bir sorun olabilir" gibi konuşursanız, kimsenin umurunda değil, çünkü ne kadar olası olursa olsun, bu da olamazdı. ve şu anda olmuyor bu yüzden kimsenin umurunda değil. Ancak, eninde sonunda kesinlikle olacak ve işte o zaman onu bir sorun noktası olarak işaret edip değeri soyut olarak değil hemen gösterebilirsiniz.

Elbette, yönetim geri gelip "peki Daha iyi geliştiriciler olsaydınız, hata yapmazdınız ve test etmeye ihtiyacınız olmazdı ". Özgeçmişinizi tazelediğiniz ve başka bir iş bulduğunuz nokta budur. Her geliştirici hata yapar; hiç hatalı kod göndermemiş bir geliştirici yoktur ve geliştiricilere kodlarının olabildiğince hatasız olduğundan emin olmaları için zaman vermek şirketin sorumluluğundadır.

Sorununuzu yanlış teşhis ettiniz.

Standartları / incelemeleri / vb. atlayarak neler görüyorsunuz? Bu, probleminizin bir belirtisidir .

Asıl probleminiz iki şeyin birleşimidir:

• Patronunuz bazı konularda çatışmacı olmak istemez
• İş arkadaşlarınız işi geçici olarak görüyor ve sadece asgari düzeyde yapıyor

Patronunuz iş alanıyla yüzleşmeyi iş arkadaşlarınıza etkili bir şekilde devrediyor ... ve iş arkadaşlarınız sadece başka bir iş bulana kadar akışla devam ediyor. Standartların tek belirtisi olsaydı çok şaşırırdım. Öncelikleriniz, en yüksek sesle çığlık atan şey tarafından mı belirlenir, işe en çok yardımcı olan şey değil mi? Bu, sorunuzdan ayrı bir sorun değildir - bu, aynı zamanda bu kombinasyondan kaynaklanan bir şeydir. Vb - bu iki faktörden kaynaklanan irili ufaklı düzinelerce sorun vardır.

Gerçekçi olarak, bu sorunu çözemezsiniz. En iyi çekimleriniz:

• Patronunuzun işini yapmaya başlamasını sağlamak veya işini yapacak birisinin yerini almasını sağlamak.
• İş ortamını iş arkadaşlarınız için yeterince keyifli hale getirmek bunu bir kariyer olarak gördü.

Demosunda bir özelliğe ihtiyaç duyan satış görevlileri için bir demo şubesi ve demo sunucusu kurabilirsiniz. Sadece acilen ihtiyaç duydukları her şeyi itin ve ardından onu geliştirme dalında birleştirin ve sonunda birim testleri ve kod incelemesi tamamlandıktan sonra dalda uzmanlaşın.

Sprintin sonundan önce veya daha önce Standup aptalca ve kısa vadeli kazançlar, üretimde bir şeyi düzeltmek zorunda kalmakla dengelenecek. Ekibinizin testlerin ve kod incelemesinin değerini anlaması gerekiyor. Ayrıca, sprint sona ermeden önce tamamlanmamış işleri yapmak için acele etmeniz durumunda hikaye puan tahminlerinizi gözden geçirmeniz gerekebilir.

Yabancıların sürecinize karışmaya başladığı durumlarda, sürecinizi onlara açıklamayı bırakın. Onlara verdiğiniz her bilgi parçası, onlara neden bir şey yapıp yapmamanız gerektiğini tartışmaları için yeni bir kanca verir.

Yeniden düzenlemenin "acil" son tarihler nedeniyle sürekli olarak atlandığı bir şirkette (alıntılar kullanıyorum çünkü her şey istisnasız her zaman en öncelikliydi), yeniden düzenlemeyi ayrı (ve dolayısıyla bireysel olarak atlanabilir) bir adım olarak belirtmeyi bıraktım ve yeniden düzenlemeyi tahminin bir parçası olan geliştirme çalışması olarak saymaya başladım.

Bunun yerine " Yönetimden her zaman aynı tepkiyi alacak olan 2 günlük geliştirme, 1 günlük inceleme / yeniden düzenleme "(" 2 gün sonra yayınlamanız gerekiyor, yeniden düzenleme için zamanımız yok "), bunun yerine" 3 günlük geliştirme "dedim ve onu daha fazla bozmadı. Yönetim, kişisel olarak ilgilenmedikleri için işimin hangi bölümlerini atlayabileceğimi tartışma yeteneğini kaybetti.

Kısa vadeli bir yönetim perspektifinden bakıldığında, yeniden düzenleme ve kod incelemesi bir "israftır" bir sonraki faturalandırılabilir öğe için harcanabilecek süre. Ancak geliştiricinin yaşam kalitesini önemli ölçüde artırarak geliştirici tükenmişliğini ve insanların işi bırakmasını azaltıyor ve bu da geliştirme ekibinin uzun vadeli çıktılarını önemli ölçüde artırıyor.

Kod kalitesinin ve bir yıldan daha kısa sürede ayrılan geliştiricilerin bir sürekli bir mesele, (benim tecrübelerime göre) neredeyse her zaman yönetime atfedilen, geliştirme süreçlerine karışanların değerine değer vermiyor veya anlamıyor. Bunun gibi birkaç şirkette çalıştım.

Bazı yöneticiler, çalışanlarının yaşam kalitesinin önemini anlıyor ve bazı yöneticiler umursamıyor ya da umursamıyor - sonuç ne olursa olsun aynı. İkinci kategoriye giren yöneticilerle uğraşırken, ayrıntılar konusunda her zaman tutumluyum, bu yüzden karışmamaları gereken yerlere karışmazlar.

Patronunuzu ve yeteri kadar meslektaşınızı buna izin vermeyen bir izin sistemi kurmaya ikna ederseniz bu savaşa yalnızca bir kez girilmesi gerekir.

GitHub'ı, ancak diğer hizmetleri kullanıyoruz. Kod bir kod sahibi tarafından onaylandıktan sonra yalnızca ana şubeye birleştirmeye izin veren benzer seçeneklere sahiptir. Doğal olarak, yalnızca süreci ciddiye alanlar kod sahibi olmalıdır.

Kurulduktan sonra, bu yeni bir normal hale gelecektir. Bazı süreçler şansa bırakılmaması en iyisidir.

Kod incelemelerinin neden zorunlu kılınması gerektiğine dair bir yöneticiye yapacağım temel argümanlar:

• kod incelemesi en çok böcekleri önlemek için etkili önlemler. Ben şahsen onları testlerden daha etkili buluyorum (her ikisine de sahip olmalı!). İyi bir geliştirici, daha az deneyimli veya motive olmuş geliştiricilerin en kötüsünü önleyebilir
• potansiyel olarak ciddi işlevsellik ve / veya veri kaybına neden olmak için yalnızca tek bir ciddi hata gerekir. Daha da kötüsü, bir bakıma, bir süre tespit edilemeyen ve yedekleme gibi kurtarma prosedürlerini pratik olarak kullanışsız hale getiren veri bozulmasıdır. Bu elbette ürününüze bağlıdır.
• Hataların, gelir kaybı ve / veya müşteri kaybı açısından işletmeye doğrudan bir maliyeti olması muhtemeldir (yine, ürüne bağlıdır, ancak çok azı böceklerle uğraşmak)
• bonus olarak, incelemeler harika bir eğitim aracıdır

Son kullanıcıların (satışlar, müşteri desteği, müşteriler / müşteriler / iş ortakları vb.) genel olarak geliştirme ekibine doğrudan erişimi olmamalıdır. (Sekreter, satış görevlileri veya müşteri desteği triyajı geliştiricilere doğrudan arıyor / e-posta gönderiyorsa, bu konuya değinilmeli ve ekip için iş tarafı arayüzüne, yani ağ geçidi denetleyicisine başvurmalıdırlar.)

Geliştirme ekibi, bir düzeltme / değişiklik / özelliğin durumuyla ilgili herhangi bir soruyu ekibin bekçisine yönlendirmelidir (teknik / ekip lideri, BA, PM, PO, her neyse).

İmkansız olduğu için bir geliştirici ekibini kuruluşun geri kalanından tamamen izole etmek için, bekçinin "evet adamı" olmaması, işiyle gurur duyması ve "acele israf eder" kavramını anlaması önemlidir.

Sprintler / retrospektifler ile geliştirmeye çevik bir yaklaşım yapıyorsanız, geliştirme ekibinin bir parçası olarak bunu geriye dönük olarak gündeme getirebilirsiniz. "Yeterli test ve doğrulama olmadan birçok PR'ımız vardı, bunun üzerinde çalışmamız gerekiyor." Geçmişe dönüklerin bir şey olmasının nedeni tam olarak budur - "Neler iyi gitti, ne kötü gitti, kötüyü düzeltmek için ne yapabiliriz?"

Bu PR'lardan biri kusurun rapor edilmesine neden olursa, en kısa sürede hatanın rapor edildiğini görürseniz, orijinal bilete bağlayabilirseniz bunu yapın. Ayrıca, onu tanıtan kişiye atandığından emin olun (yalnızca kodun o alanında en son deneyime sahip oldukları için ve sorunu büyük olasılıkla hızlı bir şekilde çözecekleri için, elbette "onu kırdığınız için değil, düzeltin ").

Bunu ele almanın birçok yolu var - bazıları diğerlerinden daha başarılı olacak ve çoğu kuruluşunuzun süreçlerine ve ekibinizin kişiliğine bağlı ( süpervizörünüz dahil).

Süreçler, işin doğru ve hızlı bir şekilde yapılması için tasarlanmalıdır. İnsanlar rutin olarak sistemi atlatıyorsa ve sistem iyi tasarlanmışsa, atlatma nedeniyle ortaya çıkan bir dizi sorundan bahsedebilmelisiniz. Siz ve / veya patronunuz (belki de sizden gelen verilerle donanmış patronunuz) bu sorunların belirli bir listesini yapmalısınız - bu, hileden şikayet etmekten çok daha fazla ağırlık taşır. Hileli atlatma dediğiniz kadar yaygınsa ve böyle bir liste yapamıyorsanız, süreçler yanlıştır. Aslında iyi işlerin yapılmasının önüne geçiyorlar. Süreci dikkatli bir şekilde gözden geçirmenin zamanı geldi. Kaçınılmış inceleme adımları sorun yaratmaz, bu yüzden onlardan kurtulun. Hangi incelemelerin hangi sorunları yakaladığını görün. Kuruluşun daha sonra hangi incelemelerin zorunlu olduğunu tanımlaması, bu normları uygulaması ve incelemeleri öncelik haline getirmesi gerekir, böylece işleri çok fazla yavaşlatmasınlar.

Girişiniz yazılmadıysa işe yaramaz. Bu nedenle, belirli bir görevde gerçekleştirilen tüm eylemleri günlüğe kaydeden bir günlük kaydı sistemi kurmayı öneririm:

Biri bir şeyi uyguladığında, kesinleştirme hash'i hata raporuna ve her ek göreve eklenir (kod incelemesi, birim testi, ...) ayrıca aşağıdaki soruları kolayca bulabileceğiniz şekilde hata raporuna eklenir:

• Gerçekte hata raporlarının yüzde kaçı kod incelemesini geçti?
• Hata raporlarının yüzde kaçı aslında tüm geliştirme zincirini geçti?
• ...

Ayrıca, neden yapılmadığını günlüğe kaydetmek mümkün:

• iş önceliklendirmesi nedeniyle kod incelemesi geçmedi.
• Birim testi tamamlanmadı (testlerin yalnızca% 20'si yapıldı)
• ...

Böyle bir kayıt olmadan, sadece karanlıkta bağırıyorsunuz.

Haklısın. Bu durumdaki diğer herkes yanılıyor.

Görünüşe göre süreçte ısrar ederek herkesi rahatsız eden "o adam" olmaya devam etmeniz gerekiyor. Patronunuz bu konuda liderlik yapmıyor, onun yerine bunu yapmalısınız. Doğrudan ustalaşmak için itmek, ürününüzün müşterilerinizi ve ekibinizi etkileyen kaliteli bir kaçışa sahip olmasının sadece bir zaman meselesi olduğu anlamına gelir.

Bu durumda "Size söylemiştim" diyen ve bunu destekleyecek iletişim (e-postalar vb.) olan kişi olun. Bu sizi daha iyi bir konuma getirmelidir - hatta patronunuzun işine bile girebilirsiniz.

Dikkate alınması gereken bir diğer nokta da, insanların bunu yapmasını kolaylaştıran daha iyi araçlar istemektir . süreci izleyin ve ustalaşmaya zorlamak daha zor. GitHub ve GitLab, yalnızca proje sahiplerinin ana konuma aktarmasına izin veren korumalı bir dal özelliğine sahiptir. Hatta birleştirme isteklerinin birleştirilmeden önce başka bir geliştirici ve bir QA görevlisi tarafından onaylanması için havuzunuzu kilitleyebilirsiniz. Ayrıca bir birleştirme / çekme isteğinde birim testlerini otomatik olarak çalıştıran bir yapı sunucusu da edinebilirsiniz. Görünüşe göre patronunuz bununla ilgileniyor, bu yüzden onu daha iyi araçlar kullanmaya başlamaya ikna etmek çok zor olmamalı.

Sadece işlerin değişmesini beklemeyin birisi büyük bir hata fark ettikten sonra. Yönetim, geliştirme ekibinin büyük hatalar yaptığını fark ederse ne olacağı konusunda kontrol sahibi olamazsınız. Ekibin geri kalanı kadar kendi iyiliğiniz için sorunları erkenden ve sık sık dile getirin.

Elbette, savaşmaktan sıkıldıysanız, her zaman ayrılma seçeneğiniz vardır, ancak bu olabilir Kalmayı seçerseniz, sizin için kariyer geliştirme fırsatı.

Bob Martin ("Bob Amca") tarafından verilen Agile sınıfına katılmanın zevkini yaşadım. Onu tanımıyorsanız, Agile dediğimiz şeyin kurucularından biridir.

Çevik'in amacı, müşterinin önünde "müşterinin 1 Ekim'de görmek istediği özelliği" elde etmektir. 1 Ekim'de VEYA, diyelim ki 1 Temmuz'da bu özelliği 1 Ekim'e kadar asla bitiremeyeceğinizi yönetiminize açıkça belirtin. Buna karşılık, yönetiminiz 2 Temmuz'da müşterinize bu özelliği 1 Ekim'de görmeyeceklerini açıkça belirtir. Bazı tür değişiklikler / ödünleşmeler kabul edilmedikçe. Yönetimin yapması gereken şey bu.

Dolayısıyla, Agile'ın tüm teknik tuzaklarına sahip olmanıza rağmen, şirketinizin gerçekten önemli bir rol oynamadığı benim için açık. Yönetim, müşterinin ne istediğini ve ne zaman istediğini bilmelidir. Geliştiricilerin nerede olduğu konusunda görünürlüğe (bazı güvenilir nicel ölçütler) ihtiyaçları var. Zaman geçtikçe bu bilgilerin sürekli olarak müşteriyle tartışılması ve ayarlanması gerekir. Bu Çeviktir.

Kod incelemeleri, TDD, ikili programlama ve yeniden düzenleme, iyi bir yazılım kalitesi ve işçiliği sağlayan teknik görevlerdir. Ancak bunlar tek başına şirketin Çevik bir süreç kullandığı anlamına gelmez. Yöneticilerin, bu süreçlerden elde edilen verileri kullanarak yönetmeleri , gerektiğinde zaman çizelgelerini ayarlamak için müşteri geri bildirimlerini dahil etmelidir . Bu kadar basit.

Sahip olduğunuz durum, geliştiricilerin Çevik yönetim süreci kullanmayan bir şirkette iyi yazılım ustalığı teknikleri kullanmaya çalışmasıdır. Çeşitli insanların koordinasyonsuz bir şekilde çeşitli vaatler verdiği kaos gibi görünüyor. Bir geliştirici olarak yapabileceğiniz hiçbir şey yok.

Durumla ilgili diğer geliştiriciler, muhtemelen en fazla bir yıl daha burada olacakları yönündedir, bu nedenle kodun çürümesine izin vermek, dikkatli mühendisliğe değer vermeyen çeşitli insanlarla süreçle ilgili günlük tartışmalardan daha ucuzdur.

Bence asıl sorun bu. Geliştiriciler, şirkette yalnızca kısa bir süre kalacaklarını hissediyorlarsa, İşleri Bitir'e atlamak için en iyi uygulamayı atlamak büyük bir sorun gibi görünmüyor.

Geliştiriciler neden kendilerini öyle hissediyorlar? şirkette sadece "en fazla bir yıl" mı kalacak? Bu, herhangi birinin bir şirkette çalışmayı planlaması için oldukça kısa bir süre gibi görünüyor.

Ekibe ve ürüne bağlı olarak organize geliştirme yapmanın birden çok yolu vardır. Şu anda tipik olarak itilen akış, herkesin her şey üzerinde çalıştığını ve aynı ana dalda sık sık ama küçük değişikliklere katkıda bulunduğunu varsayar, ancak kod incelemesi ve çekme talepleri yoluyla.

Organize işlemi yapmanın tek yolu bu değildir. geliştirme. "Süreçler izlenmiyorsa" henüz geliştirme iyi giderse, belki başka bazı kurallar ve süreçler de takip ediliyor: eşli programlama, kod sahipliği, sürüm dalları, özellik dalları, geliştirme dalı, test odaklı geliştirme veya benzeri bir şey.

Öyleyse, muhtemelen bozuk olmayanları düzeltmeye çalışmak yerine gerçek süreçleri keşfetmek ve yakalamak daha iyi olabilir.

Bununla ilgili ne yapabilirim?

Patronunuz size geri adım atabileceğinizi söyledi , böylece iletişimi görmezden gelerek baskı altında hissetmekten kaçınabilirsiniz zaten bir öğe üzerinde çalışırken size baskı yapmak için tasarlanmıştır. Bu, başkalarını size baskı yapmayı bırakmaları için eğitir.

Şirket kültürü ile ilgili diğer bazı yorumları okuduktan sonra: Şirket kültürünü ancak bir kapı bekçisi konumundaysanız (mutlaka yönetim değil) iyileştirebilirsiniz. bir şeyin konuşlanmasını engelleyebilirsiniz ve patronunuz sizi destekleyecektir. Bu, büyükbabanın patronunuzu yedekleyeceği anlamına gelir ... büyükbabanın patronunun onu destekleyeceği vb.

Gregory Currie'nin şu yorumunu kabul edeceğim: "Söylemek arasında oldukça büyük bir fark var biri bir şey ve birini ikna etmek. Birine otoriteye dayandığını söylemek, ikna etmek çeşitli şekillerde yapılabilir "

İşleri doğru şekilde yapmanın değerinin olamayacağı yerlerde çalıştım bunun nedeni yönetimin gerçekçi olmayan programlara izin vermeye devam etmesi. İyi süreçleri destekleyen bir otorite olmadan insanların ikna edildiği bir yerde işe yaradığını görmedim.

Genellikle işler belirli bir şekilde ilerliyorsa bunun nedeni, ne söylerlerse söylesinler, tam olarak yönetimin istediği şeydir sen. Yanında çalıştığın, kaliteye hiç önem vermeyen adam, onun böyle olduğunu bilen ya da böyle olmasını umursamayan biri tarafından işe alındı. Makul olmayan bir son tarihiniz varsa, bunun nedeni, sizin üstünüzdeki birden fazla kişinin bunu kabul etmesidir. Kalitesiz bir kodun neden yayınlandığını hayal bile edemezseniz, patronunuz nedenini tahmin edebilir ve nedenini anlar.

Nihayetinde geliştiriciler olarak yaptığımız her şey (bir şirkette) iş ihtiyaçları tarafından yönlendirilir. İş tarafı, müşterilere yeni özellikler gösterilemezse ve özelliklerin daha kaliteli olmasını beklemek için şirketin kısa sürede başarısız olacağını bildikleri gibi sizi kodu aceleye getirmeye zorlamak için meşru bir nedeni olabilir. uzun.

Tarif ettiğiniz mücadelenin yaşandığı şirketler gördüm. Ve sonra 1-2 yıl içinde herkes işten çıkarılır. Yönetim bunun geliştiricilerden çok önce geleceğini biliyordu.

Patronunuzla tekrar konuşun. Patronunuz bundan sonra bunun yasa olduğunu belirtmelidir. Sürekli kavga istemiyorsa, istisnalar için yeterince katı kurallar oluşturun, böylece insanlar onları gönülsüzce kabul etmezler.

Bu çok uzun sürerse, insanlar buna alışacak ve değişmesi gittikçe zorlaşacak. Belki patronun işin içinde olması gerekir.

Destek olmadan tek başınıza pek bir şey yapamazsınız. İş arkadaşlarınızı, süreci takip etmenin özgeçmişleri için iyi olduğuna ve kariyerlerini hiçbir yerde ilerletmeyeceklerini kibarca söyleyebilmelerine ikna etmeye çalışabilirsiniz. Bu doğru ve satması da zor.

Sürecin bir sebepten dolayı yerinde olması ve takip edilmesi gerektiği konusunda diğer yanıtlarla aynı fikirdeyim.

Ayrıca iş paydaşlarıyla bu mücadeleyle mücadele etmenin patronunuzun işi olduğuna ve bunun olması gerektiğine de katılıyorum. Onlara göre, boyun kırılma hızında serbest bırakmanın şovu durdurma (iş bitiyor mu?) sorunlarının hayata geçme riskini büyük ölçüde artırdığını açıklıyoruz.

Bununla birlikte, süreç, teknik bir düzeltme uygulamaktır. Ana şubeyi 'koruyabilir' ve uygun bir inceleme süreci olmadan insanların ona gönderme yeteneğini devre dışı bırakabilirsiniz:

https://docs.github.com/en/github/administering- a-havuz / çekme isteklerinin birleştirilebilirliğini tanımlama

Bu, TFS gibi diğer bazı depo yönetimi çözümlerinde de yapılabilir.

Eğer siz geliştiricilerin kodu üretime acele etme yeteneğini ortadan kaldırır, ardından üzerlerindeki bunu yapma baskısı da ortadan kalkar. Bu, baskıyı zincirden patronunuza (olması gereken yerde) taşır ve ardından bu argümanlara sahip olmak onlara düşer.

Öncelikle - bunu düzeltmek sizin sorumluluğunuz değildir, ancak yine de süreç odaklı olmak iyi bir şeydir.

Bir CI / CD sistemi kullanmanızı önermek isteyebilirsiniz yalnızca tüm ölçütler (testler, ...) karşılandığında dağıtıma izin verir. Aksi takdirde ardışık düzen başarısız olur ve değişiklik reddedilir.

Boru üzerinde yeterince sıkı bir kontrole sahipseniz, bu tür kısayollar başarısız olur. Ayrıca, satış görevlisinin veya kimin acil bir şeye ihtiyaç duyuyorsa gösterilecek bir şey olması için istisna sürecini de açıkça belgelendirirdim.

• İş arkadaşlarınız şirkette uzun vadeli beklentiler görmüyor, bu yüzden süreci takip etmekle ilgilenmiyorlar.
• Patronunuz işlem yapmak için sadece sözde davranıyor ve uygulamakla hiçbir ilgisi yok
• Yazılıma bağımlı olan departmanlar kusurları umursamıyorlar, sadece dün müşterilere gösterebilecekleri şeyleri umursamıyorlar, bu yüzden süreci de önemsemiyorlar.

Bu, en önemli ürünlerinin sattıkları emtia veya ürün değil, arkasındaki yazılım olduğunu anlamayan şirketlerde oldukça yaygın bir senaryodur. Bu tür şirketler, yazılımda herhangi bir değer görmediklerinden asla "doğru" yapmaya öncelik vermezler.

Böyle bir şirkette güçlü bir konumda olmadığınız sürece, bunu düzeltmek için yapabileceğiniz hiçbir şey yoktur. algı. Bu nedenle, tek seçeneğiniz - akıl sağlığınızı korumak istiyorsanız - başka bir yerde, kaliteli yazılımın başarılarının temeli olduğunu anlayan ve ileriye dönük varoluşlarının temelini oluşturan bir şirketle iş bulmaktır.

Sorudan alınan bu alıntıya yanıt olarak dikkate alınması gereken berbat bir şey.

Ekibimde, ana şubeye ulaşmak için teknik olarak geçmesi gereken kodlama gerektiren çeşitli geliştirme süreçleri var. Birim testi ve kod incelemesi gibi şeyler.

Hayır - yok. Gerçekleşen süreç, sahip olduğunuz süreç ve takımın, tüm takımın (yöneticilerden aşağıya) gerçekte değer verdiği süreçtir.

Bir yerde bir belge veya birkaç geliştiricinin kafasında belirsiz bir idealler kümesi varsa, sorun değil, ama bu sizin süreciniz değil. Yapabileceğiniz bir şey, ya gerçek sürecinizde rahat olmak, bunun ideal olmadığını anlamak ve onunla yaşamak (ve sonuçlarını iletmek) ya da geliştirme ekibini, istediğiniz süreçleri daha somut bir şekilde uygulayan yapısal değişiklikleri uygulamaya ikna etmektir. as: birleştirme, onaylanmış bir çekme talebi, otomatikleştirilmiş derleme ardışık düzenleri vb. dışında fiziksel olarak gerçekleşemez ...

İyi şanslar - bu, bir geliştirici olarak olmak için berbat bir durum

Bu konuda uzman değilim, ancak benim 2 ¢ değerim şu olurdu:

Testler / süreçler her geri alındığında, buna karşılık gelen hata sayısını artı , şirket için para kaybı açısından eşit olduğu hasar, artı bunun eski bir düzeltme haline gelmesi durumunda gerekecek çalışma saatleri (bu, tipik olarak test odaklı geliştirmeyi takip etmek için harcanan süreden çok daha fazladır) ilk sırada). Maalesef, bu muhtemelen sizin açınızdan biraz ev ödevi gerektiriyor, bu muhtemelen iş tanımınızın ötesinde, ancak aynı zamanda kaba hesaplamalar da yeterli ve muhtemelen bunun için bir miktar fikir edinebilirsiniz. kaçırılan testlerle vb. ilgili önceki hata raporlarından.

Bu rakamlara bağlı kaldığınızdan ve testler her atlandığında bunları güncellediğinizden emin olun. Ardından, her toplantının sonunda, her zamanki gibi (ancak pasif-agresif olmayan) bir tonda, bu rakamlara göre "şimdiye kadar tahakkuk eden teknik borç" notunu geçici olarak not edin. İnsanlar önce kıkırdayacak, sonra belki duymaktan bıkacaklar, ama bu sayı yükselmeye başladığında, insanların dikkatini çekebilir. Bir noktada, umarım, bir devrilme noktasına ulaşır ve tartışma şöyle gidebilir:

Boss: Dünkü prodüksiyon hamlesiyle ilgili beni bilgilendirin.

Siz: Elbette. Dün 5000 satır kodu git'e aktardık. Aciliyet nedeniyle, bu taahhüt için yaklaşık 30 birim test olarak tahmin edilen istek üzerine testleri atladık. Önceki deneyimlerimize göre, atlanan her 3 birim testinden 1'inin kendisini, satışlarda yaklaşık 10.000 ABD doları tutarında tahmini bir maliyetle ve hata başına 40 kişi-saatlik eski düzeltmelerle 2-3 aylık bir kullanıcı hata raporu olarak gösterdiğini bulduk. , yani dünkü taahhüt tahmini 100.000 dolar zarar ve 400PH teknik borca ​​mal oldu. 470 hataya ilişkin önceki teknik borç tahminimiz, eksi geçen ay içinde düzelttiğimiz özellikle eksik testle ilgili 30 hata (bunu yapmak için tahmini bir 1200PH harcadık) artı bugünün 10 hatalık tahmini teknik borcu göz önüne alındığında, bu bizim tahakkuk eden teknik bugün tahmini 450 hataya kadar olan borç, hata başına 10.000 $ / 40PH tahmini, bu şirket için tahmini 4.500.000 $ zarara ve şu ana kadar 18.000PH değerinde teknik borca ​​yol açar .

Boss: ... Wtf. Tamam, iyi, bunu düşünelim. Testler olmadan erken itmek, bizim için daha fazla X $ kazandırdı ... ama testler hakkında söyledikleriniz doğruysa, bize de Y $ 'a mal oldu. Belki de teknik borcun Y $ 'lık maliyetinin aslında erken gönderim karını $ X $ dengeleyip dengelemeyeceğini biraz düşünmeliyiz ... bu durumda bu testleri uygulamak için fazladan ne kadar zamana ihtiyacın vardı?