ÇEVİK YAKLAŞIMLAR & SCRUM

Standish Group Chaos Report, 2012

Standish Group Chaos Report, 2012

Standish Group Chaos Report 1994 1999 2001 2004 2010, 2012 1. User involvement 1. Executive mngment support 1. Executive support 2. Executive mngment support 2. Executive mngement support 2. User involvement 2. Executive mnagement support 3. Clear statement of requirements 3. Smaller project milestones 3. Competent staff 3. Clear business objectives 4. Propor planning 4. Competent staff 4. Smaller project milestones 4. Hard-working, focused staff 4. Emotional maturity 5. Realistic expectations 5. Ownership 5. Clear vision and objectives 5. Optimizing scope 6. Smaller project milestones 6. Agile process 7. Competent staff 7. Project management 8. Ownership 8. Skilled resources 9. Clear vision and objectives 9. Execution 10. Hard-working, focused staff 10. Tools & Infrastructure

PMI Certification

Müşteri Ne Bekliyor? Para Maksimum getiri (Max ROI) Pazara erken çıkmak (Minimum time to market) Kalite Değişen ihtiyaçlara cevap verebilme

Time to Market Yazılım projelerinde, t0 anında bir vizyon belirlenir -> Projenin sonuda elde edilmek istenen hedef bir değer. Waterfall modelinde: Analiz, tasarım, kodlama ve testten sonra (belirli bir süre sonra) proje müşteriye teslim ediliyor. Araştırma sonuçlarına göre: Eğer proje başlangıcı ve bitişi arası 6 ay veya daha uzun bir süre ise ve bu sürece müşteriler ve değişim dahil edilmiyorsa, büyük ihtimalle t0 anında hedeflediğiniz değerden daha düşük bir değer elde ederek projeyi bitirirsiniz. Kısaca: Müşteriler ve değişim dahil edilmedikçe, proje süresi uzadıkça -> İstenilen hedeflerin yakalanma ihtimali düşüyor! Araştırma sonuçlarına göre: Problem görülüp, sürece müşteriler ve değişim katılsa bile, hiçbir zaman ara kapatılamıyor -> Proje başarısızlığa doğru gidiyor.

Değişim olmasa? Değişim olmayan proje : Yok denecek kadar az! Farzedelim değişim yok. Müşteri: “Tamam, çok güzel, tam istediğim gibi olmuş. Ama acaba şöyle olsaydı daha mı iyi olurdu?” -> Deneyim Ayakkabı örneği İnsan doğası gereği, elle tutulur referans noktaları ile çözüme gitme konusunda daha yetkin bir varlık.

Neden çoğu fonksiyonu kullanılmayan yazılımlar üretiliyor? Fazla mal göz çıkarmaz yaklaşımı. Peki neden net gereksinimler belirlenmeli? Hem zaman, hem de bütçe açısından kısıtlar var -> Tahmin yaparken kontrol sahibi olunmalı.

Gereksinimler net olarak belirlenebilir mi? Maalesef, çoğu zaman hayır. Alternatif ne olabilir? Müşteri, gereksinimlerini ROI’ı ençoklayacak şekilde, iş değerine göre önceliklendirsin. Öncelik sırasından en üstteki birkaç gereksinimi alıp, bunları gerçekleştiren, çalışır bir kod, bir ay veya daha kısa bir sürede yazılsın. Müşteriye sunulsun. Müşteri üzerinde gerekli değişiklikleri yapsın, gereksinim listesini revize etsin. O listeden birkaç gereksinim seçip, yeni bir çalışır kod parçası yazıp, müşteriye sunalım...... -> Hedeflenen değere erişene dek. -> iterative incrementation

Pareto prensibi (80-20 kuralı) -> Yazılım projelerindeki fonksiyonalitelerin %20’si, müşterilerin ihtiyaçlarının %80’ini karşılar. Esneklik: Müşteriyle kısa aralıklarla görüşülüp, ondan fikir alındığı için, değişiklikler kucaklanmış oluyor.

Değişim ve Kalitenin Maliyeti Boehm’s Cost of Change Curve

Çevik (agile) yaklaşımlar Peki ne yapalım? Değişim kaçınılmaz: Dünya çapındaki yazılım geliştirme süreçlerinin %35’inde süreç içinde değişim oluyor. Türkiye’de bu oran daha yüksek olabilir... Iterative incrementation. Test, tüm sürece yayılmış olur. Hata iterasyon ile birlikte ortaya çıkar. Çevik (agile) yaklaşımlar

Çevik yaklaşım manifestosu

Çevik yaklaşım manifestosu

Çeviklik (agility), değişime verimli bir şekilde uyum sağlayabilme kapasite ve yetkinliğidir.

Standish Group Chaos Report, 2012

ÇevikYöntemler (2010)

Scrum Süreci

Scrum Süreci

Waterfall vs. Scrum

Scrum Uygulayanlar İlginç bir örnek: Ikea. Çünkü bir yazılım şirketi değil. Scrum her ne kadar yazılım dünyasından çıkmış olsa da, kompleks bir problem için tanımlanmış bir süreç. Ikea da yönetimsel süreçlerinde Scrum’ı kullanıyor. Yahoo da ilginç: 2005’ten beri Scrum uyguluyor. 250’nin üstünde Scrum uygulayan takımı var. Ve bu takımlardan 50 tanesi, gerçek anlamıyla Scrum’ıuygulayan ve maksimum üretkenlik kazanan takımlar. Üretkenlikleri %300-400 artmış (hiper productive takımlar). Geri kalan 200 takım da, tam olarak Scrum olmayan, iyileştirilmesi gereken, “Scrum but” olarak tanımladığımız yaklaşımları kullanıyorlar. Üretkenliklerini yaklaşık ortalama %36 oranında arttırabilmiş takımlar. Sadece bu 200 takımın %36’lık verim artışıyla, Yahoo senede 200 milyon dolar kazanç artışı yapmış. Bunlar dışında: ....

Programlama Dilleri (2012)

Çevik yaklaşımlar (2012)