Özel yazılım yaptıracaksanız “çevik (Agile) çalışıyoruz” cümlesini mutlaka duyarsınız. Bu kelime bazen “plansız ve esnek” gibi yanlış anlaşılır. Oysa çevik yaklaşım, projeyi küçük parçalara bölerek her aşamada çalışan yazılımı görmeyi ve geri bildirimle yön vermeyi esas alan bir çalışma biçimidir. Bu rehber, müşteri tarafından bakınca neyi bilmeniz gerektiğini kısaca anlatıyor.
Kısaca
- Çevik Manifesto (2001) dört değer öne çıkarır: bireyler ve etkileşim, çalışan yazılım, müşteriyle işbirliği ve değişime karşılık verme. Sağdaki değerleri öne alır, soldakileri de yok saymaz.
- Scrum, Scrum Guide 2020'ye göre karmaşık sorunlara uyarlanabilir çözümlerle değer üretmeye yardım eden hafif bir çerçevedir: 3 sorumluluk, 5 etkinlik ve 3 artefakt içerir; her Sprint en fazla bir ay sürer.
- Müşteri olarak sizin kritik rolünüz ürünün sahibi olmak, önceliklendirmek ve her Sprint sonunda çalışan yazılımı görüp geri bildirim vermektir.
- Çevik yaklaşım plansızlık veya dokümansızlık demek değildir; kapsam, öncelik ve “bitti” tanımı baştan netleştirilir.
- Gereksinimi kesin standartlara bağlı işlerde (ör. GİB e-Belge entegrasyonu) kapsamın çoğu sabittir; yine de kademeli teslim çevik ilkelerle yürütülebilir.
Çevik Manifesto'nun dört değeri
2001'de yazılım geliştiricilerinin yayımladığı Çevik Yazılım Geliştirme Manifestosu şu dört değeri öne çıkarır (sağdaki maddelerin değerini kabul ederken soldakileri daha önemli bulur):
- Bireyler ve etkileşimler, süreçlerden ve araçlardan ziyade
- Çalışan yazılım, kapsamlı dokümantasyondan ziyade
- Müşteri ile işbirliği, sözleşme pazarlıklarından ziyade
- Değişime karşılık vermek, bir plana bağlı kalmaktan ziyade
Bu, dokümantasyonun veya planın gereksiz olduğu anlamına gelmez; yalnızca onlara körü körüne bağlı kalmayıp işe yarayan yazılıma ve gerçek geri bildirime öncelik verildiğini gösterir. Manifestoya ek olarak 12 ilke de yayımlanmıştır.
Scrum nasıl işler?
Çevik anlayışı uygulamak için en yaygın kullanılan çerçeve Scrum'dır. Scrum Guide 2020, Scrum'ı karmaşık sorunlara uyarlanabilir çözümlerle değer üretmeye yardımcı olan hafif bir çerçeve olarak tanımlar.
| Bileşen | İçeriği |
|---|---|
| 3 sorumluluk | Developers (kullanılabilir ürün parçasını üretir), Product Owner (ürünün değerini maksimize eder), Scrum Master (Scrum'ın etkin uygulanmasını sağlar) |
| 5 etkinlik | Sprint (kapsayıcı etkinlik), Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective |
| 3 artefakt | Product Backlog (iş listesi), Sprint Backlog (o Sprint'in işleri), Increment (çıkan çalışan parça) |
| Sprint süresi | Sabit uzunlukta; bir ay veya daha kısa |
Müşteri olarak rolünüz
- Ürün sahibi olun veya yetkili birini atayın. Önceliklere karar verecek, soruları hızla yanıtlayacak kişi sizin tarafınızdan gelmelidir.
- Öncelik listesini (backlog) birlikte yazın. “Bu olmazsa olmaz, bu olsa iyi olur” ayrımını net yapın.
- Her Sprint sonundaki sunuma (Sprint Review) katılın. Çalışan yazılımı denemek ve geri bildirim vermek projenin yönünü belirler.
- “Bitti” tanımını netleştirin. Bir özelliğin ne zaman tamamlanmış sayılacağını (test edildi, onaylandı, canlıda çalıştı) baştan yazılı belirleyin.
- Değişiklik talebini kanalına koyun. Yeni istek varsa öncelik listesine eklenir ve mevcut işlerle kıyaslanır; sonradan “sessizce” eklenen işler bütçeyi ve süreyi bozar.
Ne zaman çevik, ne zaman sabit kapsam?
| Durum | Daha uygun yaklaşım |
|---|---|
| Gereksinimler belirsiz veya kullanıcı geri bildirimiyle şekillenecek | Çevik (kısa Sprint'ler, sık demo) |
| Piyasa veya iş süreçleri sık değişiyor | Çevik |
| Küçük, net tanımlı ve değişmeyecek iş | Sabit kapsam ve sabit fiyat |
| Standartları dışarıdan belirlenen entegrasyon (ör. GİB e-Belge) | Çekirdek kapsam sabit, teslim kademeli |
Örneğin GİB e-Belge sistemine doğrudan entegrasyon, GİB'in yayımladığı teknik kılavuzlara bağlıdır ve tebliğe göre başvurusu uygun bulunanlara test kullanıcısı verilir, entegrasyon çalışmalarının başvuru tarihinden itibaren en geç bir yıl içinde tamamlanması gerekir. Böyle bir projede gereksinimlerin büyük kısmı sabittir; yine de önce test ortamında çalışan bir sürümü, ardından canlıya geçişi kademeli teslim etmek çevik prensiplerle yürütülebilir. Entegrasyon yöntemlerini 509 tebliğ özeti yazımızda bulabilirsiniz.
Yazılım firmasına sormanız gereken sorular
- Sprint süreniz ve demo sıklığınız nedir? Her Sprint sonunda ne teslim edersiniz?
- Öncelik listesini ve “bitti” tanımını başlangıçta birlikte yazacak mıyız?
- Bütçe ve süre nasıl yönetilir? Kapsam değişirse maliyet nasıl hesaplanır?
- Kaynak kodu, doküman ve veritabanı şeması proje sonunda bana teslim edilecek mi?
- Test ve hata düzeltme süreciniz nasıl işliyor; canlıya çıkış sonrası destek nasıl?
Bu soruların net cevapları, projenin hem esnek hem kontrollü ilerlemesini sağlar. Özel yazılım ihtiyaçlarınız için yazılım geliştirme hizmetimizi inceleyebilir, e-ticaret ve muhasebe entegrasyon projelerinde API ve entegrasyon rehberimize göz atabilirsiniz.
Sıkça Sorulan Sorular
Çevik (Agile) ile Scrum aynı şey mi?
Hayır. Çevik, bir değerler ve ilkeler bütünüdür (2001 tarihli manifesto ve 12 ilke). Scrum ise bu yaklaşımı uygulamak için kullanılan çerçevelerden biridir. Kanban gibi başka yöntemler de çevik anlayışla kullanılabilir.
Çevik projede bütçe ve teslim tarihi belirsiz mi kalır?
Hayır, ama yaklaşım farklıdır. Çevik projelerde işler kısa Sprint'lere bölünür ve her Sprint sonunda çalışan bir parça teslim edilir. Bütçe ve süre genellikle sabit tutulur, kapsam öncelik sırasına göre esnetilir: en değerli işler önce yapılır, bütçe veya süre bittiğinde en değerli kısımlar hazır olur. Başlangıçta ürünün ana hedefi, öncelikleri ve “bitti” tanımı yazılı netleştirilmelidir.
Ürün sahibi (Product Owner) kim olmalıdır?
Scrum Guide'a göre Product Owner, ürünün değerini maksimize etmekten sorumludur. Müşteri tarafında iş alanını ve önceliklerini bilen, karar yetkisi olan bir kişi bu rolü üstlenmelidir. Karar yetkisi olmayan veya ulaşılamayan bir temsilci projeyi yavaşlatır.
Sprint ne kadar sürer?
Scrum Guide'a göre Sprint'ler tutarlılık sağlamak için sabit uzunlukta, bir ay veya daha kısa süreli olaylardır. Pratikte iki hafta çok yaygındır; süreyi ekiple birlikte belirlersiniz.
Her yazılım projesi için çevik yaklaşım uygun mu?
Gereksinimler belirsiz, değişken veya kullanıcı geri bildirimiyle şekillenen projelerde çevik yaklaşım güçlüdür. Gereksinimin kesin ve değişmez olduğu, küçük ve net işlerde sabit kapsamlı yaklaşım yeterli olabilir. Çoğu zaman ikisinin karışımı (ör. sabit çekirdek kapsam + esnek ek özellikler) en iyi sonucu verir.
Bu yazı genel bilgilendirme amaçlıdır; mali, hukuki veya vergisel danışmanlık yerine geçmez. Uygulamada resmî kaynakları ve mevzuatın güncel hâlini esas alın. Paron Teknoloji Editör Ekibi tarafından hazırlanmış ve 6 Ekim 2026 tarihinde gözden geçirilmiştir.
