ytu web gunleri
DESCRIPTION
YTÜ Web günleri için hazırladığım sunumTRANSCRIPT
Web GirişimlerindeYazı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
FAIL
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 ?