PROGRAMLAMADA YENİ EĞİLİMLER

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 Je 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. Bu dört madde ve manifestonun metni aşağıdaki gibidir:

ÇEVİK BİLDİRİ (AGILE MANIFESTO)

Bizler daha iyi yazılım geliştirme yollarını,

uygulayarak ve başkalarının da uygulamasına yardım ederek ortaya çıkartıyoruz.

Bu çalışmaların sonucunda:

Süreçler ve araçlardan ziyade bireyler ve etkileşimlere

Kapsamlı dokümantasyondan ziyade çalışan yazılıma

Sözleşme pazarlıklarından ziyade müşteri ile işbirliğine

Bir plana bağlı kalmaktan ziyade değişime karşılık vermeye

değer vermeye kanaat getirdik.

Özetle, sol taraaki maddelerin değerini kabul etmekle birlikte,

sağ taraftaki maddeleri daha değerli bulmaktayız

Bu nedenle doğru yanıt a) seçeneğidir.

Çevik yazılım geliştirme yöntemlerini destekleyen ve temel yazılım geliştirme faaliyetlerini kapsayan birçok pratik bulunmaktadır. Bu yöntemler, çevik yazılım projelerinin başarısında önemli rol oynarlar. Bu yöntemlerden bazıları Scrum yöntemiyle birlikte anlatılacaktır. Bunların dışında en çok bilinen ve kullanılan pratiklerden bazıları aşağıda açıklanmaktadır.

Test Güdümlü Programlama (Test Driven Development)

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.

Bu nedenle doğru yanıt a) seçeneğidir.

Sürekli entegrasyon, yazılım üzerinde yapılan değişikliklerin herhangi bir bozulmaya sebep olup olmadığının önceden belirlenmesini hedeeyen 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. Böylelikle yazılımdaki değişikliklerin maliyeti çok daha az olur. Bu durum çevik yazılım geliştirme yöntemleri için önemlidir.

Bu nedenle doğru yanıt a) seçeneğidir.

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. Örneğin, tüm yazılım geliştirilme işlemleri bitmeden test aşamasına geçilmez. Yazılım geliştirilmeye başlanmadan önce de tüm gereksinimlerin detaylı bir şekilde toplanması beklenir ve gereksinim analizi bitmeden yazılım geliştirilmeye başlanmaz. Şelale tipi süreç ile geliştirilen yazılım projelerinde, geliştirme esnasında gereksinimlerin değişmesi yazılım geliştirme maliyetini önemli şekilde artırmıştır.

Bu nedenle doğru yanıt a) seçeneğidir.

Scrum ürün geliştirme bağlamında tanımlanmak istenirse şu cümle yeterli olacaktır: 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 temelde genel bir çerçeve çizer ve içerisinde kullanılan süreç ve pratiklere karışmaz. Bu sebeple anlaşılırlığı yüksektir. Ancak bu basitliğin yanında, Scrum uygulamasında tam olarak ustalaşmak zordur. 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 temelinde deneyerek kontrol etme süreci vardır. Her bir tekrarlamada (iterasyon) kazanılan deneyime göre kararlar alınır. Bu deneyimin sağlıklı olarak değerlendirilmesi için üç temel kavrama önem verilmektedir:

Bu nedenle doğru yanıt a) seçeneğidir.

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 süresi boyunca ekip, belirli bir Sprint hedefi doğrultusunda iş parçalarını geliştirir. Süre sonunda “bitti” olarak nitelendirilen iş parçaları ile yayınlanabilir ve kullanılabilir bir ürün ortaya çıkar. Her Sprint sonunda ürün yayınlanmak zorunda değildir, ancak yayınlanabilir bir değer üretilir.

Sprint süresince bir amaca uygun olarak geliştirme yapılır ve amacın başarılmasına olumsuz etki edecek değişikliklerden mümkün olduğunca kaçınılır. Ayrıca hedefi gerçekleştirirken ürün kalitesinden feragat edilmez. Ancak her ne kadar amaca olumsuz etki edecek durumlardan kaçınılsa da, elde olmayan sebeplerden dolayı Ürün Sahibi ve Geliştirme Ekibi Sprint amaç ve kapsamını revize edebilir. Bir Sprint biter bitmez hemen diğer Sprint başlar, arada boşluk yoktur. Sprintin uzunluğunun ekibe ve ürüne göre en baştan belirlenerek tüm Sprintlerin aynı uzunlukta olması, çıktıların doğru değerlendirilmesi açısından önem arz eder. Bu sebeple ekip ilk Sprint ile Sprintleri hangi uzunlukta yapacağına (1 hafta, 2 hafta, 1 ay vb.) karar verir. Sprint dışı bir zaman olmadığı için, diğer Scrum etkinlikleri Sprint içinde yapılır. Bunlar, Sprint Planlama, Günlük Scrum, Sprint Değerlendirme ve Sprint Retrospektifidir.

Bu nedenle doğru yanıt a) seçeneğidir.

Scrum eserleri ve çıktıları temelde üretilen değeri temsil eder ve bu değeri şeaf bir biçimde gözlemleme imkânı sağlar. Ayrıca paydaşlar ve ekip için projenin ilerleyişinde ne durumda olduklarını anlamaları için kilit bilgiler sunar. Bunlar; Ürün İş Listesi, Sprint İş Listesi, Ürün Parçası, Takım Hızı ve Bitti Tanımıdı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.

Bu nedenle doğru yanıt a) seçeneğidir.

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. Değerlendirme toplantısı Ürün Sahibinin, Ürün İş Listesindeki işlerden hangilerinin bittiğini açıklaması ile başlar. Sonrasında, Ürün Sahibi veya Geliştirme Ekibi biten işleri gösterir ve soruları yanıtlar. Ürün Sahibi, Geliştirme Ekibi ve tüm paydaşların katılımı ile ortaya güncellenmiş bir Ürün İş Listesi çıkar. Scrum’ın en önemli özelliklerinden biri olan hızlı geri dönüş ve paydaşların katılımı bu toplantı sayesinde başarılır. Klasik yazılım geliştirme yöntemlerinde ortaya çıkabilecek, istenmeyen özelliklere sahip bir ürün geliştirilmesi riski en düşük seviyeye iner.

Bu nedenle doğru yanıt a) seçeneğidir.

Sprint Retrospektif toplantısı bir Sprint içinde en son yapılan etkinliktir. Genellikle Sprint Değerlendirme toplantısından hemen sonra yapılır. Bu toplantıda Scrum Takımı tüm bir Sprint’in değerlendirmesini yapar. Toplantı üç saat ile sınırlandırılmalıdır. Scrum Master toplantının, hem amacına uygun biçimde ilerlemesinden hem de süresi içinde tamamlanmasından sorumludur. Retrospektif toplantısında odaklanılan şey sürekli iyileştirmedir ve temel olarak bir sonraki Sprint sürecinde nelerin daha iyi yapılabileceği tartışılır. Bitmekte olan Sprint’in süreç, insan ilişkileri, araçlar vb. konularda nasıl geçtiği gözlemlenir. İyi giden ve verimsiz ilerleyen noktalar belirlenir ve bir sonraki Sprint sürecinde yapılacak iyileştirmeler ile ilgili bir plan çıktısı oluşturulur.

Bu nedenle doğru yanıt a) seçeneğidir.

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.

ÇEVİK BİLDİRİ (AGILE MANIFESTO) Bizler daha iyi yazılım geliştirme yollarını, uygulayarak ve başkalarının da uygulamasına yardım ederek ortaya çıkartıyoruz. Bu çalışmaların sonucunda: Süreçler ve araçlardan ziyade bireyler ve etkileşimlere Kapsamlı dokümantasyondan ziyade çalışan yazılıma Sözleşme pazarlıklarından ziyade müşteri ile işbirliğine Bir plana bağlı kalmaktan ziyade değişime karşılık vermeye değer vermeye kanaat getirdik. Özetle, sol taraftaki maddelerin değerini kabul etmekle birlikte, sağ taraftaki maddeleri daha değerli bulmaktayız.

Ç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 Driven development çevik yazılım gelişim pratiklerindendir.

Sürekli Entegrasyon (Continuous integration) 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. Böylelikle yazılımdaki değişikliklerin maliyeti çok daha az olur. Bu durum çevik yazılım geliştirme yöntemleri için önemlidir.

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 temelde genel bir çerçeve çizer ve içerisinde kullanılan süreç ve pratiklere karışmaz. Bu sebeple anlaşılırlığı yüksektir. Ancak bu basitliğin yanında, Scrum uygulamasında tam olarak ustalaşmak zordur. Scrum temel bileşenleri Scrum Ekibi, ekibin rolleri, etkinlikler, çıktılar ve kurallardır.

Scrum Uzmanı, Scrum’ın doğru anlaşılması ve doğru uygulanmasını sağlayan kişidir. Bunun için Scrum kurallarından, rehberlerden ve pratiklerden faydalanır. Ürün iş listesinin anlaşılır ve kısa parçalardan oluşması konusunda Ürün Sahibine yardımcı olur. Scrum Uzmanı ayrıca hizmetkâr-lider olarak da isimlendirilir. Bunun sebebi, Scrum Uzmanının aynı zamanda ekibin en verimli ve değer üreten şekilde çalışmasına yardımcı olmasını sağlama sorumluluğunun da bulunmasıdır. Geliştirme Ekibinin ilerlemesine engel olan problemleri çözmeye çalışır.

Ürün Sahibi, ürünün değeri ve geliştirmesinden sorumludur. Yapılacak iş listesini oluşturur ve önceliklendirir.

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 süresi boyunca ekip, belirli bir Sprint hedefi doğrultusunda iş parçalarını geliştirir. Süre sonunda “bitti” olarak nitelendirilen iş parçaları ile yayınlanabilir ve kullanılabilir bir ürün ortaya çıkar.

Sprint süresince bir amaca uygun olarak geliştirme yapılır ve amacın başarılmasına olumsuz etki edecek değişikliklerden mümkün olduğunca kaçınılır. Ayrıca hedefi gerçekleştirirken ürün kalitesinden feragat edilmez. Ancak her ne kadar amaca olumsuz etki edecek durumlardan kaçınılsa da, elde olmayan sebeplerden dolayı Ürün Sahibi ve Geliştirme Ekibi Sprint amaç ve kapsamını revize edebilir. Bir Sprint biter bitmez hemen diğer Sprint başlar, arada boşluk yoktur. Sprintin uzunluğunun ekibe ve ürüne göre en baştan belirlenerek tüm Sprintlerin aynı uzunlukta olması, çıktıların doğru değerlendirilmesi açısından önem arz eder.

Bir Sprint biter bitmez hemen diğer Sprint başlar, arada boşluk yoktur. Sprintin uzunluğunun ekibe ve ürüne göre en baştan belirlenerek tüm Sprintlerin aynı uzunlukta olması, çıktıların doğru değerlendirilmesi açısından önem arz eder. Bu sebeple ekip ilk Sprint ile Sprintleri hangi uzunlukta yapacağına (1 hafta, 2 hafta, 1 ay vb.) karar verir. Sprint dışı bir zaman olmadığı için, diğer Scrum etkinlikleri Sprint içinde yapılır. Bunlar, Sprint Planlama, Günlük Scrum, Sprint Değerlendirme ve Sprint Retrospektifidir.

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

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