Ünite 1: Çevik Yazılım ve Scrum Yöntemi

Giriş

Çevik yazılım geliştirme yöntemleri, değişikliklere daha hızlı adapte olmayı hedefleyerek yazılım projelerinde daha başarılı bir yöntem olarak öne çıkmaktadır. Ayrıca çevik yöntemler, yazılımı talep edenler ile yazılımı geliştirenler arasında sürekli iletişim ve ortak hedef oluşturmayı gerektirdiğinden, tüm paydaşların memnuniyetini de arttırmaktadır.

Çevik yazılım geliştirme pratikleri, yazılımın yapısı üzerine doğrudan veya dolaylı olarak etki ederek, yüksek doğrulukta ve gereksinimleri karşılayan bir ürün ortaya çıkmasını sağlar. Bu pratikler, yazılım geliştirme sürecinde geri dönüşüm sağlayarak, çevik yazılım geliştirme yöntemine katkı sağlarlar. Çevik yazılım geliştirme yöntemlerinin bazıları yazılım geliştirme pratikleri üzerine yoğunlaşırken, bazıları yazılım geliştirme iş akışı üzerine yoğunlaşmaktadır. Birkaç yöntem ise tüm yazılım yaşam döngüsü üzerinde yoğunlaşmıştır. Bu yöntemlerden en çok kullanılanı Scrum yöntemi olarak bilinmektedir.

Scrum, öğrenmesi kolay ve esnek bir çevik yazılım geliştirme yöntemidir. En temel özellikleri şeffaf, gözleme dayalı ve tekrarlamalı (iterative) olmasıdır. Scrum yönteminde yazılımı geliştiren ekip, sabit süreli tekrarlamalar (iterasyon) süresince, önceden paydaşlar ile birlikte belirlenen ve en çok fayda sağlayan yazılım parçalarını üretirler. Tekrarlama sonunda ise çalışan bir ürün parçacığı paydaşların kullanımına ve değerlendirmeye sunulur.

Çevik Yazılım Prensipleri ve Yöntemleri

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. Yazılımdan beklenen özellikler, yazılım henüz tam bir ürün haline gelmeden değişmiş ve şelale yöntemi ile geliştirilen yazılım kullanıma açıldığında işlevsellik ve sağladığı fayda açısından çoktan kullanışsız hale gelmiş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.

Schwaber, 1995 yılında Jeff Sutherland ile birlikte çalışarak “Scrum Software Development Process” (Scrum Yazılım Geliştirme Süreci) isimli bir makale yazarak Oopsla konferansında sunmuştur. Bu tarih, Scrum yönteminin ilk ortaya çıkış tarihi olarak nitelendirilebilir.

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

Bu yöntemlerden en sık kullanılanı Scrum olmuştur. Bunun en önemli sebebi ise basit olmasıdır.

Çevik Yazılım Geliştirme Pratikleri

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.

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.

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.

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 Tanımı ve Temel Bileşenleri

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 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:

1. Şeffaflık gereği süreç boyunca oluşan çıktılar sorumlu herkes tarafından izlenebilmelidir. Bu izlemeden çıkan anlamın aynı olması için ise belirli standartlar tanımlanmalıdır. Örneğin, bir işin bitmiş olarak tanımlanması kavramından herkes aynı şeyi anlamalıdır.
2. Gözlem sonucunda Scrum’da mevcut tekrarlama (iterasyon) için tanımlanan hedefe göre hareket edilip edilmediği belirlenir. Sürecin akışına engel olmayacak şekilde, yeterli seviyede yapılan gözlem çok faydalı olmaktadır.
3. Adaptasyon ile gözlem sonucu farkedilen kabul edilemez bir durumun düzeltilmesi sağlanır. Bu sayede ürün veya süreç çok geç olmadan, mümkün olan en kısa zamanda değiştirilir.

Scrum Ekibi ve Etkinlikleri

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.

Ürün Sahibi, ürünün değeri ve geliştirmesinden sorumludur. Yapılacak iş listesini oluşturur ve önceliklendirir. Ayrıca ürün iş listesinin herkes tarafından anlaşılır olmasını sağlamalıdır. Yapılan işlerin bittiğini kabul eden kişi Ürün Sahibidir.

Geliştirme Ekibi, her bir tekrarlama (iterasyon) sonrasında, ürünün sürüme çıkabilir bir kısmını teslim etmekten sorumlu kişilerden oluşmaktadır. Her tekrarlama sonrası tamamlanmış işler belirli bir “Tamamlandı” tanımına uyar. Bu da ürünün kalitesi açısından homojenlik sağlar. Geliştirme Ekibi kendi kendine organize olur.

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.

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.

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.

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. Geliştirme Ekibi toplantı sonrasında Sprint İş Listesindeki iş kalemlerini Scrum Ekip Panosu (Scrum Board) olarak adlandırılan panoya yerleştirir.

Günlük Scrum olarak isimlendirilen toplantı, Geliştirme Ekibinin son bir gün içinde yaptığı faaliyetler ve planladığı faaliyetler hakkında bilgi alış verişini yaptığı toplantıdır. Bu etkinlik için de zaman kısıtı bulunmaktadır ve en fazla 15 dakika sürmelidir.

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.

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

Scrum Eserleri ve Çıktıları

Scrum eserleri ve çıktıları temelde üretilen değeri temsil eder ve bu değeri şeffaf 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.

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

Ürün İş Listesindeki kalemlerin her birinin tanımı, sırası ve tahmin değeri (büyüklük) vardır. Ayrıca işin detayları ve kabul kriterleri de buradadır. İşlerin tahmin değerleri Geliştirme Ekibi tarafından yapılır.

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. Sprint gidişatını gözlemlemek için en etkili yöntem, toplam kalan işi gösteren bir grafik kullanmaktır. Scrum Ekiplerinin kullandığı ve Sprint gidişatının bir bakışta özet olarak olarak anlaşılabildiği bu grafiğe aşağı-tüketim (burndown) grafiği adı verilir. Bu grafik her Günlük Scrum toplantısında güncellenir.

Ü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. Scrum Ekibi, neyin bir Ürün Parçası olduğuna beraber karar verir. Bu ortak tanıma göre bir Ürün Parçası bir veya birden fazla Ürün İş Listesi kaleminden oluşabilir.

Bir Sprint boyunca yapılan işlerin toplam puanı kaydedilir. Bu puan Scrum Ekibinin hızı olarak tanımlanır. Her Sprint için kaydedilen bu değerin ortalaması, ekibin kapasitesi olarak değerlendirilir.

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

Bitti Tanımı önceden belirlenip, herkesin erişebileceği bir yerde sunulmalıdır. Ekipler genellikle Scrum panosunda uygun bir yere Bitti Tanımının özelliklerini yerleştirirler.