Yazılım geliştirme süreci temel olarak tasarım, geliştirme, test ve dağıtma aşamalarını içerir. 1970’li yıllardan itibaren ilk yazılım geliştirme süreç modelleri oluşturulmaya baş- lanmıştır. Bu modellerin bazıları yazılım geliştirme sürecindeki temel faaliyetlerin nasıl uygulanacağı hakkında biçimsel bir çerçeve sunarken, diğerleri ise belirli bir faaliyet özelinde yapılan işleri detaylı bir şekilde modellemektedir.

1980’lerden 2000’li yıllara kadar uygulanan yazılım geliştirme süreçlerinin birçoğu şelale (waterfall) yaklaşımını kullanmıştır. Şelale tipi süreçlerde, tüm temel yazılım geliştirme faaliyetleri önceden belirlenen sabit bir zaman aralığında ve belirlenmiş bir sıra ile yapılır.

1990’lı yıllarda yazılım geliştirme süreci ile ilgili farklı yaklaşımlar öne süren çalışmalar ortaya atılmıştır. Bu çalışmalardan çıkarılabilecek ortak sonuçlardan bazıları, büyük yazılım projelerinin baştan sona planlanabilmesinin zor olduğu ve yazılım geliştirme esnasında değişiklikleri izole etmenin mümkün olmamasıdır. Geliştirilecek yazılımın gereksinimlerinin, yazılım kullanılmaya başlamadan tam olarak netleşmesinin zor olduğu da bu yıllarda dile getirilmiştir. Sonradan adı Scrum olacak yöntemin ilk prototipleri 1990’lı yılların başında Ken Schwaber (yazılım geliştirici, ürün yöneticisi) tarafından kendi şirketinde denenmiştir

2001 yılına geldiğimizde ise yazılım sektörünün önde gelenlerinden oluşan bir grup, yazılım geliştirme yöntemlerinin gözden geçirilmesi konusunda hemfikir olarak bir beyin fırtınası yaptılar. Bu fikir alışverişinin sonunda “Çevik Yazılım Geliştirme Manifestosu” adlı bir bildiri yayınladılar. Bu bildiri, ilerleyen yıllarda ve günümüzde de çevik yazılım geliştirme yöntemleri için hedef gösterici bir vizyon sunmuştur.

2001 yılında 17 yazılım sektörü önde geleni, yazılım geliştirme süreçlerini gözden geçirme ve fikir alışverişi yapmak üzere toplandıklarında, aralarında Scrum yönteminin fikir babaları olan Ken Schwaber ve Jeff Sutherland da bulunmaktaydı. Bu toplantı sonucunda dört maddelik bir değer topluluğu üzerinde hemfikir oldular ve bu maddeleri “Çevik Yazılım Geliştirme Manifestosu” olarak yayınladılar

Manifestodaki maddelere göre aşağıdaki çıkarımlar yapılabilir:

• Süreçler ve araçlar, yazılımın temel amacı olan değeri üretmek için kullanılmalı- dır. Araçlar işimizi kolaylaştırmalı ve takip edilebilirliği arttırmalıdır. Bir değeri olmayan araçlar ve süreçler fayda sağlamayacaktır. Ayrıca bireyler arası etkileşim, bir takım olma hissiyatı, araçlar ve süreçler tarafından engellenmemeli, aksine desteklenmelidir.

• Dokümantasyon da araçlar ve süreçler gibi değer katan düzeyde yapılmalıdır. Engelleyici ve gereğinden fazla yük getiren dokümantasyon faydasızıdır. Çalışan bir yazılım ortada yoksa dokümantasyon bir işe yaramayacaktır. Kaynaklar, bu durum göz önünde bulundurularak önceliklendirilmelidir.

• Yazılımı talep eden müşteri ile sürekli etkileşim halinde olmak, yazılım geliştirme sürecini daha çevik yapacaktır. Önceden yapılan pazarlıklar bazı durumlarda ilerlemeyi yavaşlatır ve müşteri ile iletişim kopukluğu projenin başarısız olmasına yol açabilir. Müşteri dış bir paydaş değil, takımın bir parçası olarak konumlanmalıdır. Bu sayede daha doğru ürünün ortaya çıkması mümkün kılınmaktadır.

• Bir projenin baştan sona tüm planının yapılması hem zordur hem de gerçek dışı olma ihtimali yüksek bir faaliyettir. Gereksinimlerde meydana gelebilecek değişiklikler baştan kabul edilmeli ve planlamalar adapte olabilecek şekilde yapılmalıdır. Planlama da değer üretmek için kullanılan bir araçtır. Bu sebeple planlar değişikliklere adapte olmalı ve değer üretimine fayda sağlamalıdır.

Çevik Yazılım Geliştrme Manifestosu’ndaki bu maddelere ek olarak 12 adet Çevik Yazılım Prensibi de toplantı sonucu olarak yayınlanmıştır. Bu 12 prensip aşağıdaki gibidir:

1. En önemli önceliğimiz, değerli yazılımın erken ve devamlı teslimini sağlayarak müşterileri memnun etmektir.

2. Değişen gereksinimler yazılım sürecinin son aşamalarında bile kabul edilmelidir. Çevik süreçler değişimi, müşterinin rekabet avantajı için kullanır.

3. Ç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.

4. İş süreçlerinin sahipleri ve yazılımcılar proje boyunca her gün birlikte çalışmalıdırlar.

5. 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.

6. Bir yazılım takımında bilgi alışverişinin en verimli ve etkin yöntemi yüzyüze ileti- şimdir.

7. Çalışan yazılım, ilerlemenin birincil ölçüsüdür.

8. Çevik süreçler sürdürülebilir geliştirmeyi teşvik etmektedir. Sponsorlar, yazılımcılar ve kullanıcılar sürekli olarak belirli bir tempoyu devam ettirebilmelidirler.

9. Teknik mükemmeliyet ve iyi tasarım konusundaki sürekli özen çevikliği artırır. 

10. Sadelik, yapılmasına gerek olmayan işlerin mümkün olduğunca arttırılması sanatı, olmazsa olmazlardandır.

11. En iyi mimariler, gereksinimler ve tasarımlar kendi kendini örgütleyen takımlardan ortaya çıkar.

12. 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.

Çevik yazılım geliştirme manifestosundaki maddeleri ve prensipleri dikkate alarak birçok çevik yazılım geliştirme yöntemi geliştirilmiştir veya mevcut yöntemler çevik yöntemlere adapte olmuştur. Bu yöntemlerin bazıları aşağıda sıralanmıştır:

• Adaptive software development (ASD)

• Agile modeling

• Agile Unified Process (AUP)

• Crystal Clear methods

• Disciplined agile delivery

• Dynamic systems development method (DSDM)

• Extreme programming (XP)

• Feature-driven development (FDD)

• Lean software development

• Kanban

• Rapid application development (RAD)

• Scrum

• Scrumban

Test güdümlü programlama, yazılım geliştirme faaliyetini hedefleyen bir yöntemdir. Bu yöntemde ilgili kodu yazan yazılımcı, kodu doğrudan yazmaya başlamak yerine, öncelikle koddan bekleneni test edecek olan test kod parçacıklarını yazarak işe başlar. Gerçekte geliştirilmesi gereken yazılım parçası her defasında ilgili testlere tabi tutulur. Testler ba- şarısız olduğunda, testleri başarılı hale getirecek biçimde kod güncellemeleri yapılır ve testler tekrar çalıştırılır. Testler başarılı olana kadar bu işlem devam eder. Testler başarılı olduğunda ya yeni testler yazarak yazılımı geliştirmeye devam eder ya da kodu tekrar yapılandırır. Yeniden yapılandırma işlemleri kodun işlevselliğini değiştirmek üzere değil, kodun yapısal olarak kalitesinin arttırılması amacıyla yapılır.

Kod yeniden yapılandırma, mevcut kodun davranışını değiştirmeden yapısal değişiklik yapma faaliyetidir. Çevik yazılım geliştirme yöntemlerinin faydalı olması için kodda yapılacak yeniden yapılandırma işlemlerinin, kodun okunabilirliğini arttırmak, sürdürülebilirliğini sağlamak, karmaşıklığını azaltmak gibi hedefleri olmalıdır. Aynı zamanda çevik yazılım projeleri değişikliğe açık olduğundan, çevik yazılımın kodları da esnek ve geliş- tirmeye açık olmalıdır. Bu nedenle gerçekleştirilen kod yeniden yapılandırma faaliyetleri çevik yazılım geliştirme yöntemleri için faydalı bir pratiktir.

Sürekli entegrasyon, yazılım üzerinde yapılan değişikliklerin herhangi bir bozulmaya sebep olup olmadığının önceden belirlenmesini hedefleyen bir pratiktir. Bu yöntemde yazı- lım beraberinde geliştirilen testler büyük önem taşımaktadır. Yapılan her değişiklik sonrası yazılım merkezi bir noktada derlenir ve tüm testler çalıştırılır. Eğer derlemede veya testlerde bir problem ortaya çıkarsa yazılım ekibi bilgilendirilir. Böylelikle yazılım gerçek ortama çıkmadan önce erken geri dönüş sağlanmış olur. Yazılımdaki olası hatalar erken yakalanır ve düzeltilir.

Eşli programlama iki yazılımcının aynı iş üzerinde aynı iş istasyonunu kullanarak beraber çalışması pratiği olarak tanımlanabilir. Burada iş istasyonu genellikle aynı bilgisayar ve ekran olarak düşünülebilir. Yazılımcılardan bir tanesi kodu yazarken, diğeri gözlemleyerek kodu anında gözden geçirir. Yazılımcılar ara ara rol değişikliği de yaparlar.

Scrum, insanların karışık ve adaptasyona açık problemleri ele alabilmek için en yüksek değere sahip ürünü, üretken ve yaratıcı bir şekilde geliştirmesini sağlayan bir iskelettir. Scrum, özellikle yazılım ürünü geliştirmek için ortaya konmuş bir yöntem değildir. Herhangi değer üreten bir ürün geliştirmesi için de kullanılabilir. Ancak Scrum, en çok yazılım projelerinde uygulanmaktadır. Scrum konusunda bilgi birikiminin oluşması ve Scrum’ın yaygınlaşması konusunda yazılım projelerinin payı büyüktür.

Scrum temel bileşenleri Scrum Ekibi, ekibin rolleri, etkinlikler, çıktılar ve kurallardır. Tüm bu parçaların ayrı ayrı amaçları bulunmaktadır ve Scrum başarısında önemli rol oynarlar.

Scrum ekibi, Ürün Sahibi (Product Owner), Geliştirme Ekibi (Development Team) ve Scrum Uzmanı’ndan (Scrum Master) oluşur. Scrum ekiplerinin en önemli özelliği dışarı- dan komutlar ile yönetilmiyor olmasıdır. Ekip kendi içinde en iyisine karar vererek kendisini yönetir. Bu sebeple ekip bir bütün olarak geliştirme için gerekli tüm fonksiyonaliteye sahiptir. Scrum’ın en önemli özelliği ürünün (yazılım) tekrarlamalı (iterasyonlu) olarak teslim edilmesidir. Scrum ekibi her tekrarlama sonrası geri bildirim alarak, bu geri bildirimden fazlasıyla faydalanır. Geri bildirimler, Scrum projelerinin başarısında çok önemli bir rol oynamaktadır.

Scrum etkinlikleri düzenlilik sağlamak ve fayda arttırımı için yapılır. Bu etkinlikler süreç içinde yeterli sayıda olmalı ve başka toplantı, etkinlik vb. yapılmamalıdır. Tüm etkinliklerde bir zaman kısıtı vardır ve zaman dolduğunda etkinlik bitirilmelidir. Bu kural zaman israfını engeller ve etkinliklerin verimli olmasına katkı sağlar. Bu etkinliklerin herhangi birini uygulamamak veya uygun biçimde gerçekleştirmemek Scrum değerlerinin sağladı- ğı faydalara doğrudan etki edecektir. Bu sebeple Scrum’ın tam anlamıyla gerçekleştirilmiş olması için tüm etkinlikler uygun şekilde yapılmalıdır.

Scrum’ın en temel yapıtaşı olan Sprint, belirli bir zaman aralığını temsil eder. Bu aralığın uzunluğu en fazla bir ay olabilir. Genellikle Sprintlerin uzunluğu bir veya iki hafta olarak tercih edilir. Sprint süresi çok uzun olursa risk ve belirsizlik artar. Çok kısa olması durumunda ise Sprint hedefinin sağlanması zorlaşır.

Sprint Planlama bir Sprintin en başında yapılan etkinliktir. Planlamada tüm Scrum Ekibi mevcut Sprint içinde yapılacak işi planlarlar. Toplantıya Scrum Ekibi dışında ürünün paydaşları da fayda sağlamak amacı ile katılabilir. Tüm Scrum etkinlikleri gibi, Sprint Planlama da zaman kısıtı olan bir etkinliktir. Planlama toplantısının süresi Sprintin uzunluğu ile orantılıdır. Bir aylık Sprint için planlama toplantısı en fazla 8 saat, iki haftalık bir Sprint için ise 4 saat olabilir. Scrum Master, etkinliğin amacına uygun yapılmasını ve zaman yönetimini gerçekleştirir. Sprint Planlama toplantısında temel olarak, içinde bulunulan Sprint süresince kullanılabilir ürün parçası olarak neler yapılacağı ve bu ürün parçalarını oluşturmak için yapılacak işlerin nasıl gerçekleştirileceği sorularına cevap aranır. Toplantı, Ürün Sahibinin önceliklendirdiği özellikleri ekibe anlatması ile başlar. Ürün İş Listesi bu toplantıda kullanılan en temel girdidir

Günlük Scrum toplantılarında Geliştirme Ekibi üyeleri sırayla söz alır ve aşağıdaki üç temel konu dışında başka birşey konuşmaz: • Sprint hedefi doğrultusunda dün yapılan işler

• Sprint hedefine ulaşmak için bugün yapacağı işler

• Sprint hedefine ulaşmayı engelleyen durumlar

Sprint Değerlendirme toplantısı, Sprint’in en sonunda, ekibin geliştirdiği ürünü kontrol ettiği bir toplantıdır. Bu toplantıda ürün paydaşlarının bulunması son derece faydalıdır. Ekip bir Sprint boyunca bitirdiği kullanılabilir ürün parçalarını sunar ve bunlar üzerinde görüşme yapılır. Bu görüşme toplantısı kesinlikle resmi sunum tipinde bir toplantı değildir. Tüm paydaş- lar ve ekip geliştirilen ürün üzerinde iş birliği çerçevesinde fikirlerini ortaya koyarlar. Herkes ürünün değerini arttırmak için görüşlerini söyler ve bu görüşler geri bildirim olarak Ürün Sahibi tarafından not edilebilir. Bu toplantının süresi en fazla dört saat olabilir. Diğer etkinliklerde olduğu gibi Scrum Master, toplantının süresi içinde tamamlanmasından sorumludur.

Ürün İş Listesi değer üreten ürünün, önceliğe göre sıralanmış özellik listesidir. Üründen beklenen tüm gereksinimler için tek bilgi kaynağı burasıdır. Ürün Sahibi, Ürün İş Listesinden sorumlu tek kişidir. Listenin sıralaması, içeriği ve erişilebilirliğinden sorumludur.

Sprint İş Listesi belirlenen Sprint hedefi doğrultusunda seçilmiş Ürün İş Listesi kalemleridir. Ayrıca Sprint İş Listesinde, hedefe ulaşmak için yapılan plan da mevcuttur. Sprint İş Listesinde, Sprint hedefine ulaşmak için gerekli tüm işler mevcuttur. Böylelikle şeffaflık sağlanır. Bu işlerin hepsinin mevcut tahmini, kalan efor bilgileri açık bir şekilde görülebilir durumdadır.

Ürün Parçası bir Sprint sonunda tamamlanan Ürün İş Listesi kalemleri ile daha önce bitirilmiş Sprintlerdeki Ürün Parçalarının değerlerinin toplamıdır. Her Sprint sonunda bir Ürün Parçası kullanılabilir olarak hazır ve “Bitti” olarak tanımlanmış bir şekilde ortaya çıkmalıdır.

Ürün İş Listesi kalemleri “Bitti” olarak nitelendirildiğinde tüm ekip aynı şeyi anlamalıdır. Bu bitti tanımının neleri içerdiği önceden belirlenmelidir. Tüm iş kalemlerinin aynı “Bitti” özelliklerine sahip olması ürünün kalitesi açısından çok önemlidir