SDLC Modellerine Genel Bakış

Bir önceki yazımızda standart bir yazılım geliştirme modelinin aşamalarından ve bu aşamalarda görev alan rollerden bahsetmiştik. Eğer denk gelmediyseniz, konu bütünlüğü açısından okumanızı tavsiye ederim. (Bir önceki yazıya buradan ulaşabilirsiniz.)

Bu yazımızda ise yazılım geliştirme modellerinden bahsedeceğiz. Yazılım geliştirme modelleri geleneksel ve çevik (agile) modeller olarak ikiye ayrılır. Biz bugün geleneksel modellerden “Waterfall” modelini; çevik modellerden ise “Scrum” modelini inceleyeceğiz.

Waterfall (şelale) modeli

Geleneksel yazılım geliştirme modellerinden biridir ve diğer geleneksel modellerin (V modeli, barok model vb.) temelini oluşturur. Bu model, yazılım geliştirmede kullanılan en erken SDLC yaklaşımıdır. Modelin içerisindeki süreçler ismi ile benzerlik gösterir ve bir şelalenin yukarıdan aşağıya kesintisiz bir şekilde akması gibi Waterfall modelinde de her aşama bir önceki aşamanın tamamen bitmesiyle başlar. Bu modelde proje fazları çakışmaz. 1970’li yılların ortalarında yapısal sistem geliştirme metodolojileri ile birlikte ortaya çıkmıştır. Yazılım üretiminde belirtilen yaşam döngüsü adımlarını baştan sona bir kez izleyerek gerçekleştirir. Özellikle gereksinimleri iyi tanımlanmış projeler için daha uygun bir model olarak bilinir. 

Eğer yazılımımızın gereksinimlerinde belirsizlik yok ya da çok az belirsizlikler bulunuyorsa ve isterlerimizin sürekli değişeceği durumlar yoksa bu model kullanılabilir.

Ancak bu saydığımız özellikler günümüzde çok fazla rastladığımız durumlardan değildir. Günümüzdeki modern yazılım projelerinde isterlerin değişmesi veya müşterilerin yeni gereksinimler talep etmesi normal bir durumdur. 

Waterfall modelinde ise değişim ve yenilikler zordur. Bu nedenle günümüzde, geleneksel model olarak da adlandırılan Waterfall modelinin kullanımı azalmaktadır. Daha çok askeri ve devlet kurumlarının projelerinde  kullanılmaktadır. 

Agile prensipleri ve scrum modeli

Teknolojinin ve ihtiyaçlarımızın değişmesi ile birlikte yazılım ürünleri ve bu ürünleri geliştirme süreçleri de değişime uğradı. Bu değişimler yazılım geliştirme modellerini de etkiledi. Geleneksel modellerdeki değişime ayak uyduramama sorunu, günümüzdeki yazılım projelerinde geleneksel modellerin uygulanmasını zorlaştırıyordu. 2001 yılında Amerika’da 17 yazılım üstadı bir araya gelip yazılım geliştirme ile alakalı iki günlük bir toplantı yaptılar. Toplantının amacı yazılım geliştirme süreçlerindeki üretkenliği arttırmak ve daha başarılı yazılım geliştirme süreçleri oluşturmaktı. Toplantı sonucunda kabul edilen dört maddelik bir metni “çevik yazılım geliştirme manifestosu“ ismi ile yayınladılar. Bu bildirge geçtiğimiz o günden bu yana yazılım projelerinde başarıyla uygulandı ve uygulanmaya da devam ediyor.

Agile manifesto’nun türkçesi 

“Süreçler ve araçlardan ziyade bireyler ve aralarındaki 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, kanaat getirdik.

Özetle sol taraftaki maddelerin değerini kabul etmekle birlikte sağ taraftaki maddeleri daha değerli bulmaktayız.”

Ayrıca bu toplantıda çevik yazılımın 12 prensibi adında bir belge de yayınlanmıştır. Bu 12 madde günümüzde başarılı yazılımlar üretmek için uyulması gereken maddelerdendir. 

“Bizler şu ilkeleri izliyoruz; 

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ıklara belirlenerek birkaç haftada ya da birkaç ayda bir düzenli olarak müşteriye sunmalı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 sabit tempoyu sürekli devam ettirebilmelidir. 
9. Teknik mükemmelliyet ve iyi tasarım konusundaki sürekli özen çevikliği arttırır.
10. Sadelik yapılmasına gerek olmayan işlere mümkün olduğunca arttırılması sanatı olmazsa olmazlardandır.
11. En iyi mimarilerin gereksinimleri tasarımlanırken, kendi kendini örgütleyen takımlar da 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 (agile) modeller başlığı, geleneksel modellerde olduğu gibi içinde Scrum, XP, crystal, FDD gibi bir çok alt modeli barındırır. Bu modeller arasında en çok kullanılan ve başarılı olan model scrum modelidir.

Scrum modeli

Scrum; agile şemsiyesi altında bulunan yazılım proje yönetimi metodolojilerinden birisidir. Agile prensiplerinin başarılı bir şekilde uygulanabilmesi için gerçekleştirilen bir dizi süreçten oluşur. Karmaşık ve değişken yazılım süreçlerinin yönetilmesi için kullanılır. Projeyi yönetirken bütünü parçalayarak ilerler. Değişen müşteri ihtiyaçlarına yönelik geri bildirimlerle hedefe ulaşmayı savunur ve esnek bir yapısı vardır. İletişim ve takım çalışması çok önemlidir. 3 temel prensip üzerine kurulmuştur;

• Şeffaflık; projenin ilerleyişi, sorunlar, gelişmeler herkes tarafından görülebilir olmalıdır.
• Denetleme; projenin ilerleyişi düzenli olarak kontrol edilir.
• Uyarlama; proje, yapılabilecek değişikliklere uyum sağlayabilmelidir.

Şimdi de scrum metodolojisindeki rollere, toplantılara ve kavramlara göz atalım
 

Scrum takımındaki roller

Bir scrum takımı genel olarak Ürün Sahibi (product owner), geliştirme ekibi ve scrum master’dan oluşur. Takımlar kendi kendini yönetir bu nedenle kendi içerisinde uyum içinde olan takımlar daha başarılı sonuçlar alırlar. 

Product owner

Geliştirme takımı ve müşteri arasındaki iletişimi sağlar ve köprü görevi görür. Projenin özelliklerini tanımlar. Projenin önceliklerine göre product backlogu (proje gereksimlerini içeren belge) oluşturur. Sprint’i (takımın hedeflerini tamamlaması için 2 veya 4 hafta süren süreç) iptal yetkisine sahiptir. Hızla değişen ortamlarda bir sprinte alınan işlerin iş birimi/müşteri için önemi kalmamış olabilir ya da sprinte alınan işlerden daha önemli işler ortaya çıkabilir. Product Owner bunu görüp sprinti iptal etmek isteyebilir.

Scrum master

Scrum kurallarını, teorilerini ve pratiklerini iyi bilir ve takımın bu kurallarını uygulamasından sorumlu kişidir. Takımın yöneticisi değildir. Takımı rahatsız eden, verimli çalışmalarını engelleyen durumları ortadan kaldırır.

Geliştirme takımı

 Bir Sprint’e alınan bütün işleri tamamlayacak özelliklere sahip kişilerdir. Kendi kendini yönetir. İşin verilmesini beklemezler, işi kendileri alır ve geliştirirler. Kişilerin tek bir görevi yoktur, çapraz görev dağılımı yaparlar. 5–7 kişi arasında değişken sayıdan oluşur. Projenin geliştirilmesi ile ilgili sorumluluk geliştirme takımına aittir. Geliştirme takımında sadece developerlar değil; designers, analyst ve testerlar da bulunabilir. 

Scrum’ın işleyişinde aktif olarak yer almayan roller de vardır müşteriler, satıcılar gibi.

Scrum metadolojisindeki bazı kavramlar

Product Backlog

Proje için gerekli olan gereksinimler listesidir. Proje sonunda “Ne üretilmek isteniyor?” sorusuna cevap aranır. Product owner tarafından müşteriden gereksinimler alınır, öncelik sırasına göre sıralanır. Product owner, değişen ihtiyaçlara göre product backlog’a ekleme veya çıkarma yapabilir. Böylece değişim, projenin her aşamasında projeye kolayca entegre edilebilir olur.

Product backlog tem

Product backlog içindeki her bir gereksinime verilen isimdir.

Sprint (koşma)

Proje sprint denilen küçük kısımlara ayrılır. Scrum içerisindeki tüm aktiviteler sprint içerisinde gerçekleşir. 1–2 haftalık süreçlerdir.

Sprint backlog

Geliştirme takımı tarafından product backlog itemler öncelik sırasına göre sprint içerisine alınırlar. Bir sprint boyunca yapılacak itemlerin listesini oluşturur. İşlerin detaylı olarak zaman çizelgesi çıkarılır.

Scrum board

 Bir sprint içerisinde yapılacak olan maddeler burada yönetilir. Yapılacak olan tasklar “to-do” bölümüne alınır. Takım üyesi bu işe başladığında “in progress” bölümüne getirilir. Bir iş, test için hazırsa “to verify” durumuna getirilir. İş, kontrol edildikten sonra “done” bölümüne getirilir. Scrum toplantılarında bu maddeler durumlarına göre yerleri değiştirilir.

Burndown chart

Sprint esnasında, kalan iş ve yapılan iş arasındaki ilişkiyi belirten bir grafiktir. Bu grafik takım üyelerine veya yöneticilerine zamanlama açısından fikir verir. 

User story

Müşteri, son kullanıcı veya ürün sahibi için değerli olan ve anlam ifade eden genellikle fonksiyonel özelliklerin belirtildiği  ifadelerdir.

Örnek user story: Online alışverişlerimde kullanmak için kartımın kaydedilmesini istiyorum.
Her gereksinim için gereken iş gücü ve zaman aynı değildir. Bu sebeple ürün backlogları sprintlere bölünürken, user storylerin boyut ve öncelikleri göz önünde bulundurulur. Örneğin bir sprint 3 user story içerirken diğeri daha küçük boyutlarda 5 user story içerebilir. 
 

Poker kartları

User story boyutlarının belirlenmesi için kullanılır. Scrum master’ın okuduğu user story takım tarafından puanlanır. Puanlamada Fibonacci dizisindeki sayılar kullanılır.

Scrum toplantıları 

Sprint planning 

Her sprint'i başlatan etkinliktir. Product owner ve development ekibinin sprint'e hangi ürün iş listesi öğelerinin (PBI'ler) dahil edileceğini tartıştığı yerdir. Planlama Toplantısının sonucu, herkesin kabul ettiği gerçekçi ve ulaşılabilir bir sprint hedefi ve sprint iş listesi elde etmektir. User storyler puanlanır ve sprint backlog’a aktarılır. Sorumluluklar paylaşılır. Sprint bu toplantı ile başlar.

Daily scrum (Daily stand-up) -  (Günlük scrum)

Daily scrum 15 dakika kadar sürer.Geliştirme Ekibinin check-in yapması, sprint hedefine ulaşma yolundaki ilerlemeyi değerlendirmesi ve önümüzdeki 24 saat boyunca faaliyetlerini gözden geçirmesi ve planlaması için bir fırsattır. Genelde “Dün neler yaptık? Bugün ne üzerinde çalışacağız? Herhangi bir sıkıntı ile karşılaştık mı?“ sorularına cevap verilir.

Grooming meeting

Yapılması zorunlu değildir ve teorik olarak scrum toplantıları arasında zikredilmiyor olabilir ancak sıklıkla uygulanabilen bir toplantıdır ve uygulanması faydalıdır. Ekipten ekibe değişmekle beraber sprintin sonuna yakın bir zamanda, sprintin bitiş tarihinden 2-3 gün önce veya bir sonraki sprint planning toplantısından 3-4 gün önce yapılabilir. Amacı bir sonraki sprint planning toplantısının daha verimli geçmesini sağlamaktır. Bunu şu şekilde açıklayabilirim; Henüz içinde olduğumuz sprint bitmemişken bir sonraki sprintte yapılması gereken işlerle alakalı bir toplantı yapmak garip gelebilir. Fakat ekipten ekibe, projeden projeye değişmekle beraber planlama toplantıları saatler sürüyor olabilir ve planlama toplantısında bir çok user story ilk kez görülüyor olabilir. User storyler çok büyük olabilir ve parçalanması gerekiyor olabilir. Bu durumlar sprint planning toplantılarının çok uzun sürmesine neden olur. Ayrıca saydığımız durumlar user story puanlamalarında sapmalara neden olur ve verim düşer. İşte grooming toplantıları bu sorunların çözümü için; sprint planning toplantılarında takımın karşısına daha önce görmediği bir user story çıkmaması, user storyler üzerinde önceden düşünülmüş olması ve bu sayede planning toplantılarında takımın daha isabetli zaman tahminleri yapabilmesi, böylelikle de daha başarılı işler ortaya çıkması adına düzenlenen bir toplantıdır. Bu sayede bir sonraki planlama toplantısı çok daha verimli geçer ve uzun saatlerimizi almaz. Product owner bir sonraki sprint’in planlama toplantısına hazırlıklı olarak gelebilir.

Sprint review (Demo) - (Sprint incelemesi)

Sprint review genellikle sprint'in son gününde yapılır ve stakeholder’lara (müşteriler, yönetim ve ilgili ve ilgilenilen diğer herkes) “done” (tamamlanmış) yapılan işi gösterme fırsatı verir. Demo esnasında aldığımız geri bildirimler bir sonraki sprintte yapılacak işler için belirleyici olabilir.

Sprint retrospective (Geriye dönük sprint değerlendirmesi)

Sprint retrospective sprint'teki son toplantıdır. Scrum ekibi gelecekteki sprint'ler için nelerin geliştirilebileceğini ve nasıl yapmaları gerektiğini gözden geçirir. Ne tür engellerle (impediment) karşılaştılar, hangi fikirlerin ve güncellemelerin daha fazla gelişim sağlamalarına katkıda bulunduğunu değerlendirirler. Ekibin bir sonraki sprintte daha mutlu ve başarılı olması için fikirler alınır.

Yazımın sonuna gelirken bir konuyu daha ifade etmenin iyi olacağını düşünüyorum; Scrum gibi metodolojiler birebir olarak kitapta yazdığı gibi uygulanmak zorunda değildir. Bunlara ek olarak ekibinizin ihtiyaçlarına göre yeni süreçler geliştirebilirsiniz. Zaman ayırdığınız için teşekkürler umarım faydalı olmuştur. Bir sonraki yazıda görüşmek üzere…

Teknolojinin her alanında olduğu gibi yazılım geliştirme metodolojilerinde de sürekli olarak daha iyiye doğru gelişim gösterme durumu vardır. Yazılım üretiminin başladığı yıllarda waterfall model ile başlayan süreç, teknolojinin gelişmesi ve  ihtiyaçların değişmesiyle birlikte waterfall modelden daha çevik ve değişime daha çabuk adapte olup aksiyon alabilen modellere doğru gelişmiştir. Bu modellere  çevik modeller denir. Scrum ise çevik modeller arasında en popüler ve sistematik olarak ilerleyen modeldir. Yazılımın hangi alanında çalışırsak çalışalım günümüzdeki şirketlerin çoğunda çevik modeller kullanılmaktadır. Özellikle scrum modeline ve bu modelin barındırdığı süreçlere hakim olmak bize büyük faydalar sağlayacaktır.

Kaynaklar

• Martin, Micah, and Robert C. Martin. Agile principles, patterns, and practicesNin C#. Pearson Education, 2006.
• Kniberg, Henrik. "Scrum and XP from the Trenches." Lulu. com (2007).
• Kniberg, Henrik. " What is agile", 2013
• Wikipedia, Agile software development
• Cihan yılmaz blog, Product backlog refinement (Grooming) nedir?
• Scrum guides, Scrum-guide-tr 
• Agilistanbul, Blog