Çevik Yaklaşımlar ‘Highest business value in shortest time...’

Standish Group Chaos Report , User involvement 1. Executive mngment support 1. User involvement1. 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 staff3. Smaller project milestones 3. Clear business objectives 4. Propor planning4. Competent staff4. Smaller project milestones 4. Hard-working, focused staff 4. Emotional maturity 5. Realistic expectations 5. Ownership5. Clear vision and objectives 5. Optimizing scope 6. Smaller project milestones 6. Agile process 7. Competent staff7. Project management 8. Ownership8. Skilled resources 9. Clear vision and objectives 9. Execution 10. Hard-working, focused staff 10. Tools & Infrastructure

Time to Market -Yazılım projelerinde, t 0 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 t 0 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.

Geleneksel Yöntemler Bazen Neden Uygun Olmuyor? - Geleneksel yöntemler (ör: Şelale yöntemi) kullanılan projelere başlarken tüm isterler öngörülmeye çalışılır -> Analiz ve tasarım sürecinde çok fazla vakit harcanır. - Yazılım geliştirme süreci boyunca müşteri ile az iletişim olması nedeniyle, sonuçta ortaya çıkan ürün müşteriyi tatmin etmeyebilir. - Proje sürerken bazı de ğ işiklikler yapılması gereklili ğ i, projenin ilerleyen safhalarında ortaya çıkabilir.

- 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 yaklaşım manifestosu Süreçler ve araçlar Kapsamlı dokümantasyon Sözleşme pazarlıkları Bir plana ba ğ lı kalmak Bireyler ve etkileşimler Çalışan yazılım Müşteri ile işbirli ğ i De ğ işime karşılık verme yerine

Standish Group Chaos Report, 2012

8 th Annual State of Agile

SCRUM

Scrum Süreci -Müşterinin temsilcisi sayılır -Proje vizyonuna sahiptir, gereksinimleri oluşturur -Sürüm tarihleri ve içeriklerini belirler -Ürünün verimlili ğ inden sorumludur - İ sterlerin tam olarak yapılıp yapılmadı ğ ına PO karar verir.

Scrum Süreci -PO’nun oluşturdu ğ u gereksinim listesi -PO bu gereksinimleri öncelik sırasına göre sıralar -Öncelik sırası isterlerin pazar de ğ erine (market value) göre yapılır -Bu dokümanın sahibi PO ve yazılım geliştirme süresince bu listeye eklemeler çıkarmalar yapma hakkına sahiptir

Scrum Süreci -Sprint’lerin uzunlu ğ un ve çalışacak ekip belirlenir -Gereksinimler, takım üyeleri tarafından ufak işlere (task) bölünür -Ekip elemanları proje içinde çapraz görevlerde de bulunabilirler

Scrum Süreci -Scrum’daki en küçük geliştirme birimi -Belirli bir süreyle sınırlıdır (1-4 hafta) -Her bir sprint arası genelde 2 hafta olarak belirlenir -Uzunlu ğ u, projenin başında belirlenir -Sprint uzunlu ğ u proje sonuna kadar de ğ işmez

Scrum Süreci -Gereksinimler belirlendikten sonra, bu gereksinimleri alıp her iterasyonda (sprint) çalışır kod haline getirecek bir takıma ihtiyaç var -Ekip 5-9 kişi -Bu kişiler full time projede çalışırlar -Self-organizing şekilde -Ekip elemanları, her sprintte de ğ işebilir. -Her sprint sonunda hazırlanan dokümanın sahibi PO de ğ il, bu ekiptir

Scrum Süreci -Her gün, günlük Scrum toplantıları yapılır -Sabahları işe başlamadan önce, çay-kahve eşli ğ inde 5-15 dakika sürer ve ayakta yapılır -Tüm ekip elemanları toplantıya hazırlıklı gelir -Toplantı başlangıç saati bellidir, eksik kişi olsa bile toplantı başlar -Hergün aynı yerde olur -Herkes bir gün önce ne yaptı ğ ını, bugün ne yapmayı planladı ğ ını ve karşılaştı ğ ı zorlukları söyler. -Toplantı sorun çözme amaçlı de ğ ildir

Scrum Süreci -Tüm bu süreci izleyen, PO ile çalışanlar arasında bir aracı şeklinde çalışan kişi -SM ekip lideri de ğ ildir, sadece, Scrum’un bu kendine özgü gerekliliklerini yaptırtmaya zorlar ve karşılaşılan zorlukları raporlayıp, PO’a haber verir (ör: Donanım ihtiyac, Photoshop gereklili ğ i, bir yazılımcı gereksinimi) -Ekibin verimlili ğ inden sorumludur

Scrum Süreci -Sprint dokümanındaki gereksinimlerin tahmini geliştirme süresi, saat bazında takım üyelerince belirlenir -Sprint boyunca bu tahminler sürekli olarak güncellenerek kalan zaman grafikleri oluşturulur -Bu sayede, sprint süresince, PO ve SM sprintin genel gidişi hakkında bilgi sahibi olur. -Aynı zamanda takım elemanları da kalan iş ve iş süreleri ve harcadıkları zamanı takip edebilirler.

Scrum Süreci -Her sprintin bitiminde ortaya konulan ürün hakkında geri besleme alabilmek için, herkese açık yapılan toplantı -Amaç: Yazılımın PO’ın gereksinimlerine uygun olarak geliştirildi ğ inden emin olmak -E ğ er isterlerden bir ya da birkaçı tam anlamıyla bitmemiş ise, tüm sprint başarısız geçmiş demektir

Scrum Süreci - SM tarafından yönetilir dakikadır -- «Start doing», «continue doing», «stop doing» edilecek şeyler üzerinde tartışılır

Scrum’da Karşılaşılabilecek Sorunlar - Takımların bir kısmının tavsiye edilen en fazla 7 kişiden oluşma kuralına uymaması, - Scrum ustası (master) rolü ek sorumluluk olarak görülmeye başlanıp, istenmeyen bir görev haline gelebilir. - Gere ğ inden uzun süren Scrum toplantıları amaca hizmet etmekten uzaklaşıp durum de ğ erlendirme şeklinde ilerlemeye başlayabilir. - Scrum takımları içerisinde yetkinlik dengesi bozulup, sprint içerisindeki iş da ğ ılımı homojen olmaktan uzaklaşabilir. - Anlık/acil müşteri talepleri nedeniyle, sprint iş listesi bozulmaya başlayabilir. - Aynı takım için sprint süreleri sıkça de ğ iştirilirse, takvimden şaşılabilir. - Sprint planlama sırasında kullanılan öykü puanı (“story point”), işin zorluk derecesi yerine adam.gün maliyetine dayandırılabilir. - Sprint indirgeme grafi ğ i (“burndown/up chart”) ço ğ unlukla gerçek durumu yansıtmazsa takımların hızı yanlış ölçülebilir - Klasik yöntemlere kıyasla daha az belgeleme yapıldı ğ ı için, müşteri test faaliyetlerinin yetersiz ve ürün kalitesinin düşük oldu ğ unu düşünebilir.

Waterfall vs. Scrum

9 th Annual State of Agile

Scrum Uygulayanlar