PMI PMP: Agile, Scrum ve Hibrit Teslimat — Çalışma kılavuzu

By Laurynas Brazys · 22 July 2026 · #pmi #pmp #certification #exam-prep #study-guide

Şunun bir parçası: PMP — Çalışma kılavuzu. Doğrulanmış cevaplarla şurada pratik yapın: PMI sınav merkezi, veya şurada süreli deneme sınavları çözün: ExamRoll.io.

Scrum Rolleri, Seremonileri ve Artefaktları

Scrum, kasıtlı olarak küçük bir rol yapısı üzerinde çalışır çünkü sorumluluğun dağılması, karmaşık teslimat süreçlerinin temel başarısızlık nedenlerinden biridir. Product Owner, ne ve neden sorularının sahibidir: değeri tanımlar, backlog’u önceliklendirir ve ürün artırımlarını kabul etme veya reddetme yetkisine sahiptir. Scrum Master, sürecin ne kadar iyi işlediğinden sorumludur: engelleri ortadan kaldıran, çevik (agile) pratikler konusunda koçluk yapan ve takımı dış etkenlerden koruyan bir hizmetkar liderdir. Developers (sadece kod yazanlar değil, tüm teslimat ekibi) ise nasıl sorusunun sahibidir: her sprint’te backlog maddelerini çalışan bir ürün artırımına dönüştürmek için kendi kendilerini organize ederler.

Bu rollerin gerçek ve ilgili kişiler tarafından doldurulması gerekir. İlgisiz veya ortada olmayan bir Product Owner, çevik teslimattaki en yıkıcı örüntülerden biridir — onun anlık önceliklendirmesi ve kabulleri olmadan, sprint review’lar değer doğrulama etkinlikleri olmaktan çıkıp durum toplantılarına dönüşür, geri bildirim döngüleri uzar ve takım yanlış şeyi inşa etmeye doğru sürüklenir. Ortada olmayan bir PO ile karşılaşıldığında, doğru eylem sponsora durumu iletmek ve rolü yeniden tesis etmektir; Scrum Master’ın kalıcı olarak kararları vekaleten alması değil.

Temel seremoniler kapalı bir geri bildirim döngüsü oluşturur:

• Sprint Planning
  • Amaç: Sprint hedefini ve tahminini müzakere etmek
  • Sıklık: Sprint başlangıcı
  • Birincil Çıktı: Sprint backlog
• Daily Standup
  • Amaç: Senkronize olmak, engelleri yüzeye çıkarmak
  • Sıklık: Her gün, 15 dakika ile zaman sınırlı
  • Birincil Çıktı: Gün için ayarlanmış plan
• Sprint Review
  • Amaç: Ürün artırımını paydaşlarla birlikte denetlemek
  • Sıklık: Sprint sonu
  • Birincil Çıktı: Geri bildirim, güncellenmiş product backlog
• Sprint Retrospective
  • Amaç: Sürecin kendisini denetlemek
  • Sıklık: Sprint sonu
  • Birincil Çıktı: Somut iyileştirme eylemleri

Artefaktlar — Product Backlog, Sprint Backlog ve Increment — her birinin sırasıyla Product Goal, Sprint Goal ve Definition of Done olmak üzere bir taahhüdü vardır. Bu taahhütler, Scrum’ın “yinelemeli şelale (waterfall)” modeline dönüşmesini engelleyen unsurlardır.

Backlog Yönetimi ve Kullanıcı Hikayeleri

Product backlog, proje başlangıcında dondurulmuş bir spesifikasyon belgesi değil, yaşayan, sıralı bir listedir. Product Owner, takım ile işbirliği içinde bu listeyi yönetir ve backlog’un en üstündeki maddelerin küçük, iyi anlaşılmış ve çekilmeye hazır olması için maddeleri iyileştirir. Yaygın bir ritim, her sprint’te takım kapasitesinin %5-10’unu backlog refinement (iyileştirme) için harcamaktır.

Kullanıcı hikayeleri bilinen şu kalıbı takip eder: Bir [persona] olarak, [fayda] sağlamak için [yeteneği] istiyorum. Fayda maddesi de en az yetenek kadar önemlidir — bu, takımın alternatif çözümler önermesine olanak tanır ve öncelikler değiştiğinde PO’nun hikayenin hala yapmaya değer olup olmadığına karar vermesini sağlar.

Kabul kriterleri, PO’nun hikayeyi kabul edeceği gözlemlenebilir, test edilebilir koşullardır. Bunlar Definition of Done’dan farklıdır: kabul kriterleri hikayeye özgüdür (giriş ekranı beş başarısız denemeden sonra kilitleniyor mu?), DoD ise her hikaye için evrenseldir (kod gözden geçirildi mi, test edildi mi, belgelendi mi, staging ortamına dağıtıldı mı?).

Bir paydaş proje ortasında yeni bir gereksinim getirdiğinde — bu, önceki işlere benzese bile — PO hemen bir tarih vermemelidir. Doğru tepki, talebi bir backlog adayı olarak yakalamak, takımla birlikte boyutlandırmak (belki de göreceli tahminleme için referans hikayeleri dayanak noktası olarak kullanarak) ve ardından mevcut maddelere göre değerine göre backlog’a yerleştirmektir. Önceki benzerlik, boyutlandırmayı hızlandırır ancak önceliklendirme konuşmasını atlamaz.

DoR, DoD ve İterasyon Planlaması

Definition of Ready (Hazır Olma Tanımı), bir sprint’e giriş için bir kapıdır. Bir hikaye, bir sprint içinde tamamlanabilecek kadar küçük olduğunda, net kabul kriterlerine sahip olduğunda, bilinen bağımlılıkları belirlendiğinde ve takım tarafından anlaşıldığında hazırdır. DoR’u zorunlu kılmak, takımın sprint ortasında cevapsız sorularla duraksayacak yarım yamalak işleri çekmesini önler.

Definition of Done (Tamamlanma Tanımı), çıkış için bir kapıdır. Bu, “kodlamayı bitirdik” ifadesini “bu, potansiyel olarak teslim edilebilir bir ürün artırımıdır” haline getiren ortak, pazarlık edilemez kontrol listesidir. Sağlam bir DoD tipik olarak otomatik testlerin geçmesini, kodun gözden geçirilmesini, güvenlik taramalarının temiz olmasını, belgelerin güncellenmesini ve — kritik olarak — performans ve gözlemlenebilirlik gibi fonksiyonel olmayan gereksinimlerin karşılanmasını içerir. Operasyon ve QA ekiplerini DoD’nin tanımlanmasına dahil etmek, bir ürün artırımının sprint review’da “çalışıyor” görünüp prodüksiyonda gerçek yük altında çökmesi örüntüsünü önleyen şeydir. Eğer bir sprint’ten sonra operasyon ekibi bir performans endişesini dile getirirse ve veriler zaten loglarda mevcutsa, olgun bir tepki, bu endişeyi refinement’a taşımak, DoD’ye performans eşikleri eklemek ve bu açığı kapatmak için backlog maddeleri oluşturmaktır — bunu “kapsam dışı” olarak reddetmek değil.

MVP, Sürüm Planlaması ve Artımlı Teslimat

Minimum Viable Product (Minimum Uygulanabilir Ürün), takımın gerçek kullanıcılarla önemli bir varsayımı test etmesini sağlayan en küçük tutarlı dilimdir. Amacı sadece teslimat yapmak değil, öğrenmektir. Sürüm planlaması daha sonra bunun üzerine katmanlanır: MVP’yi ve ardından artımlı sürümleri içeren bir yol haritası verildiğinde, takım hangi yeteneklerin hangi sürüme denk geleceğini kaba bir kılavuz olarak velocity’yi kullanarak tahmin eder.

Artımlı teslimat, kuruma opsiyonellik kazandıran şeydir — yani görüşlere değil, kanıtlara dayanarak yön değiştirme yeteneği. Kullanıcılara herhangi bir şey göstermeden “tamamlanmış” bir sürümü beklemek, çevik metodolojinin özellikle önlemek için tasarlandığı bir anti-pattern’dir.

Tahminleme, Hikaye Puanları ve Hız (Velocity)

Hikaye puanları, süreyi değil; göreceli eforu, karmaşıklığı ve belirsizliği ölçer. Beş puanlık bir hikaye, o belirli ekip için bir puanlık bir hikayenin kabaca beş katı efor gerektirir. Hız (velocity), yani sprint başına tamamlanan puan sayısı, birkaç sprint boyunca deneysel olarak ortaya çıkar ve takvim taahhütleri vermek için değil, tahmin aralıkları oluşturmak için kullanılır.

Hikaye puanlarını sabit günlermiş gibi ele almak birkaç nedenden ötürü ciddi bir tuzaktır. İlk olarak, bu durum soyutlamayı yok eder: Eğer 1 puan = 1 gün olursa, ekip basitçe gün bazında tahminleme yapar ve son teslim tarihlerine yetişmek için tahminleri şişirir. İkinci olarak, belirsizlik sinyalini ortadan kaldırır — 13 puanlık bir hikaye sadece “uzun” değil, aynı zamanda risklidir ve bu risk, hikayenin daha küçük parçalara ayrılmasını tetiklemelidir. Üçüncü olarak, yönetimin rakamları bir silah gibi kullanmasına olanak tanır (“40 puan demiştiniz, neden sadece 32’sini bitirdiniz?”), bu da ekibi işi ağırdan almaya (sandbagging) teşvik eder. Doğru kullanım şöyledir: hız (velocity) trendi + backlog büyüklüğü → olasılıksal sürüm tahmini, bir aralık olarak iletilir.

Engelleri, Kesintileri ve Akışı Yönetme

Scrum Master’ın en somut işi engelleri kaldırmaktır. Bir ekip üyesi sessizce zorlandığında — belki bunu dile getiremeyecek kadar gururlu veya yeni olduğundan — ekip lideri doğrudan müdahale etmeli, engeli anlamalı ve çözülmesine yardım etmeli veya konuyu üst birimlere taşımalıdır. Günlük toplantının (daily standup) amacını göz ardı etmek, bu durumun kök salmasına neden olur; düzensiz toplantı katılımı bilgi siloları yaratır, engelleyicileri gizler ve küçük sorunların takvim risklerine dönüşmesine izin verir. Katılım pazarlığa açık değildir, çünkü bu seremoninin değeri durum raporlaması değil, senkronizasyon sağlamasıdır.

Anlık (ad-hoc) kesintiler — yani backlog’u atlayan “acil” talepler — aynı derecede yıpratıcıdır. Sprint hedefini aşındırır, tahmini geçersiz kılar ve paydaşlara sürecin etrafından dolaşılabileceğini öğretirler. Doğru yaklaşım, yeni talepleri Ürün Sahibi’ne (PO) yönlendirmektir. Talebin bir sprint iptalini (nadiren) gerektirip gerektirmediğine veya gelecekteki bir sprinte (genellikle) ait olduğuna PO karar verir.

Test veya başka bir disiplinin darboğaz haline geldiği hibrit ekipler için, Kanban panoları ve burndown/burnup grafikleri aracılığıyla akışın görselleştirilmesi bu kısıtı ortaya çıkarır. Eğer ekip, test sürecindeki engeli kaldırabilecek bir araç belirlerse, proje yöneticisi tek taraflı olarak onaylamamalı veya reddetmemelidir — teklifi iş birliği içinde değerlendirmeli, kurumsal yönetişimi (satın alma, güvenlik) kontrol etmeli, backlog üzerindeki etkisi konusunda PO ile görüşmeli ve ardından karar vermelidir. Düşünmeden onaylamak gereken özeni atlar; düşünmeden reddetmek ise ekibin uzmanlığını göz ardı eder.

Retrospektifler ve Sürekli İyileştirme

Retrospektifler döngüyü tamamlar. İyi bir retrospektif, bir dertleşme seansı değil, sahiplenilmiş bir veya iki somut iyileştirme eylemi üretir. Operasyon ve QA ekiplerini retrospektiflere erken dahil etmek, ekiplerin sprint sonu demoları için optimizasyon yapıp üretim ortamı gerçekliğini göz ardı ettiği klasik devir teslim hatalarını önler. Sürekli iyileştirme, ürünün yaşam döngüsü boyunca hızın (velocity) dürüst, Bitti Tanımı’nın (DoD) anlamlı ve ekibin katılımının yüksek kalmasını sağlayan mekanizmadır.

Pratik Problem: Örnek Senaryo

Senaryo: Priya Nair, bir fintek firmasında “LumenPay” mobil cüzdan ekibinin Scrum Master’ıdır. Ekip, altı geliştirici, bir QA mühendisi ve bir UX tasarımcısından oluşmakta ve iki haftalık sprint’lerle çalışmaktadır. Son üç sprint boyunca, Ürün Sahibi (Product Owner) olan Marcus Reeves, Perakende Ortaklıkları başkanı olarak diğer sorumluluklarını gerekçe göstererek sadece bir sprint planlama toplantısına katılmış ve hiçbir sprint değerlendirme (sprint review) toplantısına katılmamıştır. Uyum (Compliance) ve Sahtekarlık Operasyonları (Fraud Ops) departmanlarındaki paydaşlar, çelişkili öncelik talepleriyle doğrudan geliştiricilere e-posta atmaya başlamıştır ve ekip son iki sprint’te toplam 82 hikaye puanının 34’ünü bir sonraki sprint’e devretmiştir. Projenin sponsoru olan Ürün Başkan Yardımcısı Anita Chen, ekibin hızını (velocity) sorgulamaya başlamıştır.

Zorluk: Priya, ürün kararlarını kendisi alarak hizmetkar lider (servant-leader) rolünün sınırlarını aşmadan, Ürün Sahibi’nin katılımını yeniden sağlamalı ve backlog’un parçalanmasını durdurmalıdır.

Önerilen Yaklaşım:

1. Gerçeklere dayalı bir durum sunumu oluşturmak için son üç sprint’teki PO yokluğunun spesifik etkilerini belgeleyin: devreden puanlar, belirsiz kabul kriterleri, çözülmemiş backlog maddeleri ve PO’yu atlayarak doğrudan gelen paydaş taleplerinin sayısı.
2. Öncelikle Marcus ile bire bir toplantı yapın, verileri paylaşın ve bu rolün gerektirdiği haftalık 10-15 saati ayırıp ayıramayacağını veya rolün yeniden atanması ya da bölünmesi gerekip gerekmediğini doğrudan sorun.
3. Belgelenmiş kanıtlarla birlikte durumu resmi olarak Anita Chen’e taşıyın ve iki seçenek sunun: PO rolünü kapasitesi olan birine yeniden atamak veya Marcus’un Perakende Ortaklıkları görevlerinde bir azaltma için pazarlık yapmak.
4. Geliştirme ekibine, gelen tüm paydaş taleplerini anlık olarak kabul etmek yerine ürün backlog’una yönlendirmeleri konusunda koçluk yapın ve yalnızca PO’nun yeniden önceliklendirme yapabileceğini pekiştirin.
5. Kendini adamış bir PO onaylandıktan sonra, öncelikleri yeniden temel almak, kabul kriterlerini temizlemek ve bir sonraki iterasyon için sprint hedefini sıfırlamak üzere bir backlog düzenleme (refinement) çalıştayı düzenleyin.
6. PO’nun planlama, değerlendirme (review) ve sprint başına en az iki düzenleme (refinement) oturumuna katılımını belirten bir çalışma anlaşması oluşturun.

Bu Neden İşe Yarar: Boşluğu sponsora taşımak, rolün bütünlüğünü korur — Scrum Master, vekil bir Ürün Sahibi olmamalıdır, çünkü bu durum kurumsal sorunu kalıcı olarak maskeler ve değere dayalı önceliklendirmeden ödün verilmesine neden olur. Durumu üst birimlere taşırken somut metriklere dayanmak, konuşmayı kişilikler yerine teslimat sonuçları üzerine odaklar ve paydaş trafiğini backlog üzerinden yeniden yönlendirmek, Scrum’ın dayandığı tek bir doğruluk kaynağı (single-source-of-truth) disiplinini yeniden tesis eder.

← Ekip Liderliği ve Kaynak Yönetimi · Tüm alanlar · Kapsam →

Bu soruları çözün → · ExamRoll.io’da süreli pratik →