Yönetici okuma sürümü kontrol taahhütleri


18

Yöneticimiz Git'in tüm projelerimizdeki taahhütlerini izliyor ; genellikle bu bir sorun değildir ve sürüm kontrolünün, özellikle daha sonraki denetim ve analiz için (bir şey ters giderse) gerçekleşen tüm işlerin bir kaydını sağladığını seviyorum.

Ancak, yönetici, "stil düzeltmeleri" yazan bir taahhüt veya görev yönetim sistemimizde bir bilet numarasına referans vermeyen herhangi bir taahhüt mesajı gördüğünde insanların neler üzerinde çalıştığını soran birkaç yorum yaptı.

Bunun sosyal veya teknik bir çözümü var mı?

Ek bilgi: Bu bir bakım projesi, bu yüzden bir sürü "A sonra B sonra C ve sonra D yapmak zorunda kaldı ve sonunda X uygulamak zorunda" görevleri oluyor.

Daha fazla bilgi: yönetici ile bir bayrak kaldırdı özel taahhüt mesajı "X, Y ve Z için daha iyi bir yol dahil" yakın olan basit bir stilistik düzeltme yerine bir yeniden düzenleme mesajı daha yakın oldu.



10
Müdürünüze katılıyorum. Bir şeyin ne zaman değiştiğini anlamak için iki yaşındaki bir işlem günlüğüne bakmak ve "stil düzeltmeleri" gibi taahhütleri görmek sinir bozucu. Yöneticiniz görev yönetim sistemine yeniden düzenleme görevleri eklemenize izin vermiyorsa, bu başka bir konudur.
Robotu Gort

9
Gerçek yeniden düzenleme, stilistik değişikliklerden çok daha önemlidir. En azından taahhüt mesajı neyin yeniden düzenlendiğini söylemelidir, ama gerçekten izlenmesini isterdim, böylece herkes neyin yeniden düzenlendiğini biliyordu, QA daha dikkatli bir şekilde neyi test edeceğini biliyordu, vb.
Robot

3
^ ^ @ @StevenBurnap ne dedi - bu çok iyi bir uygulama. Sadece ne tür bir stil iyileştirme / yeniden düzenleme var uzun açıklamaları ile taahhüt mesajı kirletmek yerine bilet kimliği başvurabilmek ve bunların neden istenir buna değer yapar. Ve çaba, / QA vs vs yönetimi ile iletişimi izleme Ve bana uygun olur nasıl başladı alamadım, daha o kadar varken VCS / kod incelemesi aracıyla hata izleyici bütünleştirir
tatarcık

1
Tamamen duruma bağlı. Yönetici, zamanının% 50'sini yeniden düzenleme için harcanan ekibin bir üyesine mi yoksa bilet referansı olmadan tek bir taahhüde mi tepki veriyor?
winkbrace

Yanıtlar:


42

Bunun sosyal veya teknik bir çözümü var mı?

Sanırım, ama bu bir sorun değil .

Yöneticiniz gerektiğini siz ne yaptığını biliyoruz. Hiçbir değer sağlamayan bir grup iş yapmadığınızdan veya bilet dışı çalışmaya neden öncelik verildiğinden emin olmalıdırlar. Bunda bir zarar yok. İdeal bir dünyada fayda sağlayacaktır, çünkü yöneticiniz iş ile ilgili beklentileri belirleyebilir, böylece tüm işleri baskı veya kesinti olmadan halledebilirsiniz.

Bu sadece, menajeriniz sadece bilet işlerinin yapılması gerektiğini düşünüyorsa ve teknik temizlik işlerinin bilet olmasını engelliyorsa sorun haline gelir. Her zaman temizlemek için teknik borç vardır. Her zaman ince ayar yapmak gerekir, çünkü net ve acil bir iş avantajı sağlamamasına rağmen.


14

Stilistik düzeltme, üzerinde çalıştığınız biletin bir parçasıysa ve ilgili ise, daha iyi tanımlama için üzerinde çalıştığınız bilet numarasıyla ayrı olarak kontrol etmenin yanlış bir yanı yoktur.

Sadece yapılması gereken değişiklikleri keşfediyorsanız ve şu anda üzerinde çalıştığınız biletle ilgili değilse, o zaman teknoloji borcu ile ilgili biletlerin yapılmasını ve daha sonra yeniden rehashing için birikiminize koymanızı öneririm.

Planlamanız sırasında, teknoloji borcu ile ilgili biletleri inceleyebilir ve bu yol üzerinde çalışmayı planladığınız gerçek bakım biletlerine bağlayabilirsiniz.

Bu, "hiçbir yerde olmayan" düzeltmeleri ortadan kaldırmanıza ve üzerinde çalıştığınız belirli sorunlar / biletler kategorisine giren her şeyi korumanıza yardımcı olacaktır.


1
Tamam ama eğer önemsiz bir düzeltme ise bu tamamen aptalca.
Monica ile Hafiflik Yarışları

1
Teknik borç zamanın% 99,99'u önemsiz bir değişiklik değil. Bu yüzden büyük bir bağlam anahtarı olan başka bir şeye dalmak yerine bir bilet yap diyorum. Üzerinde çalıştığınız şeyle ilgisiz ve ilgisiz bir şeyse, üzerinde çalıştığınız bilet adının altında ayrı bir yorumla kontrol edebilirsiniz. Ya da daha iyisi, daha sonra kolay bir tanımlama için QFIX gibi bir gösterimi düşünün, böylece hiçbir kuruluş olmadan etrafta rastgele önemsiz değişiklikler yapmazsınız.
AvetisG

yönetici JIRA'yı yeni biletler için izliyor ve sonra bunları sorguluyorsa ne olacak? biletlerin gelecekteki bir sprint'ten şu anki sprint'e ne zaman taşındığını sorgulamaz, ancak birisi teknik borçla ilgili yeni bir bilet oluşturduğu anda sorgulanır.
Rudolf Olah

Birinci QFIX notasyonu, uygulamadan önce ekip olarak konuşmanız gereken bir şeydir. Her şey iletişim ile ilgili, sadece içeri girip kendi kurallarınızı yazmıyorsunuz. Bu yüzden önce bir ekip olarak konuşun ve sonra kabul etmiyorlarsa, ana biletinizle birlikte kontrol etmek için başka bir çözümle devam edin, ayrı bir yorum ile çalışıyorsunuz. Yine de, sadece değişiklik önemsiz ise, herhangi bir mantık değişikliği veya büyük yeniden düzenleme içermediğini lütfen unutmayın. Zararsız, zararsız, önemsiz değişiklikler.
AvetisG

@omouse Yöneticinizin mikro yönetim yapması veya teknik borçla düzgün şekilde ilgilenmemesi iyi olabilir. Bununla birlikte, yönetici sonuçta projeden bir bütün olarak sorumludur ve kodun kendisinden sorumludur ve bu yüzden ideal olarak devam eden her işin ve nedeninin bir düzeyde farkında olmalıdır.
Robot Gort

1

Bu beni de hata (hiçbir cinas amaçlanan :).

En yararlı check-in'ler, yalnızca neyin değiştiğine değil aynı zamanda nedenine özgü ve benzersiz yorumlar içerir. Bazen paragraf yorumları yazıyorum.

Bazen bir UI gereksiniminin, geliştirme başladıktan sonra ileri geri sıçradığı durumlara giriyorum ve kodu da zıplamamı gerektiriyor (evet, gerçek dünya bazen berbat). Bu durumlarda, yorumlarımın hemen çıkma nedenini ve daha da önemlisi kodun neden nerede bittiğini açıklığa kavuşturmasının daha da önemli olduğunu görüyorum. Daha sonra, yönetim müşterilerle konuştuktan sonra geri döndüğünde ve nedenini bilmek istediğinde, tüm deneyimi adım adım hatırlamak zorunda kalmadan onlara gösterebilirim.

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.