Yazılım Projesi Yönetimi:
Agile ve Scrum Rehberi

Yazılım projelerinin başarısız olma oranı hala rahatsız edici derecede yüksek. Projelerin geç teslim edilmesi, bütçeyi aşması veya müşterinin beklentisini karşılamaması sektörde günlük karşılaşılan sorunlar. Bunun en büyük nedeni kod kalitesi değil, proje yönetimi yaklaşımıdır. Doğru yönetim metodolojisini seçmek ve ekibe doğru şekilde uygulamak, teknik yetkinlik kadar belirleyici bir faktör.

Waterfall: Klasik Yaklaşım ve Sınırları

Waterfall (şelale) modeli, yazılım geliştirmede yıllarca standart kabul edildi. Analiz, tasarım, geliştirme, test ve dağıtım aşamaları sırasıyla ve bir önceki aşama tamamlanmadan sonrakine geçilmeden uygulanır. Köprü inşaatı veya uçak tasarımı gibi gereksinimlerin baştan net olduğu projelerde mantıklı bir yaklaşımdır.

Ancak yazılım projeleri nadiren bu şekilde işler. Müşteri projenin ortasında fikir değiştirir. Pazar koşulları projenin başından sonuna kadar değişir. Kullanıcı testleri, başta doğru sanılan varsayımların yanlış olduğunu ortaya koyar. Waterfall modelinde bu değişikliklere uyum sağlamak ya çok pahalıdır ya da imkansızdır. Altı ay boyunca kapalı kapılar ardında geliştirilen bir ürünü teslim ettiğinizde müşterinin "ama ben bunu kastetmemiştim" demesini hepimiz yaşadık. Web geliştirme projelerimizde bu sorunu Agile yaklaşımla çözüyoruz.

Agile: Değişime Açık Geliştirme

Agile (çevik) metodoloji, 2001 yılında 17 yazılım geliştiricinin bir araya gelerek yayınladığı Agile Manifesto ile resmi şeklini aldı. Manifesto'nun dört temel değeri şöyledir:

• Süreçler ve araçlardan ziyade bireyler ve etkileşimler
• Kapsamlı dokümantasyondan ziyade çalışan yazılım
• Sözleşme pazarlığından ziyade müşteri işbirliği
• Plana bağlı kalmaktan ziyade değişime karşılık verme

Bu değerler "soldaki öğeleri reddediyoruz" anlamına gelmez. Dokümantasyon da önemlidir, plan da. Ama çalışan yazılım ve değişime uyum her zaman önceliklidir. Agile bir framework değil, bir zihniyettir. Scrum, Kanban, XP gibi framework'ler bu zihniyetin somut uygulamalarıdır.

Scrum Framework'ü

Scrum, Agile prensiplerini somut bir çerçeveye oturtan en yaygın kullanılan framework'tür. Jeff Sutherland ve Ken Schwaber tarafından geliştirilmiştir. Temelinde kısa iterasyonlar (sprint'ler) halinde çalışma, düzenli geri bildirim alma ve sürekli iyileştirme yatar.

Scrum Rolleri

Product Owner (Ürün Sahibi): Ürünün "ne" olacağını belirler. İş tarafını temsil eder, backlog'u önceliklendirir ve her sprint'te ekibin en değerli işi yapmasını sağlar. İyi bir Product Owner, hem iş hedeflerini hem de teknik kısıtları anlayan biridir. Her toplantıda "bu özelliği neden yapıyoruz" sorusuna net cevap verebilmelidir.

Scrum Master: Scrum'ın doğru uygulanmasını sağlayan kolaylaştırıcıdır. Yönetici değildir; ekibin önündeki engelleri kaldıran, süreçlerin düzgün işlemesini sağlayan bir koç rolündedir. İyi bir Scrum Master, ekibi mikro-yönetmek yerine kendi kendini organize etmesine yardımcı olur.

Geliştirme Ekibi: Ürünü gerçekten inşa eden kişilerdir. Genellikle 3-9 kişilik cross-functional (çapraz fonksiyonlu) ekiplerdir. Frontend, backend, test ve tasarım yetkinlikleri ekip içinde bulunmalıdır, böylece ekip dış bağımlılık olmadan iş teslim edebilir.

Sprint: Scrum'ın Kalp Atışı

Sprint, 1-4 haftalık sabit süreli çalışma dönemleridir. Çoğu ekip 2 haftalık sprint'ler kullanır. Sprint başında ekip, Product Owner ile birlikte backlog'dan öncelikli işleri seçer ve sprint boyunca bu işleri tamamlamaya odaklanır. Sprint süresi boyunca kapsam değişmez; bu, ekibin odaklanmasını sağlayan kritik bir kuraldır.

Scrum Seremonileri

Sprint Planning (Sprint Planlama): Sprint'in ilk gününde yapılır. Product Owner öncelikleri sunar, ekip hangi işleri tamamlayabileceğini tahmin eder. "Bu sprint'te ne yapacağız?" ve "Nasıl yapacağız?" sorularına cevap aranır. 2 haftalık sprint için genellikle 2-4 saatlik bir toplantıdır.

Daily Standup (Günlük Ayaküstü): Her gün 15 dakikayı geçmeyen kısa bir senkronizasyon toplantısıdır. Her ekip üyesi üç soruya cevap verir: Dün ne yaptım? Bugün ne yapacağım? Önümde bir engel var mı? Bu toplantı sorun çözme toplantısı değildir; sorunlar tespit edilir ve toplantı dışında çözülür.

Sprint Review: Sprint sonunda tamamlanan işler paydaşlara gösterilir. Demo yapılır, geri bildirim alınır. Bu toplantı sunumdan ibaret değildir; paydaşların çalışan yazılımı görerek yorum yapması, backlog'un güncellenmesi için kritik bir fırsattır.

Sprint Retrospective: Ekibin kendi sürecini değerlendirdiği toplantıdır. Neyi iyi yaptık? Neyi geliştirebiliriz? Bir sonraki sprint'te ne deneyeceğiz? Retrospective, sürekli iyileştirmenin motorudur. Bu toplantıyı ciddiye almayan ekipler aynı hataları tekrar tekrar yapar.

Kanban: Akışa Dayalı Alternatif

Her proje sprint'lere uygun değildir. Destek ekipleri, DevOps operasyonları veya sürekli bakım gerektiren projeler için Kanban daha uygun olabilir. Kanban'ın temel prensibi WIP (Work in Progress) limitidir: aynı anda devam eden iş sayısını sınırlayarak akışı optimize etmek.

Kanban board'unda işler "Yapılacak", "Devam Eden", "Review", "Tamamlanan" gibi kolonlar arasında hareket eder. Her kolonda aynı anda bulunabilecek iş sayısı sınırlıdır. Bu sınır, darboğazları görünür kılar. "Devam Eden" kolonunda WIP limiti 3 ise ve 3 iş de bloke olduysa, yeni iş almak yerine mevcut blokları çözmek gerekir.

Scrum ve Kanban birlikte de kullanılabilir. "Scrumban" olarak bilinen bu yaklaşımda sprint'ler korunurken WIP limitleri eklenir. Bu, özellikle Scrum'dan Kanban'a geçiş yapan ekipler için iyi bir ara adımdır.

Tahminleme Teknikleri

Yazılım projelerinde tahminleme kötü şöhretiyle bilinir, ama kaçınılmazdır. İş dünyası ne zaman ve ne kadara mal olacağını bilmek ister. Burada önemli olan mükemmel tahminler yapmak değil, yeterince iyi tahminler yapabilmek ve zamanla daha iyi hale gelmektir.

Story Points: İşin mutlak süresini değil, göreli karmaşıklığını ölçer. Fibonacci dizisi (1, 2, 3, 5, 8, 13, 21) kullanılır çünkü büyük işlerin belirsizliği de büyüktür. 1 puanlık bir iş basit bir metin değişikliği olabilir; 13 puanlık bir iş yeni bir entegrasyon geliştirmektir.

Planning Poker: Ekip üyeleri her iş için bağımsız olarak tahmin yapar, kartlarını aynı anda açar. Farklı tahminler tartışılır; en düşük ve en yüksek tahmini veren kişiler gerekçelerini açıklar. Bu süreç, gizli kalmış riskleri ve varsayımları ortaya çıkarır.

T-Shirt Sizing: Erken aşamada kaba tahminler için kullanılır. İşler S, M, L, XL olarak boyutlandırılır. Road map planlaması için yeterli detay sağlar, zaman kaybettirmez.

Yazılım Projelerinde Sık Yapılan Hatalar

Yıllar içinde gördüğüm en yaygın hatalar şunlardır:

• Scope creep (kapsam kayması): "Bir de şunu ekleyelim" cümleleri projeleri öldürür. Her eklenen özellik, zamanı ve bütçeyi etkiler. Product Owner'ın hayır demeyi bilmesi gerekir.
• Seremonileri atlamak: "Bu hafta retrospective yapmayalım, yetişecek işimiz var." Bu cümle, kısa vadede zaman kazandırır ama uzun vadede ekibi körleştirir.
• Teknik borcu görmezden gelmek: "Sonra düzeltiriz" denen kod parçaları birikir ve sonunda sistemi yavaşlatır. Her sprint'te teknik borç için kapasite ayırmak gerekir.
• Yetersiz iletişim: Uzaktan çalışma döneminde bu sorun daha da belirginleşti. Yazılı iletişim kültürünü oluşturmak, kararları dokümante etmek ve şeffaf olmak kritik önem taşır.
• Yetersiz test: "Test yazacak zamanımız yok" diyerek yola çıkan projeler, hata düzeltmeye daha çok zaman harcar. Otomatik testler yatırımdır, maliyet değil. Güvenlik testleri de bu kapsamda değerlendirilmelidir.

Araçlar: Jira, Linear ve Notion

Jira: Kurumsal dünyada en yaygın proje yönetim araçıdır. Scrum ve Kanban board'ları, sprint planlaması, raporlama ve entegrasyon seçenekleri zengindir. Ancak karmaşıklığı dezavantaj olabilir; küçük ekiplerde Jira kurulumu ve bakımı gereksiz yük oluşturabilir.

Linear: Modern yazılım ekipleri için tasarlanmış, hızlı ve minimal bir araçtır. Klavye kısayolları, otomatik durum güncellemeleri ve GitHub entegrasyonu ile geliştirici deneyimini ön plana koyar. Startup'lar ve küçük-orta ölçekli ekipler için mükemmel bir seçenektir.

Notion: Proje yönetimi, dokümantasyon ve bilgi tabanını tek bir yerde birleştirir. Board, liste, takvim ve timeline görünümleriyle esnek bir yapı sunar. Teknik dokümantasyon ve proje yönetimini aynı platformda tutmak isteyen ekipler için idealdir.

İletişim En İyi Pratikleri

Hangi araç ve metodolojiyi kullanırsanız kullanın, iletişim kalitesi projenin başarısını belirler. Birkaç pratik öneri:

• Toplantıları gündemsiz yapmayın. Gündem önceden paylaşılmalı, notlar toplantı sonrasında yazılmalıdır.
• Asenkron iletişimi tercih edin. Her soru için toplantı düzenlemek yerine, yazılı olarak sormayı ve cevaplanmasını bekleyebilecek konuları Slack veya benzeri araçlarda tartışmayı alışkanlık haline getirin.
• Kararları dokümante edin. "Kim, ne zaman, neden bu kararı aldı?" sorusuna her zaman cevap bulunabilmelidir. Hafızaya güvenmeyin.
• Düzenli demo yapın. Paydaşların çalışan yazılımı görmesi, yüzlerce sayfa rapordan daha etkilidir.

Yazılım proje yönetimi, doğru araçı seçmekten çok doğru kültürü oluşturmakla ilgilidir. Şeffaflık, güven ve sürekli iyileştirme kültürü olmadan en iyi araçlar bile etkisiz kalır.

Alphacore olarak projelerimizde Scrum ve Kanban'ı hibrit bir şekilde uyguluyoruz. Mikroservis projelerinde her servis ekibinin kendi board'u olurken, her projenin başında müşteriyle birlikte hangi yaklaşımın daha uygun olduğuna karar veriyoruz. Küçük ve sabit kapsamlı projeler için hafifleştirilmiş Scrum, sürekli geliştirme gerektiren ürünler için Kanban veya Scrumban tercih ediyoruz. Önemli olan kuralları ezberlemek değil, arkasındaki felsefeyi anlamak ve ekibinize uygun hale getirmektir.