Yazılım Yaşam Döngü Modelleri

Global düzenin artık bir parçası haline gelen yazılım sektörünün günümüzde olağanüstü gelişimiyle birlikte bir yazılım ürününün nasıl yapılması gerektiği de büyük önem taşıyor. Bu noktada karşımıza yazılım yaşam-döngü modelleri çıkmakta.

Yazılım yaşam döngüsü (Software Development Life-Cycle), yazılım endüstrisi tarafından yüksek kaliteli yazılımları tasarlamak, geliştirmek ve test etmek için kullanılan bir süreçtir. Planlama, gereksinim analizi, tasarım, kodlama ve test, teslim ve bakım aşamalarından oluşmaktadır. Genel anlamda müşteri beklentilerini karşılayan, zaman ve maliyet tahminleri içinde tamamlanmaya ulaşan bir yazılım üretmeyi amaçlamaktadır.
Bir yazılım yaşam-döngü modeli, planlamadan bakıma kadar bir yazılım geliştirme projesindeki tüm faaliyetleri içeren, farklı yöntem ve özelliklerle oluşturulan bir prototiptir. Günümüzde kullanımda olan 50’den fazla model vardır. En yaygın olanları incelediğimizde hepsi eşit derecede önemli olan aynı temel adımlardan oluşup her biri belirli ekipler veya projeler için daha iyi çalışacak şekilde ayarlanabilir. Günümüzde kullanılabilirliğini yitirmiş ancak geçmişte kullanılmış modeller de mevcuttur. Gelişigüzel model ve Barok modeli bunlara örnek verilebilir. Kısaca açıklayacak olursak,
o Gelişigüzel Model: Kullanılan bir yöntem veya model yoktur. Genellikle karmaşık olmayan yazılım sistemleri içerir ve kişinin tek başına üretim yaptığı modeldir. 1960’larda uygulanmıştır. İzlenebilirliği ve bakım yapılabilirliği düşük olduğundan günümüzde sık tercih edilen modeller arasında yer almamaktadır.
o Barok Modeli: 1970’lerde ortaya çıkmıştır. Yazılım yaşam döngüsü temel aşamalarının doğrusal bir şekilde uygulandığı modeldir. Adımlar arasında geri dönüşlerin nasıl yapılacağı tanımlı değildir. Belgeleme ayrı bir süreç olarak ele alınır ve yazılımın geliştirilmesi ve testinden hemen sonra yapılır.
Günümüzde hala kullanımda olan modellerden ilk akla gelenleri Çağlayan (Waterfall) Yaşam-Döngü Modeli, V Süreç Modeli, Helezonik (Spiral) Model, Artımsal (Incremental) Geliştirme Süreç Modeli, Kodla ve Düzelt Yaşam-Döngü Modeli ve bugün en popüler yazılım geliştirme metodolojileri olarak kabul edebileceğimiz Çevik (Agile) Yazılım Geliştirme Yöntemleri şeklinde sıralayabiliriz.

1. ÇAĞLAYAN (WATERFALL) YAŞAM-DÖNGÜ MODELİ

Geleneksel yazılım geliştirme modeli olarak da bilinen en eski, tanınmış ve en temel yaşam döngü modelidir. Doğrusal ve sıralı bir yaklaşıma sahiptir. Çağlayan olarak adlandırılır çünkü model sistematik olarak bir aşamadan diğerine aşağı doğru gelişir. Fazlara bölünmüştür ve bir fazın çıktısı bir sonrakinin girdisi olacak şekilde ilerler. Bu yüzden her adım bir sonraki adım başlamadan tamamlanmalıdır. Adımlar birbiriyle çakışmaz.
Barok modelinden farklı olarak belgeleme süreç içerisindedir. Her aşama için bir doküman yazılmalıdır. Eğer bir aşamada dokümantasyon yoksa tamamlanmamıştır ve bir sonraki aşamaya geçilemez. Aynı zamanda bu modelde safhalar arasındaki geri dönüşlerin nasıl olacağı da tanımlıdır.
Kullanıcı ve sistem gereksinimleri başlangıç safhasında doğru ve temiz bir şekilde belirlenmelidir. Bu analiz aşamasında tüm ayrıntıların olabildiğince tasarım aşamasına aktarılabilmesi için önemlidir. Tasarım tüm gereksinimleri karşılayacak şekilde yapılmalıdır. Bu iki aşamada harcanan efor ve zamana rağmen her yazılım geliştirme sürecinde olduğu gibi gereksinimler değişecektir. İlerleyen aşamalarda oluşan bu değişikliği sürece yansıtmak hem vakit kaybettirecek hem de ürünün maliyetini yükseltecektir.
Kullanım kolaylığı, basit ve anlaşılır olması, her aşamanın belli çıktıları ve inceleme süreci olduğundan yönetimin kolay olması ve açıkça tanımlanmış aşamalar gereksinimlerin çok net olduğu küçük projeler için iyidir ancak fazla düşünmeye veya gözden geçirmeye izin vermeyen süreç, karmaşık ve nesneye yönelik projeler için önerilmez.
Çağlayan modeli geçmişte en popüler yazılım geliştirme modeli olarak görülse de günümüz yazılımcıları bir an önce kodlama ve çalıştırma eğiliminde olduklarından kodlamanın bu kadar küçük bir kısımda kullanıldığı bir model ekibi psikolojik açıdan yorar. Ayrıca geri dönüşlerle birlikte sürecin uzaması yöneticilerde finansal kayıp endişesi de oluşturmaktadır.
2. V SÜREÇ MODELİ
Çağlayan modelinin bir uzantısı olarak düşünülebilir. Ancak bu yöntemde süreç doğrusal bir şekilde ilerlemek yerine üretim tamamlandıktan sonra sınama aşamasına sağ taraftan yukarı olacak şekilde devam eder. Bu süreç kullanıcı modeli, mimari model, gerçekleştirim modeli olarak 3 fazdan oluşur.
· Kullanıcı Modeli: Geliştirme sürecinde kullanıcı ile ilişkilerin yer aldığı kısımdır. Üretim için kullanıcı gereksinimleri tanımlanır ve bu sayede sistemin nasıl test edileceği ya da kabul edileceğine dair planlamalar yapılır.
· Mimari Model: Sistem, alt sistemin tasarım ve sınamasını içerir.
· Gerçekleştirim Modeli: Sistemin kodlanması ve test edilmesinin bulunduğu fazdır.
V Modeli çağlayan modelde olduğu gibi kullanımı kolaydır. Yaşam döngüsünün başlarında test planlarının geliştirilmesi nedeniyle çağlayan modeline göre daha yüksek başarı şansı sağlar. Yazılımın kalitesini ve güvenilirliğini arttırır. Kusurların ve sorunların erken tespiti ile yeninden çalışma miktarını azaltır. Ancak yine de gereksinimlerin sürekli değiştiği kompleks yazılım süreçlerinde kullanım kolaylığı sağlamaz. Bunun yerine gereksinimleri değiştirmeye odaklanmayan projelerin kapsamına girebilir. Örneğin BT teknolojileri, askeri projeler, bir uzay mekiğindeki gömülü sistemler vb.
3.HELEZONİK (SPİRAL) MODEL
Spiral model kapsamlı risk yönetimine destek sağlayan en önemli SDLC modellerinden biridir. Şematik temsilinde çoklu döngüye sahip bir spirale benzer. Spiralin döngü sayısı projeden projeye değişmektedir. Spiralin her döngüsü yazılım geliştirme sürecinin bir aşamasıdır. Yinelemeli ve artımsal bir yaklaşım söz konusudur.
SDLC temel aşamaları belirgin olarak ayrılmamıştır. Planlama, risk analizi, üretim ve kullanıcı değerlendirmesinden oluşur.
· Planlama (Planning phase): Gereksinimler toplanır, (BRS, SRS) amaç belirlenir, bir önceki adımın ara ürünü ile bütünleştirme sağlanır.
· Risk Analizi (Risk Analysis): Riski ve alternatif çözümleri belirlemek için bir süreç yürütülür. Risk analizi sonunda bir prototip üretilir. Risk bulunursa alternatif çözümler üretilmekte ve uygulanmaktadır.
· Üretim (Engineering phase): Bu aşamada ara ürün geliştirilir, sınamaları yapılır.
· Kullanıcı Değerlendirmesi (Evaluation phase): Bu aşama müşterinin, proje bir sonraki spirale geçmeden önce, ara ürünü değerlendirdiği ve bir sonraki döngü için gereksinim belirttiği fazdır.
Her döngü tamamlandığında üretilen ara ürün kullanıcıya gider. Bir sonraki döngü için gereksinimler belirlenir ve bu ana ürün ortaya çıkana kadar devam eder. Ürün geliştirme aşamasında iken müşteri değişiklikleri kabul edilmez.
Çağlayan ve V modellerine göre riskin daha az olduğu bu model, geliştirme ilerledikçe ortaya çıkan çok bilinmeyenli projeler için en iyi geliştirme modelidir. Kompleks AR-GE projelerinde uygulanabilir.
Proje sahipleri veya yöneticileri, işleyişte olan yazılımlarla proje boyunca karşı karşıya oldukları için daha kolay izleme şansı bulur. Yazılım geliştirme ekibi kodlama ve sınamaya erken başlama fırsatı bulur. Ayrıca ürünün gelişimini yazılım geliştirmenin erken aşamasında gören müşteri ürün tamamlanmadan kullanarak alışmış olur ve süreç sonunda memnuniyeti artar.
Spiral model diğer SDLC modellerine göre çok daha komplekstir ve maliyetinin yüksekliğinden küçük projeler için kullanılmamalıdır. Bu modelle işleyen bir projenin iyi iş çıkarması için risk analizinin bu alanda deneyimli uzmanlar tarafından yapılması gerekir. Aksi halde proje başarılı sonuç vermeyecektir.
4. ARTIMSAL (INCREMENTAL) GELİŞTİRME SÜRECİ MODELİ
Bu model bir takvime bağlı olarak ürünü parça parça geliştirip teslim etmeye yöneliktir. Böl ve fethet yaklaşımı vardır. Gereksinimler toplandıktan sonra analiz aşamasında önem derecesi ve birbirine bağlılıkları açısından bir öncelik sırasına konur. İlk olarak sadece birkaç temel özelliği uygulayan basit bir çalışma sistemi kurulur ve müşteriye teslim edilir. Bu erken teslime öncelikli gereksinimler dahil olur. Sistem üretim aşamasındayken aynı zamanda kullanımdadır. Temel özellikler tam olarak geliştirildikten sonra bunlar ardışık sürümlere yeni işlevler ekleyerek yetenek düzeylerini artırmak için iyileştirilir. Yazılımın birbirini izleyen her sürümü oluşturulup teslim edildiğinde müşterinin geri bildirimi alınır ve bunlar bir sonraki sürüme dahil edilir.
Geliştirme süreci sıralı veya paralel olarak ilerleyebilir. Paralel geliştirme sürecinde aynı anda farklı alt sistemler geliştirilir. Bu da zamandan tasarruf sağlar ancak maliyeti yükseltebilir.
Artımsal modelde gereksinimleri ve kapsamı değiştirmek daha esnek ve ucuzdur, diğer modellere göre daha hızlı sonuç verir, hataların belirlenmesi ve telafisi kolaydır. Bir ürünün erken piyasaya sürülmesi istendiğinde, geliştirme ekibi çok yetenekli veya eğitimli olmadığında, yüksek riskli özellikler ve hedefler söz konusu olduğunda uygulanabilir. Ancak yazılım yaşam döngüsünün tamamı için gereksinim toplanmadığından bu durum sistem mimarisi için sorun yaratabilir.
5. KODLA VE DÜZELT YAŞAM-DÖNGÜ MODELİ
Direkt olarak yazılım ürününün gerçekleştirildiği modeldir. Literatürde “cowboy coding” olarak bahsedilen bu model en basit yazılım geliştirme süreci olarak kabul edilir. Bunun yanı sıra birçok gerçek dünya projesinde ve özellikle de başlangıç ürünlerinde yaygın olarak kullanılmaktadır. Kodlama ve Düzeltme olarak iki ana adımdan oluşan döngüsel bir süreçtir. Bu modelde genellikle kapsamlı bir planlama, herhangi bir somut strateji veya iyi tanımlanmış tasarım aşamaları yoktur. Analiz aşamasından sonra direkt olarak geliştirme aşamasına geçilir. Süreç ürün istenilen şekle gelene kadar devam eder.
Üretim kolaylığı nedeniyle küçük veya tecrübesiz firmalarda çoğu projede bu model kullanılır. Ayrıca zaman baskısı yaşayan yazılım ekipleri de bu modeli kullanma eğilimindedirler.
Kodla ve Düzelt, küçük, kısa projeler veya ilk planlamaya ihtiyaç olmayan prototipler için uygun olabilir. Genellikle zaman kazandırır. Bununla birlikte gereksinimlerin somut bir şekilde anlaşılmadığından müşteri memnuniyeti ve hatta başarısızlık için büyük bir risk vardır. Bu da ürünün neredeyse baştan üretilmesine sebep olabilir. Ayrıca sürekli iletişim sorunları olacağından büyük bir ekip çalışmasında bu model güvenilir bir şekilde çalışmayacaktır. Orta ve büyük ölçekli yazılım projeleri için tasarlanmadığından çoğu durumda en az etkili geliştirme modeli olarak kabul edilebilir.
Bu modeli diğer modellerden ayıran en önemli özelliklerden biri de belgelemenin bulunmamasıdır. Bu şekilde üretilen bir ürünün izlenmesi veya üzerinde oynama yapılması çok zordur. Yüksek kaliteli bir ürün çıkma olasılığı azdır. Ayrıca Kodla ve Düzelt geliştirme modelinde bir emeklilik safhası bulunur.
ÇEVİK (AGILE) YAZILIM GELİŞTİRME YÖNTEMLERİ

1990’ların başında yazılım geliştirme ekipleri bir krizle karşı karşıya kaldı. O zamanlar yaygın olarak “uygulama geliştirme krizi” veya “uygulama teslim gecikmesi” olarak adlandırılıyordu. Sektör uzmanları, doğrulanmış bir iş ihtiyacı ile üretimdeki fiili bir uygulama arasındaki sürenin yaklaşık üç yıl olduğunu tahmin etti. Buradaki problem işletmelerin bundan 25 sene önce bile daha hızlı hareket etmesiydi. Üç yıl içinde gereksinimler, sistemler ve hatta tüm işletmelerin değişmesi muhtemeldi. Bu, birçok projenin sonunda iptal edildiği anlamına geliyordu ve tamamlananların çoğu projenin orijinal hedefleri karşılansa bile işletmelerin mevcut ihtiyaçlarını karşılamıyordu.
Havacılık mühendisi John Kern, bu uzun teslim süreleri ve daha sonra değiştirilemeyen bir projede erken alınan kararlar nedeniyle hayal kırıklığına uğradı. Yazılım geliştirmenin daha iyi bir yolu olması gerektiğini düşünen insan sayısı artmaktaydı. Kendisinin de içinde olduğu 17 yazılım düşünce liderleri ile yazılım geliştirmenin çağlayan modeli gibi zamanın popüler yazılım mühendisliği tekniklerinden daha basit, daha az zaman isteyen ve dokümantasyonun olmadığı bir yöntem arayışına girdiler.
Benzer fikirlere sahip profesyoneller tarafından paylaşılan, görünüşte verimsiz yazılım geliştirme faaliyetleriyle ilgili bu hayal kırıklıkları, 2001’in başlarında Snowbird toplantısına yol açtı. Toplantıda Kern, Alistair Cockburn, Ward Cunningham, Kent Beck ve bugün çevik yazılım topluluğunda iyi bilinen on iki kişiyi içeriyordu. Özellikle bu düşünce liderleri çalışan yazılımı hızla geliştirmenin ve onu kullanıcıya teslim etmenin yollarını aradılar. Hızlı geri bildirim ve değişme isteği, çevik geliştirmenin temel özellikleri olarak ortaya çıktı.2001’de Kent Beck ve 16 arkadaşı tarafından çevik yazılım manifestosu oluşturuldu.
Çevik Yazılım Manifestosu’nun Temel Prensipleri:
· En önemli önceliği değerli yazılımın erken ve devamlı teslimini sağlayarak müşterileri memnun etmektir.
· Değişen gereksinimler yazılım sürecinin son aşamalarında bile kabul edilmelidir. Agile süreçler değişimi müşterinin rekabet avantajı için kullanır.
· Çalışan yazılım, tercihen kısa zaman aralıkları belirlenerek birkaç haftada ya da birkaç ayda bir düzenli olarak müşteriye sunulmalıdır.
· İş süreçlerinin sahipleri ve yazılımcılar proje boyunca her gün birlikte çalışmalıdırlar.
· Projelerin temelinde motive olmuş bireyler yer almalıdır. Onlara ihtiyaçları olan ortam ve destek sağlanmalı, işi başaracakları konusunda güven duyulmalıdır.
· Bir yazılım takımında bilgi alışverişinin en verimli ve etkin yöntemi yüz yüze iletişimdir.
· Çalışan yazılım ilerlemenin birincil ölçüsüdür.
· Çevik süreçler sürdürülebilir geliştirmeyi teşvik etmektedir. Sponsorlar, yazılımcılar ve kullanıcılar sabit tempoyu sürekli devam ettirebilmelidir.
· Teknik mükemmeliyet ve iyi tasarım konusundaki sürekli özen çevikliği artırır.
· Sadelik, yapılmasına gerek olmayan işlerin mümkün olduğunca arttırılması sanatı, olmazsa olmazlardandır.
· En iyi mimariler, gereksinimler ve tasarımlar kendi kendini örgütleyen takımlardan ortaya çıkar.
· Takım, düzenli aralıklarla nasıl daha etkili ve verimli olabileceğinin üzerinde düşünür ve davranışlarını buna göre ayarlar ve düzenler.
Hızlı ve sürekli teslimden kaynaklanan müşteri memnuniyeti, en iyi iletişim yöntemi olan yüz yüze iletişimin kullanımı, sürekli olarak teknik mükemmelliğe ve iyi tasarıma önem verilmesi, iş adamları ve geliştiriciler arasında günlük ve yakın işbirliği, değişen koşullara düzenli uyum, gereksinimlerdeki geç değişimlere karşı tolerans çevik programlamanın günümüzde en popüler yazılım geliştirme yöntemleri olmasını sağlamıştır. Bununla birlikte uzman proje ekipleri gerektirdiğinden küçük geliştirme projelerinde tercih edilmez.
En yaygın kullanılan çevik yöntemler; Extreme Programming (XP), SCRUM, Agile Unified Process, Feature-Driven Development (FDD), Test-Driven Development (TDD), LEAN Development, Dynamic System Development Methodology (DSDM), Microsoft Solution Framework (MSF) şeklinde sıralanabilir.
EKSTREM PROGRAMLAMA (XP)
1999’da Kent Beck tarafından ortaya çıkarılmıştır. Üretkenliğin arttığı, kolay, ekip içinde iletişimin önemli olduğu, yeni müşteri gereksinimlerinin benimsenebileceği kontrol noktalarını tanıtmayı amaçlayan kısa geliştirme döngülerinde sık sürümlerin oluştuğu yazılım geliştirme disiplinidir. Kısaca iletişim, basitlik, geri bildirim, cesaret temellerine dayanır.
· İletişim: Herhangi bir proje incelendiğinde en önemli problemlerin ekip içinde bireylerin birbiri ile tam anlamıyla anlaşamamasından kaynaklandığı görülebilir. XP bu problemi ortadan kaldırmaya yöneliktir. Yüz yüze iletişim etkindir. Sıkı iletişime bağlı olarak sorunlar erken fark edilir.
· Basitlik: Birçok kişinin düşündüğünün aksine basitlik uygulanması zor bir niteliktir. Zorunlu olan işlemlerin yapılması önemlidir. Karmaşıklıktan uzaktır.
· Geri Bildirim: Projelerde son derece etkili olan bu temel sayesinde oluşabilecek sorunlar ortadan kalkar. Müşteri ekibe dahildir. Belli zamanlarda bir araya gelip ürün incelemesi yapılır. Müşteri istekleri dikkate alınarak sonradan oluşabilecek anlaşmazlıklar daha önce giderilmiş olur.
· Cesaret: Uygulanması en zor adımlardan biri de cesur olmaktır. Ekip başarısızlıktan korkmadan oluşturan sebepler üzerine yoğunlaşmalı, üründen memnun kalınmadığı takdirde baştan başlayabilmelidir.
XP’yi diğer metodolojilerden ayıran bir özelliği de bir dizi kural ve yöntemlere (pratiklere) dayanıyor olmasıdır. Bunları geri bildirim, sürekli süreç, kod anlayışı, çalışma koşulları altında inceleyebiliriz.
Geri Bildirim (Feedback)
· Test Odaklı Geliştirme (Test-Driven Development): Kod yazılmadan önce test programı oluşturulur. Mevcut sorunlar erken tespit edilir.
· Planlama Oyunu (Planning Game): Her sürümde müşterinin de bulunduğu bir toplantıda sürecin zaman planlaması yapılır. Yazılım ekibi bu süreye dikkat ederek çalışır.
· Ekipte Müşteri (On-site Customer): Müşterinin sürece sık dahil olması yazılım geliştirmeyi kolaylaştırır.
· Çiftli Programlama (Pair Programming): Programın hızını arttırır. Ekipteki her bir yazılımcının yetenek ve bilgi birikimleri ile geliştirilen proje farklı bakış açıları sayesinde oluşabilecek sorunlar daha kolay tespit edilir.
Sürekli Süreç (Continual Process)
· Sürekli Entegrasyon (Continuous Integration): Yazılım geliştirme aşamasında sistem değişiklikleri ve yenilikler sisteme entegre edilip sınanır.
· Yeniden Yapılandırma (Code Refactoring): Kodlar ve sistem tasarımı sürekli olarak gözden geçirilir.
· Kısa Aralıklı Sürümler (Small Releases): Projenin ayrı zaman dilimlerine böünmesiyle geliştiricilerin sık sık geri bildirim almasına, hataları erken tespit etmesine ve ürünün üretimde nasıl çalıştığını izlemesine olanak tanır.
Kod Anlayışı (Code Understanding)
· Basit Tasarım: Yazılım için en iyi tasarım şeklidir. Yinelenen kod içermemeli ve mümkün olan en az metot ve sınıfla geliştirilmelidir. Ayrıca programcının niyetini de açıkça yansıtmalıdır.
· Ortak Kod Sahiplenme: Geliştirilen yazılım bütün ekip üyelerinin ortak ürünüdür.
· Sistem Benzetimi (System Metaphor): Belirli niteliklere sahip basit bir tasarım anlamına gelir. Yazılım parçalara ayrılır. Her bir parçası başka bir sistemle benzeştirilir.
· Kodlama Standardı (Coding Standards): Bir yazılım ekibi kod yazmak için aynı formatları ve stilleri kullanan ortak kodlama uygulamalarına sahip olmalıdır. Bu da karmaşıklığı azaltarak tüm ekip üyelerinin kodu kolaylıkla okumasına, paylaşmasına ve düzeltmesine yardımcı olur.
Çalışma Koşulları (Working Conditions)
Haftada 40 Saat (40-Hour Week): XP projeleri geliştiricilerin hızlı ve verimli çalışmasını ve ürünün kalitesini sürdürmesini gerektirir. İyi ve dinlenmiş bir ekip iş performansını arttırır. Maksimum çalışma saati sayısı haftada 45 saati geçmemelidir.
SCRUM
İsmini Rugby sporundaki bir hücum taktiğinden alan Scrum gerçek anlamıyla tüm oyuncuların karşı sahaya atak yapmasıdır.1990’lardan beri moda bir sözcük olmuştur ve Agile’ın yazılım geliştirme ve proje yönetiminde uygulanmasında yaygın olarak kullanılmaktadır. Scrum insanların mümkün olan en yüksek değere sahip ürünleri üretken ve yaratıcı bir şekilde sunarken, karmaşık uyarlanabilir sorunları ele alabilecekleri bir çerçevedir. Temelinde karmaşıklığı azaltmaya yönelik olup yazılımı küçük birimlere (sprint) ayırarak geliştirme yapılır. Dolayısıyla gereksinimlerin belirgin olmadığı durumlarda hayat kurtarıcıdır. Her sprint 4 haftadan fazla sürmeyecek şekilde düzenlenir ve 24 saatte bir 15 dakikalık toplantılar yapılır.
Scrum Rolleri (Roles)
· Ürün Sahibi (Product Owner): Ürün veya hizmetle ilgili ihtiyaç ve beklentileri anlayarak geliştirme ekibine aktaran kişidir. İş taleplerini netleştirme ve sıraya koymaktan sorumludur.
· Scrum Yöneticisi (Scrum Master): Proje hedeflerini gerçekleştirmek için firmaya karşı sorumlu olan kişidir. Ekibe koçluk etmek ve süreci yönetmekle görevlidir.
· Scrum Takımı (Scrum Team): Birbiri ile iletişimi sürdürerek tek hedef üzerinde yoğunlaşan ve yönetime uygun olarak çalışan genelde 5–9 kişiden oluşan ekiptir.
Scrum Toplantıları (Meetings)
· Sprint Planlama (Sprint Planning): Bir sprintin her haftası için yaklaşık bir saat süren bir çalışma seansıdır. Detaylı gereksinim listesi yapılır.
· Sprint Gözden Geçirme (Sprint Review): Product Owner ile takım gereksinim listesini gözden geçirilir. Takım gereksinimlerden ne kadarını yapacağını taahhütlendirir. Bir aylık bir sprint için maksimum 4 saat süren bir toplantıdır.
· Günlük Scrum Toplantısı (Daily Scrum Meeting) :Her gün yapılan maksimum 30 dakikalık ve ayakta olan toplantıdır.
Scrum Bileşenleri (Artifacts)
· Product Backlog: Müşteriyle anlaşmalı olarak düzenlenen bir gereksinim dokümanı gibidir. Sürekli bakım şarttır. Genellikle kullanıcı hikayelerinden oluşmaktadır.
· Sprint Backlog: 2–4 haftalık proje zaman dilimlerine verilen addır. İş ve görevleri barındırır. Düzenlemeler sadece takım tarafından yapılır.
· Burndown Chart: İşin ne kadar yapılması gerektiğinin ve ne kadarının yapıldığının görülebildiği bir grafiktir.
Scrum basitliği,hızı ve yüksek performansı nedeniyle en popüler çevik yazılım geliştirme yöntemidir. Hissedilen başarı duygusu, olumlu geri bildirim ve yapılan işin sahiplenilmesi Scrum’ın günümüzde Google, Microsoft, IBM, Siemens, BBC gibi artık vazgeçilmezimiz haline gelen firmalarda en sık kullanılan proje yönetim metodu olmasını sağlamıştır.