İki Haftalık Sürüm Sonu Demosu: Ne Gösterilir, Ne Onaylanır?

Her iki haftada bir yapılan sürüm sonu demosu, birçok projede ya hızla geçilen bir formaliteye ya da ekran görüntüleriyle dolu bir sunuma dönüşür. Sonuç tanıdıktır: toplantıdan “güzel görünüyor” diyerek çıkılır, haftalar sonra ilk gerçek kullanımda eksikler fark edilir ve düzeltme hem zaman hem bütçe üzerinde baskı yaratır.

Oysa demo, çalışan yazılımı gerçek bir senaryo üzerinde görmek ve o sürümün kapsamını bilinçli biçimde onaylamak için bir fırsattır. OPEIS Teknoloji olarak geliştirme aşamasında iki haftalık sürümlerle çalışıyor, her sürüm sonunda çalışan yazılımı demo ediyoruz. Bu yazıda KOBİ ve kurumsal karar vericiler ile BT ve ürün yöneticileri için sade bir akış çıkarıyoruz: demodan önce neye hazırlanılır, demoda ne gösterilir, ne onaylanır ve kararlar müşteri panelinde nasıl izlenir.

01Sürüm sonu demosu öncesinde hazırlık: Kabul ölçütlerini baştan yazın

Demonun değeri, toplantıdan önce yapılan işe bağlıdır. İki haftalık sürüm, çalışma sürecimizin geliştirme adımının ritmidir ve bu adımın çıktısı çalışan sürümlerdir. Her sürümün başında “bu sürümün sonunda ne çalışıyor olacak?” sorusuna yazılı bir yanıt verilmesi gerekir. Aşağıdaki beş adım bu hazırlığı somutlaştırır:

1. Sürüm hedefini tek cümleyle yazın. Örnek: “Kullanıcı ürünü sepete ekler, kartla ödeme yapar ve sipariş onayı e-postası alır.”
2. Her hedef için kabul ölçütü belirleyin. Örnek: “Stokta olmayan ürün sepete eklenemez ve kullanıcıya açık bir mesaj gösterilir.”
3. Demo ortamını netleştirin. Canlıya mümkün olduğunca yakın bir ortam ve gerçekçi test verisi kullanılmalıdır.
4. Katılımcıları belirleyin. Karar veren kişi, işi fiilen kullanacak birim temsilcisi ve BT tarafından en az bir kişi toplantıda olmalıdır.
5. Gündemi sade tutun. Bir öneri olarak 45–60 dakikalık bir toplantıda ilk yarıyı gösterime, ikinci yarıyı soru ve karara ayırabilirsiniz.

Kabul ölçütleri önceden yazıldığında demo bir beğeni toplantısı olmaktan çıkar, ölçütlerle karşılaştırılan bir kontrol toplantısına dönüşür.

02Demoda ne gösterilir?

İyi bir demo, ekibin hazırladığı en düzgün akışı değil, yazılımın gerçekte nasıl davrandığını gösterir. Aşağıdaki tablo, demoda beklemeniz gerekenleri ve yetersiz sayılacak durumları özetler.

Demoyu yönlendirmekten çekinmeyin. Ekibin hazırladığı akışın dışında bir senaryo isteyin. Bir e-ticaret projesinde örneğin kupon kullanılmış bir siparişin kısmen iade edilmesini ya da ödeme sırasında oturumun kapanmasını deneyebilirsiniz. Ayrıca sürümün otomatik test sonuç özetini istemek, “çalışıyor” ifadesini kanıtla desteklemenin pratik bir yoludur.

03Demoda ne onaylanır, ne onaylanmaz?

Onay kavramı net olmadığında iki taraf da farklı şeyler anlar. Demo sonunda üç karardan biri verilebilir:

• Kabul: Sürüm hedefi ve kabul ölçütleri karşılandı; teslimat onaylanır.
• Koşullu kabul: Küçük eksikler var; hangi maddelerin hangi sürümde kapanacağı yazılı olarak belirlenir.
• Revizyon gerekli: Temel bir akış çalışmıyor; düzeltme sonrası kısa bir tekrar gösterimi planlanır.

Onay yalnızca o sürümün kapsamındaki, demoda gösterilmiş ve kabul ölçütlerini karşılamış işleri kapsar. Şunlar ise demoda onaylanmış sayılmamalıdır:

• Gösterilmeyen ya da yalnızca anlatılan akışlar
• Kapsam dışı yeni istekler; bunlar sonraki sürümlerin planına alınır ve kapsam yazılı olarak netleştirilir
• Yük ve güvenlik gibi ayrı test gerektiren konular; demoda “hızlı görünüyor” demek yük testinin yerini tutmaz

Onay, “her şey bitti” demek değildir; “bu sürümde söz verilen iş bu ölçütlerle çalışıyor” demektir.

04Onay ve geri bildirim müşteri panelinde nasıl izlenir?

Karar toplantıda verilir, ancak takibi yazılı bir kayda dayanmalıdır. OPEIS müşteri paneli, projelerinizi izlediğiniz, teslimatları onayladığınız, destek talebi açtığınız, dosya paylaştığınız ve toplantıları gördüğünüz kapalı bir alandır. Hesabı OPEIS ekibi açar ya da hesap sahibi davet eder. Sürüm sonu demosu sonrasında şu akışı izleyebilirsiniz:

1. Demo öncesi: Panelde toplantıyı ve proje aşamasını görün, sürüm hedefini son kez gözden geçirin.
2. Demo sırasında: Her bulguya kısa bir başlık verip not alın. Hangi ekranda, hangi veriyle, ne beklediğinizi yazın.
3. Demodan sonra, aynı gün: Bulguları ekran görüntüleriyle birlikte iletin. Panelden dosya paylaşabilir, ayrı takip gerektiren konular için destek talebi açabilirsiniz.
4. Teslimat onayı: Kabul ölçütlerini karşılayan teslimatı panelden onaylayın. Koşullu kabulde bekleyen maddeleri yazılı olarak belirtin.
5. Sonraki sürümün başlangıcında: Açık maddelerin yeni sürüm planında yer aldığını kontrol edin.

Kendi ekibinizde de küçük bir bulgu kaydı tutmak işinizi kolaylaştırır. Örnek bir yapı şöyle olabilir:

Süreç hakkındaki genel soruların yanıtlarını proje süreci sık sorulan sorular sayfasında da bulabilirsiniz.

05Sık sorulan sorular

Demoya kimler katılmalı?

Karar yetkisi olan bir kişi, yazılımı fiilen kullanacak iş birimi temsilcisi ve BT ya da ürün tarafından en az bir kişi yeterlidir. Kalabalık bir katılım listesi çoğu zaman karar vermeyi yavaşlatır. Katılamayan paydaşlar için toplantı notlarını aynı gün paylaşmak daha verimlidir.

Demoda hata çıkarsa sürümü onaylamalı mıyım?

Bu, hatanın önemine bağlıdır. Ana akışı engelleyen bir hata varsa revizyon istemek doğrudur. Kapsamın geri kalanını etkilemeyen küçük bir eksik için koşullu kabul verip düzeltmenin hangi sürümde yapılacağını yazılı olarak kayda geçirebilirsiniz.

Demo sırasında yeni bir istek çıkarsa ne olur?

Yeni istekler mevcut sürümün onayını etkilemez. İstek kayda alınır, sonraki sürümlerin planında değerlendirilir ve kapsam etkisi birlikte netleştirilir. Böylece hem mevcut teslimat net kalır hem de yeni ihtiyaç unutulmaz.

06Sonuç

Sürüm sonu demosu, iki haftalık ritmin en görünür anıdır. Hedefi yazılı bir sürüm, gerçek senaryolarla yapılan gösterim, açık bir karar ve izlenebilir bir kayıt, projeyi sürprizlerden korur. Özel web uygulaması, mobil uygulama ve API geliştirme projelerinde bu yaklaşımı nasıl uyguladığımızı yazılım geliştirme hizmetimiz sayfasında inceleyebilirsiniz.