Dış Kaynak Proje Yönetim Metodolojileri: Agile, Scrum ve Kanban

Agile vs Waterfall: Dış Kaynak Projelerinde Doğru Seçim

Yazılım dış kaynak projeleri başarılı olması için uygun proje yönetimi metodolojisinin seçilmesi kritiktir. İki ana yaklaşım vardır: Waterfall (ardışık) ve Agile (yinelemeli).

Waterfall modeli projenin başında tüm gereksinimleri tanımlamayı ve sabit bir takvim içinde ilerlemyi esas alır. Bu yaklaşım bütçe ve takvim konusunda kesinlik sağlar, ancak gereksinimler değişirse yüksek maliyetlere neden olur. Değişikliklerin tamamı resmi değişiklik kontrol süreçlerinden geçmesi gerekir. Feedback sadece proje sonunda alınır, bu da sorunların çok geç keşfedilmesine neden olabilir.

Agile metodolojisi ise sürekli geri bildirim ve yinelemeli geliştirmeye odaklanır. İki haftalık sprint döngüleri içinde ekip düzenli olarak ilerleme gösterir, müşteri feedback'i alır ve gereksinimler değiştiğinde hızlı adapte olabilir. Test ve kalite kontrol her sprint'te yapılır, bu da riskli bulguların erkenden ele alınmasını sağlar.

Dış kaynak projelerinde Agile tercih edilmesi daha akılcıdır. Neden? Çünkü müşteri ve sağlayıcı arasında haftalık demo ve senkronizasyonlar güven oluşturur, gereksinimlerin başında net olmayması problemli değildir (incremental olarak açıklığa kavuşur), teknoloji kararları kilitlenmiş olmaz, ve ekip dinamik ihtiyaçlara uyum sağlayabilir.

Scrum Framework: Dış Kaynak Projelerine Uyarlanmış

Scrum, Agile'ın en yaygın uygulamasıdır. Üç ana rol ve açık bir sprint döngüsü ile çalışır.

Scrum Rolleri ve Sorumluluklarıl

Ürün Sahibi (Product Owner), müşteri tarafından atanır ve bu role kalite kontrol sorumlulukları yükler. Backlog'u önceliklendirir, gereksinimleri açıklar, kabul kriteri belirler ve her sprint'te teslim edilen çalışmayı onaylar. Dış kaynak ortamında Ürün Sahibi sık sık müşteri şirketin başka bir ülkesinde bulunur; bu sebeple Smart Maple gibi sağlayıcılar vekillik yaparak koordinasyonu sağlar.

Scrum Master ekibi Scrum praksisleri takip etmesi için rehberlik eder. Kişisel kapasite sorunlarını (blockers) çözer, sprint toplantılarını yönetir ve retrospektif'leri kolaylaştırır. İdeal olarak proje yöneticisi rolünü üstlenebilir, fakat direktif vermeyen danışman niteliğinde hareket eder.

Geliştirme Ekibi (5-7 kişi), backend geliştirici, frontend geliştirici, kalite mühendisi ve DevOps mühendislerinden oluşur. Ekip sprint'te neler başaracağını tahmin eder, kodu yazar, testler yazar ve ürünü staging ortamında doğrular. Sprint sırasında kendi kendini organize eder ve üyeleri birbirlerinin çalışmalarını gözden geçirir.

Sprint Yaşam Döngüsü

Tipik bir iki haftalık sprint, dört temel etkinlik içerir.

Sprint Planlama (4 saat) haftanın başında yapılır. Ürün Sahibi backlog'un üst öğelerini sunup tartışırken, ekip her görevin ne kadar efor gerektireceğini tahmin eder. Geçmiş sprintlerdeki hız (velocity) ölçüsü kullanılarak bu sprint'te kaç puan kapasitesi vardır hesaplanır. Ekip kesin olarak ne yapabileceğini taahhüt eder.

Günlük Standup (15 dakika) her gün aynı saatte yapılır. Her takım üyesi dün neleri bitirdiğini, bugün ne yapacağını ve karşılaştığı engelleri kısaca paylaşır. Engel varsa, Scrum Master toplantı sonrası hızlı bir çözüm toplantısı organize eder.

Sprint Demo/Review (90 dakika) sprintin sonunda yapılır. Ekip her tamamlanan özelliği staging ortamında canlı gösterir. Ürün Sahibi kabul kriteri geçtiğini onaylar. Müşteri ve paydaşlar yeni özellikleri görür ve feedback verir. Gelecek sprint'in teaser'ı yapılır.

Retrospektif (90 dakika) sprint'ten öğrenmek için yapılır. Ekip neler iyi gitti, neler iyileştirilebilir tartışır. Alınan iyileştirme kararları yazılır ve sonraki sprint'te uygulanmaya başlanır. Ekip kendi moralini kontrol eder.

Sprint'in İçinde: İş Akışı ve Kalite

Sprint başında, ekip görevleri alt görevlere ayırır. Backend, frontend, test ve diğer disiplinler paralel olarak ilerler. Her yazılan kod, diğer iki takım üyesinin tarafından gözden geçirilir. Gözden geçirme hedefi 24 saat içinde gerçekleşir. Yazılan her kod otomatik testlerden geçmek zorundadır (%80 coverage hedefi). Staging ortamına deploy edilmeden önce kalite mühendisi kabul testlerini çalıştırır.

Sprint sırasında takım burndown şeması (günlük kalan puan) takip eder. İdeal olarak kalan puanlar lineer olarak azalır. Eğer sprint 5. güne gelip hâlâ hiçbir şey yapılmamışsa, bu sorunun işareti ve Scrum Master derhal müdahale eder.

Kanban: Operasyonel Bakım İçin

Scrum tüm projeler için idealdir değildir. Operasyon desteği, bakım ve hata çözümleri daha devamlı bir akışa ihtiyaç duyar. Kanban bu senaryolara uygundur.

Kanban bir görev tablosu kullanır: Backlog → Hazır → Devam Ediyor → İncelemede → Testi Yapılıyor → Tamamlandı. Her sütünda limit vardır (örneğin "Devam Ediyor"da en fazla 3 hata aynı anda çalışılır). Sorunlar bu tablodan akar ve tamamlanmış olan işler kaydedilir. Ortalama bir hata Backlog'dan Tamamlandı'ya 3 gün içinde gider.

Smart Maple, özellikle büyük projelerde Scrum ve Kanban'ı birleştirir: Yeni özellikler Scrum sprint'leriyle geliştirilir, ama aynı zamanda prodüksyon ortamında keşfedilen hatalar Kanban sistemiyle hızlı çözülür.

SAFe: Büyük Kuruluşlar İçin

Organizasyon 200+ mühendis istihdam ediyorsa ve 10+ Scrum takımı paralel olarak çalışıyorsa, SAFe (Scaled Agile Framework) gerekebilir. Bunu takımlar arasında koordinasyon sağlar. Smart Maple ve Oplist ölçeğindeki projeler için SAFe çok ağır kalır; basit Scrum ve disiplin yeterlidir.

Başarı Metrikleri: Hız ve Sağlık

Scrum takımlarının sağlığını ölçmenin ana yolları vardır.

Hız (Velocity), takımın her sprint'te kaç puan bitirdiğidir. Oplist örneğinde, ilk sprint'lerde 28-32 puan, eğitim devam ederken 40-42 puana çıktı ve sonra 38-41 arasında stabil kaldı. Ortalama 37 puan ölçüsü kulllanılarak sonraki sprint'te plan yapılır. Takım 30% buffer tutarsa (interrupts ve bugs için), gerçekten 26 puan kesinlikle yapacağı garantilenebilir.

Burndown şeması, sprint'in her günü kalan işin miktarını gösterir. İdeal olarak kalan iş lineer olarak azalır. Gerçekte bazı gün yükselen noktalar olabilir (bug bulunur, daha fazla iş eklenir), ama genel trend aşağı olmalıdır. Sprint'in ortasında hâlâ %80 iş kalmışsa, bu sprint'i kaybedeceğinin işareti ve acil müdahale gerekir.

Dış Kaynak Projelerimdeki Yaygın Zorluklar

Zaman Dilimi Farkı

Ankara (UTC+3) ve Londra (UTC+0/1) arasında sadece 6-7 saat örtüşme vardır. Standup'ı örtüşme saatinde yapmak zorunludur. Diğer tüm iletişim asenkron yazılı olmalıdır. Slack'de kararlar alınmaz; GitHub ve Confluence'ta kaydedilir. Yanıt süresi hedefi 24 saat'dir.

Kod Gözden Geçirme

Uzak takımda bir kodun review'ü saatler alabilir. Çözüm: Küçük pull request'ler (200-400 satır), açık PR template ve haftalık pairing oturumlarıdır.

Bağlam Bilgisi

Kimin veritabanı şeması bildiği, kimin API tasarımıyla ilgilendiği bilinmelidir. Çözüm: Wiki sayfaları, mimari diyagramlar ve düzenli bilgi paylaşım oturumlarıdır.

Özet

Dış kaynak yazılım projelerinde başarının anahtarı, Agile (özellikle Scrum) metodolojisini sıkı şekilde uygulamaktır. İki haftalık sprint'ler, haftalık demo'lar, düzenli retrospektif'ler ve asenkron-first iletişim kombinasyonu güven oluşturur, hataları erken yakalar ve takımın motivasyonunu yüksek tutar.

Smart Maple, Oplist gibi müşteriler ile çalışırken bu praksisleri takip ederek, 12 ayda 250+ özelliği teslim etmiş ve üretim ortamında 99.99% uptime sağlamıştır.

Dış kaynak ortağınız bu metodolojileri ciddiye alıyorsa, projenizin başarı olasılığı önemli oranda artar.

---

Proje yönetimi yaklaşımınızı modernleştirmek mi istiyorsunuz? Smart Maple, Scrum-disiplinli ekip ve haftalık teslimat standartları ile beklenmedik projeleri başarılı kılıyor. Danışma için smart-maple.com ziyaret edin ya da [email protected] adresine yazın.