Artımlı mı Yinelemeli mi? Eklemek ile Yeniden Ele Almak Arasındaki Fark

Ortak zemin: iki ayrı planlama kararı

Artımlı ve yinelemeli geliştirme çoğu zaman aynı şeymiş gibi, hatta tek kelimeyle "iteratif" diye anılır. Oysa ikisi farklı sorulara yanıt verir. Alistair Cockburn bu ayrımı şöyle kurar: artımlı geliştirme, sistemin farklı parçalarının farklı zamanlarda geliştirilip tamamlandıkça bütüne katıldığı bir aşamalandırma ve takvimleme stratejisidir; yinelemeli geliştirme ise sistemin parçalarını gözden geçirip iyileştirmek için zaman ayrılan bir yeniden çalışma stratejisidir.

Her birinin bir alternatifi vardır. Artımlı geliştirmenin karşıtı, bütün sistemi geliştirip sonda tek seferde birleştirmektir. Yinelemeli geliştirmenin karşıtı ise her şeyi ilk seferde doğru yapmayı planlamaktır. PMI'ın terim sözlüğü de iki yaklaşımı ayrı tanımlar: artımlı yaklaşımda teslimat, yeterli yeteneğe ulaşana kadar işlev eklenerek art arda üretilir; yinelemeli yaklaşımda önce basitleştirilmiş bir ilk uygulama yapılır, sonra bu uygulama aşamalı olarak ayrıntılandırılır.

Ölçüt ölçüt fark

• Ölçüt: Temel soru. Artımlı: Hangi parçayı ne zaman yapıp bütüne katacağız? / Yinelemeli: Hangi parçayı ne zaman yeniden ele alacağız?
• Ölçüt: Kelimenin özü. Artımlı: eklemek. / Yinelemeli: yeniden yapmak.
• Ölçüt: Neyi iyileştirir? Artımlı: geliştirme sürecini ve özellik kümesini; her teslimden sonra süreç ve gereksinimler değişen koşullara göre ayarlanabilir. / Yinelemeli: ürün kalitesini; yanlış anlaşılan gereksinim, kullanışsız arayüz, zayıf mimari burada düzelir.
• Ölçüt: Planlanması. Artımlı: parçalar kolay ayrılır, görece kolay tahmin edilir ve takvime konur. / Yinelemeli: kaç tur düzeltme gerekeceği baştan bilinmez; süre önceden ayrılıp korunmazsa kaybolur.
• Ölçüt: Kullanıcıya gösterilen şey. Artımlı: yeni eklenen, tamamlanmış işlev. / Yinelemeli: üzerinde hâlâ değişiklik yapılabilecek, yarı olgun işlev.
• Ölçüt: Tipik başarısızlık. Artımlı: düzenli teslim edilen ama kullanıcının istemediği ürün. / Yinelemeli: sınırsız değişiklik izniyle sürekli eskiyen tasarım ve kod.

Scrum Kılavuzu Scrum'ı yinelemeli ve artımlı bir yaklaşım olarak tanımlar ve iki boyutu ayrı tutar: her artım önceki artımlara eklenir ve hepsinin birlikte çalıştığı doğrulanır; sprint incelemesi ise sprintin sonucunu inceleyip gelecekteki uyarlamaları belirlemek içindir. Birincisi artımlı, ikincisi yinelemeli taraftır.

Dört olası birleşim

İki strateji birbirinden bağımsız olduğu için bir proje dört durumdan birinde bulunur. Hangisinde olduğunuzu bilmek, hangi sorunla karşılaşacağınızı önceden söyler.

• Ne artımlı ne yinelemeli: Bütün sistem tasarlanır, kodlanır ve sonda birleştirilir; her şeyin ilk seferde doğru olacağı varsayılır. Kapsamı kesin, teknolojisi tanıdık işlerde yürüyebilir ama yanlış anlaşılan bir gereksinim ancak en sonda görülür.
• Yalnız artımlı: Ürün parça parça tamamlanıp eklenir, ancak tamamlanan parçaya geri dönmek için zaman yoktur. Cockburn, çevik olduğunu düşünen ekiplerin sık düştüğü hatanın bu olduğunu söyler: müşteri, düzeltmeyi yeni işi geciktirmek ya da kuyruğun sonuna itmek arasında seçmek zorunda kalır.
• Yalnız yinelemeli: Bütün sistem baştan sona tekrar tekrar elden geçirilir. Bütünü yinelemek, değişikliklerin dalga etkisini kontrol edilemez hale getirir; bir yerdeki düzeltme başka yerleri bozar.
• Artımlı ve yinelemeli birlikte: Ürün parçalara bölünür ve her parça bütüne katılmadan önce bir ya da birkaç kez kullanıcıya gösterilip düzeltilir. Cockburn'ün önerisi budur: ikisini de, farklı miktarlarda kullanmak.

Yinelemenin iki tarzı

Yinelemeli geliştirmenin kendi içinde iki farklı tarzı vardır ve proje yöneticisinin ikisini de tanıması gerekir.

• Önce iyi yap, sonra küçük düzelt: Parça olabildiğince iyi geliştirilir; değişikliklerin küçük kalacağı ve hızla eklenebileceği varsayılır. Cockburn'ün örneğinde bir müzisyen parçanın tamamını kaydeder, görüntüyle uyuşmayan küçük bir bölümü yeniden kaydedip yerine ekler.
• Önce az yap, erkenden göster: Değerlendirmeye mümkün olan en az işle gidilir; yeni bilgi geldiğinde boşa gidecek emek böylece azalır. Jeff Patton'ın Mona Lisa benzetmesinde ressam önce kaba bir eskizle müşteriye gider, yüzün yönü gibi büyük bir itiraz o aşamada kolayca düzeltilir.

Hangisinin seçileceği, değişikliğin olasılığına ve bedeline bağlıdır. Gereksinimler ve kullanıcı arayüzü en sık yeniden ele alınan alanlardır; ancak Cockburn teknoloji, mimari, algoritma ve yük altındaki performansın da gözden geçirilmesi gerektiğini hatırlatır.

Kurgusal örnek: çalışan self-servis portalı

Bir şirket, çalışanların izin talebi, masraf bildirimi ve bordro görüntüleme işlemlerini tek bir portalda toplamak istiyor.

Artımlı plan: Ekip portalı işlev gruplarına böler. Önce izin talebi uçtan uca, yani ekrandan veritabanına kadar tamamlanır ve canlıya alınır; ardından masraf bildirimi, en son bordro görüntüleme eklenir. Her artım çalışanlara gerçek fayda sağlar ve ekip her teslimden sonra kendi çalışma biçimini gözden geçirir.

Yinelemeli plan: Her artımın içinde, işlev bitmeden önce gerçek kullanıcılarla iki gösterim yapılır. İlk gösterimde akışın büyük kısmı çalışır durumdadır ve kullanıcılar istedikleri her şeyi değiştirebilir; ikinci gösterimde yalnız ciddi hatalar ve ince ayar düzeltilir. Bu kural, Cockburn'ün anlattığı başarılı bir sabit fiyatlı projede uygulanan düzenin özüdür: hem gereksinim hem arayüz düzeltmesine izin verir, hem de sözleşmenin sabit kapsamını korur.

Sonuç: Masraf bildirimi ekranında onay adımının yanlış yerde olduğu ilk gösterimde ortaya çıkar ve canlıya almadan önce düzelir. Yalnız artımlı çalışılsaydı bu hata, kullanıcıların şikâyetiyle ve bir sonraki artımı geciktirerek düzeltilecekti.

Planlarken ve yönetirken fark

İki strateji yüzeyde benzer görünse de farklı yönetilmelidir. Artımlar kolay görülür, kolay ayrılır ve görece kolay tahmin edilir; takvime bir iş listesi gibi yerleşir. Yinelemeler ise doğası gereği belirsizdir: ne kadar düzeltme çıkacağını gösterimden önce kimse bilmez.

Bu yüzden yeniden çalışma süresi takvimde ayrı bir kalem olarak görünmelidir. Cockburn, her inceleme, birleştirme ve teslim noktasının proje planında bir kilometre taşı olarak işaretlenmesini önerir; böylece düzeltmeye harcanan süre izlenebilir. Çevik bir ekipte bunun karşılığı, bir işin backlog'dan yalnız bir kez geçmeyeceğini baştan kabul etmek ve sonraki geçişler için tahmine pay eklemektir.

Çerçeve ne olursa olsun yöneticinin sorması gereken soru aynıdır: Bu planda hangi parça ne zaman eklenecek, ve eklenmeden önce hangi parça kaç kez kullanıcıya gösterilecek? İkinci soruya yanıt yoksa plan yalnız artımlıdır.

Sık yapılan hatalar

• Sprint yapmayı yinelemeli geliştirme sanmak. Kısa döngülerle her seferinde yeni iş bitirmek artımlıdır; tamamlanan işe geri dönülmüyorsa yineleme yoktur.
• Yinelemeyi "her şey her an değişebilir" diye uygulamak. Cockburn'ün anlattığı bir projede gereksinimler her ay değiştirilebildiği için programcılar zaten değişmiş bir tasarımı kodladı ve test ekibi birbirine uyan parça göremedi. Yinelemenin sınırı ve zamanı belli olmalıdır.
• Gösterimi ekran taslağıyla yapmak. Kullanıcının gerçekten tepki verebilmesi için arayüzden veritabanına çalışan yazılım gerekir.
• Düzeltme süresini tahmine katmamak. Her iş tek seferde bitecekmiş gibi planlanırsa yineleme ya yapılmaz ya da takvimi sessizce kaydırır.
• Bütün sistemi aynı anda yinelemek. Düzeltme bir parçayla sınırlı tutulmazsa değişikliğin etkisi zincirleme yayılır.
• Artımın "bitti" tanımını gevşek tutmak. Artım test edilmiş ve diğer parçalarla birlikte çalıştığı doğrulanmış olmalıdır; yarım iş artım değildir.

Mindset programlarında nerede çalışılır?

Geliştirme yaklaşımını seçmek, proje yöneticisinin plan kurmadan önce verdiği ilk karardır. Proje Yönetimi Uzmanlığı Sertifika Programı bu kararı uyarlama ve geliştirme yaklaşımı seçimi başlığında ele alır; artım ve yineleme dengesini öngörücü, çevik ve hibrit seçenekler arasında tartmayı burada çalışırsınız. Şelale disiplinini sprintlerle birleştirmek zorunda kalan ekipler için Hibrit Proje Yöneticiliği Sertifika Programı, sprint ve iterasyonların hibrit yapıya nasıl entegre edileceğini işler.