Çevİk yaklaŞimlar & scrum

Post on 02-Jan-2016

92 Views

Category:

Documents

0 Downloads

Preview:

Click to see full reader

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

TRANSCRIPT

ÇEVİK YAKLAŞIMLAR & SCRUM

Standish Group Chaos Report, 2012

Standish Group Chaos Report, 2012

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

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

- 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

Ç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

Programlama Dilleri (2012)

Çevik yaklaşımlar (2012)

top related