YAZILIM GELİŞTİRME YAŞAM DÖNGÜSÜ MODELLERİ
Yazılımın hem üretim süreci, hem de kullanım süreci boyunca, geçirdiği tüm aşamalara “Yazılım Geliştirme Yaşam Döngüsü” denir. Yazılımın fonksiyonları ile ilgili ihtiyaçlar sürekli olarak değiştiği ve genişlediği için, söz konusu adımlar devamlı bir döngü biçiminde ele alınmaktadır. Döngü içerisinde herhangi bir adımda geriye dönmek ve yeniden ilerlemek mümkündür. Yazılım yaşam döngüsü ne tek yönlü ne de doğrusaldır.
-YAZILIM YAŞAM DÖNGÜSÜ TEMEL ADIMLARI-
Planlama: Personel ve donanım ihtiyaçlarının çıkarıldığı, fizibilite(yapılabilirlik) çalışmasının yapıldığı ve proje planının oluşturulduğu adımdır.
Analiz: Sistem ihtiyaçlarının ve fonksiyonlarının detaylı olarak çıkarıldığı adım ve bunun sonucunda bunları belirli bir formatta belgelemektir. Bu çalışma müşteri, yazılım mühendisi, iş analisti, sistem analisti, ürün yöneticisi vb. rollerin bir araya geldiği ekipler aracılığıyla yapılabilir. İhtiyaçların net olmadığı durumlarda yazılım mühendisi ve müşteri arasında iletişim ve birlikte çalışmanın çok daha fazla olması gerekir. Çeşitli yazılım geliştirme yöntem biliminde bu adımda kullanım belgeleri ve test plan belgeleri de oluşturulabilir. Var olan işler incelenir, temel problemler oluşturulur.
Tasarım: İhtiyaçların tamamlanmasıyla birlikte sistem tasarım adımına başlanır. Yazılım ürün tasarımı, müşterinin ihtiyaç ve arzularını karşılamak üzere yazılım ürününün özellikleri, kabiliyetlerini ve ara yüzlerinin belirlenmesi faaliyetidir. İki çeşit tasarımdan bahsedilebilir. Yüksek Seviyede tasarım — — Mimari tasarım ve Ayrıntılı tasarım). Mimari tasarım, yazılım parçalarının genel yapıları ve organizasyon içerisindeki etkileşimleri ile ilgilenir. Sonucunda mimari tasarım belgeleri oluşturulur. Ayrıntılı tasarım adımında Mimari tasarım belgeleri genelde yenilenirler. Tasarım ve çözümleme adımlarının ayrımı “Problem Nedir- Nasıl Çözülür?” sorularının kullanımı ile ilgilidir. İhtiyaçların belirlendiği analiz adımı problemin ne olduğu ile ilgilidir. Unutmamak gerekir ki sistemdeki tüm problemler yazılım ürününün tamamlanması ile çözülmeyecektir. Maalesef çoğu zaman Ne söylemi tasarım kararı olurken Nasıl söylemi de müşterinin ihtiyacı olabilmektedir. Buna dikkat etmek gerekir. Yazılım tasarımında kullanılan en önemli tekniklerden birisi Soyutlama (Abstraction)’dır. Soyutlama, problemlerin çözümlerini kolaylaştırmak için nesnelerin, olayların ve durumların bazı özelliklerin görmezden gelinmesidir. Problemi kolaylaştırarak en önemli noktalarına odaklanmamızı sağlar. Modelleme ise temel tasarım aracı olup statik ve dinamik modellerden bahsedilebilir. Statik model, programın çalışma anında değişmeyen yönlerini ifade etmek için kullanılırken (sınıf ve nesne modelleri), dinamik model programın çalışma anındaki işleyişi anlatmak için kullanılır ( durum ve sıra diyagramları).
Gerçekleştirim: Tasarım adımının belirli bir olgunluğa ulaşması ile Kodlama adımı başlar. Müşteriye teslim edilecek ürünü programlama adımıdır. İyi kod, okunabilirliği ve bakımı kolay olan basit koddur. KISS (Keep It Simple) ilkesine göre yeni mezun olmuş birisine kod verildiğinde 1–2 gün içerisinde anlayabiliyor ve değiştirebiliyorsa kod iyi bir koddur. İster bir şirkette çalışılsın ister bireysel projeler geliştirilsin mutlaka belirli bir “kodlama kalite standardı” olmalıdır (İsimlendirme standartları, yorum satırı kullanımları, tekrar eden kodlar, dev –if koşul blokları, aşırı benzer işlevler, uzun metotlar vb.) Kodlama boyunca ve kodlama sonrasında yapılan diğer önemli adım testtir. Erken test et yaklaşımı ile (Early Testing) hareket edilip, analiz aşamasıyla test bakış açısına sahip olunursa hata yapma ihtimali ve maliyetler (zaman, para, saygınlık vb.) azalacaktır. Birim testleri, duman testleri, yanlış değer testleri, kabul testleri, kullanım senaryo testleri, yük testleri, kullanıcı kabul testi, yoldan geçen adam testi, test otomasyonu gibi sürece ve duruma göre uygulanabilecek çok farklı kategoride ve derinlikte test türü bulunmaktadır.
Test Bakım: Tüm test adımları bittikten sonra yazılım ürünün sahaya teslim edilebilir bir versiyonu çıkartılır ve teslim aşaması gerçekleştirilir. Teslim çıktısı olarak ürün tek başına yeterli değildir. Mutlaka son kullanıcılar için kullanım rehberi ve sürüm fark belgesi oluşturulmalıdır. Teslim ile birlikte bakım aşaması da başlar. Hata giderici, önleyici, altyapıyı iyileştirici, ürüne yeni özellikler ekletici gibi farklı bakım çalışmaları bulunmaktadır. Yaşam döngüsünün temel adımları çekirdek süreçler (Core Processes) olarak da adlandırılmaktadır. Bu süreçlerin gerçekleştirilmesi maksadıyla Yazılım Belirtim Yöntemleri ve Yazılım Süreç Modelleri kullanılmaktadır.
Belirtim Yöntemleri: Süreç Akışı İçin Kullanılan Belirtim Yöntemleri: Süreçler arası ilişkilerin ve iletişimin gösterildiği yöntemler (Veri Akış Şemaları, Yapısal Şemalar, Nesne/Sınıf Şemaları).
Süreç Tanımlama Yöntemleri Süreçlerin iç işleyişini göstermek için kullanılan yöntemler (Düz Metin, Algoritma, Karar Tabloları, Karar Ağaçları, Anlatım Dili). Veri Tanımlama Yöntemleri Süreçler tarafından kullanılan verilerin tanımlanması için kullanılan yöntemler :(Nesne İlişki Modeli, Veri Tabanı Tabloları, Veri Sözlüğü).
-YAZILIM SÜRECİ MODELLERİ-
Yazılım üretim işinin genel yapılma düzenine ilişkin rehberlerdir. Süreçlere ilişkin ayrıntılarla ya da süreçler arası ilişkilerle ilgilememektedirler:
Gelişigüzel Model, Barok Modeli, Çağlayan (Şelale) Modeli, V Modeli, Helezonik (Spiral) Model, Evrimsel Model, Artırımsal Model, Araştırma Tabanlı Model
Gelişigüzel Model: Herhangi bir model ya da yöntem yok. Geliştiren kişiye bağımlı (belli bir süre sonra o kişi bile sistemi anlayamaz ve geliştirme güçlüğü yaşar). İzlenebilirliği ve bakımı oldukça zordur. 60’lı yıllarda. Genellikle tek kişilik üretim ortamı bulunur. Basit bir programlama yöntemidir.
Barok Modeli: Yaşam döngüsü temel adımlarının doğrusal bir şekilde geliştirildiği modeldir. 70’li yıllarda uygulanmıştır. Belgelemeyi ayrı bir süreç olarak ele alır ve yazılımın geliştirilmesi ve testinden hemen ardından yapılmasının öngörür. Hal bu ki, günümüzde belgeleme yapılan işin doğal bir ürünü olarak görülmektedir. Aşamalar arası geri dönüşlerin ise nasıl yapılacağı tanımlı değildir. Gerçekleştirim aşamasına daha fazla ağırlık veren bir model olup, günümüzde kullanımı önerilmemektedir.
Çağlayan (Şelale) Modeli: (Sırasıyla): Gereksinimlerin Tanımlanması, Sistem ve Yazılım Tasarımı, Kodlama ve Modül test etme, Birleştirme ve Sistemi test etme, Sistemin Bakım ve İdamesi
Yaşam döngüsü temel adımları baştan sona en az bir kez izleyerek gerçekleştirilir. İyi tanımlı projeler ve üretimi az zaman gerektiren yazılım projeleri için uygun bir modeldir. Geleneksel model olarak da bilinen bu modelin kullanımı günümüzde giderek azalmaktadır. Barok modelin aksine belgeleme işlevini ayrı bir aşama olarak ele almaz ve üretimin doğal bir parçası olarak görür. Barok modele göre geri dönüşler iyi tanımlanmıştır. Yazılım tanımlamada belirsizlik yok (ya da az) ise ve yazılım üretimi çok zaman almayacak ise uygun bir süreç modelidir.
Sorunları: Gerçek yaşamdaki projeler genelde yineleme gerektirir. Genelde yazılımın kullanıcıya ulaşma zamanı uzundur. Gereksinim tanımlamaları çoğu kez net bir şekilde yapılamadığından dolayı, yanlışların düzeltilme ve eksiklerin giderilme maliyetleri yüksektir. Yazılım üretim ekipleri bir an önce program yazma, çalıştırma ve sonucu görme eğiliminde olduklarından, bu model ile yapılan üretimlerde ekip mutsuzlaşmakta ve kod yazma dışında kalan (ve iş yükünün %80’ini içeren) kesime önem vermemektedirler. Üst düzey yönetimlerin ürünü görme süresinin uzun oluşu, projenin bitmeyeceği ve sürekli gider merkezi haline geldiği düşüncesini yaygınlaştırmaktadır.
V Süreç Modeli: Gereksinimler, Sistem Tanımları, Sistem, Altsistem, Modül veya Sınanmış Modül, Sınanmış Altsistem, Sınanmış Sistem, Bitmiş Sistem, Sistem (Sol taraf üretim, sağ taraf sınama işlemleridir.)
V süreç modelinin temel çıktıları; Kullanıcı Modeli: Geliştirme sürecinin kullanıcı ile olan ilişkileri tanımlanmakta ve sistemin nasıl kabul edileceğine ilişkin sınama belirtimleri ve planları ortaya çıkarılmaktadır. Mimari Model Sistem tasarımı ve oluşacak alt sistem ile tüm sistemin sınama işlemlerine ilişkin işlevlerdir. Gerçekleştirim Modeli Yazılım modüllerinin kodlanması ve sınanmasına ilişkin fonksiyonlardır.
Belirsizliklerin az, iş tanımlarının belirgin olduğu BT projeleri için uygun bir modeldir. Model, kullanıcının projeye katkısını arttırmaktadır. BT projesinin iki aşamalı olarak ihale edilmesi için oldukça uygundur: İlk ihalede kullanıcı modeli hedeflenerek, iş analizi ve kabul sınamalarının tanımları yapılmakta, ikinci ihalede ise ilkinde elde edilmiş olan kullanıcı modeli tasarlanıp, gerçekleşmektedir.
Helezonik Model: Planlama Üretilecek ara ürün için planlama, amaç belirleme, bir önceki adımda üretilen ara ürün ile bütünleştirmedir Risk Analizi Risk seçeneklerinin araştırılması ve risklerin belirlenmesidir. Üretim Ara ürünün üretilmesi Kullanıcı Değerlendirmesi Ara ürün ile ilgili olarak kullanıcı tarafından yapılan sınama ve değerlendirmelerdir.
Helezonik Modelin Avantajları: Kullanıcı Katkısı Üretim süreci boyunca ara ürün üretme ve üretilen ara ürünün kullanıcı tarafından sınanması temeline dayanır. Yazılımı kullanacak personelin sürece erken katılması ileride oluşabilecek istenmeyen durumları engeller. Yönetici Bakışı Gerek proje sahibi, gerekse yüklenici tarafındaki yöneticiler, çalışan yazılımlarla proje boyunca karşılaştıkları için daha kolay izleme ve hak ediş planlaması yapılır. Yazılım Geliştirici (Mühendis) Bakışı Yazılımın kodlanması ve sınanması daha erken başlar.
Risk Analizi Olgusu ön plana çıkmıştır. Her döngü bir fazı ifade etmektedir. Doğrudan tanımlama, tasarım,… vs gibi bir faz yoktur. Yinelemeli artımsal bir yaklaşım vardır. Prototip yaklaşımı vardır.
Evrimsel Geliştirme Süreç Modeli: İlk tam ölçekli modeldir. Coğrafik olarak geniş alana yayılmış, çok birimli organizasyonlar için önerilmektedir (banka uygulamaları). Her aşamada üretilen ürünler, üretildikleri alan için tam işlevselliği içermektedirler. Pilot uygulama kullan, test et, güncelle diğer birimlere taşır. Modelin başarısı ilk evrimin başarısına bağımlıdır.
Örnek: Çok birimli banka uygulamaları, Önce sistem geliştirilir ve Şube-1’e yüklenir. Daha sonra aksaklıklar giderilerek geliştirilen sistem Şube-2’ye yüklenir. Daha sonra geliştirilen sistem Şube-3’e,…. yüklenir. Belirli aralıklarla eski şubelerdeki güncellemeler yapılır.
Aksaklığı: Değişiklik denetimi ve Konfigürasyon Yönetimidir; Sürüm Yönetimi, Değişiklik Yönetimi, Kalite Yönetimi
Artırımsal Geliştirme Süreç Modeli: Üretilen her yazılım sürümü birbirini kapsayacak ve giderek artan sayıda işlev içerecek şekilde geliştirilir. Öğrencilerin bir dönem boyunca geliştirmeleri gereken bir programlama ödevinin 2 haftada bir gelişiminin izlenmesi (bitirme tezleri). Uzun zaman alabilecek ve sistemin eksik işlevlikle çalışabileceği türdeki projeler bu modele uygun olabilir. Bir taraftan kullanım, diğer taraftan üretim yapılır.
Araştırma Tabanlı Süreç Modeli: Yap-at modeli olarak da bilinir. Araştırma ortamları bütünüyle belirsizlik üzerine çalışan ortamlardır. Yapılan işlerden edinilecek sonuçlar belirgin değildir. Geliştirilen yazılımlar genellikle sınırlı sayıda kullanılır ve kullanım bittikten sonra işe yaramaz hale gelir ve atılır. Model-zaman-fiyat kestirimi olmadığı için sabit fiyat sözleşmelerinde uygun değildir.
Örnek: En Hızlı Çalışan asal sayı test programı, En Büyük asal sayıyı bulma programı, Satranç programı..
-Metodolojiler-
Metodoloji: Bir BT projesi ya da yazılım yaşam döngüsü aşamaları boyunca kullanılacak ve birbirleriyle uyumlu yöntemler bütünüdür. Bir metodoloji, bir süreç modelini ve belirli sayıda belirtim yöntemini içerir. Günümüzdeki metodolojiler genelde Çağlayan ya da Helezonik modeli temel almaktadır.
Bir Metodolojide Bulunması Gereken Temel Bileşenler (Özellikler): Ayrıntılandırılmış bir süreç modeli, ayrıntılı süreç tanımları, iyi tanımlı üretim yöntemleri, süreçlerarası arayüz tanımları, ayrıntılı girdi tanımları, ayrıntılı çıktı tanımları, proje yönetim modeli, konfigürasyon yönetim modeli, maliyet yönetim modeli, kalite yönetim modeli, risk yönetim modeli, değişiklik yönetim modeli, kullanıcı arayüz ve ilişki, model standartlar.
Metodoloji bileşenleri ile ilgili olarak bağımsız kuruluş (IEEE, ISO, vs.) ve kişiler tarafından geliştirilmiş çeşitli standartlar ve rehberler mevcuttur. Kullanılan süreç modelleri ve belirtim yöntemleri zaman içinde değiştiği için standart ve rehberler de sürekli güncellenmektedir. Bir kuruluşun kendi metodolojisini geliştirmesi oldukça kapsamlı, zaman alıcı ve uzmanlık gerektiren bir faaliyet olup, istatistikler yaklaşık 50 kişi/ay’lık bir iş gücü gerektirdiğini göstermektedir.
Örnek: Yourdon Yapısal Sistem Tasarımı Metodolojisi. Kolay uygulanabilir bir model olup, günümüzde oldukça yaygın olarak kullanılmaktadır. Çağlayan modelini temel almaktadır. Bir çok CASE aracı tarafından doğrudan desteklenmektedir.
- 7 Maddede Scrum Framework (Scrum Çatısı) Nedir, Nasıl Uygulanır?-
Scrum: Scrum Rehberi’ndeki Scrum tanımlaması ile hızlı bir giriş yapalım: “İnsanların mümkün olan en yüksek değere sahip ürünleri üretken ve yaratıcı bir şekilde geliştirirken, karmaşık ve adaptasyona açık sorunları ele alabildikleri bir çerçevedir”.
Bu tanım gayet kapsayıcı olmakla birlikte, büyük resimdeki pozisyonel durumu tam kavrayabilmek için ilk akla gelen Agile (Çeviklik) ve Scrum ilişkisi. Scrum, bir Agile uygulamasıdır, fakat tıpkı Agile gibi kendi de bir çatıdır. Süreç yönetim çatısı olan Scrum’da belirlenmiş kurallar, roller, etkinlikler ve eserler (artifacts) bulunmaktadır. Tüm bunlara uyum zorunludur. Aksi halde uygulanan Scrum olmaz, hatta yanlış uyarlamalar için ScrumBut (Scrum, Ama..) denmektedir. Scrum basit, anlaması kolay ve uygulaması zor bir çatıdır. 1990’ların başından beri kullanılmakta ve hatrı sayılır seviyede gün geçtikçe popüleritesi artmaktadır. Scrum, ilk bakışta çok basit kuralları olan bir yönetimsel modeldir. Gereksinimleri açıkça belirli olmayan, değişime açık, karmaşık yazılım projelerinin yönetimi için uygulanmaktadır. Scrum, detaylı bir şekilde projede izlenmesi gereken adımları belirtmemekte, onun yerine basit ama önemli birkaç olmazsa olmaz kuralıyla esnek bir yönetim sunmaktadır.
Scrum’ın sunmakta olduğu en önemli çıktı sürecin şeffaf bir şekle getirilerek süreç içerisinde aksayan noktaların açığa vurulmasıdır. Scrum böylelikle proje ekibini ortaya çıkan aksaklıkları çözümleyerek sürekli iyileştirme yapması yönünde motive eder.
Scrum Teorisi: Transparency (Şeffaflık), Inspection (Denetim) ve Adaptation (Uyum), Scrum’ın temelleridir.
Scrum’daki kurallar kümesi bir bakışta oldukça mekanik ve sanki bir metodolojiymiş gibi adım adım uyulması gereken bir liste hissi yaratsa da, teoriye baktığımız zaman bu sadece basit bir çerçevedir/çatıdır.
Bu çerçeve içerisinde aslında istenen deneysel davranıştır. Scrum’ın temelinde deneycilik (empiricism) vardır. Sürekli kontrol sağlanabilmesi, özellikle de risklerin kontrol altında tutulabilmesi için artımlı (incremental) bir yaklaşım kullanılır. Bu artımı sağlayan iterasyonlara sprint denir.
Scrum teorisini destekleyen üç temel ayak: Şeffaflık, denetim ve uyumdur. Şeffaflık adından da anlaşılacağı üzere ortak bir dil kullanımı ve hatta anlayışı, görünürlüğü esas almaktır, denetim ve uyum içinse Scrum etkinlikleri zorunlu kılınır. Bu etkinlikler: Günlük Scrum, Sprint Planlama, Sprint Değerlendirme ve Sprint Retrospektifi’dir.
Scrum Değerleri: OPENESS, COURAGE, RESPECT, FOCUS, COMMITMENT (SCRUM). Scrum’ı Scrum yapan Scrum Teorisi’nin üç temel ayağı olan şeffaflık, gözlem ve adaptasyonun vücud bulmasını ve takım içerisinde güven ortamını yaratmasını Scrum değerleri üzerinden sağlamak esastır. içselleştirilmesi gereken beş temel değer: taahhüt, cesaret, odak, açıklık ve saygıdır. Bu değerler sağlanıp, korunduğunda gözle görülür bir ekip ruhuyla birlikte başarılı bir scrum uygulaması sağlanmış olur.
Birbirine karşı açık, saygılı davranan ve ortak bir hedefe tek bir canlı organizmasıymışçasına odaklanabilen, verilen sözlerin/taahhütlerin adeta yazılı bir anlaşma gibi önemsendiği ve bu zeminde deneme cesaretini içinde barından Kaizen kültürünü benimseyip kendini geliştirebilen bir Scrum Takımı; benimsenmiş Scrum Teorisi ve değerlerinin olası sonucudur.
Scrum Takımı: Scrum Takımı, Scrum Master, Ürün Sahibi ve Geliştirme Takımı’ndan oluşur. Scrum Takımının hizmetkar lideri olan Scrum Master’ı 5 Maddede Scrum Master Kimdir ve Ne Yapar? listemizde epeyce detaylı anlatıyoruz.
Ürün sahibi, aslında mini ceo rolündedir. Ürünün vizyonu ve amacını belirlemek/yönlendirmek, yapılacak işleri derlemek, işlerin öncelik sırasını ve değerini belirlemek, işleri geliştirme takımına anlaşılır seviyede aktarmak ve ürün değerini maximum seviyeye ulaştırabilmek gibi sorumlulukları vardır. Geliştirme takımı ise en az üç, en fazla dokuz kişiden oluşan, kendi kendini yönetebilen, çapraz fonksiyonlu (cross-functional), yani geliştirilen ürünün her hangi bir parçasını yapmak için gerekli tüm beceri ve yetenekleri bünyesinde barındıran, her bir bireyin sadece ‘geliştirici’ olarak adledildiği ve asla alt takım ve rollere (testçi, analist) izin vermeyen, scrum değerlerine sadık ve her bir iterasyon (sprint) sonunda artım üretmekle yükümlü olan takımdır.
Scrum Etkinlikleri: Scrum’ın zorunu kıldığı ve Sprint (iterasyon) içerisinde gerçekleşen dört etkinlik bulunmaktadır. Tüm bu etkinlikler gözlem ve adaptasyon için resmi birer fırsat niteliğindedir ve muhakkak belirli bir zaman kısıtına sahiptir.
Scrum takımının potansiyel olarak hayata geçirilebilir şekilde ve takım tarafından belirlenmiş ‘bitti’ tanımına uygun olarak ürettiği artımla sonuçlanan Sprint, Scrum’ın kalbi olarak ifade edilmektedir.
Sprint, Sprint Planlama etkinliği ile başlar, planlama süresi 1 aylık bir sprint için 8 saatle kısıtlandırılmıştır. Etkinlik, ne ve nasıl olmak üzere iki soruya cevap arar. Takım tarafından ürün için ne yapılacağı belirlendikten sonra nasıl yapılacağının planlanmasıyla etkinlik sona erer. Sprint’in amacı belirlenmiştir.
Scrum Takımı her sabah, zamanı 15 dakika olan Günlük Scrum etkinliğinde, Sprint amacına doğru koşarken neler yaptıklarını, neler yapacaklarını ve varsa karşılaştıkları engelleri birbirleriyle paylaşır, günlerini planlanlar.
Sprint sonunda, üretilen artımın sunulduğu Sprint Değerlendirme etkinliği yer almaktadır. Bu etkinlikte Scrum takımı ve paydaşlar bir araya gelir, geliştirme takımının yaptığı artırım kontrol edilir, geliştirme takımı ‘bitti’ dediği işi gösterir ve sorulara cevap verir, yaşadığı geliştirme sürecini anlatır, ürün sahibi işlerin ‘bitti’ olup olmadığını açıklar ve gerekiyorsa iş listesi güncellenir. Bu toplantının süresi 1 aylık sprint için en fazla dört saat olarak belirlenmiştir.
Sprint Değerlendirmenin peşi sıra son etkinlik olan Sprint Retrospektif etkinliği yapılır. Sprint Retrospektif takımın en özel etkinliğidir. Sadece Scrum takımı katılır ve 1 aylık bir Sprint için süresi üç saatle kısıtlanmıştır. Bu etkinlikte Scrum Takımı, insanlar, ilişkiler, süreçler ve araçlar üzerinden kendini inceler, denetler, gözlemler. Nelerin iyi yapıldığını, nelerin daha iyi yapılabileceğini tartışır ve iyileştirilebilecek maddeleri belirleyip bir aksiyon planı hazırlar. İyileşmek ve gelişmek için belirlenmiş bu maddelerden en az bir tanesi yeni başlayacak Sprint’in iş listesine eklenir.
Scrum Eserleri: Ürün İş Listesi (Product Backlog), Sprint İş Listesi (Sprint Backlog), Artım/Ürün Parçası (Increment) olmak üzere üç Scrum Eser’i (Scrum Artifacts) bulunmaktadır.
Ürün İş Listesi, ürünle ilgili ihtiyaç duyulan her şeyin listelendiği, herkes tarafından görülebilen, şeffaf ve Ürün Sahibi tarafından yönetilen bir listedir. İşlerin önem ve değerine göre sıralanmıştır. Aynı zamanda işle ilgili tahmini ağırlıklar da bu liste üzerinden görülebilir. Bu tahminler Geliştirme Takımı tarafından yapılır, ağırlıkların belirlenmesinde son söz her zaman geliştirme takımınındır. Üst sıralarda yer alan işler genellikle daha detaylıdır. Bu detaylar geliştirme takımının kapasitesinin %10’ununu aşmayacak şekilde düzenlenmesi gereken Ürün İş Listesi İyileştirme (Product Backlog Refinement) etkinliği sayesinde daha da anlaşılır hale gelir.
Sprint Planlama Etkinliği’nde en üst sıradan başlayarak işler incelenir, tahminler yapılır ve sprint süre zarfında hangi işlerin yapılacağı Ürün Sahibi ile anlaşarak Geliştirme Takımı tarafından seçilir ve yapılması taahhüt edilen bu görece küçük listeye de Sprint İş Listesi denir.
Sprint İş Listesi, Geliştirme Takımı tarafından yönetilir ve sprint için ‘bitti’ tanımına göre yapılması planlanan ürün parçasının yapılabilmesi için gerekli daha detaylı ve öngörülmüş bir plan olarak karşımıza çıkmaktadır. Sprint hedefine ulaşabilmek için izlenecek yol şeffaf bir şekilde herkes tarafından görünür halde olmalıdır. Ürün Parçası/artım dediğimiz Scrum Eseri, Sprint’in doğal sonucudur, önceden üretilmiş tüm ürün parçacıkları ve son sprint sonunda üretilen ürün parçacığının toplamıdır. Ürün Sahibi hayata geçirmek istesin/istemesin kesinlikle ‘bitti’ tanımına uygun olmak zorundadır.
Bitti Tanımı (Definition of Done): Bitti tanımı tüm Scrum Takımı için tek bir anlam ifade etmelidir, ortak dil kullanımı ortaya çıkacak ürün parçacığını planlarken bir rehber niteliğindedir. Bir iş için bitti dendiği anda, Scrum Takımı’na dahil olan herkes aynı şeyi anlamalıdır.
Farklı Scrum Takım’larının birbirinden farklı ‘bitti’ tanımı olabilir. Tanım takım tarafından belirlenir. Takım için asgari standardı ifade eder. Herkes için ortak bir referans noktası oluşmasını sağlar. Scrum Takımı olgunlaştıkça ‘bitti’ tanımının gelişmesi beklenir. Daha yüksek kalite standartlarının dahil edildiği bir ‘bitti’ tanımı her Scrum Takım’ı için elbette ortak bir hedeftir.
