Yanıtlar:
Açık olan konular genellikle ilk olarak ne olursa olsun oluşur.
Yeniden açıklanan konular ya 1) yeniden ortaya çıkıyor ve / veya 2) doğru şekilde düzeltilmiyor. Bunun çeşitli nedenleri olabilir - önemli bir anahtar genellikle sorunun orijinal kullanıcı tanımına bağlanabilir.
Herhangi bir mantıklı mağazanın teknik personeli [tek başına] yargılamak için bir metrik olarak kullanacağını düşünmüyorum, ancak yanıtların ne kadar etkili olduğunu belirlemek için bir önlem olarak yararlıdır ve ele alınması gereken altta yatan sorunları da belirtebilir.
Eski şirketim, bu geliştiriciyi, bir geliştiricinin ne kadar "kötü" olduğunuzu görmek için sorununuzun kaç kez "Yeniden Açıldı" ya gittiğini izlemek için kullandı. Bir iş öğesinin "Yeniden Açılma" sayısı ile programcı olarak değeriniz arasında bir ilişki olduğunu düşünüyorlardı.
Artık orada çalışmıyorum.
Bir hatanın ömrü genellikle:
yani.
Birisi bir hata bulur ve izleyicide açar. Geliştirici, sorunu anlamaları ile mümkün olan en iyi şekilde düzeltir. Test cihazının çalıştığı düzeltmeyi doğrulamak için yeniden test eder ve olmadığını doğrulayabilirlerse tekrar açar. Düzeltme doğrulanırsa, hata kapatılır.
Diğer senaryo, başka bir yerde bir düzeltmenin gerilemeye neden olması ve hatanın yeniden düzeltilmesi gerektiğidir. Böylece yeniden açılır.
Ayrıca, sorunun çözüldüğüne inanıldıktan sonra sorun olmaya devam ettiğinden, sorunun daha yakından veya daha hızlı dikkat gerektirmesi daha açık hale getirilebilir.
Açılmış olması, bunun yeni bir sorun olduğu anlamına gelir. Yeniden açılan araç, Açılan-> Kapatılan ve sonra tekrar Açılan bir sorundu.
Neden tekrar açıldı? Belki geliştirici ve testçi bu sorunun çözüldüğünü düşündü, ancak gerçekten düzeltilmedi. Ya da belki sorun gerçekten düzeltildi, ancak diğer bazı kod değişiklikleri sorunun yeniden oluşmasına neden oldu. Nasıl olduğu önemli değil ama yeniden açılan bir konu kötü bir işaret ve dolayısıyla farklı kategorilere ayrılıyor.
Burada kullanma şeklimiz:
Yeni Görev: Yapılması gereken tüm işleri göstermek için projenin başında yaratılmıştır. Birisi kodlayana kadar açıktır, sonra çözülür. Yalnızca bir şey uygulanmadığında veya işlevsellik değiştiğinde ve geliştirici geri dönüp üzerinde çalışmak için iyi bir zaman harcamak zorunda kalırsa yeniden açılır.
Hata / Hata: KG'deki bir kişi veya çalışan bir ürünü kontrol eden başka bir geliştirici tarafından açıldı. Size bir hata atanırsa, onu düzeltir ve daha sonra çözersiniz ve teste geri döner. KG düzeltilmediğini düşünürse yeniden açar ve sahip oldukları diğer bilgileri ekler. Çözülen / Yeniden Açılan döngü, QA hatanın giderildiğinden memnun olana kadar gidebilir, ardından bileti kapatır.
Yani, temelde Reopen'i bir biletin zaten bakıldığını ve birisinin üzerinde çözüldüğünü hissettiği işleri yaptığını söylemek için kullanırsınız, ancak durum böyle değildi.
Temelde tutarlılık sağlayan bir şeydir: Bir hata (veya genel olarak bir sorun) sıfırdan yaratılmışsa "açık" tır. Önceki bir işlem gerçekleştirildikten sonra yaratıldıysa "yeniden aç" olur.
Bir geliştirici (veya sorunu halleden herkes için) herhangi bir fark yaratmamalıdır. Bir dava açıldı ve şimdi işlenmesi gerekiyor.
Bununla birlikte, farklı bir "yeniden aç" durumu bazı senaryolar için hala yararlı olabilir:
İlk olarak, kalite güvence sürecinizin çalışıp çalışmadığını takip etmenin bir yolu olarak kullanılabilir. KG her şeyi doğru yaptıysa, bir hata düzeltildikten sonra asla meydana gelmemelidir. Yani, bir hatanın "yeniden açılma" durumuna kaç kez ayarlandığını, KG'nin bu işi düzgün yapmadığını kaç kez ifade ettiğini söyleyebilirsiniz. Bu elbette iyi bir KG sürecinin var olduğunu ve kullanıcıların sürece aktif olarak katıldıklarını ve bir konuyu ne zaman "açacaklarını" ve ne zaman "yeniden açacaklarını" bildiklerini göstermektedir.
Başka bir kullanım, bir hata tekrar oluştuğunda, başka bir sorunu ortaya çıkarmanıza gerek yoktur, ancak mevcut bir sorunu ekleyebilir (ve bu nedenle sorun geçmişi, yüklenen ek dosyalar, önceki yorumlar ve ama yine de "hey, bu tekrar oldu ).
"Yeniden açmayı" izlemenin temel nedenlerinden biri, basit slipup'lar ve ayrıntıların gözetimi yerine size derinden yönlendirilmiş sorunların bir göstergesidir. Belirli bir modülde veya işlevsellikte çok sayıda "repopen" varsa, adreslenmesi gereken bir zayıflığa işaret eder. Çok sayıda tek açıklık, acele iş ve / veya özensiz uygulamaya işaret eder.