Yinelemeli ve Artımlı Geliştirme Arasındaki Fark Nedir?
Eğitim sınıflarımda, öğrencilerin yinelemeli ve artımlı geliştirmeyi (IID) sıklıkla birbirine karıştırdığını fark ediyorum. Bu makalenin amacı, artımlı ve yinelemeli geliştirme arasındaki ilişkiyi anlamayı sağlamaktır.
Ödeme uygulaması sunma örneğini kullanarak şelale ve çevik yaklaşımın karşılaştırılmasıyla başlayacağım. Bu yaklaşımlar hakkında ilgili bir mini web semineri de yer almaktadır. Bu makalenin ikinci bölümünde, şelale ve çevik yaklaşımları artımlı ve yinelemeli geliştirmenin kesişimini gösteren bir matrise yerleştirecek ve matristeki dört çeyreğin tümünü açıklayacağım.
Çevik ve Şelale: Bir Ödeme Uygulamasının Geliştirilmesi
Şelale Yaklaşımı
Bu örnek uygulama geleneksel bir şelale modeline göre geliştirilirse, şekil 1'de aşağıdaki adımlar gözlemlenebilir.
Continue Reading for Free
Create a free account to finish this article, plus get ongoing access to timely insights and practical resources.
Have an account? Log In
Şekil 1: Bu diyagram, bir uygulamanın sunulması örneğini kullanarak tipik bir şelale yaşam döngüsünü göstermektedir.
Proje Başlatma
Her şey, bu uygulama için gerekli fonları serbest bırakabilen pazarlama departmanındaki bir proje sponsoruyla başlar. Sponsor, uygulamanın müşteri sadakatini ve yeni müşteri akışını artıracağını varsaymıştır. Üç üst düzey işlev grubu tasarlamıştır.
Proje onaylandıktan sonra bir proje yöneticisi atanır ve bir proje ekibi kurulur. Birçok görüşme ve gereksinim toplama çalıştayından sonra, 250 işlev içeren bir ödeme uygulaması sunulması konusunda anlaşmaya varılır. Tüm bu özellikler kapsamlı ve son derece ayrıntılı bir yazılım gereksinimleri belgesine kaydedilir ve proje sponsoru ile müşteri temsilcisi (diğer önemli paydaşların yanı sıra) tarafından imzalanır.
Proje Tasarım Aşaması
Bir sonraki adımda proje ekibi, gereksinimleri uygulama için bir tasarıma dönüştürür. Mimar, tasarımı tasarım ilkelerine göre kontrol eder. Gerekli tüm veri özniteliklerinin arka uç sisteminde de mevcut olup olmadığını denetler.
Artık iki aydır çalışıyoruz ve müşteri henüz çalışan hiçbir şey görmedi; yalnızca bazı ilerleme raporlarını gördü. Bu ilerleme raporları muhtemelen bir tür ‘karpuz’ raporlaması içeriyor ve müşteriyi projenin plana uygun ilerleyip ilerlemediği konusunda tamamen bilgisiz bırakıyor.
Proje Geliştirme Aşaması
Uygulamanın geliştirilmesi altı ay sürer ve bu tamamlandığında müşteri temsilcisinden, kullanıcı kabul testi için yardımcı olabilecek bazı kişiler temin etmesi istenir. Test sırasında çeşitli özelliklerin çalışmadığı anlaşılır.
Proje ekibi bunun nedenini anlayamaz. Gereksinimler belgesinde tam olarak açıklanan şey budur. Bu durum çok sayıda görüşmeye, yeniden çalışmaya ve gecikmeye yol açar; müşteriler de sonuçlardan memnun kalmaz. Ayrıca nihai sonuca baktığımızda, geliştirilen gereksinimlerin çoğunun müşteri tarafından kullanılmadığını veya nadiren kullanıldığını fark edebiliriz.
Durum daha da kötü olabilir. Uygulamanın geliştirilmesinin 1,5 yıl sürdüğünü ve siz geliştirmeyi yarılamışken başka bir bankanın bir ödeme uygulaması sunduğunu varsayalım. O anda ne yapardınız? Kendi uygulamanıza devam edip tamamlamanız için hâlâ uygulanabilir bir iş gerekçeniz olur muydu?
Şekil 1'e baktığımızda, şelale yaklaşımında kapsamın ve bunun altında yatan kalite ölçütlerinin tek bir teslimatla sabitlendiği açıkça görülür. Tüm adımlar projenin tamamı için bir kez gerçekleştirilir ve yönetim kontrolü maliyet ile zamana odaklanır. Müşteriye değer sunulması yalnızca uygulamanın tamamının devreye alınmasından sonra gerçekleşir.
Çevik Yaklaşım
Uygulamayı bir çevik proje yönetimi yaklaşımı kullanarak geliştirirsek aşağıdaki modeli görürüz:
- Geliştirme ekibi, ürün sahibinin önceliklendirdiği ilk iki özelliği ilk yinelemede sunabileceğini belirtir.
- Proje ekibi her üç haftada bir (sprint, yineleme veya zaman kutusu) ürünün bir artırımını sunar.
- İlk teslimatlardan veya artırımlardan sonra, projenin teslim edileceğine güvenen bir müşteri görürüz. Müşterinin hâlihazırda çalışan bir uygulaması vardır ve henüz tüm özelliklerin mevcut olmadığını, ancak mevcut özelliklerin çalıştığını anlar.
En son sürüme ve sunulan özelliklere baktıklarında, tamamen yeni bir özellikten söz ederler. Projenin başlangıcında hiç kimsenin aklında olmayan, ancak müşterinin hayatını daha üretken hâle getirebilecek bir özellik.
Her artırımdan sonra müşteri geri bildirimleri, yeni işlevsel yeteneklerle (ilk listede yer almayan) veya olası özelliklerde yapılan düzenlemelerle sonuçlanır. Ürün giderek daha olgun hâle gelir. Her artırımda müşteri yeni bir sürüm alır ve daha memnun olur.
Şekil 2: Diyagram, uygulamanın teslim edilmesine ilişkin aynı örneği kullanarak çevik geliştirme döngüsünü göstermektedir.
Şekil 2'ye baktığımızda, sabit bir süre içinde ve kalıcı çevik ekipler kullanılarak gerçekleştirilen istikrarlı bir teslimat akışı görürüz (bunlar sabit maliyetlerdir). Kapsam ve temel kalite ölçütleri esnektir (dinamiktir) ve sık aralıklarla küçük teslimatlar yapılır (bunlar artışlardır).
Bir özelliği veya kullanıcı hikâyesini teslim etmeye yönelik tüm adımlar, gerekli kaliteye ulaşılana kadar tekrar tekrar gerçekleştirilir (bu da süreci yinelemeli hâle getirir). Yönetim kontrolü, müşteriye değer sunmaya odaklanır. Müşteriye değer sunulması, her artışın dağıtımından sonra gerçekleşir.
Şelale ve Çevik: Teslimat Sonuçları
Hem şelale hem de çevik yazılım geliştirme yaklaşımı kullanılarak ortaya çıkarılan iki ürüne daha yakından baktığımızda, 250 özelliğe sahip ve pek memnun olmayan bir müşterinin bulunduğu bir ürün ile yalnızca 150 özelliğe sahip ve çok memnun bir müşterinin bulunduğu bir ürün görürüz (bkz. şekil 3).
Şekil 3: Bu diyagram, şelale ve çevik yaklaşımlar arasındaki süre, özellik sayısı ve müşteri memnuniyeti farklarını karşılaştırmaktadır.
Çevik yaklaşımla teslim edilen ürüne daha ayrıntılı baktığımızda ise özgün listedeki 100 özellikten oluşan bir alt küme ile yeni veya değiştirilmiş 50 özellik görürüz. Bu durum, Çevik Manifesto'nun bazı önemli ilkeleriyle uyumludur; bunlar arasında şunlar bulunur:
- Sadelik; yapılmayan iş miktarını en üst düzeye çıkarma sanatıdır: 250 yerine yalnızca 150 özellik
- Geliştirmenin ilerleyen aşamalarında bile değişen gereksinimleri memnuniyetle karşılayın: her yineleme ve artıştan sonra müşteri geri bildirimlerine uyum sağlamak
Çevik geliştirme süreçleri, değişimi müşterinin rekabet avantajı için kullanır (50 yeni veya değiştirilmiş özellik teslim edilmiştir). Bunun sonucunda müşteri çok memnundur. Ekibin en yüksek önceliği, değerli yazılım sistemlerini erken ve sürekli teslim ederek müşteriyi memnun etmektir.
Mini Web Semineri: Şelale ve Çevik Teslimat
Şelale ve çevik teslimat arasındaki farklar hakkında daha fazla bilgi veren kısa bir web seminerini burada bulabilirsiniz.
Yinelemeli ve Artımlı Geliştirme Arasındaki Farklar
Ödeme uygulaması oluşturma örneğini kullanarak şelale ve çevik yaklaşım arasındaki farkları ele aldığımıza göre, şelale ve çevik yaklaşımları yinelemeli ve artımlı geliştirmeyi karşılaştıran bir matriste konumlandıracağım.
Son adım olarak minimum uygulanabilir ürünü (MVP) ve minimum pazarlanabilir ürünü (MMP) ayrıntılı olarak açıklayacak, bunların farklı yaklaşımlara ve bir hikâye haritasına nasıl yerleştirildiğini göstereceğim. Ayrıca buna karşılık gelen bir mini web semineri de ekledim.
Yinelemeli ve Artımlı Geliştirme Matrisi
Belirttiğim gibi, öğrencilerin yinelemeli ve artımlı kavramlarını sıklıkla karıştırdığını fark ettim. Şekil 4'te, artımlı olup olmadığını gösteren yatay bir çizgi ile yinelemeli olup olmadığını gösteren dikey bir çizginin kesişmesi sonucunda oluşan dört bölgeyi görebilirsiniz. Bu şeklin çok basit bir versiyonu için bu YouTube videosuna bakabilirsiniz.
Şekil 4: Bu matris, farklı geliştirme yaklaşımlarını ve bu yaklaşımları izleyen ekip üyelerinin yineleme yapması ve/veya artışlar hâlinde çalışması gerekip gerekmediğini göstermektedir.
Sol Alt Bölge
Sol alt köşede, ne yinelemelerin ne de artışların bulunduğu yaklaşımı görürüz. Bu, şelale yaklaşımıdır. Tüm faaliyetler (tasarım, analiz, geliştirme, test ve dağıtım) projenin tamamı için bir kez gerçekleştirilir.
Bu durumda, sabit bir kapsama dayalı nihai ürünün tek bir teslimatı söz konusudur. Müşteri değerine ancak nihai ürün teslim edildikten sonra ulaşılabilir. Bu yaklaşımın temel hedeflerinden biri maliyeti yönetmektir.
Sağ Alt Bölge
Sağ alt çeyrekte, yinelemeler içermeyen artımlı bir yaklaşım görüyoruz. Bu, ürünün daha küçük parçalarının aşamalı veya artımlı teslimatıdır. Belirli bir aşamaya ait tüm faaliyetler (tasarım, analiz, geliştirme, test ve dağıtım) bir kez gerçekleştirilir.
Belirli bir aşamanın kapsamı sabittir, ancak toplam ürün daha dinamik veya esnek bir kapsama dayanır. Her ürün teslimatından sonra müşteri değeri elde edilebilir. Bu yaklaşımın temel hedeflerinden biri teslimat hızıdır.
Sol Üst Çeyrek
Sol üst çeyrekte, artışlar içermeyen spiral veya yinelemeli bir yaklaşım görüyoruz. Bu, nihai ürünün birkaç yineleme aracılığıyla oluşturulduğu tek bir teslimattır. Bu yaklaşıma iyi bir örnek tasarım odaklı düşünmedir. Grafikte çerçeveleme, analiz, fikir üretme, gerçekleştirme ve değerlendirme faaliyetlerinden oluşan bir dizi görüyorsunuz.
Bu dizi, her yinelemede nihai, doğru veya gerekli ürüne biraz daha yaklaşılan tekrarlı ya da yinelemeli bir biçimde gerçekleştirilecektir. Çoğu durumda bu nihai ürün bir prototip veya modeldir. Bu spiral yaklaşımda dinamik veya esnek bir kapsama sahibiz. Müşteri değeri yalnızca nihai ürünün teslim edilmesinden sonra elde edilebilir. Bu yaklaşımın temel hedeflerinden biri çözümün doğruluğudur.
Sağ Üst Çeyrek
Sağ üst çeyrekte, artışları ve yinelemeli bir yöntemi kullanan çevik yaklaşımı görüyoruz. Scrum bu yaklaşıma iyi bir örnektir.
Genellikle sprint veya zaman kutusu olarak adlandırılan her artışın sonunda ürünün bir artışı teslim edilir. Bu artış, ürünün genellikle kullanıcı hikâyeleri veya iş listesi öğeleri olarak adlandırılan küçük ama doğru parçalarını geliştirmek için yapılan birçok yinelemenin sonucudur. Nihai yinelemeli proje parça parça teslim edilecektir.
Bu çevik yaklaşımda dinamik veya esnek bir kapsama sahibiz. Her ürün teslimatından sonra müşteri değeri elde edilebilir. Bu yaklaşımın temel hedeflerinden biri sık teslimatlar ve kullanıcı geri bildirimleri aracılığıyla müşteri değeridir.
MVP mi, MMP mi?
Şekil 4'te MVP ve MMP kısaltmalarını da bulabilirsiniz. MVP, minimum uygulanabilir ürün anlamına gelir ve bir ekibin müşteriler hakkında mümkün olan en fazla öğrenimi elde etmesine ve en az çabayla doğrulama yapmasına olanak tanıyan yeni bir ürün veya hizmet sürümüdür. Dropbox hizmetinin MVP'si basit bir filmdi. Bu, MVP'deki P'nin nihai üründen tamamen farklı bir ürün olabileceği anlamına gelir.
MVP ve MMP'yi Açıklayan Bir Örnek
Yeni bir finansal ürünle ilgili aşağıdaki örneği sık sık kullanırım. Hevesli bir satış yöneticisinin yeni bir finansal ürünle ilgili harika bir fikri vardır. Bu ürünlerden en az 100.000 adet satabileceklerini düşünür.
Birkaç finans uzmanıyla birlikte ürünü birkaç ay içinde tasarlarlar. Bir geliştirme ekibi görevlendirilir ve ürünün geliştirilmesi 4 ay sürer. Aynı zamanda ticari broşürler hazırlanır ve ürün büyük bir etkinlikle piyasaya sürülür.
Ne yazık ki ürünü yalnızca birkaç kişi satın alır. MVP yaklaşımını izlersek, web kullanıcılarının %10'unun bu ürünle ilgilendiği varsayımında bulunabiliriz. Daha sonra bu hipotezi test etmek için bir MVP geliştiririz.
Bu durumda MVP, ana sayfadaki basit bir düğme olabilir. Tıkladığınızda, bu yeni ürünle ilgili bir mesajın ve ilgileniyorsanız e-posta adresinizi ekleme seçeneğinin bulunduğu bir ekran açılır. Ziyaretçilerin %1'inden azının düğmeye bastığını varsayalım — ürün geliştirilmez ve şirket kıt kaynaklarının büyük bir kısmını korumuş olur.
Şekil 4'e daha yakından baktığımızda, MVP'lerin tüm çeyreklerde potansiyel olarak kullanılabileceğini görürüz. Şelale yaklaşımını kullanırken, proje için bir iş gerekçesi olup olmadığını kontrol etmek amacıyla ilk yazılım tasarımı aşamasında bir MVP oluşturabilirsiniz.
Aynı şey, aşamalı teslimatı izlerken ilk artışın ilk aşamasında da yapılabilir. Bazı durumlarda tasarım odaklı düşünme yaklaşımınızın sonucu bir MVP olabilir. MVP, çevik bir yaklaşımın başlangıcında da faydalı olabilir.
Birçok kişi, aşamalı teslimatınızın sonunda teslim edilen ilk ürünü MVP olarak görür. Durum bu olabilir, ancak çoğu durumda bu bir MVP değil, MMP'dir. MMP veya pazarlanabilir minimum ürün, müşterinize değer sunabilecek en küçük üründür.
Çevik Teslimat Neye Benzer?
Artımlı modellerle yinelemeli modellerin aynı olmadığını ve MVP ile MMP'nin kullanımını anladığımıza göre, artımlı ve yinelemeli teslimatın nasıl göründüğünü daha ayrıntılı olarak inceleyebiliriz.
Muhtemelen Jeff Patton'ın tablonun parça parça oluşturulduğu ünlü Mona Lisa örneğini görmüşsünüzdür (aşamalı teslimat). Buna yaklaşmanın bir başka yolu, yalnızca kaba bir taslağın oluşturulduğu ilk artışla başlamak ve sonunda nihai tabloya sahip olana kadar her yeni yinelemede taslağa daha fazla ayrıntı eklemektir (artımlı ve yinelemeli veya çevik teslimat).
İlk durumda nihai ürün hakkında zaten ayrıntılı bir fikriniz olmalıdır; ikinci durumda ise değişiklik yapmak çok daha kolay olduğundan yalnızca üst düzey bir taslağa ihtiyacınız vardır. Şekil 5'e baktığımızda, ABC adlı yeni bir ürün için bir kullanıcı hikâyesi haritası görürüz.
Şekil 5: Belirli bir örnek ürün için örnek bir hikâye haritası.
Ürün sahibi bu ürün için yedi özellik öngördü. İlk dört özellik olmazsa olmazdır. 5. ve 6. özellikler olması gerekenlerdir ve son özellik olabilecek bir özelliktir. Birçok kişi buna MoSCoW önceliklendirmesi (olmazsa olmazlar, olması gerekenler, olabilecekler ve olmayacaklar) der.
Her özellik kendi içinde daha küçük parçalara ayrılabilir. Şekilde, olmazsa olmaz, olması gereken ve olabilecek özellikleri ya da kullanıcı hikâyelerini görüyorsunuz. Bir özellik olmazsa olmaz olabilir, ancak bu, altında yer alan tüm kullanıcı hikâyelerinin de olmazsa olmaz olduğu anlamına gelmez. Ya da bir özellik olması gereken bir özellik olabilir; fakat bu özelliği uyguladığınızda bazı kullanıcı hikâyeleri olmazsa olmazken diğerleri olması gereken veya olabilecek özellikler olabilir.
Bu ABC ürününü uygulamak için beş artış veya sürüm görüyorsunuz. İlki, pazarlanabilir minimum üründür. Bu MMP, 1. özelliğin ilk iki olmazsa olmaz kullanıcı hikâyesinden ve 2. ve 3. özelliklerin ilk olmazsa olmaz kullanıcı hikâyelerinden oluşur.
2. sürüm, 1., 2. ve 3. özelliklerin sonraki iki olmazsa olmaz kullanıcı hikâyesini içerir (yinelemeli geliştirme). Ürün geliştirme, sonraki sürümlerin uygulanmasıyla devam eder. Her sürümle birlikte müşteri değeri artar.
5. sürümden sonra ürün sahibi kullanıcı hikâyelerini uygulamayı bırakır. Müşteriden gelen geri bildirim, ABC ürününün ‘amacına uygun’ olduğunu gösterir ve ürün sahibi Çevik manifestonun basitlik ilkesini dikkate alarak geliştirmeyi sürdürmeyi bırakır.
Mini Web Semineri: Yinelemeli ve Artımlı Geliştirme
Yinelemeli ve artımlı yazılım geliştirme hakkında ayrıntılı bir web semineri burada.
Son Düşünceler
Yazılım geliştirme ekibiniz yinelemeli ve artımlı geliştirme konusunda net mi? Bunu çevik veya şelale metodolojilerinize nasıl uyguluyorsunuz?
Görüşlerinizi yorumlarda bizimle paylaşın veya DPM üyelik programımıza katılın ve özel forumumuzda diğer üyelerle tartışın!
