Tasarım sorularını, yeni araçları vb. Tartışmak için hata izleme / sorun izleme yazılımını kullanma


13

Herkes sadece hatalar veya görevler için değil, sonuçta bir karara yol açan tartışmalar başlatmak ve sürdürmek için bugzilla, mantis veya JIRA gibi bir hata izleme / sorun izleme yazılımı kullanma konusunda deneyime sahip mi?

Örneğin, bir geliştirici tüm korunan alanların kaldırılması ve bunlara erişen korunan yöntemlerle özel alanlarla değiştirilmesi gerektiğini düşünmektedir. Bu onun çağrısı değil ve tartışmak istiyor. Normalde bir sonraki geliştirici toplantısında sonunda karar verilen noktayı gündeme getirir. Bunun yerine, benim fikrim onun belirli bir “karar” meselesini açması ve niyetini normalde bir hatayı veya görevi tarif edeceği gibi tanımlamasıydı.

Diğer geliştiriciler görüşlerini istedikleri takdirde yapabilirler ve sonuçta sorun "kabul edildi" veya "reddedildi" olarak kapatılır.

Burada gördüğüm avantajlar:

  • Eşzamansız iletişim: Hiç kimse, bir toplantıda, söz konusu kararın tüm sonuçlarını denetlemek için zamanları olmadığında görüşlerini bildirmek zorunda değildir.
  • Karara yol açan hususların yazılı günlüğü. Daha sonra biri bu soruyu tekrar gündeme getirirse, ona yöneltilebilir.
  • Diğer konularla ilişkiler yapılabilir, örneğin bir görev bir karara kadar takip edilebilir.
  • Sürüm kontrol yazılımı ile entegrasyon, örneğin bir taahhüt, bir karara kadar izlenebilir.

Dezavantajları:

  • Altın çekiçin ağır kokusu: Sorun izleme yazılımı, normalde eyleme geçirilebilir öğeleri izlemek için kullanılır
  • Örgütsel yük orantısız olabilir: küçük bir gayri resmi konuşma yerine, fikirlerini yazılı olarak iletmek zorundadır

1
Şahsen, bu tür tartışmaların acı verici derecede yavaş ve verimsiz olduğunu düşünüyorum. En azından Jira ve Redmine ile.
c69

1
@ c69: Evet, bu benim endişemdi. Hızlı bir "hey, bu alanlar özel olmamalı mı?" böyle bir tartışmayı caydırabilecek resmi bir süreç haline gelir.
Ozan

1
Birçok sorun izleyici, tartışma bileşenleriyle bütünleşir. . .
Wyatt Barnett

Yanıtlar:


8

Çalışma şeklimiz, sorun takibi tüm sorunları izlemelidir. Analiz edilene kadar hangi konuların eyleme geçirilebileceğini bilmiyoruz. İzleme sistemi içinde sadece uygulanabilir eylem sorunları varsa, muhtemelen çok erken tetiklenirler, yani herhangi bir tartışma ve karar kaybolur. Her şeyin girmesi gereken yaklaşımı alıyoruz (yine de iş akışımızda), aksi takdirde sorunlar görünürlük olmadan tekrarlanabilir bir şekilde ortaya konulabilir.

Jira uygulamamızda "Risk" için bir kategorimiz var, dolayısıyla Jira'yı işlem dışı olan ancak yazılımı bir şekilde tehlikeye atabilecek öğeleri izlemek için kullanıyoruz. Maddeyle ilgili tartışma izlenir ve risk geçtikten (veya hafifletildikten sonra) sorun kapatılır. Verdiğiniz örnek kolayca Risk kategorisine girebilir.

Bu gibi şeylerin tartışılması ve takip edilmesi ve kararın kaydedilmesi önemlidir. Geliştirici sorunu birkaç ay içinde yeniden gündeme getirdiğinde, "Sorulan ve cevaplanan" yanıtın bir gerekçesi vardır.


İlginçtir, risk olarak sınıflandırılması, bir "karar" sorununun açık bırakılma olasılığını ortadan kaldırıyor gibi görünüyor. Böyle bir risk kategorisi sorununun iş akışı kolay mı yoksa özellikle dikkate alınması gereken herhangi bir husus var mı?
Ozan

Biraz farklı bir iş akışına sahiptir, ancak esas olarak diğer herhangi bir öğeyle aynıdır - Sorunlar ortaya çıkar, tetiklenir, sabitlenir, test edilir ve son olarak kabul edilir. Bellekten bir risk, yazılım değişikliğinde olduğu gibi KG döngüsüne girmez.
mattnz

3

Eğer Yanlışsam beni düzelt; ama ne hakkında konuştuğunuzu düşünüyorum - "Hata Takip / Sorun Takip sistemleri de 'Karar Takip' yapmak için kullanabilirsiniz / Nasıl Kullanılır. Bir şey mi eksik mi?

Başlangıçta bunun gerçekten harika bir fikir olduğunu söyleyebilirim. Tam olarak belirtilen şekilde kullanmamamıza rağmen, onu izleme amacıyla kullandığımız mantıklıdır. Bizim durumumuzda, daha çok bir forum / posta listesi olarak uzun bir e-posta dizisi takip edilmektedir.

Bununla birlikte, daha geniş anlamda sorunuz, kararların nasıl etkili bir şekilde alınacağı (ve yönetileceği) ve işin sonuçlarını daha iyi kavrayışlar getiren kararlarla tekrar ilişkilendirmektir.

Dediğim gibi, bu insanlara yardım ederse harika bir fikir olabilir. Bu konuda yanlış bir şey yok. Ancak etkili kararlar almak / yönetmek için çok az somut şeye ihtiyaç vardır.

  1. Çoğu kararın geniş tabanlı kapsayıcı çaba olması gerektiği doğrudur, böylece kararlar alınmadan önce tüm önemli hususlar uygun şekilde ele alınmalı ve tartılmalıdır. Bu nedenle, hangi aracı kullanırsanız kullanın, ilgili tüm bilgilere şeffaf bir şekilde erişebilmeniz gerekir. Asenkron bilgi aktarma ve toplama modunun yardımcı olduğu konusunda haklısınız çünkü insanlar önerilerde bulunmadan önce zaman ayırabilirler. Açık cevaplar istenirse - tipik olarak toplantılarda, karar yeterli ödevlere sahip olanla aynı derecede sağlam olmayabilir.

  2. Ancak bu her oylamanın eşit olduğu “saf demokrasi” anlamına gelmez. Genel olarak, karar veren kişi bir veya daha az olmalıdır - ve tüm görüşleri alırken, görüşlerini bildiren tüm kişilerden değil, kararlardan bireysel olarak sorumlu olmalıdırlar.

  3. Kararların çoğu uygulanabilir olmalıdır. Bu çelişkileri önlemek zor olabilir; ancak kararların eyleme geçirilebilir olmadığı ve sadece öznel olduğu gerçeği, gelecekteki (yanlış) yorumlar için olasılıklar anlamına gelir.

  4. Kararın seviyesini ve kapsamını sınıflandırmak önemlidir. En önemlisi, spesifik tasarım problemini mi yoksa kodun belirli bir yönünü mi, süreçlerin yönünü mü tartışacağımızı mı yoksa bu proje planlama ve takibi ile ilgili sorunları mı tanımalıyız? Sıklıkla sorunlar bir üretim kodundan kaynaklandığında - bunların hepsi uygulanabilir, ancak bu kararları etkili bir şekilde yönetebilmek için tüm farklı yönleri ayırt edebilmemiz ve bağımsız olarak yapabilmeliyiz.

  5. Bazen kararlar, bireyler için belirli sistemleri veya rolleri ve sorumlulukları kullanıp kullanmadığımız olabilir; bu kararları bir ilan tahtası tipi forumda belirli kararları kodlamakla birlikte koymak zor olabilir.

  6. Sadece ek bir fıkra; her takım, kod incelemelerini ve tasarım incelemelerini kendi başına bir süreç olarak koymalıdır - bu, alıntıladığınız örneğin beğenilerini birçok konuyu kapsamlı bir şekilde kapsayacaktır. Kararları izleyen kararların başka şeylerle ilgilenip ilgilenmediği zorunludur.

İyi bir karar verme uygulamaları, bilgiyi nasıl bir araya getirdiğimiz ve kararların doğru ruhla yapılan uygulamalarla izlenmesini sağlama konusunda çok fazla disiplini içerir.

Bir araç, bilgiyi bunun ötesinde değil, daha sunulabilir hale getirmeye yardımcı olabilir; ancak bu sizin için işe yararsa iyi bir yardımcı olabilir.


1

FogBugz gitmenin yolu. Ücretsiz değil. En yeni özellikler, çevik bir metodoloji uygulamayı daha da kolaylaştırır.

Gitmenin daha basit ve ücretsiz bir yolu Asana olacaktır.

Hangi aracı kullanırsanız kullanın, başarılı bir projeyi kolaylaştırmak için ekip iletişimi en önemlisidir.

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.