Blog
Mert Özen'in yazılım geliştirme, backend, frontend ve DevOps üzerine blog yazıları.
.NET'te BDD: Reqnroll 3 ile Gherkin Senaryolarını Bookstore API'sine Bağlamak
SpecFlow 31 Aralık 2024'te sona erdi; .NET'te Gherkin senaryolarını çalıştırmanın güncel yolu Reqnroll 3 ve xUnit v3 için Reqnroll.xunit.v3 paketidir. Bookstore'un kurumsal sipariş senaryolarını .NET 10'da proje kurulumu, step definition'lar, context injection, WebApplicationFactory, hata anında teşhis yapan hook, HTML formatter ile living documentation ve tag ile filtreleme üzerinden API'ye bağlıyor; Türkçe kültürde gözlenen bir tuzağı da gösteriyoruz.
Gherkin ile Executable Specification: Given-When-Then, Rule, Scenario Outline ve Declarative Senaryo Yazmak
Gherkin, Example Mapping'de bulunan kural ve örnekleri hem stakeholder'ın okuyabileceği hem de test runner'ın çalıştırabileceği bir spesifikasyona çevirir; iyi senaryo arayüzü değil, iş kuralını anlatır. Bookstore'un kurumsal sipariş kurallarıyla Feature, Rule, Background, Scenario Outline, Examples ve data table'ı, declarative ile imperative senaryo farkını, Türkçe keyword kararını ve Gherkin anti-pattern'lerini anlatıyoruz.
Non-functional Requirement'lar: ISO/IEC 25010:2023 Quality Model'i, Ölçülebilir Hale Getirmek ve Nereye Yazılır?
Non-functional requirement, davranışın hangi kalitede olacağını söyler ve ancak ortamı, ölçüsü ve sahibiyle yazıldığında işe yarar. ISO/IEC 25010:2023'ün dokuz karakteristiğini ve 2011'den farklarını, "hızlı olsun"u veriden ve ölçümden kurulan bir quality attribute senaryosuna çevirmeyi, toplu siparişte erişilebilirlik (WCAG 2.2), KVKK, audit ve güvenlik requirement'larını ve bunların acceptance criteria, Definition of Done, ADR ve fitness function arasında nereye yazılacağını anlatıyoruz.
Acceptance Criteria ve Example Mapping: Kuralları Örneklerle Netleştirmek
Acceptance criteria bir story'nin kabul koşullarıdır ve en iyi hâli, her kuralın altında somut örneklerin durduğu hâlidir. Bookstore'un kurumsal indirim ve kısmi sevkiyat kartları üzerinden kural ve senaryo tabanlı criteria'yı, Definition of Done ve Definition of Ready farkını, dört renk kartlı Example Mapping oturumunu ve oturum sonunda story'nin hazır mı, bölünmeli mi, araştırılmalı mı olduğuna karar vermeyi anlatıyoruz.
Story Mapping ve Story Bölme: Walking Skeleton, Dikey Dilimler ve İlk Release'i Seçmek
Story map, story'leri kullanıcının akışına göre soldan sağa, önceliğe göre yukarıdan aşağıya dizerek düz backlog'un gizlediği eksikleri gösterir ve ilk release'i uçtan uca çalışan bir walking skeleton üzerine kurdurur. Bookstore'un kurumsal sipariş map'ini çiziyor, iskeleti ve release dilimlerini seçiyor, büyük story'leri kural, veri, istisna, akış, önce manuel ve spike eksenlerinde bölüyor ve katman katman bölmenin neden kötü olduğunu anlatıyoruz.
Use Case'ten User Story'ye: 3C, INVEST ve Hangi Durumda Use Case Hâlâ Daha İyi?
Use case bütünü ve dallarını gösteren haritadır, user story ise o haritadan çıkan, tek başına değer veren teslimat birimidir; her alternatif akış story olmak zorunda değildir. Bookstore'un kurumsal sipariş use case'ini yedi story'ye ve kabul koşullarına bölüyor, Jeffries'in card-conversation-confirmation üçlüsünü, "As a / I want / so that" kalıbının sınırlarını, INVEST kontrolünü, epic-story-task ayrımını ve use case'in hâlâ daha iyi olduğu durumları anlatıyoruz.
Requirement Elicitation: Görüşme, Gözlem, Workshop ve Prototiple Gerçek İhtiyacı Çıkarmak
Elicitation, hazır duran requirement'ları toplamak değil; görüşme, gözlem, doküman analizi, workshop ve prototiple söylenmeyen ihtiyaçları ortaya çıkarıp stakeholder'la teyit etmektir. Bookstore'un okul ve kütüphane toplu siparişi için stakeholder haritasını, "bana son seferi anlatın" görüşmesini, müşteri hizmetlerinde gözlemi, çelişkileri gösteren workshop'u, bir günlük Angular prototipini ve çıktı olarak glossary ile açık soru listesini anlatıyoruz.
Requirement Nedir ve Neden Yanlış Anlaşılır? Türler, İyi Requirement'ın Özellikleri ve Problem ile Çözümü Ayırmak
Requirement bir ekran değil, bir ihtiyacı ona bağlı kısıt ve koşullarla birlikte ifade eden bir cümledir. Bookstore'un okul ve kütüphane toplu sipariş özelliği üzerinden business, stakeholder, functional, non-functional, constraint ve transition seviyelerini, ISO/IEC/IEEE 29148'deki iyi requirement niteliklerini, belirsiz kelime avını ve "Excel'den yükleme ekranı" gibi bir çözüm cümlesinin arkasındaki problemi bulmayı anlatıyoruz.
Tahmini İletmek ve Plan Kaydığında: Güncelleme, Kötü Haberi Erken Vermek ve Yeniden Planlamak
Plan kaydığında yapılacak ilk şey, kötü haberi seçenekleriyle birlikte hemen vermek; karar kapsam, tarih ya da kişi ekleme arasında iş tarafınındır ve geç kalmış projeye kişi eklemek çoğu zaman tarihi kurtarmaz. Bookstore'un üç sprint sonraki güncellemesi, kapsamın 142 point'e büyüdüğünü ve tam kapsamın 26 Mart'a kaydığını gösteriyor; C# koduyla seçenekleri hesaplayıp tek sayfalık tahmin notunu yazıyoruz.
Yazılım Projesinde Risk Yönetimi: Pre-mortem, Risk Register, Olasılık × Etki ve Riski Erken Azaltmak
Riski yönetmek, onu pre-mortem ile erken görünür kılmak, olasılık × etki ile buffer'la karşılaştırmak ve en riskli işi planın başına almaktır. Bookstore'un Kurumsal Sipariş register'ında toplam exposure 21,6 gün çıkıyor ve kapsam buffer'ını aşıyor; ERP spike'ı ve eşli çalışma ile üç sprint'te 4,9 güne iniyor. ROAM, risk burndown ve risk ile issue farkını C# koduyla görüyoruz.
Release Planning: Aralıklı Velocity, Burn-up, Sabit Tarih mi Sabit Kapsam mı?
Release tarihi tek bir velocity ortalamasından değil, geçmiş sprint'lerden çıkan bir aralıktan verilir; tarih sabitse kapsam MoSCoW katmanlarıyla esnetilir. Bookstore'un 130 point'lik Kurumsal Sipariş planı 12 Şubat ile 12 Mart arasına düşüyor; 1 Mart'ta Must kapsamı kötü senaryoda bile sığıyor. Aynı soruyu Monte Carlo ile de cevaplayıp iki yöntemin neden farklı sonuç verdiğini görüyoruz.
Point Dışında Tahmin Yöntemleri: Three-point/PERT, Wideband Delphi, Work Breakdown ve Reference Class Forecasting
Belirsiz bir işi tahmin etmek için işi parçalara böl, her parçaya üç nokta ver, toplamı tek tek toplamak yerine simüle et ve sonucu benzer geçmiş işlerin sapmasıyla dışarıdan kontrol et. Bookstore'un toplu sipariş dilimi için C# simülasyonu, en olası sürelerin toplamının (21 gün) yalnızca %3,1 ihtimalle tuttuğunu, %85 değerin 28 gün, geçmiş epic'lere göre düzeltilmiş değerin 34 gün olduğunu gösteriyor.