İteratif bir projede

• Bütün proje belirli sayıda küçük mini-projelere bölünür.
• Bu her bir mini-proje iterasyon olarak adlandırılır
• Her bir iterasyon kendi basına çesitli aktiviteleri/disiplinleri içeren (örneğin gereksinim analizi,tasarım, programlama, test) farklı oranlarda içeren bir mini-projedir.
• Her iterasyon sonunun temel amacı, kararlı, bütünlesmis edilmis ve test edilmis kısmi olarak bitmis sisteme ait bir iterasyon sürümü olusturmaktır.
• Teorikte bir iterasyon kodun temizliğine ya da performans artırımına yönelik olabilse de, genellikle sistem artırımlı(incremental) olarak büyür: Baska ifadeyle Arttırımlı Gelistirme.

Sistemlerin iterasyonlarla büyütülmesine kavramsal olarak Iteratif ve Arttırımlı ( iterative and incremental development ) gelistirme denir. Çoğu zaman kısaca Iteratif Gelistirme deyimi kullanılır.

  

Zaman Sınırlı (Timeboxed) İteratif Gelistirme
İterasyonun bitim tarihini sabitlemek ve değismesine izin vermemektir. Eğer istenilenlerin(kapsam) ilgili zaman aralığında yapılamayacağı anlasılırsa, iterasyon bitim tarihinin ötelenmesi yerine, kapsam daraltılır(önceliği az olan istekler). Birçok IID (iterative and incremental development) metodolojisinde, zaman aralıklarının(time-box) hepsi bir birine esit değildir. 

• İlk iterasyon 4 hafta
• İkincisi 3 hafta
• Vs. olablir.

İterasyonun Süresi
Modern iteratif gelistirme metodolojileri, 1 ile 6 hafta arasında değisen iterasyon zaman aralıklarını önermektedir.

İteratif Süreç ve Önceliklendirme
İteratif süreçte bütün proje belirli sayıda küçük mini-projelere bölündüğünden, "yapılması" /gerçeklenmesi gereken özelliklere ait bir önceliklendirme(hangisinin önce, hangisinin sonra yapılacağı) yapmanız gerekir. Bu önceliklendirme yüksek teknik riskler, iş açısından önemli özellikler, (veya her ikisinin dengeli bir karışımı) vb. kıstaslara göre yapılabilir. Önceliklendirme kriterlerine örnek olarak: http://www.infoq.com/presentations/prioritizing-your-product-backlog-mike-cohn

Risk Azaltma Odaklı İterasyonlar ( Gerçeklenecek Özelliklerin Risklerine Göre Önceliklendirilmesi)


İteratif yaklasıma diğer bir bakıs sekli de onu ‘Risk Azaltma Odaklı’ olarak tanımlamaktır. Gerçekten de kademeli olarak (aynı tür çalısmaları tekrarlayarak) ve ise en zor (en önemli)  kısmından baslayarak yazılım gelistirmeyi desteklediğinden dolayı geçirdiğimiz her iterasyon omuzlarımızdaki yükü hafifletir ve her yeni iterasyon bir öncekinden daha kolay olur.
Burdaki temel amaç ortaya çıkabilecek ve sistemi büyük bir biçimde etkileyecek unsurların bir an önce ortaya çıkmasını sağlamaktır. [Tabiri caizse projede bir yerlerde  "duvara toslayacaksak" , en erken şekilde "toslamak".]

İterasyon ya da Yerinde Saymak

Sürecinizin gerçekten iteratif olması için her iterasyonun bir önceki mevcut sisteme bir değer katması gerekmektedir. Aksi taktirde sürecinizde bir problem vardır.
 

 İterasyonda "Ne Yaptık"?

İteratif projelerde yaşanan problemlerden birisi "X,Y,Z... özelliklerini gerçekledik" sözünün farklı paydaşlarca farklı anlaşılmasıdır. Geliştirici için bu: X,Y,Z ... özelliklerini gerçekleştirdim,sistem artık test dilebilir" anlamını taşıyabilirken, müşteri bu özellikleri ürünle birlikte artık doğrudan pazara sunulabileceğini düşünebilir. Halbuki bu yarı test edilmiş, yarı belgelenmiş yarı-optimize edilmiş dolayısıyla yarı-sürüme hazır bir sürümü göstermektedir.Bu yüzden ilgili paydaşlarla (patronunuz, müşteri , geliştiriciler vb.) "yaptık /gerçekleştirdik" söznün ne anlama geldiği konusunda bir mutabakata varmanız önemlidir: Örneğin "yaptık/gerçekleştirdikten kastımız ilgili  özellik kodlandıtest edildi, ama belgelenmedi" olabilir.Önemli olan herkesin "yaptık"tan neyi kastetttiğinizi ( ve neyi kastetmediğiniz) kavramış olmasıdır. Kimsenin uymadığı, kağıt üzerinde kalan "yaptık" tanımlamalarından kaçının.Kendi kendinize yalan söylemeyin. Türübinlere oynamayın.

İteratif Süreç Sadece Kodlama İle İlgili Değildir :Evrimsel Gereksinim Analizi

İteratif bir süreçte kodlamaya başlamak için "tüm gereksinimleri", "tüm detayları"  ile % 100 bilmeniz gerekmemektedir [ bu çoğu proje içi zaten gerçekçi değildir]. İteratif süreçte gereksinimler  iterasyonlar boyunca yapılan  gereksinim analizi çalıştayları  requirement workshops) ortaya çıkartılır , detaylandırılır. Esas nokta bir sistemi olusturmadan önce analiz çalısması tarafından tabiri caizse  felçli hale gelmemektir.( analysis paralysis : bu çalısmalar aylarca sürebilir,analizcilerin temel amacı analiz sonucunda neredeyse  değismeyecek olan (varsayılan) sistem gereksinimlerini en ince ayrıntısına kadar belirlemektir. Hâlbuki müsteri istekleri ve dolayısıyla sistem gereksinimleri değisecek ve ürün yavas yavas ortaya çıktıkça müsteri kafasında yeni özellikler belirecek veya mevcut özelliklere ait yeni bakıs açıları olusacaktır.].

Bu durumda bir çok geliştiricinin aklına tüm gereksinimleri bilmeden nasıl yazılıma ait mimariyi oluşturabiliriz sorusu gelmektedir. Yazılıma ait mimariyi oluşturmak için yazılım mimarisi açısından önemli kritik gereksinimleri bilmesine ihtiyacı vardır.Tüm gereksinimlerin  sadece bir kısmı bu kategoriye girmemektedir.

"Waterfall" Yaklaşımı Neden İşe Yaramıyor?

 Yazılım Yeni Ürün Geliştirmektir

Çoğu yazılım geliştirme bir kestirilebilir veya seri/toptan üretim problemi değildir. Yazılım Geliştirme Yeni Ürün Geliştirmektir. Bu nedenle kestirilebilir üretime ait paradigmalar yazılım geliştirme için yanlıştırlar ve bu alana ait pratikler ve değerler yazılım geliştirmeye yardım edemezler.

İteratif Süreç , Hayal ve Gerçekler

İteratif Süreç size takımınızın kabiliyetleri, neyi yapıp neyi yapamayacakları (ilgili kaynaklarla) hakkında giderek daha fazla geri bildirim sağlar.Projenin en başından hayal ve gerçeği ayırt edememeniz durumunda [gerçek] iteratif süreç kısa bir sürede sonuçları itibari ile size bunu gösterecektir.

Hamiş :  Kaynaklar

• Agile and Iterative Development , Craig Larman
• Managing Iterative Software Development Projects , Kurt Bittner, Ian Spence