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

1. Web Girişimlerinde
Yazılım Süreci ve Güvenlik
Ersan Bilik

2. Hemen başlayalım...
• Odaklandığımız alan...
• Mevcut problemler...
• En iyi pratikler...
• Öneriler...
• Son söz...
• Soru & Cevap

3. Girişim masasının 4 bacağı

4. Web Girişimlerinde ürün: Yazılım
• Girişimin neresinde ?
• Nasıl Geliştirilmeli ?
• Girişimcilere uygun
yazılım süreçleri ?

5. 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.

6. 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 )

7. 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

8. Peki ne yapabiliriz ?
• Disiplin.
• Eğer oyunun kurallarını
koyarsak ve tüm
paydaşlar mızıkçılık
yapmazsa sorun çıkmaz.

9. Paydaşlar kimler ?

10. Ü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

11. 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 

12. Cevap: Çevik Yöntemler
• Scrum
• XP
• FDD
• Lean
• Agile UP
• Getting Real ( 37 Signals )

13. 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

14. Scrum

15. Scrum’da gereksinim yönetimi
• Kullanıcı hikayeleri

16. Gereksinimleri bir havuzda toplayın
• Product Backlog
• Paydaşlardan, kullanıcı hikayelerini
ölçeklendirmelerini isteyin.
– Bizim için acil olan işlevsellikler nedir ?

17. 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.

18. 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.

19. Burndown chart...

20. 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.

21. 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 ?

22. Yazılım Mühendisliğine dair pratikler ?
• Scrum’ın bir cevabı yok...
• Ama XP’nin var.. 
Resim referans: Akın Demir (flickr)

23. Konfigürasyon Yönetimi
• CVS, SVN, Gitt...
• Merkezi – Dağıtık Ambar
• Ağır siklet : TFS

24. 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...

25. Continious Integration

26. Pair Programming

27. Collective Code Ownership

28. 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 };

29. Ö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.. )

30. 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..

31. Son söz
• Bitti.

32. Sorular ? 