30 saniyelik özet

Initiative, epic, story ve task, ürün çalışmalarını farklı ayrıntı düzeylerinde ifade etmek için kullanılan kavramlardır. Initiative ortak bir amaca yönelik geniş girişimi, epic ilişkili işlerin oluşturduğu büyük çalışma bütününü, story kullanıcı açısından bir ihtiyacı, task ise yapılacak belirli bir işi anlatabilir. Bu yapı kurumdan kuruma değişir. Her araçta task story’nin altında değildir; her küçük iş için bütün seviyeleri oluşturmak da gerekmez. Amaç, günlük çalışmanın hangi kullanıcı ihtiyacına ve ürün yönüne katkı verdiğini anlayabilmektir. Bir hiyerarşinin düzenli görünmesi, işlerin doğru bölündüğünü veya beklenen faydanın oluştuğunu tek başına göstermez.

Neden önemli?

Yönetim kurumsal müşterilerin ürünü daha bağımsız kullanmasını istiyor. Ekipte ise yetki tablosu, davet ekranı ve hata mesajları gibi işler konuşuluyor. İki konuşma arasında bağlantı kurulamadığında yöneticiler yapılan işin amacını, geliştiriciler de büyük beklentinin sınırını anlamakta zorlanabilir.

İşleri farklı düzeylerde ifade etmek bu bağlantıyı kolaylaştırır. Büyük girişim neden yatırım yapıldığını anlatır. Daha dar çalışma bütünü hangi yeteneğin geliştirileceğini açıklar. Kullanıcı ihtiyacı hangi görevin mümkün olacağını gösterir. Uygulama işleri ise bunun nasıl gerçekleştirileceğine ilişkin planı somutlaştırır.

Bunun yönetim açısından değeri, kapsam ve bağımlılık kararlarını görünür kılmasıdır. Bir girişimde gecikme olduğunda bütün işlerin aynı anda büyütülmesi gerekmez. Hangi kullanım ihtiyacının önce karşılanabileceği, hangi parçanın bekleyebileceği ve hangi teknik çalışmanın gerekli olduğu incelenebilir.

Ancak çok katmanlı yapı bakım yükü yaratır. Küçük bir düzeltme için gereksiz üst kayıtlar açmak, aynı açıklamayı farklı yerlere kopyalamak ve her değişiklikte bağlantıları yeniden kurmak zaman tüketir. Yapının kalitesi, kaç seviyesi olduğundan çok karar vermeyi ve ilerlemeyi değerlendirmeyi kolaylaştırmasıyla anlaşılır.

Terim nedir?

Atlassian’ın açıklamasında initiative, ortak bir hedefe yönelen epic’lerin toplamıdır. Epic, daha küçük işlere ayrılabilen geniş çalışma bütünüdür. Story, son kullanıcının bakış açısından yazılmış kısa ihtiyaç veya taleptir. Türkçede initiative için girişim, story için kullanıcı hikâyesi karşılıkları kullanılabilir. Epic terimi çoğu ekipte olduğu gibi bırakılır.

Task, görev anlamına gelir; teknik veya operasyonel bir çalışma adımını ifade edebilir. Atlassian’ın Jira açıklamasında story ve task epic’e bağlanabilir. Dolayısıyla task’ı her durumda story’nin altında bulunan zorunlu bir seviye olarak düşünmemek gerekir.

Kavram kaynağı: Atlassian, Epics, Stories, and Initiatives.

Bu yazıda örnekleri anlatmak için task, bir kullanıcı ihtiyacını gerçekleştiren uygulama adımı olarak kullanılacaktır. Kendi ekibinizde farklı bir düzen varsa önce bu anlamı ortaklaştırın. Başka bir kurumun etiketini kopyalamak yerine, hangi seviyede hangi kararın verildiğini açıklayın.

Epic için yalnızca süreye dayalı bir sınır koymak yetersiz olabilir. “Uzun sürüyor, o hâlde epic” yaklaşımı, kullanıcının hangi yeteneğinin gelişeceğini anlatmaz. Benzer biçimde küçük bir teknik işi “Bir kullanıcı olarak...” cümlesine çevirmek, onu kendiliğinden anlamlı bir kullanıcı hikâyesi yapmaz.

Kullanıcı hikâyesi ile görev arasındaki pratik fark, değerlendirilen ihtiyacın düzeyidir. Kullanıcının bir faturayı görüntüleyebilmesi bir ihtiyaç olabilir. Bu ihtiyacı karşılamak için veri erişiminin kontrol edilmesi ve ekranın hazırlanması uygulama işleri olabilir. Her bir görev bittiğinde kullanıcı faydası tek başına oluşmayabilir; işler birlikte çalışan bir çözüm oluşturmalıdır.

Gerçek vaka: GitLab’ın kendi ürününü planlama biçimi

GitLab, açık el kitabındaki Using GitLab to plan work sayfasında ürün stratejisini belgelendirmek ve backlog’unu yönetmek için kendi platformunu kullandığını açıklıyor. Backlog, ürün için değerlendirilen işlerin sıralı listesidir.

Rehberde issue, dar kapsamlı bir iş kaydı olarak ele alınıyor. Epic, ilişkili issue’ları bir tema veya hedef altında topluyor. Task ise isteğe bağlı olarak issue’yu daha ayrıntılı uygulama adımlarına ayırıyor. Kullanıcı deneyimiyle ilgili bir issue’nun birden fazla kullanıcı hikâyesi içermesi durumunda epic olarak değerlendirilmesi öneriliyor.

GitLab ayrıca çok ilerideki çalışmaları erkenden ayrıntılı issue’lara bölmek yerine daha geniş kayıtlarla tutmayı öneriyor. Uzun süreli temalar için kullanılan meta epic ilişkilerinin, işlerin başka üst kayıtlara taşınması sırasında kaybolabileceğine dikkat çekiyor.

Bu uygulama, tek bir evrensel dört seviyeli düzenin zorunlu olmadığını gösteriyor. GitLab’ın kullandığı issue, her durumda story ile eş anlamlı değil. Kaynak bir planlama pratiğini belgeliyor; bu yapının tek başına teslimatı hızlandırdığını veya geliri artırdığını kanıtlamıyor.

Vakadan çıkarılabilecek ders, her seviyenin amacının ve bağlantılarının açık tutulmasıdır. Ayrıntı arttıkça stratejiyle ilişki kayboluyorsa yapının kendisi yeniden incelenmelidir.

Kaynak: GitLab Handbook, Using GitLab to plan work; Issues, Epics ve Meta epics bölümleri.

Varsayımsal örnek: Kurumsal hesap yönetimi

Bir kurumsal yazılımda müşteriler kullanıcı eklemek ve yetki değiştirmek için destek ekibine başvuruyor. Ürün ekibi, müşterilerin hesap yönetimini destek almadan yapabilmesini geliştirmek istiyor. Bu geniş çalışma, girişim olarak kaydediliyor. Başarı değerlendirmesinde destek ihtiyacının ve yönetim işlemlerindeki hataların nasıl değiştiği incelenecek.

Girişim altında kullanıcı davetleri ve rol yönetimi ayrı epic’ler olarak ele alınıyor. Rol yönetimi içindeki ilk kullanıcı hikâyesi şöyle ifade ediliyor: Hesap yöneticisi, finans çalışanına faturaları görüntüleme yetkisi verebilsin; bu kişi hesap ayarlarını değiştiremesin.

Bu hikâye üzerinde konuşulurken sınırlar netleştiriliyor. Finans çalışanı başka bir müşterinin faturasına erişemeyecek. Yetkisi kaldırıldığında erişimi sona erecek. Ekranda ayar seçeneğini gizlemek yeterli kabul edilmeyecek; erişim kontrolleri ilgili işlemde de uygulanacak.

Geliştiriciler çözümü planlamak için yetki kurallarının tanımlanması, sunucu tarafındaki kontroller, arayüz düzenlemesi ve testler gibi görevler belirliyor. Ürün sahibi ihtiyacı ve kabul beklentisini açıklıyor; teknik adımlar ekipçe şekillendiriliyor.

Çalışma yalnızca “veri yapısı bitti” ve “ekran bitti” şeklinde ayrılırsa müşteri henüz görevini yapamayabilir. Bunun yerine sınırlı bir rol senaryosunu birlikte çalışan bütün parçalarıyla tamamlamak, daha erken değerlendirme imkânı verebilir. Diğer roller sonraki parçalara bırakılabilir; güvenlik koşulları bu bölme sırasında zayıflatılmaz.

Hikâye tamamlandığında hesap yöneticisinin işlemi yapabildiği kontrol edilir. Girişimin başarısı ise ayrıca incelenir. Bütün görevlerin kapanması, müşterilerin destek ihtiyacının azaldığını tek başına göstermez.

Yaygın üç hata

  1. İsimleri standartlaştırıp anlamları konuşmamak

Bir ekip epic’i ürün yeteneği, başka ekip süreli proje olarak kullanıyorsa raporlar yanıltıcı olabilir. Her seviyenin amacını, tamamlanma koşulunu ve ilişki biçimini açıklayın. Süre veya kayıt türünden otomatik anlam çıkarmayın.

  1. İşi yalnızca teknik katmanlara bölmek

Veri, arayüz ve kontrol işleri ayrı ayrı tamamlandığında kullanıcıya kullanılabilir bir parça çıkmayabilir. Teknik görevleri izlerken bunların hangi ihtiyacı birlikte karşıladığını gösterin. Mümkün olduğunda daha dar bir kullanım senaryosunu uçtan uca değerlendirin.

  1. Kapanan alt kayıtları üst hedefin başarısı saymak

Görev sayısı ilerleme hakkında bilgi verir; kullanıcıdaki değişimi açıklamaz. Üst seviyede beklenen sonucu ayrıca izleyin. Yeni bilgi bir alt işin gereksiz olduğunu gösterirse sırf hiyerarşi tamamlanacak diye geliştirmeye devam etmeyin.

Mini uygulama / şablon

Büyük bir ürün çalışmasını seçin ve aşağıdaki alanları doldurun.

Girişimin amacı ve hedef kullanıcı
—
Beklenen sonuç ve kanıt kaynağı
—
Epic’in kapsamı ve tamamlanma koşulu
—
Kullanıcı hikâyesinin ihtiyacı ve faydası
—
Kabul beklentileri
—
Uygulama görevleri
—
Üst kayıtla ilişki
—
Diğer işlerle bağımlılıklar
—
Bağımsız değerlendirilebilecek ilk parça
—
Açık sorular
—
Sonucun değerlendirileceği zaman
—

Sonra her bağlantıyı sorgulayın. Alt iş üst ihtiyaca nasıl katkı veriyor? Ayrı bir seviye açmak hangi kararı kolaylaştırıyor? Tamamlanan parça kullanıcıyla değerlendirilebilir mi? Bu sorulara cevap vermeyen yapıları sadeleştirin. Gerekçeleri tek yerde tutup ilgili işlerden bağlantı vererek tekrarlanan açıklamaları azaltın.

İlgili terimler

Product Goal, Product Backlog, User Story, Acceptance Criteria, Backlog Refinement, User Story Mapping, Sprint Goal, Work Breakdown Structure, Dependency Management, Product Roadmap, Outcome ve Output, Definition of Done