Yazılımda "Milestone" (Aşama) Bazlı İlerleme Nedir?

Hayır. Sprint, geliştirme ekibinin 1-2 haftalık iç çalışma turudur ve her sprint sonunda müşteriye teslim yapılması gerekmez. Milestone ise müşteriye dönük bir kontrol noktasıdır: kapsamı, kabul kriteri ve çoğu zaman ödemesi vardır. Ekip içeride sprintlerle çalışırken sizinle olan sözleşme milestone'larla ilerler; siz sprint detayını izlemek zorunda kalmazsınız.

Orta ölçekli bir projede 4-8 milestone sağlıklı bir aralıktır; her biri 2-6 haftalık işe karşılık gelir. Çok az milestone demolar arasında aylarca karanlık dönem yaratır; çok fazlası ise gereksiz onay trafiği ve yönetim yükü doğurur. İki demo arasının bir ayı geçmemesi, pratikte en çok işe yarayan kuraldır. ERP ölçeğindeki kurumsal yazılım projelerinde modül sayısı arttıkça aşama sayısı da bu aralığın üst sınırına yaklaşır.

Senaryo diliyle ve ölçülebilir biçimde: "yeni sipariş girildiğinde stok düşer, iptalde iade edilir, gün sonu raporu iki hareketi de gösterir" gibi. Teknik jargondan kaçınılır; kriteri işletme sahibinin kendisi test edebilmelidir. Kriterler aşama başlamadan yazılı olarak netleştirilir; böylece onay aşamasında "tamam mı, değil mi" tartışması yaşanmaz. Edge Bilişim'de bu kriterleri tek sayfalık bir kontrol listesine dönüştürüyor, her maddenin karşısına testi kimin yapacağını (depo sorumlusu, muhasebeci, satış temsilcisi) yazıyoruz; demo günü liste satır satır işaretleniyor.

Bir aşamanın canlı demosunu kendi verilerinizle test edip kabul kriterlerini karşıladığını onayladıktan sonra. Tüm bedeli baştan ödemezsiniz; her onaylanan aşama için usulüne uygun fatura kesilir ve sözleşmedeki plana göre ödeme yapılır. Onaylamadığınız bir aşamanın ödemesi tetiklenmez; eksikler giderilene kadar süreç bekler.

Türkiye'de kurumsal yazılım firmalarının yaygın kurgusu %30-40 peşinat, aşama teslimlerinde %20-30'luk dilimler ve proje kabulünde kalan bakiyedir. Müşteri lehine kurgulanmış milestone modellerinde ise peşinat bunun altına çekilir ve ağırlık onaylanan aşamalara kaydırılır. Oranlar pazarlığa ve projenin risk profiline göre değişir; kritik olan, her dilimin yazılı bir teslimata bağlanmasıdır.

Tek seferlik (yüksek peşinatlı) ödemede tüm riski siz üstlenirsiniz; sonuç beklentinizi karşılamazsa geri dönüş zordur. Aşamalı ödemede risk zamana ve teslimata yayılır: her adımda çalışan bir çıktı görür, onaylamadan ödemezsiniz. Toplam fiyat değişmez; değişen şey riskin dağılımı ve sizin süreç üzerindeki kontrolünüzdür.

Çünkü sonraki her aşamanın ölçülebilmesi, kapsamın ve kabul kriterlerinin baştan yazılmasına bağlıdır. İlk aşamada iş analizi raporu, ekran tasarımları ve kapsam dokümanı üretilir; bu doküman onaylandığında kapsam kilitlenir. Analiz ve planlamaya toplam eforun %10-15'i kadar pay ayrılması yaygın bir orandır ve sonraki aşamalardaki tartışmaları baştan önler.

Hayır, ama prosedürü vardır. Mevcut kapsam içindeki düzeltmeler aşamanın parçasıdır ve ek ücret doğurmaz. Kapsam dışı yeni bir özellik ise değişiklik talebi olarak yazılır; süre ve maliyet etkisi hesaplanıp ayrı bir aşama olarak planlanır. Henüz başlanmamış aşamaların sırası da önceliklerinize göre yeniden dizilebilir. Plan bozulmaz, kontrollü biçimde güncellenir.

Hayır. Toplam süreyi kapsam belirler; milestone modeli aynı işi ölçülebilir dilimlere böler. Hatta sapmalar ilk demoda görünür hale geldiği için düzeltme maliyeti düşer ve proje sonunda aylarca süren "düzeltme turu" yaşanmaz. Onay süreçlerinin projeyi tıkamaması için inceleme süresi (genellikle 3-7 iş günü) sözleşmede sınırlandırılır.

Model iade üzerine değil, ödememe üzerine kuruludur: onaylamadığınız aşamanın ödemesini zaten yapmamış olursunuz. Eksikler tutanağa geçer, düzeltilir ve kabul kriterleri karşılandığında onaylayıp ödersiniz. Bu sıralama sayesinde paranız her zaman görüp test ettiğiniz, çalışan bir işe karşılık gelir; iade kovalamak zorunda kalmazsınız.

Evet; her milestone aynı zamanda bir karar noktasıdır. Durdurma ve fesih koşulları sözleşmede tanımlanır; o ana kadar onaylayıp ödediğiniz aşamaların çalışan hali ve ilgili teslimatlar sizde kalır. Bu, bütçe daralması veya öncelik değişikliği gibi durumlarda size gerçek bir çıkış kapısı sağlar; kayıp, klasik modeldeki gibi tüm peşinat olmaz.

En geç proje kabulünde; iyi kurgulanmış sözleşmelerde ise onaylanan her aşamanın kodu kademeli olarak teslim edilir ya da ortak bir depoda erişiminize açık tutulur. Kademeli teslim, en kötü senaryoda bile elinizde çalışan sistemle birlikte kodun da kalmasını sağlar. Kod ve dokümantasyon sizde olduğunda hiçbir firmaya bağımlı kalmazsınız.

Tipik kurgu; analiz ve tasarım, çekirdek ekranlar, entegrasyonlar (ödeme, bildirim), kapalı test (TestFlight/Internal Testing) ve mağaza yayını şeklindedir. Son milestone'a mağaza onayını da dahil etmek önemlidir; App Store ve Google Play onay süreçleri ret ve düzeltme turlarıyla haftalar alabilir. Fikir aşamasındaysanız mobil uygulama fikrinizi nasıl projelendireceğinizi ayrı bir rehberde anlattık.

Evet. Önce mevcut kod ve dokümantasyon incelenir, neyin çalışır durumda olduğu raporlanır; kalan iş milestone'lara bölünür ve her aşama için kabul kriteri yazılır. Yalnızca teslim edilip onayladığınız kısımlar için ödersiniz. Böylece bir kez yaşadığınız "peşin öde, sonucu bekle" riskini ikinci kez almadan projeyi güvenle tamamlatırsınız. Edge Bilişim'de devralınan projelerde ilk iş, mevcut kodu kendi ortamımızda ayağa kaldırmayı denemek ve veritabanındaki eksik ya da çelişkili kayıtları listelemektir; bu tespit raporu çıkmadan kalan iş için takvim vermiyoruz.

Geliştirme aşamaları ve varsa garanti dönemi tamamlandıktan sonra bakım, isteğe bağlı ayrı bir anlaşmayla sürer; aylık sabit ücret veya saat bazlı kullanım şeklinde kurgulanabilir. Kritik nokta, garanti süresinin ve bakım koşullarının daha sözleşme aşamasında yazılmasıdır; böylece canlıya geçtikten sonra "her düzeltme ücretli mi" belirsizliği yaşanmaz.