Module 2: Agile Planning

Neden Planlarımız Gerçekleşmez?

• Hedef belirlememize rağmen hedefe ulaşamamamızın nedenleri ve bunları nasıl önleyebileceğimiz açıklanmaktadır.
• Bu durum "bilinmeyene yolculuk" olarak adlandırılır; tıpkı bir penguen sürüsünden geçerken olduğu gibi, planlar sürekli değişir.
• Yazılım geliştirmede değişikliklerin kaçınılmaz olduğu vurgulanır.
  • İşletim sistemleri sürekli güncellenir.
  • Bağımlılıklar ve kütüphaneler güncellenir.
  • Müşteri talepleri değişir.
• Büyük bir yol haritası çıkarmak yerine, küçük adımlarla ilerleyip yeni bilgilere göre planları güncellemek önerilir.

Hatalı Planlama: Başlangıçta Her Şeyi Belirleme Hatası

• Projelerin başında az bilgiye sahipken tüm süreci planlamaya çalışmak hatalara yol açar.
• Tıpkı penguen sürüsünde rota çizmeye çalışmak gibi, çevreniz değiştikçe yeni seçenekler ortaya çıkar.
• Agile (Çevik) metodolojinin özü bu duruma bir çözümdür.
  • Önceden her şeyi belirlemek yerine, sadece bildikleriniz doğrultusunda plan yapın.
  • İlerledikçe, edindiğiniz yeni bilgilerle planınızı güncelleyin.

Geleneksel Planlama Hatası

• En başta her şeyi kesin olarak belirlemeye çalışmak, yanlış tahminlere ve kaçırılan teslim tarihlerine neden olur.

İteratif Planlama: Sürekli Güncellenen Yol Haritası

• Daha doğru tahminler yapmak için yapılması gerekenler belirtilir.
  • Sadece bildiklerinize dayalı plan yapın ve her adımda yeni bilgiler doğrultusunda güncelleyin.
  • Projeyi küçük parçalara bölün ve her sprint (çevik döngü) sonunda planı gözden geçirin.

Gerçekçi Tahminler Yapmanın Yolu

• Tahminlerin ne kadar gerçekçi olabileceği zamanla ilişkilendirilir.
  • 3 ay sonrası için yapılan tahminlerde doğruluk payı en fazla %50 olabilir.
  • Ancak 2 hafta sonrasını tahmin etmek gerektiğinde, doğruluk oranı neredeyse %100'e ulaşır.

Ana Fikir

• Her şeyi baştan bilmeye çalışmayın. İlerledikçe öğrenin ve yol haritanızı sürekli geliştirin.

Sonuç ve Özet

• Her şeyi baştan planlamaya çalışmak hatalara ve teslim tarihlerini kaçırmaya neden olur.
• İteratif planlama, adım adım ilerleyerek süreci düzenli olarak güncellemenizi sağlar.
• Planlamayı yol boyunca şekillendirmek, daha doğru tahminler yapmanıza yardımcı olur.
• Agile metodolojisini benimseyin ve planlarınızı esnek tutarak en iyi sonucu elde edin.

Agile Geçişinde Roller Neden Önemlidir?

• Agile metodolojisine geçiş yaparken mevcut çalışanları doğrudan yeni rollere atamak başarısızlıklara yol açabilir.
• Çoğu organizasyon, proje yöneticilerini Scrum Master, ürün yöneticilerini ise Product Owner olarak atamaya çalışır.
• Ancak, bu rollerin gerektirdiği yetkinlikler farklıdır ve uygun eğitim verilmeden yapılan bu değişiklikler başarısızlıkla sonuçlanabilir.

Yanlış Agile Rol Atamalarının Sonuçları

• Ürün Yöneticisinin Product Owner Olması
  • Ürün Yöneticisi genellikle bütçe yönetimi ve operasyonel süreçlere odaklanır.
  • Product Owner ise, vizyon sahibi olup Scrum takımını yönlendiren kişidir.
  • İki rolün sorumlulukları farklıdır ve ürün yöneticisi Product Owner rolüne eğitim almadan geçirilirse vizyoner yönlendirme eksikliği yaşanabilir.
• Proje Yöneticisinin Scrum Master Olması
  • Proje Yöneticisi görevleri yöneten, işleri belirli bir plana göre takip eden kişidir.
  • Scrum Master ise bir koç gibi hareket eder ve ekibin önündeki engelleri kaldırmakla görevlidir.
  • Proje yöneticileri genellikle riskleri belgelendirerek işleri takip ederken, Scrum Master doğrudan engelleri kaldırarak ekibin önünü açar.
• Geleneksel Geliştirme Takımlarının Scrum Takımına Dönüştürülmesi
  • Geleneksel yazılım geliştirme ekipleri genellikle yalnızca yazılım mühendislerinden oluşur.
  • Ancak Scrum takımı çok işlevli bir ekip olmalıdır: Geliştiriciler, Test mühendisleri, Güvenlik uzmanları, İş analistleri, Operasyon ekibi.
  • Eğer yalnızca geliştiricilerden oluşan bir takım oluşturulursa, test ve analiz süreçleri aksayabilir.

Doğru Agile Geçiş İçin Yapılması Gerekenler

• Doğru Eğitim ve Farkındalık
  • Agile geçişinde üst yönetimin de bu süreci desteklemesi gerekir.
  • Scrum Master, Product Owner ve Scrum Takımı üyelerine eğitim sağlanmalıdır.
  • Geleneksel proje yönetim süreçleri ile Agile süreçler arasındaki farklar iyi anlaşılmalıdır.
• Takımların Yeniden Yapılandırılması
  • Scrum takımları yalnızca geliştiricilerden oluşmamalıdır.
  • Çok işlevli takımlar oluşturulmalı ve test, analiz, operasyon gibi destekleyici roller de dahil edilmelidir.
• Yönetim Tarafından Agile Düşünce Yapısının Benimsenmesi
  • Üst yönetim Gantt chart gibi geleneksel planlama araçlarından vazgeçmelidir.
  • Uzun vadeli tahminlerden çok iki haftalık sprint hedefleri belirlenmelidir.
  • "Bu yılın sonunda ne teslim edeceksiniz?" sorusu yerine, "Bir sonraki sprint sonunda müşterilerimizi nasıl memnun edeceksiniz?" sorusu sorulmalıdır.

Sonuç ve Özet

• Mevcut çalışanları Agile rollere eğitimsiz atamak, metodolojinin başarısız olmasına neden olabilir.
• Product Owner ve Scrum Master rollerinin gerektirdiği yetkinlikler, geleneksel yöneticilerin becerilerinden farklıdır.
• Scrum takımları sadece yazılım mühendislerinden değil, çok işlevli ekiplerden oluşmalıdır.
• Agile geçişi yalnızca ekip seviyesinde değil, yönetim seviyesinde de desteklenmelidir.
• Doğru roller, doğru ekipler ve doğru eğitim ile Agile başarısı kaçınılmazdır.

Kanban Panosunun Önemi

• Kanban panosu, iş akışlarını görselleştirmek ve ilerlemeyi takip etmek için kullanılan bir araçtır.
• Gerçek çeviklik, bir zihniyet değişimi gerektirir. Araçlar süreci destekler, ancak önce sürecin doğru bir şekilde tanımlanması gerekir.
• Kanban, esnek ve sürekli ilerlemeye odaklanan bir yaklaşımdır.

Kanban Panosunun Temelleri

• Kanban panosu üç temel kategoriye sahiptir:
  • Yapılacaklar (To Do): Henüz başlanmamış görevler
  • Devam Edenler (In Progress): Üzerinde çalışılan görevler
  • Tamamlananlar (Done): Tamamlanmış görevler
• Basit ve etkili bir yapı ile başlamak her zaman en iyisidir.

ZenHub ve GitHub ile Kanban Yönetimi

• ZenHub, GitHub ile entegre çalışan bir proje yönetim aracıdır. Kanban panosu oluşturmanıza ve projelerinizi takip etmenize olanak tanır.
• Neden ZenHub?
  • Geliştiriciler GitHub'da çalışırken projeleri yönetebilir.
  • GitHub Issues kullanır, böylece farklı bir araca ihtiyaç duyulmaz.
  • Gerçek zamanlı durum takibi sağlar.
  • Yönetici ve ekip üyeleri, projelerin hangi aşamada olduğunu anında görebilir.
• ZenHub, GitHub üzerindeki işleri doğrudan bir Kanban panosuna dönüştürerek geliştiricilerin ayrı bir platforma girme ihtiyacını ortadan kaldırır.

ZenHub Kanban Panosundaki Aşamalar (Pipelines)

• ZenHub, işleri organize etmek için farklı aşamalar (pipelines) sunar:
  • Yeni İşler (New Issues): Yeni oluşturulan tüm görevlerin geldiği yerdir.
  • Beklemede (Icebox): Uzun vadede yapılması düşünülen ancak şu an öncelikli olmayan görevler buraya alınır.
  • Ürün Backlog (Product Backlog): Tüm planlanan ancak henüz sprint'e dahil edilmemiş görevler burada tutulur.
  • Sprint Backlog: Bu sprint içinde yapılacak görevlerin listesi burada yer alır.
  • Devam Edenler (In Progress): Aktif olarak çalışılan görevler burada bulunur.
  • İnceleme ve Test (Review/QA): Kodun tamamlanıp test ve kod incelemesine gönderildiği aşamadır. GitHub entegrasyonu sayesinde, pull request'ler doğrudan buraya gelir.
  • Tamamlandı (Done): Geliştirici açısından tamamlanan görevler buraya taşınır. Ancak bu, işin tamamen bittiği anlamına gelmez; son onay ürün sahibine aittir.

Kanban Panosunun İşleyişi

• İş akışı her zaman soldan sağa ilerler.
  • Yeni işler New Issues sütununa gelir.
  • Planlanan işler Sprint Backlog'a taşınır.
  • Geliştiriciler işi üstlenip In Progress aşamasına alır.
  • Kod tamamlandıktan sonra Review/QA aşamasına gider.
  • Testler başarılı olursa Done aşamasına taşınır.

Avantajları

• Gerçek zamanlı ilerleme takibi sağlar.
• Tek bir merkezi sistemde (GitHub) yönetim yapmayı mümkün kılar.
• Proje durumunu anında görebilirsiniz.

Sonuç ve Özet

• Kanban panosu, işlerin hangi aşamada olduğunu görsel olarak takip etmeyi sağlar.
• ZenHub, GitHub ile entegre çalışarak iş akışlarını otomatikleştirir.
• Kanban panosundaki işler soldan sağa ilerleyerek tamamlanır.
• Sprint Backlog, geliştiricilerin odaklanması gereken en önemli aşamadır.
• İyi organize edilmiş bir Kanban panosu, çevik ekiplerin verimliliğini artırır.
• Ekibiniz için en uygun Kanban panosunu oluşturun ve süreçleri sürekli olarak iyileştirin.

Kullanıcı Hikayelerinin Önemi

• Kullanıcı hikayeleri, yazılım geliştirme sürecinde bir özelliğin veya işlevin nasıl çalışması gerektiğini tanımlayan, kullanıcı odaklı gereksinimlerdir.
• Geleneksel gereksinimlerden farklı olarak, kullanıcı hikayeleri kimin için, neyin gerekli olduğunu ve neden önemli olduğunu açıkça belirtir.

Kullanıcı Hikayeleri Neden Önemlidir?

• İş gereksinimlerini net bir şekilde ifade eder.
• Takımların iş önceliklerini belirlemesine yardımcı olur.
• Yazılım geliştirme sürecini kullanıcı odaklı hale getirir.
• Gereksinim değişikliklerine daha hızlı adapte olunmasını sağlar.

Kullanıcı Hikayesi Yapısı

• Bir kullanıcı hikayesi üç ana bileşenden oluşur:
  • Rol: Hikayeyi talep eden kişi veya kullanıcı grubu kim?
  • İşlevsellik: Kullanıcının hangi işlevi gerçekleştirmesi gerekiyor?
  • İş Değeri: Bu özelliğin sağladığı iş değeri nedir?
• Kullanıcı Hikayesi Formatı: "Bir [kullanıcı rolü] olarak, [şu işlevi] yapmak istiyorum, böylece [iş değeri] elde edebilirim."
• Örnek Kullanıcı Hikayesi: "Bir pazarlama yöneticisi olarak, müşteri e-posta adreslerini içeren bir liste almak istiyorum, böylece pazarlama kampanyaları için onlara e-posta gönderebilirim."

Kullanıcı Hikayelerinde Varsayımlar ve Detaylar

• Kullanıcı hikayelerinde açık olmayan, ancak geliştirme sürecinde kritik olan varsayımlar ve ek bilgiler belirtilmelidir.
• Varsayım: Müşteri e-posta adresleri zaten sistemde saklanıyor.
• Detay: Yalnızca e-posta promosyonlarına izin veren müşteriler listelenmeli.
• Bu bilgiler, geliştiricilerin doğru ve eksiksiz bir çözüm oluşturmasına yardımcı olur.

Kullanıcı Hikayelerinde Kabul Kriterleri (Definition of Done)

• Kabul kriterleri, bir hikayenin ne zaman tamamlanmış sayılacağını tanımlayan ölçütlerdir.
• Örnek Kabul Kriterleri:
  • Veritabanında 100 müşteri var ve bunlardan 90'ı e-posta promosyonlarına izin vermiş.
  • Bir müşteri e-posta listesi talep edildiğinde, yalnızca promosyonlara izin veren 90 müşteri listelenmelidir.

Kabul Kriterleri İçin Gherkin Söz Dizimi Kullanımı

- Given (Ön Koşul): Veritabanında 100 müşteri var ve 90'ı promosyonları kabul etti.

- When (Eylem): Bir müşteri e-posta listesi talep edildiğinde.
- Then (Sonuç): Liste yalnızca 90 müşteriyi içermelidir.

• Bu yaklaşım, geliştiriciler, test mühendisleri ve iş analistleri için net ve ölçülebilir hedefler belirler.

INVEST İlkesi ile Kullanıcı Hikayelerinin Kalitesini Artırma

• Bill Wake'in INVEST modeli, kullanıcı hikayelerinin kaliteli ve etkili olmasını sağlamak için kullanılan bir prensiptir.
  • Independent (Bağımsız): Hikaye, diğer hikayelerden bağımsız olmalıdır.
  • Negotiable (Müzakere Edilebilir): Hikayenin içeriği geliştirilebilir olmalıdır.
  • Valuable (Değerli): İşletmeye veya kullanıcıya değer katmalıdır.
  • Estimable (Tahmin Edilebilir): Hikaye boyutu tahmin edilebilir olmalıdır.
  • Small (Küçük): Hikaye, bir sprint içinde tamamlanabilecek kadar küçük olmalıdır.
  • Testable (Test Edilebilir): Hikayenin tamamlandığını doğrulamak için test edilebilir kriterler içermelidir.

Örnek Kullanımı

• Bir hikaye çok büyükse, epic (büyük hikaye) olarak işaretlenmeli ve daha küçük kullanıcı hikayelerine bölünmelidir.

Sonuç ve Özet

• Kullanıcı hikayeleri, yazılım gereksinimlerini belirlemenin kullanıcı odaklı bir yoludur.
• Kullanıcı hikayesi kim, ne, neden formatında yazılmalıdır.
• Kabul kriterleri, hikayenin ne zaman tamamlanmış sayılacağını belirler.
• Gherkin dili, kabul kriterlerini daha net ifade etmek için kullanılabilir.
  • INVEST prensibi, kullanıcı hikayelerinin daha etkili olmasını sağlar.
• Kullanıcı hikayelerini yazarken net, ölçülebilir ve iş değeri odaklı olmalarına dikkat edin!

Story Point Nedir?

• Story point'lar, bir kullanıcı hikayesinin uygulanmasının ne kadar zor olduğunu tahmin etmek için kullanılan bir ölçü birimidir.
• Önemli olan nokta, story point'lerin soyut bir ölçü olduğudur.
• Story point tahmininde dikkate alınan faktörler:
  • Efor: Ne kadar çaba gerektiriyor?
  • Karmaşıklık: İşlem ne kadar zor veya kolay?
  • Belirsizlik: Daha önce yapılmış mı, yoksa tamamen yeni mi?
• Story point tahmini yaparken, bilinenler ile bilinmeyenler arasında bir denge kurmak gerekir.
• Yeni bir şey yapıyorsanız, belirsizlik nedeniyle puanı biraz daha yüksek verebilirsiniz.

Neden Story Point Kullanıyoruz?

• İnsanlar zaman tahmini yapmada kötüdür. Kebin zaman "Bu iş 30 dakika sürer" denmesine rağmen genellikle işler tahmin edilenden daha uzun sürer.
• Bu yüzden kesin zaman tahminleri yapmak yerine, story point'leri kullanıyoruz.

Story Point'leri Nasıl Düşünüyoruz?

• Story point'leri T-shirt bedenleri gibi düşünebilirsiniz:
  • Küçük (Small)
  • Orta (Medium)
  • Büyük (Large)
  • Ekstra Büyük (XL)
• Ancak, S-M-L'yi toplayamayacağımız için, genellikle Fibonacci dizisini kullanırız
  • Küçük → 3
  • Orta → 5
  • Büyük → 8
  • Ekstra Büyük → 13
• Çok fazla ayrıntıya girmeden, genel büyüklük kıyaslamaları yaparak tahminlerimizi oluşturuyoruz.

Story Point Tahminini Nasıl Yapıyoruz?

• Öncelikle, referans noktası olarak belirli bir hikayeyi seçiyoruz ve onu "ortalama" kabul ediyoruz.
• Sonra diğer hikayeleri bu hikayeye göre karşılaştırıyoruz:
  • Bu hikaye ortalama büyüklükte mi?
  • Bu hikaye daha mı küçük, daha mı büyük?
• Binaları kıyaslamak gibi düşünebiliriz: Bir bina 5 birim yüksekliğinde diyelim.
  • Yanındaki bina biraz daha küçükse, 3 birim olarak düşünebiliriz.
  • Daha büyük bir bina varsa, 8 birim diyebiliriz.
• Bu tamamen göreceli bir kıyaslama sürecidir.

İdeal Story Büyüklüğü Nasıl Olmalı?

• Story'ler küçük ve tamamlanabilir olmalıdır.
• Mümkünse birkaç gün içinde tamamlanabilmeli.
  • Çok büyük story'ler bölünerek daha küçük parçalara ayrılmalıdır.
• 21 veya daha yüksek bir puana sahipse, daha küçük hikayelere ayrılmalıdır.
• Büyük hikayeler, birden fazla sprint'e yayılabilir. Bu durumda, bir "epic" oluşturularak takip edilmesi sağlanır.

Story Point Kullanırken Yapılan Hatalar (Anti-Pattern'ler)

 - Story point'leri zaman ile eşitlemek

- "1 story point = 1 gün, 3 story point = 3 gün" gibi düşünmek yanlıştır!

• Story point = göreceli büyüklük
• Kesinlikle zaman ölçümü değildir!

Sonuç ve Özet

• Story point, kullanıcı hikayelerinin karmaşıklığını tahmin etmek için kullanılır.
• Story point'ler, zaman yerine göreceli büyüklükleri temsil eder.
• T-shirt bedenleri veya Fibonacci dizisi kullanılarak tahmin edilir.
• Story point'leri asla zamanla eşitlememeliyiz!
• Takım içinde ortak bir "orta büyüklük" standardı belirleyerek, daha doğru tahminler yapabilirsiniz!

Ürün Backlog'unun Önemi

• Ürün backlog'u, bir yazılım projesindeki tüm tamamlanmamış hikayelerin (stories) listesidir.
• Sprint içinde olmayan, henüz çalışılmayan ama ileride işlenecek görevleri içerir.
  • Backlog'un sıralı olması gerekir, ancak sıralamanın en doğru olduğu kısım en üstteki görevlerdir.

Ürün Backlog'u Neden Önemlidir?

• Geliştirme sürecine yön verir ve öncelikleri belirler.
• İş gereksinimlerini net bir şekilde tanımlar.
• Sprint planlamasında en önemli görevlerin önce ele alınmasını sağlar.
• Takımın hedeflerine odaklanmasını kolaylaştırır.
• Sprint'e alınacak görevler daha ayrıntılı olmalı, ancak backlog'un alt kısımlarındaki görevler daha az detaylandırılmış olabilir.

Ürün Backlog'unun Oluşturulması

• Bir ürün backlog'unu oluştururken, gereksinimler hikayelere (user stories) dönüştürülür.
• Bu hikayeler, kullanıcı odaklı olmalıdır ve aşağıdaki formatta yazılır: "As a [rol], I need [ihtiyaç] so that [değer]."
• Bu şablon, hikayenin kimin için yapıldığını, hangi ihtiyacı karşıladığını ve iş değerini belirlemeyi sağlar.
• Örnek: Sayaç hizmetine gereksinimler kullanıcı hikayelerine dönüştürülerek backlog'a eklenir.
  • Sayaç oluşturma ve artırma
  • Birden fazla sayaç desteği
  • Sayaç verilerinin kalıcı olması
  • Sayaçları sıfırlama yeteneği

Ürün Backlog'unun Önceliklendirilmesi

• Yeni hikayeler öncelik sırasına göre backlog'a yerleştirilir:
  • En kritik görevler en üstte yer almalı.
  • Öncelikli hikayeler daha fazla detaylandırılmalı.
  • Daha az öncelikli görevler, geliştirme sürecinin ilerleyen aşamalarında detaylandırılabilir.
• Öncelik sıralaması örneği:
  • Sayaç hizmetinin temel işlevselliği oluşturulmalı.
  • Veriler kalıcı olmalı.
  • Sayaçları sıfırlama özelliği eklenmeli.
  • Birden fazla sayaç desteği sağlanmalı.

Sonuç ve Özet

• Ürün backlog'u, tamamlanmamış tüm hikayelerin sıralı bir listesidir.
• Sprint'e alınacak görevler, en üst sıralarda yer almalı ve daha ayrıntılı olmalıdır.
• Hikayeler kullanıcı odaklı yazılmalı ve değer yaratacak şekilde önceliklendirilmelidir.
• Backlog yönetimi, projeye netlik kazandırarak ekibin daha verimli çalışmasını sağlar.
• Önceden Sprint planlamasına başlamadan önce backlog'unuzu net bir şekilde organize etmeyi unutmayın.

Backlog Refinement Nedir?

• Backlog refinement (geri besleme toplantısı), backlog'un düzenlenmesi ve önceliklendirilmesini sağlayan önemli bir süreçtir.
• Bu süreçte, backlog içindeki işlerin sıralaması yapılır, büyük işler daha küçük görevlere bölünür ve geliştiricilerin sprint'e başladığında doğrudan çalışabilecekleri seviyeye getirilir.

Backlog Refinement Sürecinde Neler Yapılır?

• Önceliklendirme: Backlog'daki işleri en önemliden en az önemliye sıralamak.
• Bölme: Büyük hikayeleri (stories) daha küçük, sprint'e sığabilecek parçalara ayırmak.
• Detaylandırma: Üst sıralardaki hikayeleri, geliştiricinin hemen alıp çalışabileceği seviyeye getirmek.

Backlog Refinement Toplantısına Kimler Katılmalı?

• Ürün Sahibi (Product Owner): - Kullanıcı hikayelerini yazar.
  • İşlerin sıralamasını yapar ve işlerin iş değerini belirler.
• Scrum Master:
  • Ürün sahibine backlog refinement sürecinde destek olur.
  • Ekip üyelerinin doğru verileri sağladığından emin olur.
• Teknik Uzmanlar (Opsiyonel):
  • Teknik bağımlılıkları anlamak için geliştirme liderleri veya mimarlar bulunabilir.

Backlog Refinement Toplantısının Hedefleri

• Backlog'un Önceliklendirilmesi:
  • En önemli işler en üstte olmalıdır.
  • Her iş için öncelik belirlenirken iş değeri ve teknik bağımlılıklar göz önüne alınmalıdır.
• Sprint İçin Hazır Kullanıcı Hikayeleri:
  • Sprint planlama toplantısında ek detay eklenmemesi için hikayelerin yeterince açıklanmış olması gerekir.
  • Geliştiriciler doğrudan çalışmaya başlayabilmelidir.

Kanban Tahtasında Backlog Refinement

• Kanban tahtasındaki "Yeni Talepler" (New Issues) sütunu sürekli olarak yeni müşteri talepleriyle dolabilir.
• Backlog refinement toplantısının ilk adımı yeni taleplerin sıralanmasıdır.
• Yeni Taleplerin Ele Alınması: - Ürün backlog'una eklenebilir: Önümüzdeki sprintlerde çalışılacak işlere eklenir.
  • Icebox'a taşınabilir: Düşük öncelikli işler ilerleyen zamanlarda ele alınmak üzere bekletilir.
  • Reddedilebilir: Ürün vizyonuna veya hedeflerine uymayan talepler reddedilir.
• Hedef: Toplantı sonunda "Yeni Talepler" sütununun boşaltılmış olmasıdır!

Kullanıcı Hikayelerinin Detaylandırılması

• Backlog refinement sırasında hikayeler aşağıdaki formatta yazılmalıdır:
• Hikaye Tanımı: "Bir kullanıcı olarak, bir sayaç hizmetine ihtiyacım var, böylece belirli işlemleri takip edebilirim."
• Kabul Kriterleri: "Eğer sayaç 2'ye kadar artırıldıysa ve kullanıcı sayaç değerini isterse, geri dönen değer 2 olmalıdır."
  • Varsayımlar: - Sayaç artırılabilir olmalıdır.
    • Sayaç değeri herhangi bir noktada sorgulanabilir olmalıdır.

Backlog Refinement Çıktıları

• Öncelikli backlog: Hikayeler en önemli olandan en az önemli olana sıralanır.
  • Sprint'e uygun işler: Hikayeler sprint'e hazır hale getirilir.
• Yeni taleplerin triage edilmesi: Gereksiz veya düşük öncelikli işler backlog'dan çıkarılır veya icebox'a alınır.

Sonuç ve Özet

• Backlog refinement, işlerin düzenlenmesi ve sprint'e hazır hale getirilmesi için kritik bir süreçtir.
• Yeni talepler toplantının başında triage edilerek backlog'a eklenir, icebox'a taşınır veya reddedilir.
• Ürün sahibi ve scrum master sürecin ana yöneticileridir. Teknik uzmanlar gerektiğinde destek sağlar.
• Kullanıcı hikayeleri açık, önceliklendirilmiş ve sprint-ready hale getirilmelidir.
• Backlog refinement sürecini düzenli yaparak sprint planlamasını daha verimli hale getirebilirsiniz!

Backlog Refinement (Bakıma Alma) Nedir?

• Backlog refinement, ürün backlog'unu düzenleme ve hikayeleri sprint'e hazır hale getirme sürecidir.
• Bu süreçte hikayeler detaylandırılır, teknik borçlar belirlenir ve sprint planlaması için önceliklendirme yapılır.

Backlog Refinement Süreci

• Hikayelerin düzenlenmesi sürecinde aşağıdaki adımlara dikkat edilmelidir:
• Etiketleme (Labeling)
  • Etiketler, işlerin görselleştirilmesini sağlar.
  • Kanban panosunda belirli renklere sahip etiketler kullanarak işlerin türü daha net hale getirilebilir.
  • Örneğin:
    • Hata (Bug) → Kırmızı (Tehlike anlamına gelir)
    • Geliştirme (Enhancement) → Mavi
    • Teknik Borç (Technical Debt) → Sarı (Dikkat edilmesi gereken konular)
• Hikayelerin Gözden Geçirilmesi
  • Hikayelerin müşteri için ne kadar değer kattığı belirlenir.
  • Geliştirmeler, teknik borçlar ve diğer iş türleri ayrıştırılır.
  • Eksik detaylar tamamlanarak hikayeler sprint'e uygun hale getirilir.
• Örnek Hikaye Refinement Süreci: "Bir sayaç servisi sağlamak istiyorum."
  • Assumption (Varsayımlar): Redis kullanılacak, sayaçlar bellek içi tutulacak.
  • Acceptance Criteria (Kabul Kriterleri): Sayaç artırıldığında ve servis yeniden başlatıldığında değer korunmalıdır.
  • Etiket: Geliştirme (Enhancement)
• Teknik Borç: "Servisi buluta dağıt."
  • Assumption (Varsayımlar): IBM Cloud üzerinde çalıştırılacak.
  • Acceptance Criteria (Kabul Kriterleri): Servis URL'si üzerinden erişilebilir olmalıdır.
  • Etiket: Teknik Borç (Technical Debt)

Teknik Borç Nedir?

• Teknik borç, müşteri tarafından doğrudan algılanmayan ancak sistemin sürdürülebilirliği ve kalitesi için yapılması gereken işlerdir.
• Örnek Teknik Borçlar:
• Kod Refaktörleme: Geliştiricilerin daha hızlı ve hatasız kod yazmasını sağlamak için kodun iyileştirilmesi.
  • Ortam Yönetimi: Test ve üretim ortamlarının hazırlanması.
  • Teknoloji Değişiklikleri: Yeni bir veritabanına geçiş gibi altyapı güncellemeleri.
  • Güvenlik Güncellemeleri: Harici kütüphanelerdeki güvenlik açıklarının giderilmesi.
• Teknik Borç Nasıl Yönetilmeli?
  • Her sprint'te belirli miktarda teknik borç azaltılmalıdır. Teknik borç birikirse sistemin bakımı zorlaşır.

Backlog Refinement İçin İpuçları

• Sürekli Yapılmalı: Her sprint'te en az bir kez backlog refinement yapılmalıdır.
• Planlama Öncesi Yapılmalı: Sprint planlama toplantısında hikaye detayları net olmalıdır.
  • Hikayeler Önceden Hazırlanmalı: Sprint sırasında yeni hikayeler oluşturmak yerine önceden backlog'da hazır olması gerekir.
  • En Az İki Sprint'lik İş Planlanmalı: Acil durumlar için yedek sprint backlog'u bulunmalıdır.

Sonuç ve özet

• Backlog refinement süreci sprint planlamasını kolaylaştırır.
• Teknik borç, müşteriye doğrudan değer katmasa da sistemin sürdürülebilirliği için önemlidir.
• Hikayelerin etiketlenmesi ve görselleştirilmesi, planlamayı hızlandırır.
  • Backlog'un düzenli olarak gözden geçirilmesi, sprint'lerin verimli geçmesini sağlar.
• Teknik borçları ve geliştirmeleri renk kodları ile ayırarak backlog'unuzu daha net hale getirin!

Sprint Planlamasının Önemi

• Sprint planlaması, ekibin belirli bir zaman diliminde neyi başarabileceğini belirlediği toplantıdır.
• Amaçları:
  • Ekibin üstleneceği görevleri netleştirmek.
  • Sprint hedefini belirlemek ve herkesin bu hedef doğrultusunda çalışmasını sağlamak.
  • Yapılacak işleri belirleyerek sprint backlog’unu oluşturmak.
  • İş yükünü ekip kapasitesine uygun şekilde dağıtmak.

Sprint Planlama Süreci

• Ürün sahibi, Scrum Master ve geliştirme ekibinin katılımıyla gerçekleştirilir.
• Sprint Hedefinin Belirlenmesi:
  • Ürün sahibi, sprint sonunda hangi işlerin tamamlanacağını net bir şekilde ifade etmelidir.
  • Ekip üyelerinin sprint boyunca odaklanmasını sağlar, projenin genel vizyonuna uygun şekilde ilerlenmesini garanti eder ve sprint sırasında alınan kararları yönlendirir.

Sprint Planlamasının Mekaniği

• Backlog'dan İş Seçimi:
  • Ürün backlog'undan en öncelikli iş öğeleri seçilir.
  • Takım, bu işleri sprint backlog'una taşır.
• Hikayelerin Puanlanması (Story Points):
  • Geliştirme ekibi, backlog öğelerini değerlendirmek için story point kullanır.
  • Örnek bir puanlama süreci
    • Küçük bir hikaye → 1-2 puan
    • Orta büyüklükte bir hikaye → 3-5 puan
    • Büyük bir hikaye → 8+ puan
• Planlama Pokeri ile Tahminleme:
  • Ekibin her üyesi, hikayeye kendi tahmin ettiği bir puan atar.
  • Farklı tahminler tartışılır ve ortak bir karara varılır.
• Sprint Backlog'un Tamamlanması:
  • Ekibin hızına (velocity) uygun olarak backlog öğeleri seçilir.
  • Geçmiş sprint'lerde tamamlanan story point sayısı dikkate alınarak, ekip aşırı yüklenmeden sprint boyunca tamamlayabileceği işler seçilir.

Sprint Hızı (Velocity) Nedir?

• Ekibin bir sprint içinde tamamlayabildiği toplam story point sayısını ifade eder.kibin kapasitesini ifade etmektedir.
• Gerçekçi taahhütlerde bulunmasını sağlar, sprint planlamasında aşırı yüklenmeyi önler ve gelecekteki sprint'ler için daha iyi tahminler yapılmasını sağlar.
• Farklı ekiplerin velocity değerleri karşılaştırılmamalıdır! Çünkü her ekip, farklı hikaye büyüklükleri kullanmaktadır. değerlendirdiği gibi.

Sprint Planlamasında Milestone (Kilometre Taşı) Kullanımı

• Sprint hedeflerini netleştirmek için milestone oluşturulabilir.
• Nasıl oluşturulur?
  • Sprint'in adını belirleyin. (Örn: Sprint 1 - Cloud Deploy)
  • Açıklama kısmına sprint hedefini yazın.
  • Sprint'in başlangıç ve bitiş tarihlerini belirleyin.
  • Sprint süresi genellikle iki hafta olarak seçilir.

Sprint Planlama Sürecinin Adımları

• Sprint hedefi belirlenir.
• Ürün backlog'undan işler seçilir.
• Story point tahminleri yapılır.
• Ekip kapasitesine uygun sprint backlog oluşturulur.
  • milestone belirlenir ve sprint süresi tanımlanır.
• Sprint planlamasının amacı, ekibin hedefe odaklanmasını sağlamak ve sprint boyunca verimli çalışmasına yardımcı olmaktır.

Sonuç ve özet

• Sprint planlaması, ekibin bir sprint boyunca tamamlayacağı işleri belirler.
• Sprint hedefi, ekibin odak noktasını belirleyerek sprint'in başarısını artırır.
• Story point kullanımı iş yükünün doğru tahmin edilmesini sağlar.
• Velocity ekibin kapasitesini ölçerek gerçekçi taahhütlerde bulunmasını sağlar.
• Milestone'lar, sprint sürecini planlamak ve takip etmek için kullanılır.
• Sprint planlamasında geçmiş sprint'lerden ders çıkarılması ekibinizin tahmin doğruluğunu artırır.

• Sprint planlama sürecini açıklama
• Backlog oluşturma ve iyileştirme süreçlerini tanımlama
• İyi bir kullanıcı hikayesinin (user story) nasıl olması gerektiğini açıklama
• Kanban tahtasını tanımlama ve süreçlerin nasıl ilerlediğini açıklama
• Tekrarlayan planlamanın (iterative planning) neden başlangıçta yapılan planlamadan daha doğru olduğunu anlatma