Article

Kabul Kriteri Şablonu: Daha Az Revizyon, Net Teslim

Belirsiz görevler kaçınılmaz olarak revizyona yol açar. Alios node açıklamasında kullanabileceğiniz kabul kriteri şablonunu ve dolu bir feature örneğini öğrenin.

Kabul Kriteri Şablonu: Daha Az Revizyon, Net Teslim

Kabul Kriteri Şablonu: Daha Az Revizyon, Net Teslim

Geliştirici görevi bitirdi. "Hazır" dedi. Ürün müdürü baktı, "bu ben istediğim gibi değil" dedi. Geliştirici "ama istediğin şeyi yaptım" dedi. İkisi de haklı — çünkü "istediğin şey" hiçbir zaman net yazılmamıştı.

Revizyon döngüsünün en yaygın sebebi teknik yetersizlik değil. Beklentinin belirsizliği.

"Kullanıcı profil sayfasını güncelle" bir görev tanımı değil. Hangi alanlar güncellenecek, hangi validasyonlar çalışacak, hata durumunda ne gösterilecek, mobilde nasıl görünecek — bunlar yazılmadan görev tamamlanamaz. Tamamlanmış gibi görünür, ama revizyon gelir.

Belirsiz Task Neden Revizyona Yol Açıyor?

Belirsiz görevin yarattığı sorun tek taraflı değil. Her taraf kendi zihnindeki versiyonu tamamlıyor.

Geliştirici "profil güncelleme" duyunca en mantıklı implementasyonu yapıyor. Ürün müdürü "profil güncelleme" derken tasarım dosyasındaki spesifik etkileşimi kastediyor. Tasarımcı başka bir versiyonu hayal ediyor. Üçü de farklı şeyi tamamlıyor.

Sonra revizyon başlıyor. İlk revizyon "küçük düzeltme" olarak başlıyor, ikinci revizyonda kapsam kayıyor, üçüncüde feature yeniden yazılıyor. Bu döngünün maliyeti başta net bir kabul kriteri yazmanın maliyetinden çok daha yüksek.

Bunun yanında belirsiz görev motivasyonu etkiliyor. Geliştirici bitirdiğini sandığı işin "yanlış" olduğunu öğrendiğinde hem zaman kaybetti hem de güven sarsıldı. Bu deneyim tekrar tekrar yaşandığında dikkatli çalışmak yerine "onay beklemek" alışkanlığına dönüşüyor.

Kabul Kriteri Nedir, Ne Değildir?

Kabul kriteri bir görevin "tamamlandı" sayılması için karşılanması gereken koşulların listesi. Test edilebilir, ölçülebilir, yoruma kapalı olmalı.

Kabul kriteri DEĞİL:

  • "Kullanıcı deneyimi iyi olmalı"

  • "Hızlı çalışmalı"

  • "Temiz görünmeli"

  • "Hataları düzgün göstermeli"

Kabul kriteri:

  • "Kaydet butonuna tıklandığında form 2 saniye içinde yanıt vermeli"

  • "Geçersiz e-posta formatı girildiğinde 'Geçerli bir e-posta adresi girin' mesajı gösterilmeli"

  • "Profil fotoğrafı 5MB'tan büyük yüklenmeye çalışıldığında hata mesajı çıkmalı, sayfa yenilenmemeli"

  • "Mobilde 375px genişliğinde tüm form elemanları tam görünmeli, yatay scroll olmamalı"

Fark net: ilk grup yoruma açık, ikinci grup test edilebilir.

Alios Node Açıklamasında Kabul Kriteri Şablonu

Alios'ta her görev node'una aşağıdaki şablon uygulanıyor. Şablonun tamamını doldurmak zorunlu değil — görevin büyüklüğüne göre ölçekleniyor. Ama "Kabul Kriterleri" bölümü her zaman doluyor.

📌 GÖREV TANIMI

Başlık: [Ne yapılacak — tek cümle, fiille biten]
Sorumlu: [Geliştirici adı]
Deadline: [Tarih]
Öncelik: [Kritik / Yüksek / Orta / Düşük]

🎯 AMAÇ
[Bu görev neden açıldı? Hangi kullanıcı ihtiyacını veya
teknik gereksinimi karşılıyor? 1-2 cümle.]

📐 KAPSAM
[Ne yapılacak — ve ne YAPILMAYACAK. Sınırları net çizmek
kapsam kaymasını önlüyor.]

✅ KABUL KRİTERLERİ
[Her madde test edilebilir ve yoruma kapalı olmalı]

Fonksiyonel:
- [ ] [Kullanıcı X yaptığında Y olmalı]
- [ ] [Z durumunda W gösterilmeli]
- [ ] [A koşulunda B engellenmeli]

Hata durumları:
- [ ] [Hata senaryosu 1 — beklenen davranış]
- [ ] [Hata senaryosu 2 — beklenen davranış]

Performans / Teknik:
- [ ] [Yükleme süresi / boyut / uyumluluk kriteri]

Tasarım / UI:
- [ ] [Mobil davranış]
- [ ] [Boş durum görünümü]
- [ ] [Yükleniyor durumu]

🔗 REFERANSLAR
Figma: [Link]
İlgili node: [Bağlantılı görev veya epik]
Teknik spec: [Varsa link]

⏭️ TAMAMLANMA KOŞULU
Yukarıdaki tüm kabul kriterleri karşılandı ve
[QA / ürün müdürü / ilgili kişi] onayladı.

Örnek: "Profil Fotoğrafı Yükleme" Feature'ı

Şablonun dolu hali nasıl görünüyor? Gerçekçi bir feature üzerinden:

📌 GÖREV TANIMI

Başlık: Kullanıcı profil fotoğrafı yükleme özelliğini ekle
Sorumlu: Ali
Deadline: Perşembe, 20 Mart
Öncelik: Yüksek

🎯 AMAÇ
Kullanıcılar profil sayfasında fotoğraf yükleyemediği için
avatar görünümü boş kalıyor. Bu eksiklik onboarding
tamamlanma oranını düşürüyor. Fotoğraf yükleme eklenince
profil tamamlanma adımı kapanacak.

📐 KAPSAM
YAPILACAK: Fotoğraf yükleme, kırpma (crop), kaydetme,
profil sayfasında görüntüleme.
YAPILMAYACAK: Fotoğraf filtresi, sosyal medyadan çekme,
çoklu fotoğraf — bunlar sonraki iterasyonda.

✅ KABUL KRİTERLERİ

Fonksiyonel:
- [ ] Kullanıcı profil sayfasında "Fotoğraf Yükle"
      butonuna tıklayınca dosya seçici açılmalı
- [ ] JPG, PNG ve WebP formatları kabul edilmeli
- [ ] Fotoğraf seçildikten sonra kırpma ekranı çıkmalı,
      1:1 oranında kırpma yapılabilmeli
- [ ] "Kaydet" tıklandığında fotoğraf profil sayfasında
      anında görünmeli, sayfa yenilenmemeli
- [ ] Kaydedilen fotoğraf header'daki avatar alanında
      da güncellenmiş görünmeli

Hata durumları:
- [ ] 5MB üzeri dosya seçildiğinde "Maksimum dosya
      boyutu 5MB" mesajı gösterilmeli, yükleme başlamamalı
- [ ] Desteklenmeyen format seçildiğinde (GIF, PDF vb.)
      "Sadece JPG, PNG veya WebP yükleyebilirsiniz"
      mesajı çıkmalı
- [ ] Yükleme sırasında bağlantı kesilirse hata mesajı
      gösterilmeli, mevcut fotoğraf korunmalı

Performans / Teknik:
- [ ] Yükleme sonrası görüntülenen fotoğraf 200KB'ı
      geçmeyecek şekilde sıkıştırılmalı
- [ ] Yükleme işlemi 3 saniyeyi geçmemeli (normal
      bağlantıda, 1MB dosya için)

Tasarım / UI:
- [ ] Mobilde (375px) fotoğraf yükleme akışı tam
      görünmeli, yatay scroll olmamalı
- [ ] Fotoğraf yokken varsayılan avatar gösterilmeli
      (baş harf veya placeholder)
- [ ] Yükleme sırasında spinner veya progress bar
      gösterilmeli, buton devre dışı kalmalı

🔗 REFERANSLAR
Figma: [Profil sayfası tasarım linki]
İlgili node: "Kullanıcı Profil Sayfası İyileştirmeleri" epiği
Teknik spec: S3 yükleme dokümanı

⏭️ TAMAMLANMA KOŞULU
Yukarıdaki tüm kabul kriterleri karşılandı ve
ürün müdürü staging'de onayladı.

Şablonu Kullanırken Dikkat Edilecekler

"Kullanıcı X yaptığında Y olmalı" formatını kullan. Bu format kabul kriterini otomatik olarak test edilebilir kılıyor. "İyi görünmeli" yerine "kullanıcı fotoğraf seçtiğinde kırpma ekranı açılmalı."

Hata durumlarını atlama. Feature'ın mutlu yolu (happy path) her zaman çalışıyor. Revizyonların büyük çoğunluğu hata durumlarından geliyor. Bu bölüm doldurulmadan görev yazılmamış sayılır.

Kapsam dışını yaz. "Yapılmayacaklar" listesi kapsam kaymasını önlüyor. Geliştirici neyin bu görevin parçası olmadığını biliyor. "Bunu da eklesek mi?" sorusu kabul kriterlerine bakılarak cevaplanıyor.

Çıktı kişiye değil, kritere bağlı. "Ali onaylarsa bitti" değil, "şu kriterler karşılanırsa bitti." Bu ayrım hem hesap verebilirliği artırıyor hem de kişisel yorumun yarattığı belirsizliği kaldırıyor.

Son Düşünce

Kabul kriteri şablonu kullanmak başta yavaşlatıyor gibi görünüyor. Bir görevi açmak 5 dakika yerine 15 dakika alıyor.

Ama bu 15 dakika revizyondan, "ben bunu kastetmemiştim" tartışmasından, yeniden yazılan koddan ve iki tarafın da harcadığı zamandan tasarruf ettiriyor. Net yazılmış bir görev genellikle ilk seferinde doğru teslim ediliyor.

Alios'ta bu şablonu node açıklaması olarak kullanmak için ayrı bir araç gerekmiyor. Görev açılıyor, şablon doldruluyor, geliştirici başlıyor. Revizyon döngüsü başlamadan bitiyor.

Related articles

More articles

Explore other guides connected to this workflow.