“Bir şekilde” çözülmesi gereken sürekli büyüyen sorun yığınlarını nasıl ele alıyorsunuz?


15

Yazılım projelerimizdeki sorunları takip etmek için JIRA kullanıyoruz. Fark ettiğimiz bir etki, genellikle yeni bir sorun yarattığımızdır, ancak sorunun ne zaman çözüleceğini / çözüleceğini henüz bilmiyoruz. Bu yüzden, bu tür konuların atandığı sahte bir 'Uzak Gelecek' kilometre taşı keşfettik.

Olduğu gibi, bu kilometre taşına atanan sorunların yığını sürekli büyümeye devam ediyor, bu yüzden bu iyi bir yaklaşım değil gibi görünüyor. Şimdiye kadar o kadar çok var ki, hepsini geçerlilik açısından gözden geçirmek oldukça fazla iş haline geldi. Sizinle ilişkili oldukları bileşen kaldırıldığı için bazıları geçersiz hale geldi. Bazıları başka konular tarafından çoğaltıldı. Bazılarının öylesine kötü ifade edilmiş bir açıklaması var ki, artık kimse ne hakkında olduklarını bilmiyor.

Diğer yazılım geliştirme ekipleri, geçerli olan ancak her zaman düzeltilemeyen sorunlarla nasıl başa çıkarlar? Onları hiç kayıt etmiyor musunuz? Bunları bir sonraki planlanan sürüme atar ve bir sonraki sürüm yaklaştıkça tekrar bakar mısınız? Başka bir şey?


1
Görünüşe göre iş yerimden bahsediyorsun, çok rahatsız edici. Bununla iyi şanslar, bir süredir duruyorum ve bu noktada hiçbir ilerleme kaydedemiyorum. Biz artık ognore edemez kadar çok çöp yönetimi kadar rahatsız görünmüyor.
deadalnix

Neden düzeltilmesi gerekiyor? Önemli değilse ve asla sabitlenmezse, o zaman mükemmeldir.
B Seven

Yanıtlar:


11

Bunlar, şirketinize yeni katılan yeni geliştiricileri düzeltmek için ilk iyi iletişim hatalarıdır. Veya genç geliştiricilerin sistem hakkındaki bilgilerini harcamaları için.

Değilse, düzeltmek için gereken zamanı haklı çıkaracak kadar ciddi değilse, onları "düzeltmeyecek" olarak işaretleyebilirsiniz.


3
+1 Çünkü çözülmezse, teknik bir sorun olduğu kadar sosyal bir sorun da olabilir. Bazen HAYIR demek zorundasınız. Eğer hataları düzeltmeye devam ederseniz, özellikle önemsiz veya gereksiz özellik talepleri insanların beklentileri artacak ve daha fazlasını istemeye devam edecektir.
Keyo

4
Genç programcıların hataları düzeltmesi kötü bir fikirdir, maalesef bu sektörde yaygın bir uygulamadır. Bir hatayı düzeltmenin en uygun maliyetli yolu, onu tanıtan geliştiricinin düzeltmesine izin vermektir.
Trasplazio Garzuglio

6
@MarcoDinacci - "Uygun maliyetli" ne koyduğunuza bağlıdır. Kısa vadeli bir görünüm ile haklısınız. Ancak proje uzun sürerse, genç programcıya 'hataları düzelt' ödevlerinin verilmesi bir yatırım olarak görülebilir.
mouviciel

2
@mouviciel Bence genç programcıları böcek üzerinde çalışmasına izin vermekten daha iyi ve daha teşvik edici yollar var ama kod temeli öğrenmek için bir yol olduğunu kabul ediyorum. Bu yaklaşımla ilgili bir başka sorun, üst düzey geliştiricilerin sadece hataları tanıtmakla ilgilenmeyen kod yazmalarıdır, çünkü onları yine de düzelten genç geliştiriciler vardır.
Trasplazio Garzuglio

3
@MarcoDinacci, farklı bir şekilde ifade edeyim: eğer üst düzey geliştiriciler onları kaliteli iş üretmeye zorlamak için harici bir sürece ihtiyaç duyarlarsa, ekibin temel bir sorunu vardır. IMHO herhangi bir iyi geliştiricinin - özellikle de yaşlıların - kalite için içsel bir motivasyona sahip olması gerekir . Bu motivasyon ekibin fikir liderlerinde yoksa, proje neredeyse kaçınılmaz olarak bir şekilde başarısız olur ve hiçbir süreç ona yardımcı olamaz.
Péter Török

11

Bir hatayı yalnızca uygulama hata olmadan daha değerliyse düzeltmelisiniz.

Bir metin alanı yanlış hizalanmışsa ve düzeltilmesi üç gün sürüyorsa, maliyet muhtemelen çok yüksektir ve bırakmanız gerekir. Aksine, kullanıcılar metin alanına hiç yazamazlarsa, bunu hızlı bir şekilde düzeltmelisiniz.

Genel olarak, bir sorunu keşfedildikten hemen sonra düzeltmek daha kolaydır. Zaman geçmesine izin verirseniz, geliştiriciler kodun bir kısmının nasıl çalıştığını unutabilir ve hatayı düzeltmek daha uzun sürecek ve bu nedenle daha pahalı olacaktır.

Hala bekleyen hatalar varsa bazı şirketler yeni bir kod satırı yazmaz. Diğerleri teslimattan önce test aşamasına kadar rahatsız etmiyor.

Şirketinizde, yeni hataları düzeltmeden önce birikmeleri için çok fazla zaman geçmesine izin veriyorsunuz. Ekibin moralinin çok büyük bir hata listesi görmesi de kötü.

Sorunları bir sonraki dönüm noktasından önce çözmek için mevcut hataları çözmek, düzeltmeye değer olanlara ve olmayanlara karar vermek ve mevcut ekip üyelerine düzeltmek için atamak için bir gün geçirmenizi öneririm. .


6

Sorun takibimizde "zaman kısıtlı" bir durum var. Bir sorun birkaç ay hatta yıl yaşındaysa ve hiçbir müşteri sorunu çağırmaz veya yeniden doldurmazsa, bu durum son durum olarak kullanılır. Yöneticiler açık sorunları temizlememizi istediğinde bu otomatik olarak değil, manuel olarak yapılır. Bu işlem sırasında, bazı sorunların giderilmesi de muhtemeldir, çünkü düzeltilmesi kolay ve / veya nispeten önemlidir (zorlanmamasına veya yeniden doldurulmamasına rağmen).


1
Bu iyi bir stratejidir - size yıllarca sallanan bir hatayı bilmek sonsuza dek halının altına süpürülebilir, bununla mücadele için harika bir motivasyon kaynağıdır.
Steve Jackson

2

JIRA kullanmıyorum, işte fogbugz var ama eminim bu çoğu hata izleyici için geçerlidir. Bunu yazarken, çalışma şeklimin şelaleden daha çevik olduğunu, son teslim tarihlerinin benim için somut olmadığını ve önemli olanın öncelik olduğunu fark ettim.

  • Patronunuz çok fazla biletin açık olmasını önemsiyorsa, ilk etapta önemsiz olanları yaratmayın. Prgamatik olmalısınız ve faydası olmayan hiçbir özellik / düzeltme eklememelisiniz. Bazı kodları parlatmak veya kullanıcı arayüzünü değiştirmek hayatınızı kolaylaştıracaksa, o zaman ekleyin. Üründeki küçük kusurları düzeltmeye çalışarak sadece kendiniz için çalışmayın, hiçbir şey mükemmel değildir.
  • Önemsiz hataları / özellikleri geçerli aşamaya koyun, ancak düşük önceliğe sahip olun. Sorunla ilgili daha fazla şikayet / istek belirtilirse, önceliği yükseltebilirsiniz.
  • Düzeltemeyeceğiniz, çoğaltamayacağınız, çoğaltamayacağınız, vb. Yapabileceğiniz şeyleri kapatın / çözün. Bazı hatalar düzeltilemeyecek kadar önemsizdir veya çok uzun sürecek özellik istekleridir. Bazen bu düzeltmeleri / özellikleri isteyen kişiye "Üzgünüz, vaktimiz yok" demeniz gerekir.
  • Hataları gerektiği gibi önceliklendirin ve bilet listenizin önceliğe ve kilometre taşına göre sıralanmasını sağlayın.
  • Eğer kilometre taşını yapmayacaklarsa, onları gelecekteki bir kilometre taşına taşıyın.
  • Bilet, tamamlanan başka bir bilete bağımlıysa, o zaman engellenmiş olarak işaretleyin veya biletleri bir hiyerarşiye göre düzenleyin, böylece bilet-x ve bilet-y ilişkilidir.
  • Bilet, birisinden bazı geri bildirimler gerektiriyorsa, o kişiye atayın.

Sonuçta her zaman bir sürü düşük öncelikli biletiniz olacak, ancak yukarıdaki puanlar bunu en aza indirmenize yardımcı olacaktır.


2

JIRA kullanıyoruz ve denilen ek bir çözünürlük Suspendeddurumumuz var - eğer bir özellik / hata sadece bir süre vazgeçmemiz gereken bir şeyse, Askıya alındı ​​olarak çözülür. Bu şekilde, dikkatimizi çekmemiz gereken aktif sorunların listesi veya satistfactory ile ele alındığını bildiğimiz çözülmüş sorunların listesi ile karıştırılmıyor ve hala veritabanında.

Askıya alınan sorunların listesi, gerektiğinde yeniden açmak için periyodik olarak (ancak çok sık değil) gözden geçirdiğim bir şeydir.


1

Doğru JIRA terminolojisinden emin değilsiniz, ancak her "bilete" bir son kullanma tarihi koymayı düşünün. Özellik ihtiyaçları veya hata şiddeti nedeniyle belirli bir süre içinde uygulamaya yükseltilmezse, ilk etapta muhtemelen bu kadar önemli değildi. Bu, yığının otomatik olarak kesilmesine yardımcı olmalıdır. Genellikle "iyi olmaz mıydı" veya "bu istediğim gibi mükemmel bir şekilde çalışmaz" dayalı biletler alıyorum. Başka hiç kimse bunun için yeterince itmezse veya kullanıcının yeterli nüfuzu yoksa, tamamlanmaz ve birkaç ay sonra bileti kapatırım.

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.