[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"blog-post-8-haftalik-urun-odakli-yazilim-gelistirme-egitim-plani-ve-proje-ornekleri":3},{"dataItem":4,"heading":36,"metaData":38,"schema":81},["Reactive",5],{"id":6,"title":7,"summary":8,"content":9,"seo_title":10,"seo_description":11,"seo_keywords":12,"slug":13,"createdAt":14,"updatedAt":14,"blog_categories":15,"authors":19,"image":24,"thumb":25,"image_webp":26,"thumb_webp":27,"rating":28,"heading_title":7,"heading_sub_title":17,"readingTime":29,"url":34,"comments":35,"meta_cover":24},22581,"8 Haftalık Ürün Odaklı Yazılım Geliştirme Eğitim Planı ve Proje Örnekleri","Bu rehber, ürün odaklı bir yazılım geliştirme eğitimini 8 haftaya bölerek hedefleri, ölçülebilir teslimleri, sprint akışını ve değerlendirme yöntemlerini verir. TDD ve test piramidi yaklaşımıyla testleri erken konumlandırır, küçük PR’lar ve yapılandırılmış kod inceleme pratiklerini müfredata ekler. Ayrıca 3 örnek proje brifi ve her biri için haftalık kilometre taşları sunar.","\u003Ch2>Bu 8 haftalık plan neyi hedefler?\u003C/h2>\n\u003Cp>Bu eğitim planı, “bir dili öğretmekten” çok \u003Cstrong>ürün odaklı yazılım geliştirme\u003C/strong> alışkanlıklarını kazandırmayı amaçlar: kullanıcı ihtiyacını netleştirme, kapsamı küçük tutma (MVP), iteratif teslim (sprint), ölçülebilir kalite (test), ekip içi çalışma (kod inceleme) ve üretime yakın bir çalışma ritmi.\u003C/p>\n\n\u003Cblockquote>\n\u003Cp>\u003Cstrong>Hedef kitle & önkoşullar (beklentiyi netleştirme)\u003C/strong>\u003Cbr>\n\u003Cstrong>Kimler için:\u003C/strong> Temel programlama bilgisi olan (değişkenler, fonksiyonlar, veri yapıları) ve Git/komut satırına giriş yapmış geliştiriciler veya ekipler.\u003Cbr>\n\u003Cstrong>Önkoşullar:\u003C/strong> En az 1 küçük uygulama geliştirmiş olmak, Git ile branch/commit atabilmek, test çalıştırma mantığını bilmek.\u003Cbr>\n\u003Cstrong>Kapsam dışı:\u003C/strong> Bu plan belirli bir teknoloji yığını seçtirmez ve “işe yerleştirme” gibi kesin sonuçlar vaat etmez; amaç ölçülebilir proje çıktıları ve tekrar edilebilir ekip pratikleridir.\u003C/p>\n\u003C/blockquote>\n\n\u003Cp>Zaman planı programdan programa değişir. \u003Cstrong>Örnek olarak\u003C/strong> bir bootcamp program sayfasında 8 haftalık part-time bir faz için \u003Cem>haftada 20–25 saat\u003C/em> civarı bir taahhüt ifadesi yer alır; bu sayı burada “genel bir pazar standardı” olarak değil, \u003Cstrong>tek bir örnek\u003C/strong> olarak iş yükünü kaba taslak planlamaya yardımcı olması için anılır (\u003Ca href=\"https://launchacademy.com/program/\">S4\u003C/a>).\u003C/p>\n\u003Chr>\n\n\u003Ch2>Programın omurgası: Sprint + Proje-Temelli Öğrenme\u003C/h2>\n\u003Cp>8 haftaya sığan pratik bir kurgu genellikle \u003Cstrong>2–3 sprint\u003C/strong> ya da tek bir capstone projenin sprint mantığıyla ilerlemesidir. Proje-temelli öğrenme yaklaşımında öğrenme, ders anlatımından çok “gerçekçi bir problem” etrafında yapılandırılır ve \u003Cstrong>ara teslimlerle\u003C/strong> takip edilir; bu da geri bildirim döngüsünü görünür kılar (\u003Ca href=\"https://www.pblworks.org/blog/project-based-learning-all\">S3\u003C/a>).\u003C/p>\n\u003Cp>Bu nedenle planı şu üç eksende tasarlıyoruz:\u003C/p>\n\u003Cul>\n\u003Cli>\u003Cstrong>Ürün ekseni:\u003C/strong> kullanıcı hikâyeleri, kabul kriterleri, MVP ve backlog yönetimi\u003C/li>\n\u003Cli>\u003Cstrong>Mühendislik ekseni:\u003C/strong> test stratejisi (TDD ve test piramidi), kod kalitesi, gözden geçirme\u003C/li>\n\u003Cli>\u003Cstrong>Takım ekseni:\u003C/strong> PR akışı, rol paylaşımı, demo ve retrospektif\u003C/li>\n\u003C/ul>\n\u003Chr>\n\n\u003Ch2>Başlamadan: Araçlar, repo düzeni ve çalışma kuralları\u003C/h2>\n\u003Ch3>Önerilen minimum araç seti\u003C/h3>\n\u003Cul>\n\u003Cli>\u003Cstrong>Git + GitHub\u003C/strong> (branch, PR, review, issues)\u003C/li>\n\u003Cli>\u003Cstrong>Test çerçevesi\u003C/strong> (seçtiğiniz dile göre: ör. Jest/Pytest/JUnit vb.)\u003C/li>\n\u003Cli>\u003Cstrong>CI\u003C/strong> (ör. GitHub Actions) ile testlerin PR’da otomatik çalışması\u003C/li>\n\u003Cli>\u003Cstrong>Baseline kalite kontrolleri\u003C/strong>: linter/formatter, basit güvenlik taramaları (imkâna göre)\u003C/li>\n\u003C/ul>\n\n\u003Ch3>Kod inceleme (PR) için temel kurallar\u003C/h3>\n\u003Cp>Kod inceleme, sadece “hata bulma” değil; ekip standartlarını öğretmek, tasarımı tartışmak ve bilgi paylaşmaktır. GitHub’ın önerileri; \u003Cstrong>küçük ve odaklı PR’lar\u003C/strong>, net bağlam ve otomasyonla desteklenen kontroller gibi pratiklerin gözden geçirme kalitesini artırmaya yardımcı olabileceğini vurgular (\u003Ca href=\"https://github.com/resources/articles/software-development/how-to-improve-code-with-code-reviews\">S1\u003C/a>).\u003C/p>\n\u003Cul>\n\u003Cli>PR başına hedef: tek bir kullanıcı hikâyesi ya da tek bir teknik iş\u003C/li>\n\u003Cli>PR açıklaması: “Ne değişti, neden, nasıl test edilir?”\u003C/li>\n\u003Cli>En az 1 bağımsız inceleyici; kritik dosyalarda 2 inceleyici (ekip uygunsa)\u003C/li>\n\u003Cli>İnceleme checklist’i: güvenlik, performans, test, okunabilirlik, hata durumları\u003C/li>\n\u003C/ul>\n\u003Chr>\n\n\u003Ch2>Test yaklaşımı: TDD ve test piramidi (özet ve uygulama)\u003C/h2>\n\u003Cp>Testleri “en sona” bırakmak, 8 haftalık yoğun bir programda risk oluşturur: hızlanmak için kalite borcu birikir ve proje ilerledikçe değişiklik maliyeti artar. Bu yüzden TDD ve test piramidi gibi yaklaşımları daha ilk haftalardan sisteme bağlamak faydalıdır. Burada araçlardan çok, \u003Cstrong>uzun süredir kullanılan mühendislik prensiplerine\u003C/strong> odaklanıyoruz (\u003Ca href=\"https://martinfowler.com/testing/\">S2\u003C/a>).\u003C/p>\n\n\u003Ch3>Test piramidi ile pratik hedefler\u003C/h3>\n\u003Cul>\n\u003Cli>\u003Cstrong>Çok sayıda birim testi:\u003C/strong> iş kuralları, edge-case’ler\u003C/li>\n\u003Cli>\u003Cstrong>Daha az entegrasyon testi:\u003C/strong> API + DB gibi kritik akışlar\u003C/li>\n\u003Cli>\u003Cstrong>En az sayıda UI/E2E testi:\u003C/strong> “en kritik kullanıcı yolculuğu” için\u003C/li>\n\u003C/ul>\n\u003Cp>Bu rehber bir “kapsama yüzdesi” hedefi dayatmaz; ölçülebilir hedef olarak şunları kullanabilirsiniz: kritik kullanıcı akışlarının test edilmesi, PR’larda test ekleme alışkanlığı ve regresyon hatalarının daha erken yakalanması.\u003C/p>\n\u003Chr>\n\n\u003Ch2>8 haftalık ürün odaklı eğitim planı (hafta hafta)\u003C/h2>\n\u003Cp>Aşağıdaki plan, tek bir ana projeyi 8 hafta boyunca büyütmeye uygundur. İsterseniz aynı yapıyı 2 daha küçük projeye bölebilirsiniz; ancak ürün odaklı akışın oturması için tek proje daha tutarlı olabilir.\u003C/p>\n\u003Ctable>\n\u003Cthead>\n\u003Ctr>\n\u003Cth>Hafta\u003C/th>\n\u003Cth>Odak\u003C/th>\n\u003Cth>Öğrenme hedefi\u003C/th>\n\u003Cth>Teslim (ölçülebilir çıktı)\u003C/th>\n\u003C/tr>\n\u003C/thead>\n\u003Ctbody>\n\u003Ctr>\n\u003Ctd>1\u003C/td>\n\u003Ctd>Problem ve MVP\u003C/td>\n\u003Ctd>Kullanıcı hikâyesi yazma, kabul kriterleri, repo/CI kurulumu\u003C/td>\n\u003Ctd>Backlog + MVP tanımı, çalışan CI, “Hello feature” PR’ı\u003C/td>\n\u003C/tr>\n\u003Ctr>\n\u003Ctd>2\u003C/td>\n\u003Ctd>Temel mimari\u003C/td>\n\u003Ctd>Modüler yapı, veri modeli, API sözleşmesi\u003C/td>\n\u003Ctd>İlk endpoint’ler + birim testleri, küçük PR’larla ilerleme\u003C/td>\n\u003C/tr>\n\u003Ctr>\n\u003Ctd>3\u003C/td>\n\u003Ctd>TDD ile çekirdek özellik\u003C/td>\n\u003Ctd>İş kuralı geliştirme, test piramidi mantığı\u003C/td>\n\u003Ctd>Çekirdek akış için testler + özellik demo’su\u003C/td>\n\u003C/tr>\n\u003Ctr>\n\u003Ctd>4\u003C/td>\n\u003Ctd>Entegrasyon ve hata yönetimi\u003C/td>\n\u003Ctd>Validation, hata cevapları, logging temelleri\u003C/td>\n\u003Ctd>Entegrasyon testi eklenmiş 1–2 kritik API akışı\u003C/td>\n\u003C/tr>\n\u003Ctr>\n\u003Ctd>5\u003C/td>\n\u003Ctd>Ön yüz/istemci\u003C/td>\n\u003Ctd>İstemci-API entegrasyonu, durum yönetimi\u003C/td>\n\u003Ctd>Minimum arayüz + API bağlantısı, kullanılabilir MVP\u003C/td>\n\u003C/tr>\n\u003Ctr>\n\u003Ctd>6\u003C/td>\n\u003Ctd>Kalite ve gözden geçirme\u003C/td>\n\u003Ctd>Kod inceleme kalitesi, refactor, teknik borç azaltma\u003C/td>\n\u003Ctd>Refactor PR’ları, checklist uygulanması, testlerin güçlenmesi\u003C/td>\n\u003C/tr>\n\u003Ctr>\n\u003Ctd>7\u003C/td>\n\u003Ctd>Üretime yakınlaştırma\u003C/td>\n\u003Ctd>Basit güvenlik kontrolleri, performans temelleri\u003C/td>\n\u003Ctd>Deploy denemesi (ortama göre), kritik akış için E2E testi\u003C/td>\n\u003C/tr>\n\u003Ctr>\n\u003Ctd>8\u003C/td>\n\u003Ctd>Sunum ve değerlendirme\u003C/td>\n\u003Ctd>Demo, ölçüm, dokümantasyon, retrospektif\u003C/td>\n\u003Ctd>Capstone demo + teknik dokümantasyon + öğrenilenler raporu\u003C/td>\n\u003C/tr>\n\u003C/tbody>\n\u003C/table>\n\u003Chr>\n\n\u003Ch2>Her hafta uygulanacak sprint ritmi (checklist)\u003C/h2>\n\u003Cp>Proje-temelli öğrenme yaklaşımını güçlü kılan şey “haftalık ritim”dir: planla, yap, göster, ölç, iyileştir. Ara teslimler ve düzenli geri bildirim döngüleri özellikle önemlidir (\u003Ca href=\"https://www.pblworks.org/blog/project-based-learning-all\">S3\u003C/a>).\u003C/p>\n\u003Cul>\n\u003Cli>\u003Cstrong>Pazartesi/başlangıç:\u003C/strong> Sprint hedefi, 3–6 kullanıcı hikâyesi seçimi, görev kırılımı\u003C/li>\n\u003Cli>\u003Cstrong>Günlük 10–15 dk:\u003C/strong> blokajlar ve PR sırası (kim neyi review ediyor?)\u003C/li>\n\u003Cli>\u003Cstrong>Hafta ortası:\u003C/strong> ara demo + backlog yeniden önceliklendirme\u003C/li>\n\u003Cli>\u003Cstrong>Hafta sonu:\u003C/strong> demo + retrospektif (1 iyileştirme kararı)\u003C/li>\n\u003C/ul>\n\u003Chr>\n\n\u003Ch2>Pratik şablonlar: PR açıklaması ve demo rubriği\u003C/h2>\n\u003Cp>Aşağıdaki şablonlar, “ne yaptık?”tan çok “nasıl doğruladık?” sorusunu standartlaştırır. Kod incelemeyi küçük PR’lar ve net bağlamla güçlendirme önerileri için GitHub’ın kılavuzunu referans alabilirsiniz (\u003Ca href=\"https://github.com/resources/articles/software-development/how-to-improve-code-with-code-reviews\">S1\u003C/a>).\u003C/p>\n\n\u003Ch3>PR açıklama şablonu (kopyala-yapıştır)\u003C/h3>\n\u003Ctable>\n\u003Cthead>\n\u003Ctr>\n\u003Cth>Alan\u003C/th>\n\u003Cth>Ne yazılmalı?\u003C/th>\n\u003C/tr>\n\u003C/thead>\n\u003Ctbody>\n\u003Ctr>\n\u003Ctd>Özet\u003C/td>\n\u003Ctd>Bu PR neyi değiştiriyor? (1–3 madde)\u003C/td>\n\u003C/tr>\n\u003Ctr>\n\u003Ctd>Neden\u003C/td>\n\u003Ctd>Hangi kullanıcı hikâyesi / sorun / kabul kriteri?\u003C/td>\n\u003C/tr>\n\u003Ctr>\n\u003Ctd>Nasıl test edilir?\u003C/td>\n\u003Ctd>Komutlar, senaryolar, örnek istek/yanıt\u003C/td>\n\u003C/tr>\n\u003Ctr>\n\u003Ctd>Riskler\u003C/td>\n\u003Ctd>Geriye dönük uyumluluk, veri değişimi, kritik akış etkisi\u003C/td>\n\u003C/tr>\n\u003Ctr>\n\u003Ctd>Ekran görüntüsü / çıktı\u003C/td>\n\u003Ctd>UI varsa ekran görüntüsü; yoksa log/çıktı örneği\u003C/td>\n\u003C/tr>\n\u003C/tbody>\n\u003C/table>\n\n\u003Ch3>Haftalık demo için mini rubrik\u003C/h3>\n\u003Ctable>\n\u003Cthead>\n\u003Ctr>\n\u003Cth>Kriter\u003C/th>\n\u003Cth>Minimum kanıt\u003C/th>\n\u003C/tr>\n\u003C/thead>\n\u003Ctbody>\n\u003Ctr>\n\u003Ctd>Ürün\u003C/td>\n\u003Ctd>1–2 kullanıcı hikâyesi + kabul kriterine göre gösterim\u003C/td>\n\u003C/tr>\n\u003Ctr>\n\u003Ctd>Kalite\u003C/td>\n\u003Ctd>En az 1 yeni test + CI çıktısı\u003C/td>\n\u003C/tr>\n\u003Ctr>\n\u003Ctd>Süreç\u003C/td>\n\u003Ctd>PR linkleri + 1–2 önemli review yorumu\u003C/td>\n\u003C/tr>\n\u003Ctr>\n\u003Ctd>Öğrenme\u003C/td>\n\u003Ctd>Bu hafta neyi iyileştirdik? (retrospektiften 1 karar)\u003C/td>\n\u003C/tr>\n\u003C/tbody>\n\u003C/table>\n\u003Chr>\n\n\u003Ch2>Örnek proje brifleri (ürün odaklı, 8 haftaya uygun)\u003C/h2>\n\u003Ch3>Proje 1: “Randevu Takip” mini SaaS (B2C)\u003C/h3>\n\u003Cp>\u003Cstrong>Kullanıcı problemi:\u003C/strong> Hizmet alan kullanıcıların randevularını kaçırmaması, hizmet verenin çakışmaları azaltması.\u003C/p>\n\u003Cul>\n\u003Cli>\u003Cstrong>MVP:\u003C/strong> kayıt/giriş, randevu oluşturma, listeleme, iptal\u003C/li>\n\u003Cli>\u003Cstrong>Hafta 3–4:\u003C/strong> çakışma kontrolü (iş kuralı) + TDD ile geliştirme\u003C/li>\n\u003Cli>\u003Cstrong>Hafta 5:\u003C/strong> basit takvim görünümü (istemci)\u003C/li>\n\u003Cli>\u003Cstrong>Hafta 7:\u003C/strong> validation ve temel istek sınırlandırma gibi korumalar (ihtiyaca göre)\u003C/li>\n\u003C/ul>\n\u003Cp>\u003Cstrong>Değerlendirme ipucu:\u003C/strong> “Randevu çakışması” kuralı için birim testlerini zorunlu tutmak, TDD mantığını somutlaştırır (\u003Ca href=\"https://martinfowler.com/testing/\">S2\u003C/a>).\u003C/p>\n\n\u003Ch3>Proje 2: “Okuma Listesi + Notlar” (İçerik/Blog odaklı)\u003C/h3>\n\u003Cp>\u003Cstrong>Kullanıcı problemi:\u003C/strong> İçerik üreticilerinin/link toplayanların kaynaklarını etiketleyip not alması.\u003C/p>\n\u003Cul>\n\u003Cli>\u003Cstrong>MVP:\u003C/strong> link ekleme, etiketleme, arama, not ekleme\u003C/li>\n\u003Cli>\u003Cstrong>Hafta 2:\u003C/strong> API sözleşmesi + veri modeli\u003C/li>\n\u003Cli>\u003Cstrong>Hafta 4:\u003C/strong> arama ve filtreleme (edge-case’lerle test)\u003C/li>\n\u003Cli>\u003Cstrong>Hafta 6:\u003C/strong> refactor: servis katmanı / modülerleşme (dile göre)\u003C/li>\n\u003C/ul>\n\u003Cp>\u003Cstrong>Kod inceleme odağı:\u003C/strong> Arama/filtre PR’larını küçük tutun ve inceleme checklist’ine “performans ve hata durumları” maddesi ekleyin (\u003Ca href=\"https://github.com/resources/articles/software-development/how-to-improve-code-with-code-reviews\">S1\u003C/a>).\u003C/p>\n\n\u003Ch3>Proje 3: “IT Envanter ve Ticket” (Basit iç araç)\u003C/h3>\n\u003Cp>\u003Cstrong>Kullanıcı problemi:\u003C/strong> Küçük ekiplerde cihaz/envanter takibi ve basit destek talepleri.\u003C/p>\n\u003Cul>\n\u003Cli>\u003Cstrong>MVP:\u003C/strong> cihaz ekle, kullanıcıya ata, ticket aç/kapat, durumlar\u003C/li>\n\u003Cli>\u003Cstrong>Hafta 3:\u003C/strong> rol bazlı yetkilendirme taslağı (basit seviyede)\u003C/li>\n\u003Cli>\u003Cstrong>Hafta 5:\u003C/strong> yönetim paneli sayfaları\u003C/li>\n\u003Cli>\u003Cstrong>Hafta 8:\u003C/strong> kısa teknik dokümantasyon + kurulum adımları\u003C/li>\n\u003C/ul>\n\u003Chr>\n\n\u003Ch2>Kod inceleme pratikleri: Eğitimde nasıl öğretilir?\u003C/h2>\n\u003Cp>Kod inceleme becerisi, “yorum yazmayı” değil, \u003Cstrong>risk yönetimini\u003C/strong> öğretir: değişikliğin kapsamını küçültme, geri alma kolaylığı, test edilebilirlik ve okunabilirlik. GitHub’ın kılavuzu, küçük PR’lar ve otomasyon kontrolleriyle desteklenen incelemelerin ekip içinde tutarlılığı artırmaya yardımcı olabileceğini anlatır (\u003Ca href=\"https://github.com/resources/articles/software-development/how-to-improve-code-with-code-reviews\">S1\u003C/a>).\u003C/p>\n\n\u003Ch3>İnceleme egzersizi\u003C/h3>\n\u003Cp>Her hafta 1 kez, ekipteki herkesin aynı PR’a asenkron review yaptığı bir egzersiz planlayın. Ardından 15 dakika “hangi riski neden vurguladık?” tartışması yapın. Amaç, tek bir doğru yorum seti üretmek değil; ortak standartları görünür kılmaktır.\u003C/p>\n\u003Chr>\n\n\u003Ch2>AI destekli araçlar: Nerede işe yarar, nerede yetmez?\u003C/h2>\n\u003Cp>\u003Cstrong>AI kod tamamlama ve metin asistanları\u003C/strong> (marka bağımsız) hız kazandırabilir; ancak eğitim hedefiniz, “kod üretmek” kadar \u003Cstrong>doğru kodu doğrulamak\u003C/strong> olmalıdır. Bu yüzden AI kullanımını ölçülebilir ve kontrol edilebilir işlere bağlamak daha sağlıklıdır:\u003C/p>\n\u003Cul>\n\u003Cli>PR açıklaması için taslak üretme (son düzenleme geliştiricide)\u003C/li>\n\u003Cli>Test senaryosu fikirleri üretme (son karar ekipte; testlerle doğrulama şart)\u003C/li>\n\u003Cli>Refactor seçenekleri önermek (CI ve test kapılarıyla doğrulamak)\u003C/li>\n\u003C/ul>\n\u003Cp>Bu yaklaşım, kod inceleme ve otomasyon kontrollerinin önemini vurgulayan genel PR disiplinine uyumludur (\u003Ca href=\"https://github.com/resources/articles/software-development/how-to-improve-code-with-code-reviews\">S1\u003C/a>).\u003C/p>\n\u003Chr>\n\n\u003Ch2>Değerlendirme: Not vermekten çok, kanıt üretmek\u003C/h2>\n\u003Cp>8 haftalık programlarda en yaygın hata, sadece “proje çalışıyor mu?” üzerinden değerlendirmektir. Bunun yerine süreç kanıtı toplayın: PR geçmişi, testlerin evrimi, demo düzeni, retrospektif çıktıları. Proje-temelli öğrenme yaklaşımı ara teslim ve süreç değerlendirmesini özellikle öne çıkarır (\u003Ca href=\"https://www.pblworks.org/blog/project-based-learning-all\">S3\u003C/a>).\u003C/p>\n\u003Cul>\n\u003Cli>\u003Cstrong>Ürün düşüncesi:\u003C/strong> MVP netliği, kullanıcı hikâyeleri, kabul kriterleri\u003C/li>\n\u003Cli>\u003Cstrong>Mühendislik kalitesi:\u003C/strong> test stratejisi, hata yönetimi, okunabilirlik\u003C/li>\n\u003Cli>\u003Cstrong>Takım süreci:\u003C/strong> küçük PR’lar, review kalitesi, sprint ritmi\u003C/li>\n\u003Cli>\u003Cstrong>Dokümantasyon ve sunum:\u003C/strong> kurulum, demo akışı, öğrenilenler\u003C/li>\n\u003C/ul>\n\u003Chr>\n\n\u003Ch2>Part-time ve full-time varyantı nasıl uyarlanır?\u003C/h2>\n\u003Cul>\n\u003Cli>\u003Cstrong>Part-time:\u003C/strong> Kapsamı daraltın, UI’yı minimal tutun, test ve PR disiplinini koruyun. İş yükü tahmini yaparken tekil program örneklerinden ilham alabilir, kendi kohortunuzla kalibre edebilirsiniz (\u003Ca href=\"https://launchacademy.com/program/\">S4\u003C/a>).\u003C/li>\n\u003Cli>\u003Cstrong>Full-time:\u003C/strong> Daha yoğun bloklarla ikinci bir entegrasyon (örn. bildirimler, arka plan işleyicileri) eklenebilir; yine de sprint hedefini küçük tutun.\u003C/li>\n\u003C/ul>\n\u003Chr>\n\n\u003Ch2>Hızlı başlangıç: İlk 48 saatte yapılacaklar\u003C/h2>\n\u003Col>\n\u003Cli>Tek bir proje seçin ve 10–15 kullanıcı hikâyesi yazın (MVP için 3–5 tanesini işaretleyin).\u003C/li>\n\u003Cli>Repo + CI kurun: testler PR’da çalışsın.\u003C/li>\n\u003Cli>PR şablonu ve review checklist’i ekleyin.\u003C/li>\n\u003Cli>Test stratejisi sayfası oluşturun: birim/entegrasyon/E2E kapsamı.\u003C/li>\n\u003Cli>Hafta 1 demo tarihini belirleyin ve demo kriterini yazın.\u003C/li>\n\u003C/ol>\n\u003Chr>\n\n\u003Ch2>Sonuç\u003C/h2>\n\u003Cp>8 haftalık ürün odaklı bir yazılım eğitimi, doğru kurgulandığında katılımcılara “tek seferlik proje”den çok \u003Cstrong>tekrar edilebilir geliştirme alışkanlığı\u003C/strong> kazandırabilir. Ana kaldıraçlar: ara teslimli proje-temelli öğrenme (\u003Ca href=\"https://www.pblworks.org/blog/project-based-learning-all\">S3\u003C/a>), testleri erken kurmak (TDD ve test piramidi prensipleri) (\u003Ca href=\"https://martinfowler.com/testing/\">S2\u003C/a>) ve küçük PR’larla yapılandırılmış kod inceleme kültürü (\u003Ca href=\"https://github.com/resources/articles/software-development/how-to-improve-code-with-code-reviews\">S1\u003C/a>).\u003C/p>\n\u003Cp>Planı doğrudan uygulayabilir veya hedef kitlenize göre sadeleştirip pilotlayabilirsiniz. En iyi iyileştirmeler genellikle ilk kohortun PR verilerinden, demo geri bildirimlerinden ve haftalık retrospektiflerden çıkar.\u003C/p>","8 Haftalık Ürün Odaklı Yazılım Eğitimi (TDD ve PR)","8 haftada ürün odaklı yazılım geliştirmeyi öğretmek için haftalık hedefler, sprint teslimleri, TDD/test piramidi, kod inceleme (PR) akışı ve 3 örnek proje brifi","ürün odaklı yazılım geliştirme, yazılım eğitim planı, 8 haftalık bootcamp müfredatı, TDD, test piramidi, kod inceleme, pull request, MVP, sprint planlama, proje temelli öğrenme","8-haftalik-urun-odakli-yazilim-gelistirme-egitim-plani-ve-proje-ornekleri","2026-03-18T16:08:46.000Z",{"id":16,"title":17,"slug":18},596,"Yazılım Eğitimleri","yazilim-egitimleri",{"id":20,"name":21,"nickname":22,"slug":23},149,"Cenk Demircioğlu","CodeVizyoner","cenk-demircioglu","/media/blog/29ce6a8123282e73e86e2636a639731a.jpg","/media/blog/29ce6a8123282e73e86e2636a639731a_thumb.jpg","/media/blog/29ce6a8123282e73e86e2636a639731a.webp","/media/blog/29ce6a8123282e73e86e2636a639731a_thumb.webp",null,{"minutes":30,"wordCount":31,"imageCount":32,"formatted":33},8,1487,0,"8 dk okuma süresi","/blog/yazilim-egitimleri/8-haftalik-urun-odakli-yazilim-gelistirme-egitim-plani-ve-proje-ornekleri",[],["Reactive",37],{"title":7,"subTitle":17,"image":24},["Reactive",39],{"title":10,"meta":40,"link":75},[41,43,45,48,51,54,57,60,63,66,69,71,73],{"hid":42,"name":42,"content":11},"description",{"hid":44,"name":44,"content":12},"keywords",{"hid":46,"name":46,"content":47},"author","Yazılım Rehberi",{"hid":49,"name":49,"content":50},"robots","index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1",{"hid":52,"property":52,"content":53},"og:type","website",{"hid":55,"property":55,"content":56},"og:title","Yazılım Rehberi: Blog ve Sosyal Medya İçin Yeni Yazılımlar",{"hid":58,"property":58,"content":59},"og:description","Blog yazarları ve sosyal medya içerik üreticileri için yeni yazılımlar, kullanım önerileri ve pratik rehberler sunan güncel bilgi blogu.",{"hid":61,"property":61,"content":62},"og:image","https://yeniyazilimlar.com/media/blog/29ce6a8123282e73e86e2636a639731a.jpg",{"hid":64,"property":64,"content":65},"og:url","https://yeniyazilimlar.com/blog/yazilim-egitimleri/8-haftalik-urun-odakli-yazilim-gelistirme-egitim-plani-ve-proje-ornekleri",{"hid":67,"name":67,"content":68},"twitter:card","summary_large_image",{"hid":70,"name":70,"content":56},"twitter:title",{"hid":72,"name":72,"content":59},"twitter:description",{"hid":74,"name":74,"content":62},"twitter:image",[76,78],{"rel":77,"href":65},"canonical",{"rel":79,"href":80},"amphtml","https://amp.yeniyazilimlar.com/blog/yazilim-egitimleri/8-haftalik-urun-odakli-yazilim-gelistirme-egitim-plani-ve-proje-ornekleri",["Reactive",82],{"@context":83,"@graph":84},"https://schema.org",[85,98],{"@type":86,"headline":10,"image":62,"author":87,"publisher":90,"datePublished":14,"dateModified":14,"mainEntityOfPage":96,"description":11},"BlogPosting",{"@type":88,"name":21,"url":89},"Person","https://yeniyazilimlar.com/yazarlar/cenk-demircioglu",{"@type":91,"name":47,"logo":92},"Organization",{"@type":93,"url":94,"width":95,"height":95},"ImageObject","https://yeniyazilimlar.com/img/icons/favicon.png",32,{"@type":97,"@id":65},"WebPage",{"@type":99,"itemListElement":100},"BreadcrumbList",[101,106,110,113],{"@type":102,"position":103,"name":104,"item":105},"ListItem",1,"Ana Sayfa","https://yeniyazilimlar.com",{"@type":102,"position":107,"name":108,"item":109},2,"Blog","https://yeniyazilimlar.com/blog",{"@type":102,"position":111,"name":17,"item":112},3,"https://yeniyazilimlar.com/blog/yazilim-egitimleri",{"@type":102,"position":114,"name":7,"item":65},4]