Gecelik yapıyı kırdığın zaman nasıl özür dilersin [kapalı]

Projemdeki ilk taahhüdüm, gece inşasının bozulmasına neden oldu ve serbest bırakmaya yaklaştıkça insanlar benim üzerimde. Samimi ve aynı zamanda bunun benim ilk taahhüdüm olduğunu ve bunun tekrarlanmayacağını ima eden bir özür e-postası göndermek istiyorum.

Ana dili İngilizce olmayan bir konuşmacı olarak doğru kelimelerle gelmekte zorlanıyorum. Birisi lütfen yardım edebilir mi?

Yapmayın özür dile!

• Yapıyı mavi ay içinde bir kez kırmak önemli bir şey değil ve asla bir gösteri durdurucusu olmamalı.
• Sürekli ve otomatikleştirilmiş yapıları yapılandırmamak sizin yöneticinizin hatası.

Ayrıca, ekibinizin 'Joel Testini' geçemediğini ve bir adımda bir yapı oluşturamayacağına bahse girerim .

Öyleyse, özür dilememeniz gereken başka bir şey olurdu. Gerçekten de, bir takım anti-kalıp.

Simit. Donuts. Vb. Geçmişte çalıştığım bir şirkette, bozuk kodları kontrol etmek ya da iş arkadaşının bozulmasına neden olmak, genellikle ertesi gün özürlü gıda maddelerinin getirilmesiyle çözülür.

Bir gün bir üretim veritabanını havaya uçuran bir adam vardı ve tüm takım için büyük bir panik ve gece geç saatlere neden oldu. Ertesi gün öğle yemeğinde burger ızgara yaptı.

İş arkadaşı özrünü seviyorum. Lezzetli, lezzetli özürler.

Sizin için iki teklif:

Hata yapmayan adam genellikle hiçbir şey yapmaz .-- William Connor Magee

Hata yapmayan hiç kimse yeterince zorlamıyor .-- Wess Roberts

Jim G. ile aynı fikirdeyim , özür dileme ama ondan öğren ve yine aynı hatayı yapma ... DRY;

Özür dileme, sadece en kısa sürede FIX IT. Yine de sorun değil, herkes en az bir kez yapıyı kırıyor, son şirketimde bu bir başlangıç ​​ritüeliydi. Bir ekip üyesi binayı bozduğunda, sabah içeri girmeden önce masasına bir lastik şapşal koyardık, bu onun binayı kırdığını ve düzelteceğini bilmesini sağladı.

Buna Sürekli Entegrasyon Duckie adını verdik ve insanlar sizi alay ettikleri gün için varken bunların hepsi eğlenceliydi, hiçbirinin kötü ruhlu olması gerekmiyordu.

Kırık bir yapı gibi bir şey aldık ve onu bir ekip oluşturma çalışmasına dönüştürdük.

"Üzgünüm benim hatam!" yapıyı kırdığımda genellikle nasıl özür dilerim. Olur. Ancak başkalarının da söylediği gibi, bu sisteminizi geliştirmek için bir fırsattır, böylece bir kişi herkes için yapıyı kolayca kıramaz.

Bu şartlarda resmi bir özür dilemem ama, daha resmi bir özrün uygun olduğunu düşünüyorsanız, özrünüz aşağıdakileri yapmalıdır:

• Pişmanlık ifade eder.
• Sorunu belirt.
• Sorumluluk almak.
• Tadilat yap.
• Yüzü korumak.

Yani, "Üzgünüm [EXPRESS REGRET], sizi [SORUMLULUK] 'u yanlışlıkla rahatsız ettiğimden [rahatsız ettiğim için] [SORUMLULUK]. Rahatsız ettim.

Her bölüm uygun bir özründe gereklidir; Eğer sorunu belirtmezseniz o zaman belirsizdir. Eğer pişmanlık duymuyorsanız, sorumluluk almıyorsanız ve düzeltiyorsanız, insanlar içgüdüsel hissetmezler. Yüz koruyucu kısım, bir özrün en gözardı edilen kısmıdır; Yüz kurtaran kısım, yaralı tarafa, bazen hata yapan değerli bir iş arkadaşı olduğunuzu hatırlatan ve bir aptal (veya sabotajcı!) olduğunu hatırlatan kısımdır.

Son olarak, yapı kırma üzerine bazı düşünceler:

C # / Visual Basic derleyici ekibinde çalışıyorum. Tabii ki bugün Visual Studio şimdi inşa altyapısını yönetmek için kendine ait bir ekibine ve kendine ait klima sistemine sahip büyük bir odaya sahip olduğu çok büyük bir proje. Stajyer olarak başladığım 1990'ların ortalarında, Visual Basic yapım ekibi bir stajyerdi - ben ve makinelerle dolu bir dolap. Zaman değişti!

Sürekli entegrasyon ve güçlü check-in işlemlerinden önceki günlerde ekiplerin yapıyı bozmak için çeşitli cezaları olacaktı. Bazı takımlarda ceza, yapıyı kırdıysanız, her gün işyerinde başkası yapılana kadar komik bir şapka giymek zorunda kalmanızdı. Bazı takımlarda, eğer o şapkayı takıyorsanız, gece yapısının doğru olduğunu onaylamaktan sorumlusunuz.

Bu son ses biraz acımasız gelebilir, ama aslında değerli bir amaca hizmet etti. Neredeyse herkes yapıyı bir anda ya da diğerinden kırdığı için, sonunda tüm takım gece yapısını doğrulama süreçlerini öğrenecekti.

Özür dileme. Sürekli bir entegrasyon sunucusu gibi kurulumlar için ilk taahhüdünüzü gözden geçirmediğinizden ve hızlı bir geri bildirim sistemine sahip olmadığınızdan dolayı suçlu olan iş arkadaşlarınız.

Şu andaki işimde, işten ayrılmadan hemen önce sinsice işleyen ve inşaatı bozduğunu belirten birinin ertesi gün tüm ekip için şeker / kek / içecek getirmesi gerektiği konusunda gayrı resmi bir kural var. Ancak, bizi gün boyunca kırılmış bir binadan uyaran sürekli bir entegrasyonumuz var. Ve kural muhtemelen birinin ilk taahhüdüne uygulanmaz.

Her neyse, resmi bir özür mesajı muhtemelen biraz fazla.

Temel bir kural - yanılıyorsanız, BT ADMIT: - | Özür dilemek zorunda değilsin. Herkes hata yapar. Artıları itiraf et. Bu takım çalışması. Diğer takım üyeleri size yardım edebilmek için bir araya gelmelidir. Olmazlarsa, yardım isteyin. Daha sonra söylenmesi gereken en çok şey - bundan ne öğrenebiliriz?

Başarılı bir evliliğin üç küçük kelimeye dayandığını söylüyorlar - "yanılmışım".

Birisi ara sıra bir hata yapmazsa, çalışmıyor demektir, ancak birinden öğrenmeyen bir hata iki hatadır.

En iyi özür, araları çabucak düzeltmek.

Şirketinizde zaten yapı değişikliklerinizi test etmek için bir yöntem varsa, (A) değişiklikleriniz başarısız oldu (ancak yine de kontrol ettiniz) veya (B) başarılı oldular (ve yeni bir test durumu oluşturmanız gerekiyor).

Eğer meslektaşlarınız değişikliklerini zekice test ediyorlarsa ve gece inşasında molalar bulmayı umuyorlarsa, o zaman (C) kırılgan bir işlem geçirirsiniz (ve Aşırı Programlama'da olduğu gibi bir test başlatmanız gerekir).

(D) Yaptığınız değişikliklerin, daha önce yürürlükte olan veya sizinkiyle aynı yapıda değiştirilen Bill kodunda öngörülemeyen değişikliklere neden olması olasıdır.

Siz ve şirketinizin nasıl test ettiğine bağlı olarak, duruma göre özür dilerim:

• (A) Yapı testinde başarısız oldum ancak değişikliklerimi kontrol ettim. Üzgünüm, işlemimi değiştiriyorum, böylece bir daha yapmayacağım.
• (B) Yapı testini geçtim ve tekrar oluşma ihtimalini azaltmak için JUnit testi XYZtest.java'yı ekledim.
• (C) Yapım testi sürecimiz olmadığından, değişikliklerim için bir tane oluşturuyorum. Yapım sürecimizi nasıl geliştirebileceğimizi sizlerle paylaşmak istiyorum.
• (D) Yeniden oluşma ihtimalini azaltmak için bir JUnit testi XYZtest.java yazmak için Bill ile birlikte çalışacağım.

Eminim hiç düşünmediğim bir (E) vardır.

"Yeniden oluşma şansını azaltmak" yerine "tekrar yaşanmayacağını" söylediğime dikkat edin. Yine olacak. Ancak bu olasılığı azaltmak için sürecinizi iyileştirebilirsiniz. Bence, kazanan bir programcının işaretlerinden biri.

Özür dileme. Sen insansın ve hatalar yapacaksın. Herkes yapıyı zaman zaman bozacak, anahtar sadece hızlıca düzeltmektir.

Her tarafına atlayan insanlara gelince ... iyi bir hata yapmışlarsa merak ediyorum.

Buna nasıl yaklaşılacağı, grubunuzdaki atmosfere bağlıdır. Eğer suçlu bir kültürse, özür dileme konusunda ve nasıl yaptığın konusunda çok dikkatli olurum . Eğer işbirlikçi, olumlu bir atmosfer ise, o zaman evet, “Dağınık kaldım, özür dilerim. Gelecekte bunu nasıl önleyebiliriz?” muhtemelen iyi bir fikir.

Her durumda, bunun gibi bir sersemlemeye, bir çeşit ölüm sonrası eşlik etmelidir: a) nasıl olduğunu öğrenmek ve b) tekrar oluşma ihtimalini en aza indirmek.

Yapınıza aşina değilim (çok farklı bir ortamda çalışıyorum) ama nihayetinde, gerçek şu ki, insanlar hatalar yapıyor ve işler bozuluyor. Deneyimden öğreniyorsun ve devam ediyorsun.

Benim çevremde yapıyı kırdıysanız, iyi huylu bir kaburga ve biraz esprili bir buluşma elde edersiniz. Hangi İngilizce konuşulan ülkenin sizin dilinizde olduğundan emin değilim, ancak anadili İngilizce olmayan bir konuşmacı olarak yorumların altını çizemiyor olabilirsiniz.

Üst düzey bir geliştirici olarak diğer taraftan olmak, bir zamanlar bir kod incelemesine, x'in bir şekilde “sucked” yapmanın, kodun kötü olmadığı için değil, projenin yapısına yaptığı gibi yorumda bulunduğunu yorumladım. Yapısal problemi çözmem gerektiğinden kendim için daha fazla yorum vardı. Ancak daha sonra Jr Dev'in yanlış saygısız konuşmam nedeniyle ona çok kızmış olmama rağmen olduğunu keşfettim.

Um. Bozuk yapı jetonunu aldın . Kuduzleri bir sonraki şanslı alıcıya götür. Her zaman olur. Kalite önemlidir, ancak hatalar kaçınılmazdır. Onları tamir etmek. Devam et. Bir sonraki zavallı adamla ayıp.

Genel bir kural olarak şöyle derdim:

Eğer girişiniz bir derleyici hatasına neden olmuşsa, giriş yapmadan önce bir "son al" yapmış olsaydınız, basit bir "sersem, benim kötü" sırasına girdi. (özellikle ertesi sabah saat 10'da içeri girerseniz, herkes hangi değişime geri döneceğine karar verirken)

Girişiniz genel beklenmeyen davranışlara, hatta çalışma zamanı hatalarına neden olursa, size karşı tutulması gerektiğini düşünmüyorum. Bölge ile birlikte geliyor. Herkesin “en yenisi” genellikle derleyicilerinden geçtiği sürece, insanlar gerçekten bir uyum sağlamamalıdır (bir veritabanını silmek, projenin sunucu kopyasını ve tüm değişiklikleri veya başka bir şeyi silmek gibi birkaç istisna dışında) aptal insanların kötü niyetli bir niyet almaları gerektiğine dair aptalca).

EKİP başarısız oldu.

Şirketiniz, ilk kez yapılanması yapan bir dev üzerinde daha fazla kod incelemesine ihtiyaç duyar.

Bir ekibin, bir şeyi gözden geçirmeden ve işleri doğru yaptığınız yolunda bazı güvenceler sunmadan nasıl devam etmesine izin verdiğini anlamıyorum.

Yayın süresine yakın olmak bir bahane değil, yeni kodu tekrar kontrol etmek için daha iyi bir nedendir.

Serbest bırakmanız kolayca çözülemezse, bu grupla ilgili daha büyük sorunlar vardır.

İnsanların neden senin üzerinde olduğunu anlamıyorum. Sistem iyi kuruluysa, değişikliklerinizi düzeltebilmeli / çok hızlı bir şekilde düzeltebilmelidir.

Fakat yine de, eğer camdan inşaa yapanlardan biriyseniz, o zaman ... Ben yardım edemem. (Btw yapmak inanılmaz derecede zordur - herhangi biri MS'e felsefeler inşa etmeyi sorgulamadan önce, ama şimdi ve sonra birisi yapar - ve tüm şirket KG bir gün boyunca durur).

Ve evet - özür dileme. Sadece yöneticinizle sohbet edin ve yaptığınız şeyden öğrendiğinizi anlamasını sağlayın.

Binalar her zaman kırılır. Hatalar ve hatalar yaşamın bir gerçeğidir ve bu yüzden hataların ve hataların etkilerini en aza indiren bir sürece sahip olmalısınız.

Eğer bir yapı kırılması bu kadar büyük bir şeyse, işleminizin bozulduğu anlamına gelir.

Sürekli yapımlar yapmalısınız, gecelik yapımlar değil.

Hiç olmadığı kadar geç bir cevap ...

Diğerlerinin de söylediği gibi, yapıyı bozduğum için özür dileme. Basitçe senin olduğunu kabul et ve işine devam et. Bu şey sizin orada olsanız da olmasanız da olur ve hiç kimse bu nedenle kötü muamele görmeyi hak etmez. İnsanlar baskı altında ağır tepki gösteriyorlar, bu yüzden sakin kalabiliyorsanız ve işe devam edebiliyorsanız, önemli olduğunda öne çıkacaksınız. İnsanların size zor anlar yaşatması konusundaki tavsiyem, sadece savunmaktan kaçınmak, durumu sorundan uzaklaştığınızı veya sıkıştığınızı tespit ederseniz tavsiye almak için çabucak araştırarak durumun etkisiz hale getirilmesidir.

Şahsen ben kırılmış bir yapıyı bir fırsat olarak görüyorum.

• Yapı bozulursa ve bunun sizin suçunuz olduğunu ispat ederseniz, sürekli entegrasyon ve oluşturma işlemlerinin işlerini yaptığını gösterme olasılığı yüksektir. İşlemlerinizi doğruladığı için bu iyi bir şey. Yapı hiç bozulmazsa, yanlış bir şey olduğu için endişeleniyorum.
• Yapıyı oldukça yaygın bir şekilde kırdıysanız ve bu sık sık bu şekilde kırılıyorsa, CI işleminde bir şey eksik olabilir. Bu, ortak başarısızlık senaryolarının daha iyi yönetilebilmesi için süreçlerinizi iyileştirme fırsatıdır.
• Görev çağrısının ötesine geçtiyseniz ve yapıyı belirsiz bir sorunla gerçekten karıştırdıysanız, o zaman ekibin geri kalanına bir uyarı tetiklemek için yeterince önemli olabilecek yeni bir şey öğrenme fırsatınız olur.

Yani demek istediğim, yapıyı kırmanın zaman zaman insanların işlerini yaptıkları anlamına geliyor. Elbette bir hata yapmış olabilirsiniz, ancak bunu öğrenme fırsatı olarak kullanırsanız, bir dahaki sefere daha iyisini yapmayı öğrenerek işinizi yapıyorsunuzdur.

Onlara her check-in için CI oluşturmaya ihtiyaçları olduğunu söyle. Bu şekilde, kırıldığını bilmek için akşama kadar beklemek zorunda kalmazsınız. YEA !!! Onlara bunun yanlış olan süreç olduğunu, başka hiçbir şeyin olmadığını söyleyin. Sadece bir boşluk tespit onların sisteminde.

Ama evet, tamir ettiğinden emin ol. Önemli bir şey değil. Üretimde değil. Sadece değersiz bir gecelik.

Şirketimde olağan bir uygulama:

• "Ben değildim!" (genellikle CVS / SVN provası yoksa)
• "My userlogin ist Schuld!" Diyen bir tişört giyiyor. (evet, geliştiricimizin% 50'si böyle bir forması)
• Yerel gönderim kutusunda çalıştığını ve tüm testlerin iyi geçtiğini iddia etmek

Şirketimin ayrıca böyle bir "olayı" ele almanın iyi bir yolu var:

• İşçi yarım gün boyunca aşağıdaki kostümü giymek zorundadır ( http://www.tradoria.de/kostueme/kruemelmonster-sesamstrasse-kostuem-kruemelkostuem-337103661.html )

• Özür dilemem.

• Kırık inşaat yapmama izin verdiğim için CI liderliğini suçlardım.

• Geliştiricilerin bozuk kod vermesini durdurmak için bir CI işlemi yapılmalıdır.

• Yerel derleme başarısız olursa, derleme sunucusuna girilmesine izin verilmemelidir.

Bir özür dilemenin yerinde olabileceğini düşünmeme rağmen, lütfen "Bunun bir daha olmayacağından emin olacağım" deme. Çünkü olacak. Ve eğer yaparsa seni ısırır.

Açık kaynak kodlu bir proje üzerinde çalışıyorsanız,

"Üzgünüm, yapıyı bozdum. Çok uykum var!"

ve bir github yorumu olarak ekleyin.

Bunun nedeni, birçok açık kaynak geliştiricisinin gece yarısı boyunca kod yazmasıdır.