Çevik(Agile) Yazılım Geliştirme Metodolojileri

         Agile Software Development(Çevik yazılım geliştirme), yazılım geliştirme süreçleri içerisinde(SDLC-Software Development Life Cycle) kabul edilen etkin bir yazılım geliştirme metodoloji türüdür. En iyi yazılım ürününü, en hızlı, en güvenli, yazılım geliştirme paradigmalarına en uygun olarak geliştirmek, SDLC nin ilk zamanlarından itibaren ortaya çıkan, şekillenen bir sorun olmuştur. Buna çözüm olarak, Waterfall, Spriral, … ve son olarak Çevik yazılım geliştirme methodolojisi 2000 li yılların başlarında bir grup software development influencer tarafından duyurulmuştur.  2001 yılında Utah, Snowbird'deki bir kayak merkezinde 17 kişilik software development influencer kendi aralarında çevik yazılım geliştirme yaklaşımları üzerinde hem fikir olup, çevik yazılım geliştirme manifestosu yayınlamışlardır(http://agilemanifesto.org). Ayrıca imzaladıkları manifestoyu, kendileri ile aynı fikirde olup imzalamak isteyenlere de açmışlardır(http://agilemanifesto.org/display/index.html).

Bu manifesto da;

Süreçler ve araçlardan ziyade bireyler ve etkileşimlere
Kapsamlı dökü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 verdiklerini, çevik yazılım geliştirebilme açısından sol taraftaki maddelerin değerini kabul etmekle birlikte, sağ taraftaki maddeleri daha değerli bulduklarını ifade etmişlerdir.

Manifestonun detayında ise; 12 temel prensibi(http://agilemanifesto.org/principles.html) benimsemişler ve bunları da kayıt altına alıp imzalamışlardır. Bu prensipler;

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 sabit tempoyu sürekli devam ettirebilmelidir.

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.

Manifestoyu ilk imzalayanlar(http://agilemanifesto.org/authors.html);

Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler

James Grenning Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Brian Marick

Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland Dave Thomas

            Çevik Yazılım Geliştirme Manifestosu ve arkasındaki 12 ilkede ifade edilen değerleri uygulayan şirket, kurum veya organizasyonlar kendilerine özgün uygulama şekillerine göre bu metodolojiden avantaj sağlarlar. Tabiiki dezavantajlı durumlar da söz konusudur. Bu metodolojinin; 

Avantajları;

·         Kısa planlanmış döngüler, değişen gereksinimler ve ani ortaya çıkabilecek değişiklikler için agile metodoloji, kullanan organizasyonlara esneklik imkânı sağlar.

·         Nihai hedefin açıkça tanımlanmadığı yazılım projeleri için faydalıdır. Yazılım projesi ilerledikçe hedefler ortaya çıkacak ve yazılım ürünü bu gelişen gereksinimlere kolayca adapte olabilecektir.

·         Müşterilerin yada proje sahiplerinin ürünlerini oluşturmak ve bu ürünlerle ilgili çıkan problemleri kolayca çözebilmek için müşteri yada proje sahiplerinden aktif bir şekilde geribildirim alınabilmesini sağlar.

·         Ekip katılımına öncelik verilerek kurulan iletişim sayesinde yazılımsal sorunların daha hızlı ve etkin çözülmesini sağlar.

·         Yazılım projeleri hızla ilerlerken ortaya çıkan her problem, bir sonraki döngüde daha iyi bir çözüm için önceki döngüleri basamak olarak kullanabilir. Her yineleme (sprint) sırasında test yapmak, hataların daha hızlı tanımlanmasına ve çözülmesine katkı sağlar. Yazılım projeleri; bu yöntem ile daha tutarlı ve art arda yinelenen adımlarla daha hızlı yazılım ürününü ortaya çıkartabilmeyi sağlar.

·         Müşterilerin, teslim edilen işi görmeleri, girdilerini paylaşmaları ve son ürün üzerinde daha etkili olabilmeleri için çok fazla fırsatları vardır. Müşteriler, yazılım proje ekibiyle çok yakın çalıştıklarından yazılım ürününe olan sahiplik duyguları ve motivasyonları da daha fazladır.

Dezavantajları;

·         Ürün gereksinimleri sürekli değişebileceğinden maliyetler peşinen tahmin edilemez.

·         Müşteriler geri bildirim vermek istediklerinde, akıllarına gelebilecek yeni istekler ek fazları ortaya çıkarır. Agile software development, belirli süreli yinelemeli çıktılara dayalı olduğundan ve proje yöneticileri genellikle görevleri tekrarlamakta olduğundan, başlangıçta teslimat için planlanan bazı öğelerin zamanında tamamlanamaması olasıdır. Yani, projenin herhangi bir anında yeni bir sprint eklenebilir. Bu gibi durumlarda yazılım projelerinin maliyetlerinin artması ve belirlenen bitirme sürelerinin uzaması söz konusudur.

·         Müşterilerden, proje sahiplerinden sürekli geri bildirim almak çalışma ekiplerini alaşağı edebilir ya da bazı müşterilerin zamanı ve hiç ilgisi olmayabilir.

·         Yazılım projelerinin başarısı için gerekli olan dökümantasyon ihmal edilebilir; Agile Manifesto, kapsamlı bir dokümantasyon yerine çalışan yazılımı tercih eder, bu nedenle bazı ekip üyeleri, dokümantasyona odaklanmayı daha az önemli gibi hissedebilirler. Kapsamlı dokümantasyon, proje başarısına yol açmamakla birlikte, çevik takımlar dokümantasyon ve çalışan yazılım arasındaki doğru dengeyi mutlaka bulmalıdırlar. Yani dökümantasyonu olmayan yazılım kaliteli yazılım değildir. Dökümantasyon ile ilgili çok detaylı kapsamdan uzaklaşmak başarıyı artırır önerisi vardır.(“Büyük harita” deyimi)

·         Çevik yazılım projeleri ilk başlarda kesin bir plana sahip olmayabilir, bu nedenle nihai ürün başlangıçta tasarlanandan çok farklı görünebilir. Agile software development çok esnek olduğu için, değişen müşteri geri bildirimlerine dayanarak yeni iterasyonlar eklenebilir. Bu da çok farklı bir hedefe gitmeye yol açabilir. Yazılım projesinin başında hedeflenmiş olan ürün ile proje bitiminde sonuçlanan ürün arasında çok fark olması, müşterileri ve proje sahiplerini olumsuz etkileyebilmektedir.

·         Agile metodolojisini; müşteri ile iletişimi zor olan büyük kurumsal yapılarda uygulamak zor olabilir. Bunun için Agile dönüşüm danışmanlığı veren firmalardan destek alınması yada şirket, kurum yada organizasyon içerisinde bir birim kurup ilgili yetkin personelleri istihdam etmek gerekebilir.

·         Agile methodolojisini uygulamak tek başına yazılım ekiplerinin, sadece bir takımın yada bir kişinin uygulayabileceği bir pratik değildir. Eğer müşteri ile beraber organizasyondaki yönetim, alt yönetim ekipleri ve yazılım geliştirme ekipleri ile birlikte çevik yazılım geliştirme metodolojisi uygulanamazsa yazılım projelerinin çevikliğinden bahsetmek söz konusu olamaz. Yani bu durumda SDLC süreci daha da hantallaştırılmış olur.

Sonuç : Agile metodolojiler 2001 yılında fiilen duyurulmuş olsada, bu ilk başlangıç adımı olarak nitelendirilmiştir. Agile manifesto sunu imzalayanlar “Agile Alliance(çevik ittifak)” isminde bir gönüllü topluluk da oluşturmuşlardır(www.agilealliance.org). “Manifesto for Agile Software Development'ın” orijinal yazarları; “Agile Manifesto'yu yazarak ve Agile Alliance'ı başlatarak Agile yazılım geliştirme gemisini inşa edip denize bıraktıklarını, ancak geminin yelken açmasına ve çevik gelişim liderliğinin bu geminin çok ötesine yayılmasına izin vermekten mutlu olduklarını” ifade etmişlerdir.

Çevik yazılım geliştirme frameworkleri ve yöntemleri olarak; Extremming Programming, Lean Software Development(LSD), Feature-Driven Development(FDD), Adaptive System Development(ASD), Dynamic Systems Development Method(DSDM), Cristal Clear, Test-Driven Development, Rapid Application Development, Emprical Control Method, Scrum, Kanban, Scrumban, … gibi framework ve yöntemler günümüzde tercih edilmektedir. Ancak çeviklik yaklaşımında öyle bir açık kapı ifadesi bırakılmıştır ki her yazılım geliştirme ekibine göre özgün olarak uygulama pratiği söz konusudur. Bu yüzden çevik yazılım geliştirme frameworkleri ve yöntemleri her geçen gün çeşitlenmeye devam etmektedir. Cevik yazılım geliştirme prensiplerinin bir adım ötesini arama çabası olarak, “çıtayı yükseltmek” mottosuyla, 2009 yılında “Software Craftsmanship manifestosu(https://manifesto.softwarecraftsmanship.org/)” bir grup developer community tarafından duyurulmuş ve imzaya açılmış bulunmaktadır. Dolayısıyla, çeviklik metodolojisinin yeni implementation(uyarlama)ları ilerleyen zaman içinde daha da gelişip çeşitlenmeye, evrim geçirmeye devam edecek gibi gözükmektedir.

Not: Çevik yazılım geliştirme metodolojisi ile ilgili, literaturde olan yayınlanmış kaynakları tarayarak bu notları yazmış bulunmaktayım. Özellikle avantaj ve dezavantajlar somut tecrübe isteyen yorumlar olacağından, deneyim ve gözlemlerime göre makaleyi güncellemeyi planlamaktayım.

Kaynaklar:

• https://www.pem360.com/blog/Agile/Agile-Yontemlerin-Avantajlari-ve-Dezavantajlari/183
• http://agilemanifesto.org
• http://agilemanifesto.org/iso/tr/principles.html
• http://manifesto.softwarecraftsmanship.org/#/tr
• https://www.bukrek.com/artilari-ve-eksileri-ile-agile-yontemler
• https://www.agilealliance.org/agile101/
• https://www.agilealliance.org/the-alliance/
• https://www.acmagile.com/agile-nedir/
• https://www.acmagile.com/googlein-basarili-takimlarinin-sirri-psikolojik-guvenlik/

Takım iletişiminde, Adaptif ve Plan odaklı yaklaşım

Takım dinamikleri ve iletişim yönetimi açısından, Şirket/Kuruluş içerisinde yazılım geliştirme ekipleri arasındaki, Plan odaklı(geleneksel) ve Adaptif(çevik) yaklaşımların farkları aşağıdaki gibi özetlenebilir.

Kaynaklar :

• https://www.linkedin.com/pulse/tak%C4%B1m-dinamikleri-ve-ileti%C5%9Fim-adaptif-plan-odakl%C4%B1-dilek
• http://www.agilealliance.org/the-alliance/the-agile-manifesto/the-twelve-principles-of-agile-software/

SCRUM’a Giriş

Agile (çevik), dünya üzerinde kabul edilen yöntemler arasında hızlı ve güvenli proje geliştirme yaklaşımıdır.Scrum, en kısa zamanda en yüksek iş değerini teslim etmeye odaklanmamızı sağlayan bir agile süreçtir. Hızlı ve tekrar tekrar asıl çalışan yazılımı denetlememize imkan verir. İş birimi önceliklerini belirler. Takımlar, en öncelikli yetenekleri teslim etmek için, en iyi yolu, en iyi yöntemi, kendiliğinden organize olarak belirlerler. Her 1 hafta veya 1 aylık sürede gerçek, çalışan yazılım ortaya çıkarılır. Yaygınlaştırma veya bir sprint daha bu ürün üzerinde çalışılma kararı verilir.

Karakteristikleri:

•          Kendiliğinden organize takımlar,

•          1 ay uzunluğundaki “Sprint”lerde ürün geliştirilir,

•          Gereksinimler “Product Backlog” içerisinde maddeler olarak tutulur,

•          Herhangi bir mühendislik pratiği tanımlı değildir,

•          Proje teslimatı yapılan Agile bir ortam yaratmak için üretken kurallar kullanır,

•          “Agile süreçlerden” birisidir.

Çevik Yazılım Geliştirme Manifestosu;

Scrum Döngüsü;

Scrum Sprintleri:

•          Scrum projeleri Sprint’ler süresince ilerler(Extreme Programming’deki iterasyonlar gibi),

•          Süresi 1–4 hafta veya en fazla 1 takvim ayıdır,

•          Sabit Sprint süresi, daha iyi ritim yakalanmasını sağlar,

•          Sprint süresince ürün tasarlanır, kodlanır ve test edilir.

Ürün Geliştirme Tekniği;

Sprint sürelerinde değişiklik yapılmaz ; Sprint süreleri, ne kadar süre değişikliği sprintin dışında tutulabileceğine göre planlanır.

Scrum Çerçevesi:

ROLLER

a)    Ürün Sahibi

•          Ürünün yeteneklerini belirler,

•          Yaygınlaştırma içeriğini ve tarihini belirler,

•          Ürünün karlılığından sorumludur (ROI),

•          Pazar değerine göre yetenekleri önceliklendirir,

•          Gerektiği durumda her iterasyon yeteneklerini ve öncelikleri günceller,

•          İş sonuçlarını kabul veya reddeder.

b)    Scrum Master

•          Projede yönetimi temsil eder,

•          Scrum değer ve pratiklerinin içselleştirilmesinden sorumludur,

•          Engelleri ortadan kaldırır,

•          Takımın tam olarak fonksiyonel ve üretken olduğundan emin olur,

•          Tüm roller ve fonksiyonlar arasındaki yakın işbirliğini sağlar,

•          Dış müdahalelerden takımı korur.

c)    Takım

•          Genellikle 5-9 kişidir,

•          Disiplinler arası yetenekler bulunur(Yazılımcılar, test mühendisleri, kullanıcı deneyimi tasarımcıları, vb.),

•          Takım üyeleri tam zamanlı olmalıdır(Bazı özel durumlar olabilir; Veritabanı yöneticileri gibi),

•          Takımlar kendiliğinden örgütlüdür (self organized),

•          İdeal olarak hiç bir ünvan yoktur (çok nadiren olabilir),

•          Takım üyeleri sadece sprintler arasında değişmelidir.

TOPLANTILAR

a)    Sprint Planlama

Sprint planlama işlemleri;

v  Takım bitirmek için taahhüt verebileceği maddeleri ürün iş yığınından seçer,

v  Sprint Görev Yığını oluşturulur,

    Ø  Görevler belirlenir ve tahmin yapılır (1-16 saat),

    Ø  Sadece Scrum Master tarafından değil, ortak olarak yapılır.

v  Üst seviye tasarım düşünülür.

Örneğin;

gibi.

b)    Ne var? Ne yok? Toplantısı

v  Parametreler (Günlük, 15 dakika ve ayakta yapılır),

v  Problem çözmek için değildir,

Ø  Tüm dünyayı davet edebilirsiniz,

Ø  Sadece takım üyeleri, Scrum Master, Ürün Sahibi konuşabilir.

v  Diğer ekstra toplantıların düzenlenme ihtiyacını ortadan kaldırır

Herkes 3 soruyu cevaplar;

v  Bunlar Scrum Master’a durum bildirmek için değildir. Takım üyelerinin önünde verilen taahhütlerdir.

c)    Sprint Ürün Gözden Geçirme

•          Takım, sprint süresince ne tamamladığını sunar,

•          Genellikle yeni yeteneklerin ve mimarinin demosu şeklindedir,

•          Resmi değildir (2 saat hazırlanılır, slayt olmaz),

•          Tüm takım katılır.

d)    Sprint Süreç Gözden Geçirme

•          Her sprint sonunda yapılır,

•          Periyodik olarak iyi ve kötü giden noktalara bakılır,

•          Genellikle 15–30 dakika sürer,

•          Tüm takım katılır(Scrum Master, Ürün Sahibi, Takım, Belki müşteriler ve diğerleri),

•          Başla/Dur/Devam Kararının verilmesi; Tüm takım bir araya gelir ve yapılmak istenenleri tartışır.

 ÇIKTILAR

a)    Ürün İş Yığını

•          Gereksinimler,

•          Projede yapılması istenen tüm işlerin listesi,

•          İdeal olarak her maddenin müşteri veya kullanıcı açısından bir değeri vardır,

•          Ürün sahibi tarafından önceliklendirilmiştir,

•          Her sprint başlangıcında tekrar önceliklendirilir.

Örnek iş yığını;

Sprint Hedefi: Sprintte yapılacak işin odaklanacağı noktayı tanımlayan kısa ifadedir.

b)    Sprint Görev Yığınının Yönetilmesi

•          Bireyler kendi yapacakları işleri seçerler(Asla iş ataması yapılmaz!),

•          Kalan tahmini iş miktarı her gün güncellenir,

•          Takım üyeleri, Sprint Görev Yığını üzerinde ekleme, silme ve güncelleme yapabilir,

•          Sprint işleri gelişir,

•          Eğer net değilse, daha yüksek tahminli bir Sprint Görev Yığını maddesi tanımlanır, sonra parçalara ayrılır,

•          Yapılacak iş daha çok belli olmaya başlayınca kalan iş miktarı güncellenir.

Örnek Sprint görev yığını;

c)    Eksiltmeli İş Bitirme Çizelgesi

Ölçeklenebilirlik;

v  Genellikle takımlar 7 ± 2 kişidir

Ø  Ölçeklenebilirlik, takımların takımından gelmektedir

v  Ölçekleme Faktörleri

Ø  Uygulamanın tipi

Ø  Takım boyutu

Ø  Takım dağılımı

Ø  Proje süresi

v  Scrum 500+ kişiden oluşan projelerde kullanılmaktadır

Kaynaklar:

·         http://www.scrumturkey.com/

·         www.agilemanifesto.org

·         www.mountaingoatsoftware.com/scrum

·         “The New New Product Development Game” by Takeuchi and Nonaka. Harvard Business Review, January 1986