Sorun izleyicinin biriktirme listesi nasıl yönetilir

Trac'ı birkaç yıldır titizlikle kullanıyoruz ve "aktif biletler" listemiz yaklaşık 200 ürüne ulaştı. Bunlar, çok düşük önceliğe sahip ve şimdilik düzeltilemeyecek kadar karmaşık hataları, ertelenen özellik isteklerini, daha önce hiç şikayet oluşturmayan sorunları, ancak herkesin bir gün düzeltilmesi gerektiğini, planlanan kod yeniden düzenlemelerini ve yapmadığımız diğer tasarım hatalarını içerir. izini kaybetmek istemiyorum vb.

Sonuç olarak, bu konuların yaklaşık 200'ü ile liste neredeyse ezicidir; şu anda üzerinde çalışılması gerekenlerin kaynağı olarak artık kullanışlı değil.

Bu tür sorunları takip etmenin en iyi yolu nedir?

Sorunun bir kısmı, bu konuların bazılarının asla yapılmayacak kadar düşük bir öncelik olması. Bu eşyaları takip etmekten nefret ediyorum (bir gün ihtiyacım olursa evimden bir şey atmak istememeye benzer); ne olursa olsun onları atmak gerekir (alışkanlık olarak işaretleyerek) ve onlara ihtiyacım olursa gelecekte bulabileceğini varsayalım?

İlk olarak, her geliştiricinin öğelerin her birine bakmasını ve hala bir sorun olup olmadığını görmek için her öğeyi gözden geçirmesini / test etmesini sağlayın (bunları insanlar arasında bölmek en iyi sonucu verebilir). Ardından, artık sorun olmayan veya diğer geliştirme çabalarıyla ilgilenilmiş olanları kapatın.

Şimdi her birinin büyük, orta veya küçük bir geliştirme çabası olarak işaretlendiğinden emin olun. Bu, projeleri daha kolay sınıflandırmak ve işleri bir araya getirmeye yardımcı olmak için kullanılan çok kaba bir tahmindir. Her şey zaten tahmin edilirse, yardımcı olacaktır, ancak saatlere takılma. Sadece hızlı bir bağırsak kontrolü ile gidin. Geliştiricileri bir odaya almak ve sadece her öğeyi gözden geçirmek ve insanların çoğunun uygun olduğunu düşündüğü çabayı kullanmak için çalışır.

Üç çaba grubunun her birini gözden geçirin ve gruptaki her bir öğeyi Kritik, Yüksek İşletme değeri, Yüksek Teknik değer, Orta değer, Düşük değer ve Asla düzeltmeyecek şekilde işaretleyin.

Bu noktada, listeyi içeriden gerçekten biliyorsunuz ve biriktirmenizle ilgili işi gerçekten anlıyorsunuz ve öğelerle ne yapacağınız konusunda gerçekten bir karar vermeye başlayabilirsiniz. Asla düzeltmeyecek olarak işaretlenen tüm öğeleri alın ve bunları biriktirme listenizden arşivleyin.

Şimdi öğeleri bir sonraki sürümünüze girecek şekilde planladığınızda, kritik ve yüksek önem taşıyan öğeleri sürümünüzün çekirdeği olarak kullanabilirsiniz. Orta ve düşük öncelikli öğelerin listesini inceleyin ve geliştiriciler zaten sistemin o bölümünde çalışacakları için listenizdeki diğer öğelerle aynı anda üzerinde çalışılabilecek öğeleri ekleyin.

Orta veya düşük öncelikli olarak işaretlenmiş öğelerin listesi, insanların biraz boş zamanları olduğunda üzerinde çalışacakları bir liste veya yeni çalışanlar için eğitim olarak kullanılabilir. Bu öğeler üzerinde çalışan ve gerektiğinde ekibin geri kalanına yardımcı olan her yineleme sırasında ekipte bir kişinin olması her zaman güzel olur. Bu şekilde, mevcut yineleme üzerinde çalışmayı tamamlıyorsunuz, ancak esnek ve gerektiğinde yangınları söndürmeye yardımcı olabilecek, ancak normalde dikkat çekmeyecek sorunları ele alan birisine sahip oluyorsunuz.

Bulduğumuz bir şey güzeldi, her yineleme arasında, tüm ekibin sadece küçük bir geliştirme çabasıyla işaretlenmiş öğeler üzerinde çalışacağı 2 haftalık kısa bir süremiz vardı. Kısa sürede çok sayıda bileti kapatmaya odaklanacağız.

Trac bir öncelik ayarına sahip mi? Büyük şov tıpaları için 1 ve bir ara yapmış olmak güzel şeyler için 5 ya da öylesine bir şey?

Önceliğe göre sıralayabilirseniz, şimdilik daha düşük öncelikli şeyleri göz ardı edebilirsiniz.

oku: http://en.wikipedia.org/wiki/5S_%28metodoloji%29

Onları tavana koyun, bir yıl bekleyin, sonra evi taşıyın. Yaptığım budur.

Cidden düzeltmek için gitmiyorsanız o zaman unutun. Bkz. Ekstrem Programlama.

Ancak kodla ilgili öğeler için. Onları küçük gözlemler olarak bir kod inceleme sistemine koyabilirsiniz. Bu sistem, sistemin bir bölümü düzenlendiğinde sorunları işaretlemek için ayarlanabilir. Bunun iş arkadaşı olarak çalışmadığını gördüm, beklenen şey olduğunu düşündüm ve inceleme gözlemlerini ele almadı.

Bunu yapmanın tek yolu acımasız önceliktir. Şimdi yap ya da rahatsız etme.

Bu aslında bir iş akışı ve iş önceliği sorunu kadar bir sürüm kontrolü sorusu değildir. Yanlış olduğu bilinen şeyleri takip etmek, "sabit" olma ihtimalleri düşük olsa bile iyi bir fikirdir. Birincisi, bu, KG'nin (ayrı bir KG ekibiniz varsa) bunun için yeni bir hata günlüğe kaydetmemeyi bildiği anlamına gelir. Başka bir fayda, yeni bir sorun ortaya çıkarsa, ancak kök nedeninin bu "bunu biliyoruz, ancak düşük öncelikli" sorunlardan biriyse, düzeltmeyle ilgili herhangi bir analiz zaten izlenir - bu da daha yeni, daha yüksek - Öncelikli sürümü hata düzeltmek çok daha kolay.

Bunun bir başka yönü, şimdi veya gelecekte bu çalışmanın bir kısmıyla başa çıkmak için bazı zorluklar olabilir. Belki bir gün bir stajyer alırsınız ve onlara daha basit olanlardan birkaçını, kod tabanındaki ayaklarını ıslatmak için bir giriş olarak atayabilirsiniz.

Geliştiriciler bu sorunların düzeltilmesinin iyi olacağını düşünüyorsa - örneğin, teknik borcu temsil ediyorlarsa ve kod tabanının düzeltilmesi için birlikte çalışmayı kolaylaştırırlar, ancak iş değeri yoktur - tartışmaya değer olabilir. iş paydaşları ile ve bu birikmiş işler zaman zaman alındığı bir anlaşmaya varılıp ulaşılamayacağını görmek. Scrum ekiplerinin "teknik birikim" öğeleri için sprint başına 3-5 puan hızını bloke etmek gibi şeyler yaptığını gördüm - bu, geliştirme ekibinin iş paydaşlarıyla ilişkisine bağlı olarak bazı politik incelik gerektirebilir, ancak gördüm çok iyi çalışıyor.

Bu gerçekten birkaç şeye bağlıdır.

1. Takım ne kadar büyük: Takım yeterince büyükse, düşük öncelikli öğelerin tamamlanmasına izin verecek şekilde bilet atayabilirsiniz.
2. Ne sıklıkla yayın yaparsınız: Yayın döngüsü yeterince uzunsa, daha fazla şey ekleyerek veya tüm biletler çözülene kadar bir sürüme devam etmekten kurtulabilirsiniz.