Jira workflow özelleştirme: durum, geçiş ve kural tasarımı

Jira iş akışı neyi tanımlar?

Jira'da iş akışı (workflow), bir iş kaydının yaşam döngüsünü tanımlar: kayıt hangi durumlarda bulunabilir, bir durumdan diğerine nasıl geçer ve geçişi kim, hangi koşulda yapabilir. Varsayılan akışlar genellikle basit bir yapılacak, devam ediyor, tamamlandı sırasını içerir; gerçek bir ekibin süreci ise sıklıkla bundan daha fazla adım taşır.

Özelleştirmenin amacı Jira'yı ekibin gerçek çalışma biçimine uydurmaktır; tersi değil. Bir yazılım ekibinin kod incelemesi ve test aşaması, bir destek ekibinin müşteri yanıtı bekleme durumu, bir satın alma ekibinin onay adımı akışa yansıdığında pano ve raporlar da ekibin gerçeğini göstermeye başlar.

Yapı taşları: durum, geçiş ve kurallar

Atlassian belgelerine göre bir iş akışı birkaç yapı taşından oluşur. Durumlar (statuses), bir işin süreçteki halini anlatır. Geçişler (transitions), işin durumlar arasında nasıl hareket ettiğini tanımlar; geçişler tek yönlüdür, dolayısıyla geri dönüş istiyorsanız ayrı bir geçiş tanımlamanız gerekir. Bir geçiş aynı duruma geri de dönebilir; bu döngü, bir ekran açmak ya da bir eylemi tetiklemek için kullanılır.

Kurallar ise geçişlerin davranışını denetler. Koşul kuralları (condition rules), geçişin ne zaman kullanılabilir olduğunu belirler; doğrulama kuralları (validation rules) geçiş yapılmadan önce belirli bilgilerin doldurulmuş olmasını sağlar. Tetikleyiciler (triggers) ise akış kapsamında otomatik eylemleri çalıştırmak için kullanılır.

Örneğin yalnızca yönetici rolündeki bir kişinin "onaylandı" geçişini yapabilmesi bir koşul kuralıdır. Kapatma geçişinde çözüm açıklaması alanının boş bırakılamaması ise bir doğrulama kuralına örnektir.

Önce süreci kâğıtta tasarlayın

Akışı doğrudan araçta kurmak en sık görülen hatadır. Önce tahtaya ya da kâğıda işin gerçekte nasıl ilerlediğini çizin.

• Her adımın sahibini yazın: durumda kim bekliyor, bir sonraki adımı kim yapıyor.
• Her duruma bir ad verin ve adın o andaki gerçeği anlatmasına özen gösterin. "İnceleme" ile "Müşteri yanıtı bekleniyor" aynı şey değildir.
• Durumları ham gerçekliğe göre değil, karar ihtiyacına göre sayın: raporda ayrı görmek istemediğiniz ardışık adımları tek durumda toplayın.
• Geri dönüşleri çizin: reddedilen bir iş nereye döner, yeniden açılabilir mi.
• Bitiş durumlarını belirleyin: tamamlandı, iptal edildi, yinelenen gibi sonuçlar ayrı kapanış nedenleridir.

Çok sayıda durum, ekibin yalnızca durum güncellemekle uğraşmasına yol açar. Çok az durum ise darboğazı gizler. Hedef, tahtada akışı okunabilir kılan en küçük durum kümesidir.

Aktif bir iş akışını güvenle değiştirmek

Bir iş akışı kullanımdayken yapılacak değişiklik, o akışı kullanan tüm proje ve iş türlerini etkiler. Atlassian belgelerine göre aktif bir akış düzenlenebilir ve değişiklikler Update workflow ile uygulanır ya da vazgeçilir; aktif bir iş akışının adı ise değiştirilemez, bunun için kopyasını çıkarıp kopya üzerinde çalışmak ve sonra onu etkinleştirmek gerekir.

Bu nedenle güvenli bir değişiklik sırası şöyledir:

• Akışın hangi projeler tarafından kullanıldığını kontrol edin.
• Değişiklik kapsamını ekiplerle önceden konuşun; kaldırılacak bir duruma bağlı açık kayıtlar olabilir.
• Mümkünse önce bir deneme projesinde kopya akışı deneyin.
• Silmek istediğiniz durumda açık iş varsa, önce o işleri uygun bir duruma taşıyacak planı yapın.
• Değişikliği ekibe duyurun, ardından panoları ve kayıtlı filtreleri kontrol edin; eski durum adına bağlı filtreler sessizce boş sonuç verir.

Takım yönetimli ve şirket yönetimli projelerde fark

Jira'da proje türleri akış üzerindeki söz hakkını farklı dağıtır. Atlassian belgelerine göre şirket yönetimli (company-managed) projelerde akışları site yöneticileri ve ilgili proje için akış düzenleme izni verilmiş kullanıcılar düzenleyebilir. Takım yönetimli (team-managed) projelerde ise site yöneticileri ve proje yöneticileri düzenleme yapabilir.

Pratikte bu şu anlama gelir: takım yönetimli bir projede ekip kendi süreci üzerinde hızlı karar verir ve değişiklik yalnızca o ekibi etkiler. Şirket yönetimli yapıda akışlar sıklıkla birden çok proje arasında paylaşılır; bu da tutarlılık sağlar ama değişikliği daha dikkatli koordine etmeyi gerektirir. Kurum düzeyinde ortak raporlama gerekiyorsa şirket yönetimli yapı, tek tek ekibin özgürlüğü ön plandaysa takım yönetimli yapı daha uygun olur.

Sık yapılan hatalar

• Ekibin gerçek sürecini sormadan akışı yöneticinin hayalindeki süreçle kurmak. Kullanılmayan bir akış, güncellenmeyen durumlar ve yanlış raporlar üretir.
• Her istisna için yeni durum eklemek. İstisnalar etiketle, alanla ya da kuralla da çözülebilir.
• Geçişleri herkese açık bırakmak. Onay gibi kritik adımlarda koşul kuralı yoksa süreç kâğıt üzerinde kalır.
• Zorunlu alanları doğrulama olmadan istemek. Bilgi eksik gelir; kural eklendiğinde ise ekran sürtünmesi artar. Gerçekten gerekli alanı seçin.
• Tüm iş türlerine aynı akışı vermek. Hata, görev ve talep farklı yaşam döngülerine sahip olabilir.
• Akışı değiştirdikten sonra mevcut panoları ve filtreleri güncellememek.

Her değişikliğin sonunda kısa bir deneme yapın: örnek bir kaydı baştan sona geçirin, geri dönüşleri ve reddi deneyin.

Bu beceriyi Mindset programlarında nerede çalışırsınız?

Jira ile Proje Yönetimi Eğitiminin müfredatında terminoloji ve iş akışları (workflow), proje tipleri olarak takım yönetimli ve şirket yönetimli projeler, issue takibi ile backlog yönetimi ve sprint planlama başlıkları bulunur. Jira Eğitimi: Temel ve İleri Uygulama ise terminoloji ve durum geçişleri, takım yönetimi, proje kurulumu ve yapılandırma ile diğer araçlarla entegrasyon ve ileri özellikler modüllerini içerir. Jira'yı bir ekip için yapılandıracak proje yöneticileri, ürün sahipleri ve Jira yöneticileri için uygundur; kurumsal ekipler ortak bir süreç dili oluşturmak için bu içeriklerden yararlanabilir.