• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
YTU Web Gunleri
 

YTU Web Gunleri

on

  • 1,610 views

YTÜ Web günleri için hazırladığım sunum

YTÜ Web günleri için hazırladığım sunum

Statistics

Views

Total Views
1,610
Views on SlideShare
1,587
Embed Views
23

Actions

Likes
1
Downloads
23
Comments
0

5 Embeds 23

http://www.kodblog.com 7
http://www.linkedin.com 7
http://kodblog.com 4
https://www.linkedin.com 4
http://www.slideshare.net 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

CC Attribution License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    YTU Web Gunleri YTU Web Gunleri Presentation Transcript

    • Web Girişimlerinde Yazılım Süreci ve Güvenlik Ersan Bilik
    • Hemen başlayalım... • Odaklandığımız alan... • Mevcut problemler... • En iyi pratikler... • Öneriler... • Son söz... • Soru & Cevap
    • Girişim masasının 4 bacağı
    • Web Girişimlerinde ürün: Yazılım • Girişimin neresinde ? • Nasıl Geliştirilmeli ? • Girişimcilere uygun yazılım süreçleri ?
    • Yazılım: Girişimin neresinde ? • Ürün ya da fikir yoksa, neyi pazarlıyoruz? • Finans ?  • İş planı <bağımlıdır> ürün. • Yazılım, kraldır. • Kötü haber: İyi yazılım zanaatkarları durumun farkındadır. • İyi haber: Kötü yazılım geliştiren binlerce “yazılımcı” vardır.
    • Yazılım: Nasıl geliştirmeli ? • Mevcut durum nedir ? – Rock Star Yazılımcı. (10x) – 2 kişiyiz. (2 * 5x) – 3.... ( 3 * 3x ) – 5 ? ( 5 * 1x ) – x = verimlilik • Malesef sihirli değnek yok. – (bkz: no silver bullet by Dr.Fred Brooks )
    • Ne demek yok ? Bunun adı kaos ! • Yazılım “mühendisliği” diye henüz bişey yok. (ama zamanla olgunlaşıyor...) • Mevcut durumda yazılım zanaatkarları var. • Yazılım hala onu geliştiren insanların yetenekleri doğrultusunda sizi başarıya ya da başarısızlığa götürür. • Kaynaklar: – Chaos Report (Standish Group) – Google Ara: Bill Clinton quote about software – Google Ara: Alistair Cockburn phd thesis
    • Peki ne yapabiliriz ? • Disiplin. • Eğer oyunun kurallarını koyarsak ve tüm paydaşlar mızıkçılık yapmazsa sorun çıkmaz.
    • Paydaşlar kimler ?
    • Ürün geliştirme yaşam döngüsü • Paydaşların üründen beklentileri nedir ? – Gereksinim Yönetimi • Gereksinimler ürüne nasıl dönüşecek ? – Analiz, Tasarım, Kodlama • Takım halinde nasıl geliştiririz ? – Proje Yönetimi • Nasıl sürümleri çıkarabilirim ? – Sürüm yönetimi
    • Web girişimlerinde durum • İstekler an be an değişiyor... • Yazılım geliştiricilerin işi zor... – ( değişiklik isteği çok fazla ) • Tüm start-up şirketlerin ortamı : “çevik” • Hantallığa tahammül YOK ! • Ve herşeyi yapması beklenen bir tane rock star yazılımcı var 
    • Cevap: Çevik Yöntemler • Scrum • XP • FDD • Lean • Agile UP • Getting Real ( 37 Signals )
    • Scrum • Bir proje yönetimi metodolojisi – Sadece yazılım projelerin mahsus bir metodoloji değil ama çıkışı yazılım projeleri ile birliktedir. – Yazılım mühendisliğine özel pratiklerden söz etmez
    • Scrum
    • Scrum’da gereksinim yönetimi • Kullanıcı hikayeleri
    • Gereksinimleri bir havuzda toplayın • Product Backlog • Paydaşlardan, kullanıcı hikayelerini ölçeklendirmelerini isteyin. – Bizim için acil olan işlevsellikler nedir ?
    • Tahmin edin • Yazılım ekibi olarak toplanın. • Her işlevsellik için ne kadar efor harcayacağınızı tahmin etmeye çalışın • Planning poker.
    • Sprint’i planlayın • Sprint Backlog – Product backlogtan 2 ila 4 haftalık (fixed) süre için müşterinin ölçeklendirdiği kullanıcı hikayelerini seçin ve sprint backloga atın. – Sprint süresini belirleyin ( fixed süre , 2-4 hafta) – Bu süre zarfında, seçtiğiniz kullanıcı hikayelerini bitirmeye çalışın, sprint sonunda toplam kaç puanlık kullanıcı hikayesi bitirdiğinizi ölçün.
    • Burndown chart...
    • Kurallar • Sprint süreci içinde, yeni bir istek gelirse, o istek çok kritik olmadıkça, sprint backloga değil, product backloga eklenir ve bir sonraki sprintte gerçeklenir. • Hergün 15 dakika toplantı yapılır ve geliştiricilere şu sorular sorulur – Dün ne yaptın ? – Bugün ne yapıyorsun ? – Yarın ne yapacaksın ? • Her sprint sonunda mevcut ürüne bir değer eklenmesi gerekmektedir.
    • Kendi kendinizi denetleyin • Reprospective toplantıları... • Her sprint sonunda ekip olarak bir araya gelin ve şu soruları cevaplayın; – Neyi iyi yaptık ? – Neyi daha iyi yapabilirdik ? – Neyi başaramadık ? – Bizi engelleyen şey nedir ?
    • Yazılım Mühendisliğine dair pratikler ? • Scrum’ın bir cevabı yok... • Ama XP’nin var..  Resim referans: Akın Demir (flickr)
    • Konfigürasyon Yönetimi • CVS, SVN, Gitt... • Merkezi – Dağıtık Ambar • Ağır siklet : TFS
    • Test Driven Development • Önce kodu değil, testi yazın. • Neden ? – Test aslında bir gereksinime tekabül ediyor.. – Gereksinimin testini önce yazarsak, o testi geçecek kadar kod yazmış oluruz. – KISS , YAGNI prenspileri.. – Less is More – Refactoring, etc...
    • Continious Integration
    • Pair Programming
    • Collective Code Ownership
    • En iyi pratikler • Temel bir mimari oluşturmak elzem... – Değişikliklerin maliyeti bazen yüksek olabilir • Modüler geliştirme faydalı – Daha sonra değişiklik istendiğinde, gerçeklenmesi kolaylaşır • while(true) – {Write Test,Code,Review,Refactor,Commit };
    • Öneriler & Tavsiyeler • Re-invent wheel ikilemi... • Kullanılacak araçlar... • Paydaşlar birbirinin işine burnunu sokmasın – Yazılımcı vs Tasarımcı – Yazılımcı vs Yazılımcı – Yazılımcı vs Herkes  • Araba herkese çarpıyor. ( Riskler.. )
    • Güvenlik konusuna gelince • Kaynak kod güvenliği.. • Yazılım güvenliği.. • Donanım güvenliği.. • İletişim güvenliği... • Veri güvenliği... • Etc..
    • Son söz • Bitti.
    • Sorular ? 