Çevik Planlama Modülü PDF

Destination Unknown 🏗 Neden Planlarımız Gerçekleşmez? Douglas Adams'ın ünlü sözüyle başlayalım: "Son teslim tarihlerine bayılıyorum. Uçup giderken çıkardıkları 'vuuş' sesini seviyorum. Vuuş! İşte bir teslim tarihi daha gitti."...

Destination Unknown 🏗 Neden Planlarımız Gerçekleşmez? Douglas Adams'ın ünlü sözüyle başlayalım: "Son teslim tarihlerine bayılıyorum. Uçup giderken çıkardıkları 'vuuş' sesini seviyorum. Vuuş! İşte bir teslim tarihi daha gitti." Bu hepimizin başına gelir. Bir hedef belirleriz, ancak onu kaçırırız. Peki neden? Daha da önemlisi, bunu nasıl önleyebiliriz? Bu durumu bilinmeyene yolculuk olarak adlandırıyorum. Örneğin, bir penguen sürüsünün içinden geçmek zorunda olduğunuzu düşünün. İlk başta, belirli bir noktadan geçmeyi planlayabilirsiniz. Ancak penguenler sürekli hareket eder. İşte yazılım geliştirme de böyledir. İşletim sistemleri sürekli güncellenir. Bağımlılıklar ve kütüphaneler güncellenir. Müşteri talepleri değişir. 📌 İlk başta yol haritasını tamamen çıkarmaya çalışmak yerine, küçük adımlarla ilerleyerek yeni bilgiler edindikçe planınızı güncellemelisiniz. 🛑Hatası Hatalı Planlama: Başlangıçta Her Şeyi Belirleme Projelerin en başında en az bilgiye sahibiz. Buna rağmen tüm süreci o anda planlamaya çalışıyoruz. Ancak bu, hataların kaçınılmaz olmasına neden olur. Bu durumu şöyle düşünün: 🐧 Penguen sürüsünün başına gelip rotanızı çizmeye çalışıyorsunuz. Ancak içeri girdikçe, çevreniz değişiyor ve yeni seçenekler ortaya çıkıyor. İşte Agile (Çevik) metodolojinin özü de budur! Önceden her şeyi belirlemek yerine, sadece bildikleriniz doğrultusunda plan yapın. İlerledikçe, edindiğiniz yeni bilgilerle planınızı güncelleyin. Destination Unknown 1  ❌ 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ı Peki daha doğru tahminler yapmak için ne yapmalıyız? ✔ 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: 3 ay sonrası için tahminde bulunmanız gerektiğinde, en fazla %50 doğruluk payınız olur. Ancak 2 hafta sonrasını tahmin etmeniz gerektiğinde, neredeyse %100 doğruluk oranına ulaşırsınız. 🎯 Ana fikir: 💡 Her şeyi baştan bilmeye çalışmayın! 💡 İlerledikçe öğrenin, yol haritanızı sürekli geliştirin. 🚀 Sonuç ve Özet 📚 Bu Derste Öğrendikleriniz: ✅ 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. 🛠 Öneri: Agile metodolojisini benimseyin ve planlarınızı esnek tutarak en iyi sonucu elde edin! 🚀 Destination Unknown 2  Agile Roles and the Need for Training 🚀 Agile Geçişinde Roller Neden Önemlidir? Agile metodolojisine geçiş yaparken, mevcut çalışanları doğrudan yeni rollere atamak ciddi 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ı ve becerileri farklıdır. Ü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 eder. Ancak 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. ✅ Geliştiriciler✅ Test Ancak Scrum takımı çok işlevli bir ekip olmalıdır: 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. Agile Roles and the Need for Training 1  🔄 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!" Agile Roles and the Need for Training 2  Kanban and Agile Planning Tools 🏗 Kanban Panosunun Önemi Kanban panosu, iş akışlarını görselleştirmek ve ilerlemeyi takip etmek için kullanılan bir araçtır. Ancak unutulmaması gereken en önemli nokta, bir aracın sizi doğrudan çevik hale getiremeyeceğidir. 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. Bazı kişiler, Kanban panosunu Gantt şeması gibi kullanmaya çalışır. Ancak bunlar iki farklı proje yönetimi yöntemidir. 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 Bu yapıyı daha karmaşık hale getirmek mümkündür, ancak 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. Kanban and Agile Planning Tools 1  🏗 ZenHub Kanban Panosundaki Aşamalar (Pipelines) ZenHub, işleri organize etmek için farklı aşamalar (pipelines) sunar: 1️⃣ Yeni İşler (New Issues) 🆕 Yeni oluşturulan tüm görevlerin geldiği yerdir. Geliştiriciler buradaki işleri inceler ve uygun bir aşamaya taşır. 2️⃣ Beklemede (Icebox) ❄️ Uzun vadede yapılması düşünülen ancak şu an öncelikli olmayan görevler buraya alınır. 3️⃣ Ürün Backlog (Product Backlog) 📜 Tüm planlanan ancak henüz sprint’e dahil edilmemiş görevler burada tutulur. 4️⃣ Sprint Backlog ⏳ Bu sprint içinde yapılacak görevlerin listesi burada yer alır. Geliştiriciler sadece bu aşamaya odaklanır. 5️⃣ Devam Edenler (In Progress) 🔄 Aktif olarak çalışılan görevler burada bulunur. Hangi geliştiricinin hangi işi yaptığı net bir şekilde görülebilir. 6️⃣ İnceleme ve Test (Review/QA) ✅ Kodun tamamlanıp test ve kod incelemesine gönderildiği aşamadır. GitHub ile entegrasyon sayesinde, pull request’ler doğrudan buraya gelir. 7️⃣ 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. Kanban and Agile Planning Tools 2  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 📌 Bu Derste Öğrendikleriniz: 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. 💡 Öneri: Ekibiniz için en uygun Kanban panosunu oluşturun ve süreçleri sürekli olarak iyileştirin! 🚀 Kanban and Agile Planning Tools 3  Creating Good User Stories 🏗 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: 1️⃣ Rol: Hikayeyi talep eden kişi veya kullanıcı grubu kim? 2️⃣ İşlevsellik: Kullanıcının hangi işlevi gerçekleştirmesi gerekiyor? 3️⃣ İş 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. ✅ Örneğin: Creating Good User Stories 1  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. 🔍of Done) Kullanıcı Hikayelerinde Kabul Kriterleri (Definition 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. 📌Artırma INVEST İlkesi ile Kullanıcı Hikayelerinin Kalitesini 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. Creating Good User Stories 2  ✔ 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 📚 Bu Derste Öğrendikleriniz: ✅ 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. 💡 Öneri: Kullanıcı hikayelerini yazarken net, ölçülebilir ve iş değeri odaklı olmalarına dikkat edin! 🚀 Creating Good User Stories 3  Effectively Using Story Points 🏗 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. Ancak birçok kişi, bu soyutluk nedeniyle zorluk yaşar. 📌 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? Geleneksel olarak, insanlar zaman tahmini yapmada çok kötüdür. Çoğu zaman "Bu iş 30 dakika sürer" deriz ama gerçek dünya bunu doğrulamaz. Çoğu iş tahmin edilenden çok 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: 3️⃣ Küçük → 3 5️⃣ Orta → 5 Effectively Using Story Points 1  8️⃣ 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? Örneğin, 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) 🚨 1️⃣ 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! Effectively Using Story Points 2  📚 Bu Derste Öğrendikleriniz: ✅ 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! 💡 Öneri: Takım içinde ortak bir "orta büyüklük" standardı belirleyerek, daha doğru tahminler yapabilirsiniz! 🚀 Effectively Using Story Points 3  Building the Product Backlog 🏗 Ü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. 📌 Ürün Backlog’u Örneği: Sayaç Hizmeti Örneğimizde, bir sayaç hizmeti geliştiriyoruz. Kullanıcı, bir sayaç oluşturup, artırıp, toplam sayıyı sorgulayabilecek. Bu hizmetin temel gereksinimleri şunlardır: 1️⃣ Sayaç oluşturma ve artırma – Kullanıcı sayacı oluşturup artırabilmeli. 2️⃣ Birden fazla sayaç desteği – Farklı sayaçlar aynı anda kullanılabilmeli. 3️⃣ Sayaç verilerinin kalıcı olması – Sunucu yeniden başlatıldığında sayaç verileri korunmalı. Building the Product Backlog 1  4️⃣ Sayaçları sıfırlama yeteneği – Sayacı sıfırlayıp yeniden başlatabilmeliyim. 📝 Hikayelerin Yazılması Bu gereksinimler kullanıcı hikayelerine dönüştürülerek backlog’a eklenir: 🔹 Sayaç oluşturma ve artırma 📌 As a user, I need a service that has a counter so that I can keep track of how many times something has been done. 🔹 Birden fazla sayaç desteği 📌 As a user, I need to have multiple counters so that I can keep track of several counts at once. 🔹 Sayaç verilerinin kalıcı olması 📌 As a service provider, I need a service to persist the last known count so that users don’t lose track of their counts after the service is restarted. 🔹 Sayaçları sıfırlama yeteneği 📌 As an administrator, I need the ability to reset the counter so that I can redo counting from the start. Bu hikayeler backlog’a eklenerek önceliklendirilecektir. 🚀 Ü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. Örneğimizde, önceliklendirme şu şekilde olabilir: ✅ 1. Öncelik → Sayaç hizmetinin temel işlevselliği oluşturulmalı. ✅ 2. Öncelik → Veriler kalıcı olmalı. ✅ 3. Öncelik → Sayaçları sıfırlama özelliği eklenmeli. ✅ 4. Öncelik → Birden fazla sayaç desteği sağlanmalı. Ö Building the Product Backlog 2  🔍 Sonuç ve Özet 📚 Bu Derste Öğrendikleriniz: ✅ Ü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. 💡 Öneri: Sprint planlamasına başlamadan önce backlog’unuzu net bir şekilde organize ettiğinizden emin olun! 🚀 Building the Product Backlog 3  Backlog Refinement: Getting Started 🛠 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? Backlog refinement toplantısının üç temel adımı vardı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. 📅Katılmalı? Backlog Refinement Toplantısına Kimler 👤 Ü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. Tüm geliştirme ekibini dahil etmek zaman kaybına yol açabilir. Backlog Refinement: Getting Started 1  🔄 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. Bu nedenle, 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: ✅ Örnek: Backlog Refinement: Getting Started 2  "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 📚 Bu Derste Öğrendikleriniz: ✅ 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. 💡 Öneri: Backlog refinement sürecini düzenli yaparak sprint planlamasını daha verimli hale getirebilirsiniz! 🚀 Backlog Refinement: Getting Started 3  Backlog Refinement Finishing Up 🏗 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: 1. 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) 2. 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. 3. Örnek Hikaye Refinement Süreci Örnek Hikaye: "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. Backlog Refinement Finishing Up 1  Etiket: 🟦 Geliştirme (Enhancement) Örnek 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. Backlog Refinement Finishing Up 2  🚀 Sonuç ve Özet 📚 Bu Derste Öğrendikleriniz: ✅ 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. 💡 Öneri: Teknik borçları ve geliştirmeleri renk kodları ile ayırarak backlog'unuzu daha net hale getirin! 🎯 Backlog Refinement Finishing Up 3  Sprint Planning 🏗 Sprint Planlamasının Önemi Sprint planlaması, ekibin belirli bir zaman diliminde (genellikle iki hafta) neyi başarabileceğini belirlediği toplantıdır. Sprint boyunca gerçekleştirilecek işleri organize etmek, ekibin odaklanmasını sağlamak ve teslim edilecek işlerin belirli bir hedef doğrultusunda ilerlemesini sağlamak için kritik öneme sahiptir. 📌 Sprint Planlamasının 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 Sprint planlama toplantısı genellikle ürün sahibi (Product Owner), Scrum Master ve geliştirme ekibinin katılımıyla gerçekleştirilir. Sprint boyunca yapılacak işlerin belirlenmesi, ekibin kapasitesine uygun şekilde işlerin dağıtılması ve sprint’in başarıya ulaşmasını sağlamak için şu adımlar izlenir: 📌 Sprint Hedefinin Belirlenmesi Sprint planlamasının en önemli noktalarından biri sprint hedefinin belirlenmesidir. Ürün sahibi, ekibin önceliklendirilmiş backlog öğelerinden hangi hikayeleri (stories) alacağını ve sprint sonunda hangi işlerin tamamlanacağını net bir şekilde ifade etmelidir. 📌 Sprint hedefi neden önemlidir? ✅ Ekip üyelerinin sprint boyunca odaklanmasını sağlar. ✅ Projenin genel vizyonuna uygun şekilde ilerlenmesini garanti eder. ✅ Sprint sırasında alınan kararları yönlendirir. Sprint Planning 1  🛠 Sprint Planlamasının Mekaniği Sprint planlamasında ekip şu adımları izler: 📌 1. Backlog’dan İş Seçimi Ürün backlog’undan en öncelikli iş öğeleri seçilir. Takım, bu işleri sprint backlog’una taşır. 📌 2. Hikayelerin Puanlanması (Story Points) Geliştirme ekibi, backlog öğelerini değerlendirmek için story point kullanır. Eğer backlog refinement sürecinde hikayeler puanlanmadıysa, sprint planlamasında ekip bu puanları belirler. ✅ Ö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 📌 3. 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. 📌 4. 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? Sprint hızı, ekibin bir sprint içinde tamamlayabildiği toplam story point sayısını ifade eder. 📌 Velocity neden önemlidir? ✅ Ekibin gerçekçi taahhütlerde bulunmasını sağlar. ✅ Sprint planlamasında aşırı yüklenmeyi önler. ✅ Takımın hızını takip ederek gelecekteki sprint’ler için daha iyi tahminler yapılmasını sağlar. ⚠ Önemli Not: Farklı ekiplerin velocity değerleri karşılaştırılmamalıdır. Çünkü her ekip, farklı hikaye büyüklükleri kullanabilir. Bir ekibin "orta" olarak değerlendirdiği bir Sprint Planning 2  hikaye, başka bir ekip için "küçük" olabilir. 🎯Kullanımı Sprint Planlamasında Milestone (Kilometre Taşı) Sprint hedeflerini netleştirmek için milestone oluşturulabilir. 📌 Milestone 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. 🔹 Örnek Milestone Tanımı: 🎯 Sprint 1 – Tek Sayaç Uygulaması 📝 Hedef: Tek sayaç bileşenini geliştirmek ve buluta deploy etmek. 📅 Süre: 2 hafta 📌 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. 🔍 Özet ve Sonuç 📚 Bu Derste Öğrendikleriniz: ✅ 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. Sprint Planning 3  ✅ 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. 💡 Öneri: Sprint planlamasında, geçmiş sprint’lerden ders çıkararak ekibinizin tahmin doğruluğunu artırabilirsiniz! 🚀 Sprint Planning 4