Görev ve bilet — nedir, izleme sistemleri ve görevlerle çalışma

Görev ve bilet nedir?

Görev — bir izleme sisteminde kaydedilen iş birimi. Açıklama, öncelik (Critical, High, Medium, Low), atanan kişi, son tarih ve durum içerir. Mobil geliştirmede, bir görev “Avatar ile profil ekranı ekle”, “Akış sayfalamasını uygula” veya “targetSdk'yi 35'e güncelle” olabilir. Her görev bir projeye, sprint'e ve belirli bir geliştiriciye veya ekibe bağlıdır.

Bilet — daha geniş bir varlık. Bir bilet, hata raporu (“Android 14'te ekran döndürürken uygulama çöküyor”), özellik talebi (“Koyu tema desteği ekle”), teknik destek sorgusu (“Push bildirimi gelmiyor”) veya yönetici görevi (“Aylık çökme oranı raporu hazırla”) olabilir. Görev ve bilet arasındaki çizgi bulanıktır: Jira'da her iki kavram Issue'da birleştirilmiştir. Temel fark: bir görevin her zaman bir atanan kişisi vardır, oysa bilet triyaja kadar belirli bir atanan kişisi olmayan bir talep olabilir.

Scrum ve Kanban'da görevler, birikim listesinin ana öğesidir. Her görev INVEST kriterlerini (Independent, Negotiable, Valuable, Estimable, Small, Testable) karşılamalıdır. Bağımsız görevler herhangi bir sırada uygulanabilir. Tahmin edilebilir — ekip çabayı tahmin edebilir. Küçük — bir sprint'e sığar. Test edilebilir — net kabul kriterleri vardır. Büyük görevler (epikler), tüm kriterler karşılanana kadar daha küçük görevlere bölünür.

Mobil geliştirmede görev türleri

Feature — yeni uygulama işlevselliği. Örnek: “Biyometrik giriş ekranı (Face ID / Touch ID)”. Feature görevleri her zaman bir kullanıcı hikayesine bağlıdır ve Kabul Kriterlerine sahiptir. Tahmin, story point (1, 2, 3, 5, 8, 13) cinsindendir. Bug — geliştirme veya test sırasında bulunan bir kusur. Hata biletinin önceliği, ciddiyete göre belirlenir (crash → Critical, UI hatası → Medium, yazım hatası → Low). Mobil geliştirmede, %0,1'in üzerindeki çökme oranı acil düzeltme gerektiren kritik bir hatadır.

Tech Debt / Chore — kullanıcıya görünür etkisi olmayan teknik görevler: kütüphane güncellemeleri (Dependency Bump), yeniden düzenleme (ViewPager'dan ViewPager2'ye geçiş), CI/CD kurulumu, test yazma. Tech Debt görevleri genellikle hafife alınır, ancak Stripe 2025'e göre, bir mobil ekibin zamanının %30'a kadarı bakım ve teknik borç ödemeye gider. Teknik borcu görmezden gelmek, hataların artmasına ve yeni özelliklerin geliştirilmesinin yavaşlamasına yol açar.

Ek türler: Spike (araştırma görevi — yeni teknoloji keşfetme, POC yazma), Task (kod dışı herhangi bir iş — dokümantasyon, tasarım incelemesi), Improvement (mevcut işlevselliği iyileştirme — ekran yükleme süresini optimize etme). Jira'da, issue türleri projeye göre özelleştirilebilir. Bir mobil ekip için standart set: Story, Bug, Task, Improvement, Epic. Epic — birden çok hikayeyi birleştiren büyük bir tema. Örnek: “E-ticaret: sepet ve ödeme”.

Görev yaşam döngüsü: oluşturmadan kapatmaya

Open (To Do) — görev oluşturuldu ancak başlatılmadı. Açıklama, Kabul Kriterleri, öncelik içerir. Bu durumda, görev bir sprint'e girmeden önce incelme (grooming) ve tahminden geçmelidir. In Progress — geliştirici çalışmaya başladı. Mobil geliştirmede, commit'leri ve pull request'leri göreve bağlamak önemlidir: Jira'da Smart Commits (APP-123 #comment fix bug) aracılığıyla, GitHub/GitLab'de PR açıklamasındaki anahtar kelimelerle (Closes APP-123).

In Review — kod incelemeye gönderildi. Otomatik kontroller: CI (Gradle build, lint, unit tests), SonarQube (kod kalitesi), Danger (changelog, tests). Geliştirici, mevcut görev Review'deyken bir sonraki görevi alamaz — bu çoklu görevi önler. QA / Testing — test uzmanı gerçek cihazlarda doğrular (Android — çeşitli işletim sistemi sürümleri ve ekran boyutları, iOS — farklı iPhone modelleri). Hatalar bulunursa, görev bir yorumla In Progress'e geri döner.

Done (Closed) — görev tamamlandı: kod main/master'da birleştirildi, test edildi, yayına hazır. Bazı ekipler Deployed durumu ekler — görev, yalnızca mağazalarda yayınlandıktan sonra kullanıcıya ulaşır. Görevleri sonuç yorumuyla kapatmak önemlidir: hangi sürüm, hangi PR, hangi metrikler değişti. Linear (2025)'e göre, görevleri sonuç açıklamasıyla kapatan ekiplerin aynı görevlere geri dönme olasılığı %40 daha düşüktür.

Yaşam döngüsü Blocked durumunu içerebilir — harici bir bağımlılık nedeniyle görev tamamlanamaz (tasarım bekleniyor, backend yanıtı, yönetici onayı). Engellenen görevler, neden ve bir sonraki kontrol tarihi ile bir yorum içermelidir. Engellenen görevlerin haftalık incelemesi, geliştirme sürecindeki sistemsel gecikmeleri belirlemeye yardımcı olur. 2 haftadan uzun süren engelleyiciler, ürün yöneticisi seviyesine yükseltme gerektirir.

Görev izleme sistemleri

Jira — 10 veya daha fazla kişilik ekipler için endüstri standardı. Scrum ve Kanban panoları, gelişmiş iş akışı özelleştirmesi, özel alanlar, otomasyonlar ve Bitbucket/GitHub entegrasyonunu destekler. Dezavantajlar: küçük ekipler için aşırı, yavaş UI, karmaşık yapılandırma. Mobil projeler için Jira şunlarla özelleştirilir: Mobile-specific fields eklentisi (Platform, OS version, Device model), TestFlight ve Firebase Test Lab entegrasyonu ve sürüm derleme otomasyonu. Jira, bürokratik süreçleri olan kurumsal projeler için seçimdir.

Linear — ürün ekipleri için modern bir izleyici. Hızlı UI, birinci sınıf klavye kısayolu desteği, yerleşik Cycle (sprint benzeri), GitHub ve Slack entegrasyonu. Avantajlar: CMD+K ile hızlı görev oluşturma, otomatik aşama dağıtımı (Triaged → Backlog → Upcoming → Current → Completed), yerleşik dokümantasyon ve yol haritaları. Linear, hıza değer veren startup'lar ve ürün ekipleri tarafından seçilir. 2025'te yeni mobil projelerin %40'ı Linear kullanmaktadır.

Trello — küçük ekipler (2–5 kişi) için basit bir kanban panosu. Kontrol listeleri, etiketler, son tarihleri olan kartlar. Dezavantaj: sprint yok, sınırlı analitik, ölçeklendirmesi zor. YouGile — kanban panoları, sohbet ve görüntülü aramalarla Trello'nun Rus benzeri. Asana — projelere ve zaman çizelgelerine odaklanan bir izleyici. İzleyici seçimi ekip boyutuna, bütçeye ve tercihlere bağlıdır: Jira kurumsal, Linear ürün ekipleri, Trello/YouGile startup'lar için. Önemli: araç tüm ekip için birleşik olmalıdır — tasarımcılar, geliştiriciler, QA, yöneticiler aynı sistemde çalışır.

Görev yönetimi için en iyi uygulamalar

Kabul Kriterleri yazın — kabul kriterleri spesifik ve doğrulanabilir olmalıdır. Kötü: “Giriş ekranı çalışıyor”. İyi: “Kullanıcı e-posta ve şifre girer, Giriş Yap'a tıklar. Bilgiler doğruysa — ana ekrana gider. Yanlışsa — “Geçersiz e-posta veya şifre” hatası gösterir”. Kabul Kriterleri (AC), geliştirici, test uzmanı ve ürün yöneticisi arasındaki sözleşmedir. AC olmadan, bir görev Definition of Ready'yi (DoR) karşılamaz ve sprint'e girmemelidir.

Her şeyi bağlayın. Commit'ler, PR'ler, test senaryoları, tasarım maketleri (Figma), Slack tartışmaları — her şey göreve bağlanmalıdır. Jira'da bu, yorumlardaki bağlantılarla; Linear'da, otomatik PR bağlamayla yapılır. Tek tıklama kuralı: görevden tasarıma/koda/testlere — tek tıklamadan fazla değil. Geliştirici görevi açar ve hemen Figma maketini, PR bağlantısını ve test senaryolarını görür. Bu, Linear (2025)'e göre yeni ekip üyelerinin oryantasyonunu %30 hızlandırır.

Hayalet görevler oluşturmayın. Açıklaması, AC'si ve önceliği olmayan bir görev çöptür. Günlük toplantıda kimse bir görevin neden oluşturulduğunu hatırlamıyorsa — silinmeli veya netleştirilmelidir. 48 saat kuralı: bir görev 48 saat boyunca etkinlik olmadan In Progress durumunda kaldıysa, geliştirici gecikme nedenleri hakkında bir yorum bırakmalıdır. Jira (2025)'e göre, 3 günden fazla boşta kalan görevlerin %60'ı sonunda tamamlanmadan kapatılır.

Görev ayrıştırması: epikler, kullanıcı hikayeleri ve alt görevler

Epik (Epic) — birçok hikayeyi birleştiren büyük bir işlevsel alan. Örnek: “Kullanıcı oryantasyonu” şunları içerir: “Karşılama ekranı”, “İlgi seçimi”, “Avatar yükleme”, “Bildirim ayarları”. Kullanıcı Hikayesi (User Story) — kullanıcı bakış açısından bir görev. Biçim: “Bir [rol] olarak, [değer] için [eylem] yapmak istiyorum”. Örnek: “Bir kullanıcı olarak, her seferinde şifremi girmek zorunda kalmamak için biyometri ile giriş yapmak istiyorum”. Kullanıcı Hikayeleri, ürün yöneticisi veya ürün sahibi tarafından yazılır.

Alt görev (Sub-task) — bir Story / Task içindeki teknik işin ayrıştırması. Story “Profil Ekranı” için örnek: Alt görev 1: UI oluşturma (XML / SwiftUI), Alt görev 2: ViewModel'e bağlama, Alt görev 3: Birim Testleri yazma, Alt görev 4: Snapshot Testleri, Alt görev 5: UI Testleri (Espresso / XCUITest). Ayrıştırma kuralı: her alt görev 1–2 günde tamamlanır. Bir geliştirici alt görevi daha uzun tahmin ederse — daha da bölün. Alt görevler, ekip içi bir tekniktir, ürün birikim listesinde görünmezler. Alt görev tahminlerinin toplamı, üst Story'nin tahminine eşit olmak zorunda değildir (işin bir kısmı iletişim, kod incelemesi, testtir).

Ayrıştırma piramidi: Epic (Çeyrek / Yarı yıl) → Feature / Story (Sprint) → Task (1–3 gün) → Sub-task (Birkaç saat). INVEST tekniği, ayrıştırmanın kalitesini doğrulamaya yardımcı olur. Bir görev Bağımsız değilse (başkalarına bağlı) — bu yanlış ayrıştırmayı işaret eder. Bir görev Küçük değilse (8 story point'ten fazla) — daha fazla bölünme gerekir. Yaygın desen: Epic → 5–15 Stories → her Story → 3–8 Sub-tasks. Nihai epik tahmini = Story tahminlerinin toplamı, ancak ilk sprint genellikle tahminlerde %20–30 hata payı verir.

Görevlerle çalışırken yaygın hatalar

Hata 1: görevler çok büyük. 2 haftalık bir görev, ayrıştırma gerektiren bir epik'tir. Büyük görevler günlük izlemeye entegre edilemez; haftalarca In Progress'te kalır. Kural: maksimum görev boyutu — 2–3 günlük iş. Daha büyük olan her şey ayrıştırılmalıdır. Yan etki: geliştirici, dev bir görev yerine haftada 2–3 görevi kapatarak ilerleme hisseder. Bu, motivasyonu ve zaman çizelgesi öngörülebilirliğini artırır.

Hata 2: Kabul Kriterlerinin eksikliği. Geliştirici özelliği uyguladı, test uzmanı doğruladı — her şey iyi. Yönetici: “Düzenleme düğmesi nerede?” — “Görevde yazmıyordu”. AC olmadan, her taraf görevi farklı anlar. Sonuç: yeniden çalışma, çatışmalar, kaçırılan son tarihler. AC bir sözleşmedir: görevde kriter yoksa, sprint için hazır değildir. İncelmede, ilk kontrol edilen AC'nin varlığıdır. AC eksikse, görev inceltme için Ürün Yöneticisine geri gönderilir.

Hata 3: teknik borcu unutmak. Ekip sprint üstüne sprint yalnızca Feature görevleri yapar. Altı ay sonra: derleme 15 dakika sürer, Gradle 3 ana sürüm geridedir, testler kullanımdan kaldırma nedeniyle CI'da başarısız olur. Çözüm: Tech Debt için ekip zamanının %20'sini ayırın (Google SRE uygulaması “SLO tabanlı hata bütçesi”). Her Feature sprint için en az bir Tech Debt görevi oluşturun. Oran: her 3 Feature görevi için — 1 Tech Debt veya Bug. Bu, teknik borç birikimini önler ve geliştirme hızını korur.