28
ÇEVİK YAKLAŞIMLAR & SCRUM

ÇEVİK YAKLAŞIMLAR & SCRUM

Embed Size (px)

DESCRIPTION

ÇEVİK YAKLAŞIMLAR & SCRUM. Standish Group Chaos Report, 2012. Standish Group Chaos Report, 2012. Standish Group Chaos Report. PMI Certification. Müşteri Ne Bekliyor?. Para Maksimum getiri (Max ROI) Pazara erken çıkmak (Minimum time to market) Kalite - PowerPoint PPT Presentation

Citation preview

Page 1: ÇEVİK YAKLAŞIMLAR & SCRUM

ÇEVİK YAKLAŞIMLAR & SCRUM

Page 2: ÇEVİK YAKLAŞIMLAR & SCRUM

Standish Group Chaos Report, 2012

Page 3: ÇEVİK YAKLAŞIMLAR & SCRUM

Standish Group Chaos Report, 2012

Page 4: ÇEVİK YAKLAŞIMLAR & SCRUM

Standish Group Chaos Report1994 1999 2001 2004 2010, 2012

1. User involvement

1. User involvement 1. Executive mngment support

1. User involvement

1. Executive support

2. Executive mngment support

2. Executive mngement support

2. User involvement

2. Executive mnagement support

2. User involvement

3. Clear statement of requirements

3. Smaller project milestones

3. Competent staff 3. Smaller project milestones

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

Page 5: ÇEVİK YAKLAŞIMLAR & SCRUM

PMI Certification

Page 6: ÇEVİK YAKLAŞIMLAR & SCRUM

Müşteri Ne Bekliyor?

- Para

- Maksimum getiri (Max ROI)

- Pazara erken çıkmak (Minimum time to market)

- Kalite

- Değişen ihtiyaçlara cevap verebilme

Page 7: ÇEVİK YAKLAŞIMLAR & SCRUM

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.

Page 8: ÇEVİK YAKLAŞIMLAR & SCRUM

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.

Page 9: ÇEVİK YAKLAŞIMLAR & SCRUM
Page 10: ÇEVİK YAKLAŞIMLAR & SCRUM

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

Page 11: ÇEVİK YAKLAŞIMLAR & SCRUM

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

Page 12: ÇEVİK YAKLAŞIMLAR & SCRUM

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

Page 13: ÇEVİK YAKLAŞIMLAR & SCRUM

Değişim ve Kalitenin Maliyeti

Boehm’s Cost of Change Curve

Page 14: ÇEVİK YAKLAŞIMLAR & SCRUM

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

Peki ne yapalım?

Çevik (agile) yaklaşımlar

Page 15: ÇEVİK YAKLAŞIMLAR & SCRUM

Çevik yaklaşım manifestosu

Page 16: ÇEVİK YAKLAŞIMLAR & SCRUM

Çevik yaklaşım manifestosu

Page 17: ÇEVİK YAKLAŞIMLAR & SCRUM

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

Page 18: ÇEVİK YAKLAŞIMLAR & SCRUM
Page 19: ÇEVİK YAKLAŞIMLAR & SCRUM
Page 20: ÇEVİK YAKLAŞIMLAR & SCRUM

Standish Group Chaos Report, 2012

Page 21: ÇEVİK YAKLAŞIMLAR & SCRUM

ÇevikYöntemler (2010)

Page 22: ÇEVİK YAKLAŞIMLAR & SCRUM

Scrum Süreci

Page 23: ÇEVİK YAKLAŞIMLAR & SCRUM

Scrum Süreci

Page 24: ÇEVİK YAKLAŞIMLAR & SCRUM

Waterfall vs. Scrum

Page 25: ÇEVİK YAKLAŞIMLAR & SCRUM

Scrum Uygulayanlar

Page 26: ÇEVİK YAKLAŞIMLAR & SCRUM

Programlama Dilleri (2012)

Page 27: ÇEVİK YAKLAŞIMLAR & SCRUM

Çevik yaklaşımlar (2012)

Page 28: ÇEVİK YAKLAŞIMLAR & SCRUM