SlideShare a Scribd company logo
Çevik(Agile) Yaklaşım ve Pratikleri
Osman DÖNER, PMP, PMI-ACP
Proje Yöneticisi ve Bölüm Sorumlusu
Ajanda
Geleneksel ve Çevik Yaklaşım
XP ve Geliştirme Pratikleri
Çevik Manifesto ve Prensipleri
Scrum Çerçevesi
Quiz ve Tartışmalar
Geleneksel vs. Çevik Yaklaşım
Geleneksel Yaklaşım – Şelale Yöntemi
Gereksinim
Analizi
Tasarım
Kodlama
Test
Kurulum
Bakım
Geleneksel Yaklaşımın Dezavantajları
 Ürün teslimatı çok gecikiyor – proje / iş paketi sonu,
 Sistemin test edilmesi ve müşteri geri bildirimleri proje / iş paketi
sonuna kalıyor,
 Büyük / kompleks işlerin tek fazda analizi mümkün değil,
Gereksinimler başlangıçta çok net olmuyor.
 Değişiklik yapma maliyetini yükseltiyor.
Şelale Yöntemi Ne Zaman Uygun?
 Kısa bir projeyse (3-6 ay gibi),
 Gereksinimler çok açıksa ve değişim
beklenmiyorsa, belirsizlik yoksa ve
 Kullanılacak teknolojik yaklaşım netse,
 Endüstriyel (fiziksel-mekanik) bir ürün
geliştiriliyorsa.
Endüstriyel Ürün vs. Yazılım Ürünü
 Somut,
 Değişiklik maliyetli / zordur,
 Parçalı teslimi mümkün değil,
 Komut / kontrol mekanizması,
 Katı standartlara tabi,
 Üretim miktarına odaklanır,
 Çalışanlar maliyet unsuru.
 Soyut,
 Geç dönemlerde dahi değişime açık,
 Parçalı olarak teslim edilebilir,
 Ortak karar alma mekanizmaları,
 Standartlar esnektir, uyarlanabilir,
 Kaliteye odaklanır,
 Çalışanlar projenin en değerli varlıkları.
İhtiyaç Nedir?
 Lineer olmayan, tekrarlayan(iterative) bir süreç,
 Sık aralıklarla teslimatlar (2-4 haftalık döngüler),
 Belli fonksiyonları içeren artırımlar(increment)
 Geri bildirimlerin kısa süreli döngülerle alınması,
 Ürün ihtiyacı karşılıyor mu?
 Doğru yolda ilerliyor muyuz?
 Geri bildirimlere göre ürünü güncelle.
Plan
Do
Check
Act
Çevik Yaşam Döngüsü Her Zaman Uygun Mu?
Basit
Kaotik
GereksinimlerinBelirsizliği
Teknolojinin Belirsizliği
Çevik Manifesto ve Prensipleri
Çevik Manifesto - Değerler
Process and toolsIndividuals and interactions over
Following a planResponding to change over
Comprehensive
documentation
Working software over
Contract negotiationCustomer collaboration over
http://www.agilemanifesto.org
Değer 1:
COCOMO II Faktörlerinin Ağırlıkları
33
10
4
3
1
1
0 5 10 15 20 25 30 35
People
Product
Computer Platform
Tools & Processes
Design Reuse
Schedule Constraints
Değer 2:
Değer 3:
Geleneksel vs. Agile Kontratlar
Değer 4:
«The map is not the territory.»
Çevik Prensipler
 https://agilemanifesto.org/principles.html
 Çevik Prensipler(12), çevik pratiklerin doğru uygulanması için anlaşılması
gereken temel prensiplerdir.
 Yazılımın Düzenli Aralıklarla Teslimatı,
 Takım İletişimi,
 İdeal Yazılım Tasarımı
Yazılımın Düzenli Aralıklarla Teslimatı - 1
https://agilemanifesto.org
Çalışan yazılım ilerlemenin birincil ölçüsüdür.
-- Author
 Kodlamanın tamamlanması ilerleme için bir tek başına ölçü değildir.
 Tüm ekiplerin anlaştığı Definition of Done kriterleri belirlenmelidir.
 Kodlamanın tamamlanması, kod gözden geçirmenin yapılması, birim ve sistem
testlerinin geçmesi, kabul kriterlerinin karşılanması vs.
Yazılımın Düzenli Aralıklarla Teslimatı - 2
https://agilemanifesto.org
En önemli önceliğimiz değerli yazılımın erken ve devamlı
teslimini sağlayarak müşterileri memnun etmektir.
 Değerli yazılım: İş faydası oluşturan yazılımdır. Önceliklendirme ile her
zaman maksimum iş faydası amaçlanır.
 Erken teslimat: Erken geri bildirim ve erken aksiyon almayı sağlar. Güven
ortamını oluşturur.
Yazılımın Düzenli Aralıklarla Teslimatı - 3
https://agilemanifesto.org
Çalışan yazılım, tercihen kısa zaman aralıkları belirlenerek
birkaç haftada ya da birkaç ayda bir düzenli olarak
müşteriye sunulmalıdır.
 Çevik süreçler Sürekli İyileştirme’ye odaklanır.
 Sık kontrol noktaları, «fail fast, learn fast»
 Ürün demosu ve gözden geçirme,
 Hangi güncellemeler / iyileştirmeler gerekli?
 Ekipler kısa planlarla daha verimli çalışır.
Yazılımın Düzenli Aralıklarla Teslimatı - 4
https://agilemanifesto.org
Çevik süreçler sürdürülebilir geliştirmeyi teşvik etmektedir.
Sponsorlar, yazılımcılar ve kullanıcılar sabit tempoyu sürekli
devam ettirebilmelidir.
 Sürdürülebilir tempoda çalışmak Sürekli fazla mesai
 Yaratıcılık ve motivasyona dayalı ortamlarda daha da önemli.
 Kurumsal: Ürün kalitesi, çalışan memnuniyeti, daha az işten ayrılma,
 Kişisel: İş ve özel yaşam dengesinin kurulması.
Takım İletişimi - 1
https://agilemanifesto.org
İş süreçlerinin sahipleri ve yazılımcılar proje boyunca günlük
olarak birlikte çalışmalıdırlar.
 «customer collaboration over contract negotiation»
 Ekip çözüme yönelik olarak işin niteliğini ve ihtiyaçları,
 Müşteri de trade-offları daha net anlayabilir.
 Örn: Sprint Review’lere Müşteri de dahil edilebilir.
Takım İletişimi - 2
https://agilemanifesto.org
Bir yazılım takımında bilgi alışverişinin en verimli ve etkin
yöntemi yüz yüze iletişimdir.
-- Author
 Waterfall: Dokümantasyon yoluyla formal iletişime ağırlık verir. (Planlar,
SRS, SDD vs.). Teslim Et – Onay Al.
 Agile: Mümkün oldukça yüz yüze iletişime önem verir.
 Duruma göre (ekiplerin lokasyonu, toplu bilgilendirme vs.) farklı yöntemler de
tercih edilir.
Takım İletişimi - 3
https://agilemanifesto.org
En iyi mimariler, gereksinimler ve tasarımlar kendi kendini
örgütleyen takımlardan ortaya çıkar.
-- Author
 Self-organized: Teknik kararlar, 2-4 haftalık planlar.
 Önkoşulu: Takımın birlikte çalışma kültürü olan ve yetkin bireylerden
oluşması.
Takım İletişimi - 4
https://agilemanifesto.org
Projelerin temelinde motive olmuş bireyler yer almalıdır.
Onlara ihtiyaçları olan ortam ve destek sağlanmalı, işi
başaracakları konusunda güven duyulmalıdır.
 Komut-Kontrol taktikleri ve mikro-yönetim yerine destekleyici liderlik.
 Ekibe genel direktifler verilerek insiyatif almaları beklenir.
 Önkoşul: Ekip üyelerinin yetkin bireylerden oluşması gerekiyor.
 Yönetim vs. Liderlik?
Google’ın Takım Verimliliği İçin Prensipleri
Takım İletişimi - 5
https://agilemanifesto.org
Takım, düzenli aralıklarla nasıl daha etkili ve verimli
olabileceğinin üzerinde düşünür ve davranışlarını buna göre
ayarlar ve düzenler.
 Çevik süreçler Sürekli İyileştirme’ye odaklanır.
 Üründen ayrı Sürecin de iyileştirilmesi
 Scrum Retrospective: Nasıl daha iyi iş yaparız?
 Çıktısı: Süreç İyileştirme Aksiyonları
İdeal Yazılım Tasarımı - 1
https://agilemanifesto.org
Teknik mükemmeliyet ve iyi tasarım konusuna sürekli
özen göstermek çevikliği artırır.
-- Author
 Çevikliği nasıl artırır?
 İyi tasarım ve kod -> «Maintainability»
 Pratikler: Refactoring, Simple Design (barely good enough), Pair
Programming vb.
İdeal Yazılım Tasarımı - 2
https://agilemanifesto.orghttps://agilemanifesto.org
Sadelik - yapılmayan işin maksimize edilmesi sanatı -
temel prensiptir.
-- Author
 Sadeliğin düşmanı, Gold-Plating: Gereksinim ve teknik çözümlerde
ihtiyaçtan fazlasını / daha kompleks olanı gerçekleştirmeye çalışmak.
 «Don’t over-design»,
 «Keep it as simple as possible»: Gereksinimler, teknik çözüm ve süreçler…
İdeal Yazılım Tasarımı - 3
https://agilemanifesto.org
Değişen gereksinimler yazılım sürecinin son aşamalarında
bile kabul edilmelidir. Çevik süreçler değişimi müşterinin
rekabet avantajı için kullanır.
 Waterfall: Değişimin kontrol altına almaya odaklanır. Değişim zordur.
 Agile: Bunun yerine değişime adapte olmayı önerir. Değişim kaçınılmazdır.
 Tüm değişiklik taleplerinin gerçekleştirilmesi anlamına gelmez.
 Değişiklik Yönetimi: Etki Analizi, Fayda/Maliyet Analizi
Çevik vs. Geleneksel Yaklaşım
Çevik Yaklaşım-Özet
 Time-to-market: Rekabet edebilmek için daha hızlı piyasaya sürüm,
 Adapte olabilirlik: Ürünün sık geri bildirimlerle değişen/netleşen ihtiyaçlara,
sürecin de koşullara adapte edilmesi,
 İş faydasına odaklanır, israfı en aza indirmeye çalışır, böylece maliyetleri azaltır,
 Müşteri ve çalışan memnuniyetini artırır.
 Being Agile vs. Doing Agile,
 Çevik Olmak: Düşünce yapısı ve prensiplerini yeterince anlamadan pratikleri ezbere
uygulamak yeterli değil.
 Ya hep ya hiç gibi düşünülmemeli,
 Duruma göre geleneksel ve çevik pratiklerin bir karışımı kullanılabilir.
 Örnek: Sabit maliyet ve kilometretaşlarında bir kontrat yapıp, bu kısıtları etkilemeyen
değişikliklere iteratif bir yaklaşımla adapte olabiliriz.
Çevik Metodolojiler
Scrum Framework
Scrum Framework
Süreç için bir Framework /
Çerçeve sunar.
Adımları dikte eden bir Süreç / Metot
değildir.
Scrum, karmaşık ürün ve sistemlerin geliştirilmesi için
oluşturulmuş bir süreç çerçevesidir. Belirsiz hususlar ve
riskleri kontrol etmek için iteratif, artırımlı bir yaklaşımı
benimser.
-- Ken Scwaber
Scrum – Temel İlkeler
Kontrol
Scrum ekipleri sıklıkla hem sürecin
hem de ürünün gidişatını kontrol
eder.
• Sprint sonlarında ürün(1) ve
süreç(2) gözden geçirilir.
• Hedeften sapmalar,
• İyi-kötü giden hususlar
belirlenir.Adaptasyon
Kontrol sonucundaki bulgulara göre
hangi aksiyonlar alınmalı?
• Ürün adaptasyonu,
• Süreç adaptasyonu.
Şeffaflık
• İşin ilerleme durumu,
• Karşılaşılan sorunlar,
• Çözüm ve iyileştirme önerileri
Projeyi ilgilendiren her bilgi şeffaf
bir ortamda paylaşılır. Sırlar
yoktur.
TEMEL
İLKELER
Scrum – Büyük Resim
Sprintler
 Scrum projelerinde bir dizi Sprint ile ilerlenir.
 Sprint = Mini proje
 2-4 haftalık periyotlar tercih edilir.
 Tipik aktiviteler:
 Tasarım,
 Kodlama,
 Refactor,
 Birim ve Sistem Testleri,
 Kurulum ve Altyapı İşleri,
 Dokümantasyon
 Sprint kapsamı planlandıktan sonra mümkün
olduğunca değiştirilmez.
Scrum Framework
ROLLER TOPLANTILAR YAPILAR
 Sprint Planning
 Sprint Review
 Sprint
Retrospective
 Daily Scrum
 Product Owner
 Scrum Master
 Development
Team
 Product Backlog
 Sprint Backlog
 Increment
 Definition of
Done / Ready
Roller ve Görevleri
ROLLER TOPLANTILAR YAPILAR
 Sprint Planning
 Sprint Review
 Sprint
Retrospective
 Daily Scrum
 Product Owner
 Scrum Master
 Development
Team
 Product Backlog
 Sprint Backlog
 Increment
 Definition of
Done / Ready
Product Owner
 Ürün vizyonunu, içermesi gereken gereksinimleri belirler.
 Vizyon ve gereksinimlerin iç-dış paydaşlar tarafından doğru anlaşılmasını
sağlar.
 Ürünün maksimum iş faydasını sağlamasını garanti altına alır.
 İşleri katma değerine göre önceliklendirir.
 Planlamaya dahil edilmeye yakın ürün gereksinimlerini detaylandırır.
(Backlog Refining)
 Geliştirilen ürünün beklenen özelliklere göre kontrolünü sağlar. (Kabul
veya Ret)
 Product Backlog’un tek sorumlusu ve karar vericisidir. Ürünün
başarısından sorumludur.
Scrum Master
 Proje yöneticisi rolünü temsil eder.
 Scrum sürecinin etkin bir şekilde uygulanması için koçluk yapar.
 Toplantılar ve işleyişleri (facilitator)
 Zaman kısıtları,
 Önceliklendirme, planlama pratikleri vs.
 Ekibin karşılaştığı sorunların aşılması için destek olur. (Destekleyici Liderlik)
 Ekibin dış etkenlerden (müşteriden gelen telefonlar, doğrudan üst
yönetimden gelen talepler vs.) en az ölçüde etkilenmesine çalışır.
 Scrum rolleri arasında birlikte çalışma yöntemleri konusunda destek olur.
Development Team
 3-9 kişilik ekipler.
 Cross-functional (geliştirme, test, yazılım mimarisi, vt yönetimi, dokümanlar vs.),
 Ürünün teslimata hazır duruma gelmesi için gereken tüm işlerden sorumlu.
 Kendi organize olur.
 Büyüklük tahminleri, Sprint planlamaları,
 Tasarım ve diğer teknik kararların verilmesi.
 Sprint Backlog’da user storyleri alt görevlere böler.
 Tasarım,
 Veritabanı görevleri, (tablo ve alanların oluşturulması gibi)
 Kodlama,
 Birim test,
 Sistem testi,
 İlgili dokümantasyon (yardım kılavuzları, tasarım dokümanları vs.).
Çevik Ekiplerdeki Farklılıklar
 Yapacağı işin planlanması, izlenmesi ve raporlanmasında insiyatif alması
beklenir.
 Gereksinimleri daha iyi anlamak için direkt Product Owner veya
müşteriyle doğrudan iletişim kurabilmelidir.
 Kodun işlevinden ayrı olarak toplam kalitesine ve sürekli iyileştirme için
düzenli refactore odaklanır.
 Senin / benim kodum ayrımı yoktur. Gerektiği durumlarda yazılımın
herhangi bir yerinde güncelleme veya refactor için insiyatif alabilir.
Geliştiricilerden ‘sadece kod yazmaktan’ daha fazlası beklenir.
Toplantılar
ROLLER TOPLANTILAR YAPILAR
 Sprint Planning
 Sprint Review
 Sprint
Retrospective
 Daily Scrum
 Product Owner
 Scrum Master
 Development
Team
 Product Backlog
 Sprint Backlog
 Increment
 Definition of
Done / Ready
Sprint Planning
Sprint Planning
•İşlerin ekip tarafından anlaşılırlığının
sağlanması, soruların cevaplanması,
•Öncelikli işlerin büyüklük tahminlerini
revize et,
•Nihai Sprint Hedefini belirle,
•İş büyüklükleri ve takım hızına göre
product backlogtaki işleri plana dahil et
(self - organized),
•İşleri alt görevlere böl.
Nihai Sprint
Hedefi
Sprint
Backlog
Takım Hızı/
Kapasitesi
Product
Backlog
Taslak Sprint
Hedefi
Tahminleme ve Takım Hızı (Velocity)
 PBI Büyüklük ve Karmaşıklığı -> Story Point veya Adam/Saat
 Planning Poker: Tüm takım birlikte tahminleme yapar, iteratiftir.
Takım Hızı
Extra Small Small Medium Large Extra Large
Extra Extra
Large
1 point 2 points 3 points 5 points 8 points 13 points
Daily Scrum
 Geliştirme ekibi içindeki günlük koordinasyon toplantıları,
 En fazla 15 dakika,
 Ayaktadır – Daily Stand-up da denir.
 Amaç problem çözmek değildir.
 Ekibin durumu raporlaması, farkındalığın oluşması sağlanır. - Şeffaflık
 PO ve SM gözlemci olarak katılım sağlayabilir.
 Scrum of Scrums: Birden fazla ekip varsa, her ekipten birer
temsilcinin(genelde SM) katılımıyla gerçekleşir.
 Takımlar arası koordinasyon(sorunlar, riskler, mevcut ilerleyiş) sağlanır.
Daily Scrum - 3 Soru
1 - Dün ne yaptın?
2 - Bugün ne yapacaksın?
3 - İlerlemeni engelleyen bir durum var mı?
 Ekip içi taahhüt verilmiş olunur.
 Sorunlar rapor edildiyse, follow-up görüşmelerle ayrıca irdelenir.(Kontrol
ve Adaptasyon)
Sprint Review
 Tüm takım katılır.
 Dış paydaşlar da katılım sağlayabilir.
 Takım tarafından geliştirilen ürünün demosu yapılır.(Kontrol)
 Sprint hedefine ulaşılmış mı?
 Paydaşlar geliştirilen fonksiyonlardan memnun mu?
 Değişiklik talepleri var mı?
 Sprint hedefine ilişkin olması gereken diğer fonksiyonlar?
 Gereksiz fonksiyonlar var mı?
 Review sonucunda Product Backlog revize edilmiş olur.(Adaptasyon)
 PO tarafından kabul edildiği takdirde ürün canlı ortama kurulabilir.
Sprint Retrospective
 Her Sprint sonunda tüm takım katılır.
 Sprint boyunca iyi giden ve kötü giden hususlar neler? (Kontrol)
 Süreci iyileştirmek için hangi aksiyonları almalıyız? - DAKI - (Adaptasyon)
Yapmaya Başla
Yapmayı Sonlandır
Yapmaya Devam Et
Daha İyi Yap
Drop
Add
Keep
Improve
Zaman Kısıtları (Time-Boxing)
 Scrum, Sprint ve toplantılara gereğinden fazla zaman ayırmayı israf olarak
görür.
 Sprint; en fazla 1 ay,
 Daily Scrum; en fazla 15 dk.,
 Sprint Planlama; 1 aylık Sprint için en fazla 8 saat,
 Sprint Gözden Geçirme; 1 aylık Sprint için en fazla 4 saat,
 Sprint Restrospective; 1 aylık Sprint için en fazla 3 saat.
 Scrum Master, toplantıların zamanında gerçekleştirilmesi ve zaman
kısıtlarına uyulması konusunda ekibi yönlendirir.
Yapılar
ROLLER TOPLANTILAR YAPILAR
 Sprint Planning
 Sprint Review
 Sprint
Retrospective
 Daily Scrum
 Product Owner
 Scrum Master
 Development
Team
 Product Backlog
 Sprint Backlog
 Increment
 Definition of
Done / Ready
Product Backlog
 Tüm ürün gereksinimleri (user stories),
 Müşteri geri bildirimleri – değişiklik istekleri,
 Hatalar,
 Risk (anti-value) aksiyonları,
 Teknik altyapı işlerinden oluşur.
 Sürekli gelişir / değişir.
 PO işleri önceliklendirir.
 Backlog Grooming (Refining)
 Her Sprint öncesinde öncelikleri ve detay
seviyeleri gözden geçirilir.
 Takım işlerin büyüklük tahminlerini revize
eder.
Product Backlog - Örnek
Product Backlog Item(PBI) Tahmin Öncelik
Test altyapısını kur. 5 1
Sistem Yöneticisi olarak yeni bir kullanıcı eklemek
istiyorum.
3 2
Sistem Yöneticisi olarak var olan bir kullanıcıya rol
atamak istiyorum.
2 3
Oturumu Kapat düğmesi çalışmıyor. - 4
… … 5
User Story (Kullanıcı Hikayesi)
 «<Rol / Aktör> olarak, <İş Faydasını> sağlamak için, <Fonksiyonu>
gerçekleştirmek istiyorum.»
 Müşteri ile diyalog başlatmaya yöneliktir.
 Örnek: Sistem Yöneticisi olarak, kullanıcının sisteme girebilmesi ve
yetkileri çerçevesinde işlem yapabilmesi için, kullanıcıyı sisteme eklemek
istiyorum.
 Kabul Kriterleri:
 Bir kullanıcı sisteme bir defa eklenebilir.
 Kullanıcı bilgileri eksiksiz olmalıdır.
 Kullanıcı adı ve soyadı en fazla 30 karakter olabilir vb.
 INVEST…
Epicler ve Kullanıcı Hikayeleri
Backlog Grooming /
Refining
Epic ve Kullanıcı Hikayeleri - Örnek
Müşteri olarak, ziyaret ettiğim ürünleri ileride satın almak için, istek
listelerim olsun istiyorum.
Müşteri olarak, bir ürünü daha sonra tekrar
görüntülemek üzere, istek listesine
kaydetmek istiyorum.
Müşteri olarak, daha önce kaydettiğim bir
ürünü satın alabilmek için istek listelerimi
görüntülemek istiyorum.
Sprint Backlog
 Sprint Hedefi ve önceliklere ve göre iş
planlanır.
 Ne Yapılacak?: Takım üyeleri Sprint’e ne
kadar iş alınacağına karar verir – self
organized.
 Nasıl Yapılacak?: Seçilen PBIlar alt görevlere
bölünür. (‘Done’ tanımı kullanılır.)
Sprint Backlog - Örnek
Görevler
X Kullanıcı Hikayesi
Tasarla ve Kodla
Birim testlerini kodla ve çalıştır
Sistem testlerini hazırla/güncelle ve çalıştır
Yardım Kılavuzunu güncelle
Kod Refactor
Kod Gözden Geçirme ve Bulguların Düzeltilmesi
…
Essential Scrum: A Practical Guide to the Most Popular Agile Process, Addison-Wesley
Definition of Done
 İşin tamamlanma kriterlerini ifade eder.
 Bir kontrol listesidir.
 Herhangi bir kriterin sağlanmaması işin tamamlanmadığını gösterir.
 Done / Not Done
 Kodlaması tamamlandı ve gözden geçirilmesi(peer review) yapıldı,
 Kodlama standartlarını karşılıyor,
 CI ortamında ilgili tüm birim testleri geçti,
 Test ortamında ilgili tüm sistem testleri geçti,
 Kabul kriterlerinin her biri karşılandı,
 İlgili dokümantasyon (kullanıcı kılavuzu, gereksinim ve tasarım dok.) güncellendi,
 Product Owner tarafından onaylandı.
 Done kriterini sağlamayan PBIlar tekrar Product Backlog’a çekilir.
Definition of Ready
 Sprint’e dahil edilecek PBIların ‘Hazır’ durumda olması gerekir. Scrum’ın
bununla ilgili standart bir tanımı yoktur.
Bir kontrol listesi değil, rehberdir. Tüm kriterlerin mükemmel olması
beklenmez.
Scrum Takımı tarafından ilk Sprint öncesinde belirlenmelidir.
 Bir Sprint’te tamamlanacak kadar ‘Küçük’,
 Planlamaya yönelik ‘Büyüklüğü Belirlenmiş’ -> Story Point / Adam*Saat,
 Geliştirme ve testler için gerekli ‘Kabul Kriterleri’ yeterli detayda ve ölçülebilir,
 Detaylarının ‘Geliştirme Ekibi Tarafından Anlaşılmış’ olması.
Sorumluluklar
İş Geliştirme Ekibi Product Owner Scrum Master
Tahminler
Product Backlog
Öncelikleri
Çevik Koçluk
İşin Koordinasyonu
Definition of Done
Sürecin Doğru
Uygulanması
Teknik Kararlar
Sprint Planlama
Toplantısı
Sprint İlerleyişinin İzlenmesi
 Burn-Down Grafiği
Quiz – Scrum Foundations
Burn-Down Grafiği – Durum 1
 İş büyüklükleri ilk tahminlenenden daha fazla çıkmış olabilir.
 Planlanan işlerle ilgili büyüklüğe etki eden yeni durumlar ortaya çıkmış olabilir.
 Devamında ilerleyişi dikkatle izlemek gerekir.
Burn-Down Grafiği – Durum 2
 Scope Creep: Sprint devam ederken yeni işler ekleniyor olabilir.
 Bu işlerin kim tarafından eklendiğini belirleyip, bu davranışı sonlandırmak gerekir.
Burn-Down Grafiği – Durum 3
 Plateau: İşlerin bir kısmı beklenenden daha zor olabilir.
 İnsan kaynağıyla ilgili beklenmeyen durumlar oluşmuş olabilir.
 Sprint’teki işler gözden geçirilir. Öncelikli işler mümkün olduğunca bitirilmeye çalışılır.
Burn-Down Grafiği – Durum 4
 Çok Fazla İş: İşlerin geneli beklenenden daha zor / büyük.
 Tahminleme süreci gözden geçirilmeli. Sprint içindeki öncelikli işlerin bir kısmını
tamamlamaya çalışmalı.
XP (Extreme Programming) ve Pratikleri
Extreme Programming (XP)
 Scrum, proje yönetim seviyesinde işlerin önceliklendirilmesi ve planlama
ve gözden geçirmelerin yapılması gibi hususlara odaklanır.
 XP ise yazılım pratiklerine odaklanan çevik bir modeldir.
 Kent Back, Extreme Programming Explained, 1999
 Roller;
 Coach ~ Scrum Master
 Customer/Proxy ~ Product Owner
 Programmers ~ Dev. Team
 Tester ~ Dev. Team
 Iteration (1-4 Hafta) ~ Sprint
Embrace Change
Kaliteli Kod?
Any fool can write code that a
computer can understand. Good
programmers write code that
humans can understand.
(M. Fowler)
Sade Tasarım
 Sade tasarım ve kod;
 Anlaşılması,
 Bakımı ve değişiklik yapması,
 Testi kolaydır.
 Gold Plating:
 İhtiyaç duyulmayan ekstra işlevler karmaşıklık getirir.
 Overengineering de tasarım ve kodun karmaşıklığını artıracaktır.
Kodunu sıklıkla gözden geçir ve temizle
Gereksinimi karşılayan en basit çözümü ara
Refactoring
 Hedef: Kodun davranışını değiştirmeden tasarımını iyileştirmek.
 « Yazılım geliştirmek aşçının yemek pişirmesi gibidir. »
 Yemek pişirmeye devam etmek için arada biriken bulaşıklar yıkanmalı.
 Zaman baskısı, tasarım prensiplerinin izlenmemesi vs. -> Teknik Borç
 Refactor: Teknik borcun azaltılması amaçlanır.
 Düzenli olarak gerçekleştirilmelidir. (Örn: Red-Green-Refactor)
Mevcut kodu nasıl daha iyi tasarlarım?
Nasıl daha basit, anlaşılır ve kolay güncellenir duruma getiririm?
Bazı Kod Semptomları (Code Smells)
Semptom Açıklama
Bloaters
Okunabilirliği ve güncellenmesi zorlaşmış kod segmentleri.
Uzun metotlar, büyük sınıflar, uzun parametre listeleri vs.
Object-Orientation
Abusers
Nesne tabanlı prensiplerin-patternlerin doğru
uygulanmadığı noktalar.
Change Preventers
Bir yerde güncelleme yaptığınızda başka birçok yer bundan
etkileniyorsa güncellemek zorlaşır.
Dispensables
Çıkarıldığında(dead code) veya tekleştirildiğinde(duplicate
ise) kodu daha temiz hale getirecek kısımlar.
Couplers Birbirine birçok noktadan bağımlı olan sınıflar.
Kodlama Standartları
 Hedef: Belirlenen standartlara dayalı olarak kodlama yapmasını sağlar.
Kodun yazarı dışında anlaşılırlığını, dolayısıyla bakımı kolaylaştırır.
 İsimlendirme (dosya, paket, sınıf, metot, değişken, sabit vs.)
 Kodun stili (indentation, boşluklar, parantezlerin, operatörlerin kullanımı,
vs.)
 API dokümantasyonu (@param, @return vs.)
 Programlama dillerinin kendi rehberleri bulunuyor. (Java Code Conventions)
 Başlangıç noktası, ekip uyarlayabilir.
Test-Driven Development
Bu döngü devamlı geri bildirim sağlar. (Hem lokalde, hem CI ortamında).
Bir disiplin oluşturur, tüm birim testleri geçene kadar kod tamamlanmamış sayılır.
(Kod önce yazıldığı takdirde birim testler göz ardı edilebilir.)
İyi tasarıma, metotların bütünlüğüne (cohesion) destek olur.
1. Koddan önce testlerini yaz, testler başarısız sonuç verir,
2. Tüm testler geçene kadar kodlamayı yap,
3. Refactor,
4. Testini otomatize et,
5. Her bir committe geçtiğini doğrula.
Değişiklikler ve refactor için takıma güven verir. Debug’ı en aza indirir.
Continuous Integration
Develop
Unit Test
Commit
Automated
Build
Automated
Unit Test
CITool
 Devamlı Geribildirim: Build ve birim test sorunlarının erken tespit edilerek
aksiyonların alınması.
 Kodun ortak havuzda en güncel haliyle ve build edilebilir olarak saklanması
hedeflenir.
 Geliştiriciler en güncel durumu yansıtmak için sıklıkla commit yapar.
 Her commit sonrası çalıştırılması beklenir.
Code Coverage
Continuous Integration vs. Delivery vs. Deployment
Otomasyon: İnsan hatasını en aza indirir, hızlı geri bildirim sağlar.
Time-to-market süresini kısaltır.
Pair Programming
 Sürücü: İşin detaylarına odaklanır, kodlamayı yapar.
 Navigatör: Büyük resme odaklanır, genel tasarım prensipleri ve kodlama
standartlarını gözetir.
 Roller arası geçiş yapılır.
 Test-Code-Refactor döngüsünde ideal çözüm için ortak çalışırlar:
 Bir sonraki adımda gerçekleştirilmesi gereken nedir?
 Bunu nasıl test edebiliriz?
 Testin geçmesi için yazılabilecek en sade kod nasıl olmalı?
 Yazdığımız kodu nasıl refactor edebiliriz?
Çift akıl-> Daha az hata, daha kaliteli kod. Partner baskısı; test ve refactorün göz ardı
edilmesi riskini azaltır.
Bilgi ve tecrübe aktarımını destekler.
Collective Code Ownership
 Bireysel Sahiplikte;
 Bireylerin tam sorumlu oldukları kod segmentleri vardır.
 Kodu anlayan kişinin sadece yazan olduğu anlayışı hakimdir.
 Kodun sahibi dışında güncelleme yapılması zordur.
 Kolektif Sahiplik: Kod sorumluluğu tüm ekip tarafından paylaşılır.
 Kod segmentleri kişilere bağımlı değildir.
 Senin, benim kodum ayrımı yoktur. Ekibin kodu…
 Herhangi bir geliştirici, herhangi bir kod segmentini güncelleyebilir.
 Sade tasarım, kodlama standartları, pair programming gibi pratikler de
bunu destekler.
Sustainable Pace
 Hedef: Eve yorgun halde dönmek, bitmiş halde değil…
 Sürdürülebilir bir tempoda çalışmalı,
 Üretken çalışabilmek için limitlerimizin farkında olmalı,
 Fazla mesai mümkün olduğunca yapılmamalı (iş-özel hayat dengesi),
 Üretkenliği azaltan hususlar belirlenmeli ve azaltılmalı;
 Uzun toplantılar, gereksiz dokümantasyon, işin sürekli bölünmesi (telefon vs.)
Over-commitment yapma Kapasiteye göre iterasyonu planla
‘Hayır’ demeyi öğren
Multitasking Kaynaklı İş Kaybı
Quality Software Management: Systems Thinking, Gerald Weinberg
Small Releases
 Hedef: Müşteriye çabuk iş faydası sağlamak ve hızlı geri dönüş alarak
aksiyonları belirlemek.
 Her bir iterasyonun(1-4 hafta) sonunda kabul testleri geçen yazılımı teslim
et.
Customer Tests
 Hedef: Fonksiyonların kabul kriterlerinin sağlandığının doğrulanması.
 Sistem Testi veya Kabul Testi jargonu da kullanılır.
 Son kullanıcı bakış açısıyla fonksiyonlar test edilir.
 İyi pratik otomatize edilmesidir (Selenium vs.).
 Sürüm teslimatının ön koşuludur.
Çevik Metrikler
Çevik Metrikler
Value Neutrality: There are no good news or bad news, there is
only current reality / data.
 Ölçümler tek başına performansı göstermez, birer indikatördür.
 Proje ve ekibin içindeki özel durumla beraber değerlendirilmelidir.
 Rework Oranı; gereksinimlerin görece net olduğu bir projede düşük veya
görece belirsiz olduğu bir projede yüksek olabilir.
 Hata Yoğunluğu; kompleks bir projede daha yüksek olabilir.
 Ölçümler için spesifik hedefler yerine trendler üzerine odaklanılması
tavsiye edilir.
Örnek Metrikler
Delivery Metrics Business Metrics
Velocity Revenue
Code Coverage Costs
Test Automation Rate Customer Satisfaction
Defects (Density, Detection Rate) Employee Satisfaction
Coupling Lead & Cycle Time
Cyclomatic Complexity
Innovation Rate (percentage of new vs.
maintenance work)
Depth of Inheritance Usage
Build Failures
Kitap Önerileri
SORULAR?

More Related Content

What's hot

Yazılım Projelerine Scrum Yazılım Geliştirme Modelinin Uygulanması ve Scrum Y...
Yazılım Projelerine Scrum Yazılım Geliştirme Modelinin Uygulanması ve Scrum Y...Yazılım Projelerine Scrum Yazılım Geliştirme Modelinin Uygulanması ve Scrum Y...
Yazılım Projelerine Scrum Yazılım Geliştirme Modelinin Uygulanması ve Scrum Y...
Cenk Derinozlu
 
Agile Manifesto Nedir
Agile Manifesto NedirAgile Manifesto Nedir
Agile Manifesto Nedir
ACM
 
Proje yönetimi notları
Proje yönetimi notlarıProje yönetimi notları
Proje yönetimi notları
Aytekin Özel
 
Agile Scrum Temel Egitimi
Agile Scrum Temel EgitimiAgile Scrum Temel Egitimi
Agile Scrum Temel Egitimi
Muhammet Emin Akçelik
 
CBAP Uluslararası İş Analisti Sertifikasyonu
CBAP Uluslararası İş Analisti SertifikasyonuCBAP Uluslararası İş Analisti Sertifikasyonu
CBAP Uluslararası İş Analisti Sertifikasyonu
Muhammed Özdemir
 
JİRA'ya Giriş / Atlassian
JİRA'ya Giriş / AtlassianJİRA'ya Giriş / Atlassian
JİRA'ya Giriş / Atlassian
Cansu Kaya
 
Çevik Yaklaşım, Scrum ve XP
Çevik Yaklaşım, Scrum ve XPÇevik Yaklaşım, Scrum ve XP
Çevik Yaklaşım, Scrum ve XP
Osman DÖNER, PMP, PMI-ACP
 
Scrum takımlarında performans ölçüm yaklaşımı
Scrum takımlarında performans ölçüm yaklaşımıScrum takımlarında performans ölçüm yaklaşımı
Scrum takımlarında performans ölçüm yaklaşımı
Necmettin Ozkan
 
Agile Yaklaşımlar
Agile YaklaşımlarAgile Yaklaşımlar
Agile Yaklaşımlar
Mustafa Dağdelen
 
Scrum Training (One Day)
Scrum Training (One Day)Scrum Training (One Day)
Scrum Training (One Day)
beLithe
 
Scrum Temelleri
Scrum TemelleriScrum Temelleri
Scrum Temelleri
Ozan Ozcan
 
Agile & Scrum Training
Agile & Scrum TrainingAgile & Scrum Training
Agile & Scrum Training
Conscires Agile Practices
 
Agile scrum training
Agile scrum trainingAgile scrum training
Scrum framework
Scrum frameworkScrum framework
Scrum framework
Rashmi Pathak
 
Scrum
ScrumScrum
Çevik / Agile Metodoloji
Çevik / Agile MetodolojiÇevik / Agile Metodoloji
Çevik / Agile Metodoloji
Yağmur KAYA ARICAN
 
Agile Project Management for IT Projects
Agile Project Management for IT ProjectsAgile Project Management for IT Projects
Agile Project Management for IT Projects
rachna_nainani
 
Problem Çözme Teknikleri
Problem Çözme TeknikleriProblem Çözme Teknikleri
Problem Çözme Teknikleri
Caner Taban
 
Agile Methodology
Agile MethodologyAgile Methodology
Agile Methodology
Aciron Consulting
 

What's hot (20)

Yazılım Projelerine Scrum Yazılım Geliştirme Modelinin Uygulanması ve Scrum Y...
Yazılım Projelerine Scrum Yazılım Geliştirme Modelinin Uygulanması ve Scrum Y...Yazılım Projelerine Scrum Yazılım Geliştirme Modelinin Uygulanması ve Scrum Y...
Yazılım Projelerine Scrum Yazılım Geliştirme Modelinin Uygulanması ve Scrum Y...
 
Agile Manifesto Nedir
Agile Manifesto NedirAgile Manifesto Nedir
Agile Manifesto Nedir
 
Proje yönetimi notları
Proje yönetimi notlarıProje yönetimi notları
Proje yönetimi notları
 
Agile Scrum Temel Egitimi
Agile Scrum Temel EgitimiAgile Scrum Temel Egitimi
Agile Scrum Temel Egitimi
 
CBAP Uluslararası İş Analisti Sertifikasyonu
CBAP Uluslararası İş Analisti SertifikasyonuCBAP Uluslararası İş Analisti Sertifikasyonu
CBAP Uluslararası İş Analisti Sertifikasyonu
 
Proje yonetimi
Proje yonetimiProje yonetimi
Proje yonetimi
 
JİRA'ya Giriş / Atlassian
JİRA'ya Giriş / AtlassianJİRA'ya Giriş / Atlassian
JİRA'ya Giriş / Atlassian
 
Çevik Yaklaşım, Scrum ve XP
Çevik Yaklaşım, Scrum ve XPÇevik Yaklaşım, Scrum ve XP
Çevik Yaklaşım, Scrum ve XP
 
Scrum takımlarında performans ölçüm yaklaşımı
Scrum takımlarında performans ölçüm yaklaşımıScrum takımlarında performans ölçüm yaklaşımı
Scrum takımlarında performans ölçüm yaklaşımı
 
Agile Yaklaşımlar
Agile YaklaşımlarAgile Yaklaşımlar
Agile Yaklaşımlar
 
Scrum Training (One Day)
Scrum Training (One Day)Scrum Training (One Day)
Scrum Training (One Day)
 
Scrum Temelleri
Scrum TemelleriScrum Temelleri
Scrum Temelleri
 
Agile & Scrum Training
Agile & Scrum TrainingAgile & Scrum Training
Agile & Scrum Training
 
Agile scrum training
Agile scrum trainingAgile scrum training
Agile scrum training
 
Scrum framework
Scrum frameworkScrum framework
Scrum framework
 
Scrum
ScrumScrum
Scrum
 
Çevik / Agile Metodoloji
Çevik / Agile MetodolojiÇevik / Agile Metodoloji
Çevik / Agile Metodoloji
 
Agile Project Management for IT Projects
Agile Project Management for IT ProjectsAgile Project Management for IT Projects
Agile Project Management for IT Projects
 
Problem Çözme Teknikleri
Problem Çözme TeknikleriProblem Çözme Teknikleri
Problem Çözme Teknikleri
 
Agile Methodology
Agile MethodologyAgile Methodology
Agile Methodology
 

Similar to Cevik Yaklasim, Scrum ve XP Pratikleri

İTÜ İşletme Fakültesi - E-ticarette Yazılım ve Altyapı
İTÜ İşletme Fakültesi - E-ticarette Yazılım ve AltyapıİTÜ İşletme Fakültesi - E-ticarette Yazılım ve Altyapı
İTÜ İşletme Fakültesi - E-ticarette Yazılım ve Altyapı
Murat Kader
 
Yazılım mühendisliğinde i̇nsan bilgisayar etkileşimi
Yazılım mühendisliğinde i̇nsan bilgisayar etkileşimiYazılım mühendisliğinde i̇nsan bilgisayar etkileşimi
Yazılım mühendisliğinde i̇nsan bilgisayar etkileşimi
Betul Kesimal
 
E-ticarette Yazılım ve Altyapı
E-ticarette Yazılım ve AltyapıE-ticarette Yazılım ve Altyapı
E-ticarette Yazılım ve Altyapı
Murat Kader
 
Scrum tanıtımı
Scrum tanıtımıScrum tanıtımı
Scrum tanıtımı
Mehmet Çelik
 
Yazılım projeleri süreç performans ölçümü
Yazılım projeleri süreç performans ölçümüYazılım projeleri süreç performans ölçümü
Yazılım projeleri süreç performans ölçümü
TUBITAK
 
Çevik Manifesto Sunum
Çevik Manifesto Sunum Çevik Manifesto Sunum
Çevik Manifesto Sunum
ERCAN CETIN
 
Yazılım Mimarileri - Yazılım Geliştirme Modelleri
Yazılım Mimarileri - Yazılım Geliştirme ModelleriYazılım Mimarileri - Yazılım Geliştirme Modelleri
Yazılım Mimarileri - Yazılım Geliştirme Modelleri
Kubra Kose
 
Analist Eğitimi - Tüm Bölümler - [535 Slides]
Analist Eğitimi - Tüm Bölümler -  [535 Slides]Analist Eğitimi - Tüm Bölümler -  [535 Slides]
Analist Eğitimi - Tüm Bölümler - [535 Slides]
Erol Bozkurt
 
Agi̇le Yöntemleri̇
Agi̇le Yöntemleri̇Agi̇le Yöntemleri̇
Agi̇le Yöntemleri̇
Fatih Soysal
 
Proje Yönetimi
Proje YönetimiProje Yönetimi
Proje Yönetimi
Gözde Sarmısak
 
Yazılım mimarisi yazılım müh.
Yazılım mimarisi yazılım müh.Yazılım mimarisi yazılım müh.
Yazılım mimarisi yazılım müh.
Hüseyin Örer
 
Mikideas Eğitim ve Danışmanlık Hizmetleri Broşürü
Mikideas Eğitim ve Danışmanlık Hizmetleri BroşürüMikideas Eğitim ve Danışmanlık Hizmetleri Broşürü
Mikideas Eğitim ve Danışmanlık Hizmetleri Broşürü
Erol Bozkurt
 
MART - www.martgeldi.com - Scrum Eğitimlerimiz
MART - www.martgeldi.com - Scrum EğitimlerimizMART - www.martgeldi.com - Scrum Eğitimlerimiz
BTRisk Yazılım Güvenliği Yönetimi Eğitimi
BTRisk Yazılım Güvenliği Yönetimi EğitimiBTRisk Yazılım Güvenliği Yönetimi Eğitimi
BTRisk Yazılım Güvenliği Yönetimi Eğitimi
BTRisk Bilgi Güvenliği ve BT Yönetişim Hizmetleri
 
Bir CMMI Seviye 5 Organizasyonel Performans Yönetim Projesi Örneği: Kod Kalit...
Bir CMMI Seviye 5 Organizasyonel Performans Yönetim Projesi Örneği: Kod Kalit...Bir CMMI Seviye 5 Organizasyonel Performans Yönetim Projesi Örneği: Kod Kalit...
Bir CMMI Seviye 5 Organizasyonel Performans Yönetim Projesi Örneği: Kod Kalit...
Deniz Gungor
 
Scrum ve Redmine ile yazılım projesi yönetimi
Scrum ve Redmine ile yazılım projesi yönetimiScrum ve Redmine ile yazılım projesi yönetimi
Scrum ve Redmine ile yazılım projesi yönetimi
Gokhan Boranalp
 
Yazılım Mühendisliği
Yazılım MühendisliğiYazılım Mühendisliği
Yazılım Mühendisliği
AliMETN
 
Bpm yildiz tekno park 2019
Bpm yildiz tekno park 2019Bpm yildiz tekno park 2019
Bpm yildiz tekno park 2019
Serkan Turkeli
 
SDLC - Software Development Life Cycle
SDLC - Software Development Life CycleSDLC - Software Development Life Cycle
SDLC - Software Development Life Cycle
Dilaver Demirel
 
Yazılım kalitesi ve Standartları
Yazılım kalitesi  ve Standartları Yazılım kalitesi  ve Standartları
Yazılım kalitesi ve Standartları
İbrahim ATAY
 

Similar to Cevik Yaklasim, Scrum ve XP Pratikleri (20)

İTÜ İşletme Fakültesi - E-ticarette Yazılım ve Altyapı
İTÜ İşletme Fakültesi - E-ticarette Yazılım ve AltyapıİTÜ İşletme Fakültesi - E-ticarette Yazılım ve Altyapı
İTÜ İşletme Fakültesi - E-ticarette Yazılım ve Altyapı
 
Yazılım mühendisliğinde i̇nsan bilgisayar etkileşimi
Yazılım mühendisliğinde i̇nsan bilgisayar etkileşimiYazılım mühendisliğinde i̇nsan bilgisayar etkileşimi
Yazılım mühendisliğinde i̇nsan bilgisayar etkileşimi
 
E-ticarette Yazılım ve Altyapı
E-ticarette Yazılım ve AltyapıE-ticarette Yazılım ve Altyapı
E-ticarette Yazılım ve Altyapı
 
Scrum tanıtımı
Scrum tanıtımıScrum tanıtımı
Scrum tanıtımı
 
Yazılım projeleri süreç performans ölçümü
Yazılım projeleri süreç performans ölçümüYazılım projeleri süreç performans ölçümü
Yazılım projeleri süreç performans ölçümü
 
Çevik Manifesto Sunum
Çevik Manifesto Sunum Çevik Manifesto Sunum
Çevik Manifesto Sunum
 
Yazılım Mimarileri - Yazılım Geliştirme Modelleri
Yazılım Mimarileri - Yazılım Geliştirme ModelleriYazılım Mimarileri - Yazılım Geliştirme Modelleri
Yazılım Mimarileri - Yazılım Geliştirme Modelleri
 
Analist Eğitimi - Tüm Bölümler - [535 Slides]
Analist Eğitimi - Tüm Bölümler -  [535 Slides]Analist Eğitimi - Tüm Bölümler -  [535 Slides]
Analist Eğitimi - Tüm Bölümler - [535 Slides]
 
Agi̇le Yöntemleri̇
Agi̇le Yöntemleri̇Agi̇le Yöntemleri̇
Agi̇le Yöntemleri̇
 
Proje Yönetimi
Proje YönetimiProje Yönetimi
Proje Yönetimi
 
Yazılım mimarisi yazılım müh.
Yazılım mimarisi yazılım müh.Yazılım mimarisi yazılım müh.
Yazılım mimarisi yazılım müh.
 
Mikideas Eğitim ve Danışmanlık Hizmetleri Broşürü
Mikideas Eğitim ve Danışmanlık Hizmetleri BroşürüMikideas Eğitim ve Danışmanlık Hizmetleri Broşürü
Mikideas Eğitim ve Danışmanlık Hizmetleri Broşürü
 
MART - www.martgeldi.com - Scrum Eğitimlerimiz
MART - www.martgeldi.com - Scrum EğitimlerimizMART - www.martgeldi.com - Scrum Eğitimlerimiz
MART - www.martgeldi.com - Scrum Eğitimlerimiz
 
BTRisk Yazılım Güvenliği Yönetimi Eğitimi
BTRisk Yazılım Güvenliği Yönetimi EğitimiBTRisk Yazılım Güvenliği Yönetimi Eğitimi
BTRisk Yazılım Güvenliği Yönetimi Eğitimi
 
Bir CMMI Seviye 5 Organizasyonel Performans Yönetim Projesi Örneği: Kod Kalit...
Bir CMMI Seviye 5 Organizasyonel Performans Yönetim Projesi Örneği: Kod Kalit...Bir CMMI Seviye 5 Organizasyonel Performans Yönetim Projesi Örneği: Kod Kalit...
Bir CMMI Seviye 5 Organizasyonel Performans Yönetim Projesi Örneği: Kod Kalit...
 
Scrum ve Redmine ile yazılım projesi yönetimi
Scrum ve Redmine ile yazılım projesi yönetimiScrum ve Redmine ile yazılım projesi yönetimi
Scrum ve Redmine ile yazılım projesi yönetimi
 
Yazılım Mühendisliği
Yazılım MühendisliğiYazılım Mühendisliği
Yazılım Mühendisliği
 
Bpm yildiz tekno park 2019
Bpm yildiz tekno park 2019Bpm yildiz tekno park 2019
Bpm yildiz tekno park 2019
 
SDLC - Software Development Life Cycle
SDLC - Software Development Life CycleSDLC - Software Development Life Cycle
SDLC - Software Development Life Cycle
 
Yazılım kalitesi ve Standartları
Yazılım kalitesi  ve Standartları Yazılım kalitesi  ve Standartları
Yazılım kalitesi ve Standartları
 

Cevik Yaklasim, Scrum ve XP Pratikleri

  • 1. Çevik(Agile) Yaklaşım ve Pratikleri Osman DÖNER, PMP, PMI-ACP Proje Yöneticisi ve Bölüm Sorumlusu
  • 2. Ajanda Geleneksel ve Çevik Yaklaşım XP ve Geliştirme Pratikleri Çevik Manifesto ve Prensipleri Scrum Çerçevesi Quiz ve Tartışmalar
  • 4. Geleneksel Yaklaşım – Şelale Yöntemi Gereksinim Analizi Tasarım Kodlama Test Kurulum Bakım
  • 5. Geleneksel Yaklaşımın Dezavantajları  Ürün teslimatı çok gecikiyor – proje / iş paketi sonu,  Sistemin test edilmesi ve müşteri geri bildirimleri proje / iş paketi sonuna kalıyor,  Büyük / kompleks işlerin tek fazda analizi mümkün değil, Gereksinimler başlangıçta çok net olmuyor.  Değişiklik yapma maliyetini yükseltiyor.
  • 6. Şelale Yöntemi Ne Zaman Uygun?  Kısa bir projeyse (3-6 ay gibi),  Gereksinimler çok açıksa ve değişim beklenmiyorsa, belirsizlik yoksa ve  Kullanılacak teknolojik yaklaşım netse,  Endüstriyel (fiziksel-mekanik) bir ürün geliştiriliyorsa.
  • 7. Endüstriyel Ürün vs. Yazılım Ürünü  Somut,  Değişiklik maliyetli / zordur,  Parçalı teslimi mümkün değil,  Komut / kontrol mekanizması,  Katı standartlara tabi,  Üretim miktarına odaklanır,  Çalışanlar maliyet unsuru.  Soyut,  Geç dönemlerde dahi değişime açık,  Parçalı olarak teslim edilebilir,  Ortak karar alma mekanizmaları,  Standartlar esnektir, uyarlanabilir,  Kaliteye odaklanır,  Çalışanlar projenin en değerli varlıkları.
  • 8. İhtiyaç Nedir?  Lineer olmayan, tekrarlayan(iterative) bir süreç,  Sık aralıklarla teslimatlar (2-4 haftalık döngüler),  Belli fonksiyonları içeren artırımlar(increment)  Geri bildirimlerin kısa süreli döngülerle alınması,  Ürün ihtiyacı karşılıyor mu?  Doğru yolda ilerliyor muyuz?  Geri bildirimlere göre ürünü güncelle. Plan Do Check Act
  • 9. Çevik Yaşam Döngüsü Her Zaman Uygun Mu? Basit Kaotik GereksinimlerinBelirsizliği Teknolojinin Belirsizliği
  • 10. Çevik Manifesto ve Prensipleri
  • 11. Çevik Manifesto - Değerler Process and toolsIndividuals and interactions over Following a planResponding to change over Comprehensive documentation Working software over Contract negotiationCustomer collaboration over http://www.agilemanifesto.org
  • 13. COCOMO II Faktörlerinin Ağırlıkları 33 10 4 3 1 1 0 5 10 15 20 25 30 35 People Product Computer Platform Tools & Processes Design Reuse Schedule Constraints
  • 16. Geleneksel vs. Agile Kontratlar
  • 17. Değer 4: «The map is not the territory.»
  • 18. Çevik Prensipler  https://agilemanifesto.org/principles.html  Çevik Prensipler(12), çevik pratiklerin doğru uygulanması için anlaşılması gereken temel prensiplerdir.  Yazılımın Düzenli Aralıklarla Teslimatı,  Takım İletişimi,  İdeal Yazılım Tasarımı
  • 19. Yazılımın Düzenli Aralıklarla Teslimatı - 1 https://agilemanifesto.org Çalışan yazılım ilerlemenin birincil ölçüsüdür. -- Author  Kodlamanın tamamlanması ilerleme için bir tek başına ölçü değildir.  Tüm ekiplerin anlaştığı Definition of Done kriterleri belirlenmelidir.  Kodlamanın tamamlanması, kod gözden geçirmenin yapılması, birim ve sistem testlerinin geçmesi, kabul kriterlerinin karşılanması vs.
  • 20. Yazılımın Düzenli Aralıklarla Teslimatı - 2 https://agilemanifesto.org En önemli önceliğimiz değerli yazılımın erken ve devamlı teslimini sağlayarak müşterileri memnun etmektir.  Değerli yazılım: İş faydası oluşturan yazılımdır. Önceliklendirme ile her zaman maksimum iş faydası amaçlanır.  Erken teslimat: Erken geri bildirim ve erken aksiyon almayı sağlar. Güven ortamını oluşturur.
  • 21. Yazılımın Düzenli Aralıklarla Teslimatı - 3 https://agilemanifesto.org Çalışan yazılım, tercihen kısa zaman aralıkları belirlenerek birkaç haftada ya da birkaç ayda bir düzenli olarak müşteriye sunulmalıdır.  Çevik süreçler Sürekli İyileştirme’ye odaklanır.  Sık kontrol noktaları, «fail fast, learn fast»  Ürün demosu ve gözden geçirme,  Hangi güncellemeler / iyileştirmeler gerekli?  Ekipler kısa planlarla daha verimli çalışır.
  • 22. Yazılımın Düzenli Aralıklarla Teslimatı - 4 https://agilemanifesto.org Çevik süreçler sürdürülebilir geliştirmeyi teşvik etmektedir. Sponsorlar, yazılımcılar ve kullanıcılar sabit tempoyu sürekli devam ettirebilmelidir.  Sürdürülebilir tempoda çalışmak Sürekli fazla mesai  Yaratıcılık ve motivasyona dayalı ortamlarda daha da önemli.  Kurumsal: Ürün kalitesi, çalışan memnuniyeti, daha az işten ayrılma,  Kişisel: İş ve özel yaşam dengesinin kurulması.
  • 23. Takım İletişimi - 1 https://agilemanifesto.org İş süreçlerinin sahipleri ve yazılımcılar proje boyunca günlük olarak birlikte çalışmalıdırlar.  «customer collaboration over contract negotiation»  Ekip çözüme yönelik olarak işin niteliğini ve ihtiyaçları,  Müşteri de trade-offları daha net anlayabilir.  Örn: Sprint Review’lere Müşteri de dahil edilebilir.
  • 24. Takım İletişimi - 2 https://agilemanifesto.org Bir yazılım takımında bilgi alışverişinin en verimli ve etkin yöntemi yüz yüze iletişimdir. -- Author  Waterfall: Dokümantasyon yoluyla formal iletişime ağırlık verir. (Planlar, SRS, SDD vs.). Teslim Et – Onay Al.  Agile: Mümkün oldukça yüz yüze iletişime önem verir.  Duruma göre (ekiplerin lokasyonu, toplu bilgilendirme vs.) farklı yöntemler de tercih edilir.
  • 25. Takım İletişimi - 3 https://agilemanifesto.org En iyi mimariler, gereksinimler ve tasarımlar kendi kendini örgütleyen takımlardan ortaya çıkar. -- Author  Self-organized: Teknik kararlar, 2-4 haftalık planlar.  Önkoşulu: Takımın birlikte çalışma kültürü olan ve yetkin bireylerden oluşması.
  • 26. Takım İletişimi - 4 https://agilemanifesto.org Projelerin temelinde motive olmuş bireyler yer almalıdır. Onlara ihtiyaçları olan ortam ve destek sağlanmalı, işi başaracakları konusunda güven duyulmalıdır.  Komut-Kontrol taktikleri ve mikro-yönetim yerine destekleyici liderlik.  Ekibe genel direktifler verilerek insiyatif almaları beklenir.  Önkoşul: Ekip üyelerinin yetkin bireylerden oluşması gerekiyor.  Yönetim vs. Liderlik?
  • 27. Google’ın Takım Verimliliği İçin Prensipleri
  • 28. Takım İletişimi - 5 https://agilemanifesto.org Takım, düzenli aralıklarla nasıl daha etkili ve verimli olabileceğinin üzerinde düşünür ve davranışlarını buna göre ayarlar ve düzenler.  Çevik süreçler Sürekli İyileştirme’ye odaklanır.  Üründen ayrı Sürecin de iyileştirilmesi  Scrum Retrospective: Nasıl daha iyi iş yaparız?  Çıktısı: Süreç İyileştirme Aksiyonları
  • 29. İdeal Yazılım Tasarımı - 1 https://agilemanifesto.org Teknik mükemmeliyet ve iyi tasarım konusuna sürekli özen göstermek çevikliği artırır. -- Author  Çevikliği nasıl artırır?  İyi tasarım ve kod -> «Maintainability»  Pratikler: Refactoring, Simple Design (barely good enough), Pair Programming vb.
  • 30. İdeal Yazılım Tasarımı - 2 https://agilemanifesto.orghttps://agilemanifesto.org Sadelik - yapılmayan işin maksimize edilmesi sanatı - temel prensiptir. -- Author  Sadeliğin düşmanı, Gold-Plating: Gereksinim ve teknik çözümlerde ihtiyaçtan fazlasını / daha kompleks olanı gerçekleştirmeye çalışmak.  «Don’t over-design»,  «Keep it as simple as possible»: Gereksinimler, teknik çözüm ve süreçler…
  • 31. İdeal Yazılım Tasarımı - 3 https://agilemanifesto.org Değişen gereksinimler yazılım sürecinin son aşamalarında bile kabul edilmelidir. Çevik süreçler değişimi müşterinin rekabet avantajı için kullanır.  Waterfall: Değişimin kontrol altına almaya odaklanır. Değişim zordur.  Agile: Bunun yerine değişime adapte olmayı önerir. Değişim kaçınılmazdır.  Tüm değişiklik taleplerinin gerçekleştirilmesi anlamına gelmez.  Değişiklik Yönetimi: Etki Analizi, Fayda/Maliyet Analizi
  • 32. Çevik vs. Geleneksel Yaklaşım
  • 33. Çevik Yaklaşım-Özet  Time-to-market: Rekabet edebilmek için daha hızlı piyasaya sürüm,  Adapte olabilirlik: Ürünün sık geri bildirimlerle değişen/netleşen ihtiyaçlara, sürecin de koşullara adapte edilmesi,  İş faydasına odaklanır, israfı en aza indirmeye çalışır, böylece maliyetleri azaltır,  Müşteri ve çalışan memnuniyetini artırır.  Being Agile vs. Doing Agile,  Çevik Olmak: Düşünce yapısı ve prensiplerini yeterince anlamadan pratikleri ezbere uygulamak yeterli değil.  Ya hep ya hiç gibi düşünülmemeli,  Duruma göre geleneksel ve çevik pratiklerin bir karışımı kullanılabilir.  Örnek: Sabit maliyet ve kilometretaşlarında bir kontrat yapıp, bu kısıtları etkilemeyen değişikliklere iteratif bir yaklaşımla adapte olabiliriz.
  • 36. Scrum Framework Süreç için bir Framework / Çerçeve sunar. Adımları dikte eden bir Süreç / Metot değildir. Scrum, karmaşık ürün ve sistemlerin geliştirilmesi için oluşturulmuş bir süreç çerçevesidir. Belirsiz hususlar ve riskleri kontrol etmek için iteratif, artırımlı bir yaklaşımı benimser. -- Ken Scwaber
  • 37. Scrum – Temel İlkeler Kontrol Scrum ekipleri sıklıkla hem sürecin hem de ürünün gidişatını kontrol eder. • Sprint sonlarında ürün(1) ve süreç(2) gözden geçirilir. • Hedeften sapmalar, • İyi-kötü giden hususlar belirlenir.Adaptasyon Kontrol sonucundaki bulgulara göre hangi aksiyonlar alınmalı? • Ürün adaptasyonu, • Süreç adaptasyonu. Şeffaflık • İşin ilerleme durumu, • Karşılaşılan sorunlar, • Çözüm ve iyileştirme önerileri Projeyi ilgilendiren her bilgi şeffaf bir ortamda paylaşılır. Sırlar yoktur. TEMEL İLKELER
  • 39. Sprintler  Scrum projelerinde bir dizi Sprint ile ilerlenir.  Sprint = Mini proje  2-4 haftalık periyotlar tercih edilir.  Tipik aktiviteler:  Tasarım,  Kodlama,  Refactor,  Birim ve Sistem Testleri,  Kurulum ve Altyapı İşleri,  Dokümantasyon  Sprint kapsamı planlandıktan sonra mümkün olduğunca değiştirilmez.
  • 40. Scrum Framework ROLLER TOPLANTILAR YAPILAR  Sprint Planning  Sprint Review  Sprint Retrospective  Daily Scrum  Product Owner  Scrum Master  Development Team  Product Backlog  Sprint Backlog  Increment  Definition of Done / Ready
  • 41. Roller ve Görevleri ROLLER TOPLANTILAR YAPILAR  Sprint Planning  Sprint Review  Sprint Retrospective  Daily Scrum  Product Owner  Scrum Master  Development Team  Product Backlog  Sprint Backlog  Increment  Definition of Done / Ready
  • 42. Product Owner  Ürün vizyonunu, içermesi gereken gereksinimleri belirler.  Vizyon ve gereksinimlerin iç-dış paydaşlar tarafından doğru anlaşılmasını sağlar.  Ürünün maksimum iş faydasını sağlamasını garanti altına alır.  İşleri katma değerine göre önceliklendirir.  Planlamaya dahil edilmeye yakın ürün gereksinimlerini detaylandırır. (Backlog Refining)  Geliştirilen ürünün beklenen özelliklere göre kontrolünü sağlar. (Kabul veya Ret)  Product Backlog’un tek sorumlusu ve karar vericisidir. Ürünün başarısından sorumludur.
  • 43. Scrum Master  Proje yöneticisi rolünü temsil eder.  Scrum sürecinin etkin bir şekilde uygulanması için koçluk yapar.  Toplantılar ve işleyişleri (facilitator)  Zaman kısıtları,  Önceliklendirme, planlama pratikleri vs.  Ekibin karşılaştığı sorunların aşılması için destek olur. (Destekleyici Liderlik)  Ekibin dış etkenlerden (müşteriden gelen telefonlar, doğrudan üst yönetimden gelen talepler vs.) en az ölçüde etkilenmesine çalışır.  Scrum rolleri arasında birlikte çalışma yöntemleri konusunda destek olur.
  • 44. Development Team  3-9 kişilik ekipler.  Cross-functional (geliştirme, test, yazılım mimarisi, vt yönetimi, dokümanlar vs.),  Ürünün teslimata hazır duruma gelmesi için gereken tüm işlerden sorumlu.  Kendi organize olur.  Büyüklük tahminleri, Sprint planlamaları,  Tasarım ve diğer teknik kararların verilmesi.  Sprint Backlog’da user storyleri alt görevlere böler.  Tasarım,  Veritabanı görevleri, (tablo ve alanların oluşturulması gibi)  Kodlama,  Birim test,  Sistem testi,  İlgili dokümantasyon (yardım kılavuzları, tasarım dokümanları vs.).
  • 45. Çevik Ekiplerdeki Farklılıklar  Yapacağı işin planlanması, izlenmesi ve raporlanmasında insiyatif alması beklenir.  Gereksinimleri daha iyi anlamak için direkt Product Owner veya müşteriyle doğrudan iletişim kurabilmelidir.  Kodun işlevinden ayrı olarak toplam kalitesine ve sürekli iyileştirme için düzenli refactore odaklanır.  Senin / benim kodum ayrımı yoktur. Gerektiği durumlarda yazılımın herhangi bir yerinde güncelleme veya refactor için insiyatif alabilir. Geliştiricilerden ‘sadece kod yazmaktan’ daha fazlası beklenir.
  • 46. Toplantılar ROLLER TOPLANTILAR YAPILAR  Sprint Planning  Sprint Review  Sprint Retrospective  Daily Scrum  Product Owner  Scrum Master  Development Team  Product Backlog  Sprint Backlog  Increment  Definition of Done / Ready
  • 47. Sprint Planning Sprint Planning •İşlerin ekip tarafından anlaşılırlığının sağlanması, soruların cevaplanması, •Öncelikli işlerin büyüklük tahminlerini revize et, •Nihai Sprint Hedefini belirle, •İş büyüklükleri ve takım hızına göre product backlogtaki işleri plana dahil et (self - organized), •İşleri alt görevlere böl. Nihai Sprint Hedefi Sprint Backlog Takım Hızı/ Kapasitesi Product Backlog Taslak Sprint Hedefi
  • 48. Tahminleme ve Takım Hızı (Velocity)  PBI Büyüklük ve Karmaşıklığı -> Story Point veya Adam/Saat  Planning Poker: Tüm takım birlikte tahminleme yapar, iteratiftir. Takım Hızı Extra Small Small Medium Large Extra Large Extra Extra Large 1 point 2 points 3 points 5 points 8 points 13 points
  • 49. Daily Scrum  Geliştirme ekibi içindeki günlük koordinasyon toplantıları,  En fazla 15 dakika,  Ayaktadır – Daily Stand-up da denir.  Amaç problem çözmek değildir.  Ekibin durumu raporlaması, farkındalığın oluşması sağlanır. - Şeffaflık  PO ve SM gözlemci olarak katılım sağlayabilir.  Scrum of Scrums: Birden fazla ekip varsa, her ekipten birer temsilcinin(genelde SM) katılımıyla gerçekleşir.  Takımlar arası koordinasyon(sorunlar, riskler, mevcut ilerleyiş) sağlanır.
  • 50. Daily Scrum - 3 Soru 1 - Dün ne yaptın? 2 - Bugün ne yapacaksın? 3 - İlerlemeni engelleyen bir durum var mı?  Ekip içi taahhüt verilmiş olunur.  Sorunlar rapor edildiyse, follow-up görüşmelerle ayrıca irdelenir.(Kontrol ve Adaptasyon)
  • 51. Sprint Review  Tüm takım katılır.  Dış paydaşlar da katılım sağlayabilir.  Takım tarafından geliştirilen ürünün demosu yapılır.(Kontrol)  Sprint hedefine ulaşılmış mı?  Paydaşlar geliştirilen fonksiyonlardan memnun mu?  Değişiklik talepleri var mı?  Sprint hedefine ilişkin olması gereken diğer fonksiyonlar?  Gereksiz fonksiyonlar var mı?  Review sonucunda Product Backlog revize edilmiş olur.(Adaptasyon)  PO tarafından kabul edildiği takdirde ürün canlı ortama kurulabilir.
  • 52. Sprint Retrospective  Her Sprint sonunda tüm takım katılır.  Sprint boyunca iyi giden ve kötü giden hususlar neler? (Kontrol)  Süreci iyileştirmek için hangi aksiyonları almalıyız? - DAKI - (Adaptasyon) Yapmaya Başla Yapmayı Sonlandır Yapmaya Devam Et Daha İyi Yap Drop Add Keep Improve
  • 53. Zaman Kısıtları (Time-Boxing)  Scrum, Sprint ve toplantılara gereğinden fazla zaman ayırmayı israf olarak görür.  Sprint; en fazla 1 ay,  Daily Scrum; en fazla 15 dk.,  Sprint Planlama; 1 aylık Sprint için en fazla 8 saat,  Sprint Gözden Geçirme; 1 aylık Sprint için en fazla 4 saat,  Sprint Restrospective; 1 aylık Sprint için en fazla 3 saat.  Scrum Master, toplantıların zamanında gerçekleştirilmesi ve zaman kısıtlarına uyulması konusunda ekibi yönlendirir.
  • 54. Yapılar ROLLER TOPLANTILAR YAPILAR  Sprint Planning  Sprint Review  Sprint Retrospective  Daily Scrum  Product Owner  Scrum Master  Development Team  Product Backlog  Sprint Backlog  Increment  Definition of Done / Ready
  • 55. Product Backlog  Tüm ürün gereksinimleri (user stories),  Müşteri geri bildirimleri – değişiklik istekleri,  Hatalar,  Risk (anti-value) aksiyonları,  Teknik altyapı işlerinden oluşur.  Sürekli gelişir / değişir.  PO işleri önceliklendirir.  Backlog Grooming (Refining)  Her Sprint öncesinde öncelikleri ve detay seviyeleri gözden geçirilir.  Takım işlerin büyüklük tahminlerini revize eder.
  • 56. Product Backlog - Örnek Product Backlog Item(PBI) Tahmin Öncelik Test altyapısını kur. 5 1 Sistem Yöneticisi olarak yeni bir kullanıcı eklemek istiyorum. 3 2 Sistem Yöneticisi olarak var olan bir kullanıcıya rol atamak istiyorum. 2 3 Oturumu Kapat düğmesi çalışmıyor. - 4 … … 5
  • 57. User Story (Kullanıcı Hikayesi)  «<Rol / Aktör> olarak, <İş Faydasını> sağlamak için, <Fonksiyonu> gerçekleştirmek istiyorum.»  Müşteri ile diyalog başlatmaya yöneliktir.  Örnek: Sistem Yöneticisi olarak, kullanıcının sisteme girebilmesi ve yetkileri çerçevesinde işlem yapabilmesi için, kullanıcıyı sisteme eklemek istiyorum.  Kabul Kriterleri:  Bir kullanıcı sisteme bir defa eklenebilir.  Kullanıcı bilgileri eksiksiz olmalıdır.  Kullanıcı adı ve soyadı en fazla 30 karakter olabilir vb.  INVEST…
  • 58. Epicler ve Kullanıcı Hikayeleri Backlog Grooming / Refining
  • 59. Epic ve Kullanıcı Hikayeleri - Örnek Müşteri olarak, ziyaret ettiğim ürünleri ileride satın almak için, istek listelerim olsun istiyorum. Müşteri olarak, bir ürünü daha sonra tekrar görüntülemek üzere, istek listesine kaydetmek istiyorum. Müşteri olarak, daha önce kaydettiğim bir ürünü satın alabilmek için istek listelerimi görüntülemek istiyorum.
  • 60. Sprint Backlog  Sprint Hedefi ve önceliklere ve göre iş planlanır.  Ne Yapılacak?: Takım üyeleri Sprint’e ne kadar iş alınacağına karar verir – self organized.  Nasıl Yapılacak?: Seçilen PBIlar alt görevlere bölünür. (‘Done’ tanımı kullanılır.)
  • 61. Sprint Backlog - Örnek Görevler X Kullanıcı Hikayesi Tasarla ve Kodla Birim testlerini kodla ve çalıştır Sistem testlerini hazırla/güncelle ve çalıştır Yardım Kılavuzunu güncelle Kod Refactor Kod Gözden Geçirme ve Bulguların Düzeltilmesi …
  • 62. Essential Scrum: A Practical Guide to the Most Popular Agile Process, Addison-Wesley
  • 63. Definition of Done  İşin tamamlanma kriterlerini ifade eder.  Bir kontrol listesidir.  Herhangi bir kriterin sağlanmaması işin tamamlanmadığını gösterir.  Done / Not Done  Kodlaması tamamlandı ve gözden geçirilmesi(peer review) yapıldı,  Kodlama standartlarını karşılıyor,  CI ortamında ilgili tüm birim testleri geçti,  Test ortamında ilgili tüm sistem testleri geçti,  Kabul kriterlerinin her biri karşılandı,  İlgili dokümantasyon (kullanıcı kılavuzu, gereksinim ve tasarım dok.) güncellendi,  Product Owner tarafından onaylandı.  Done kriterini sağlamayan PBIlar tekrar Product Backlog’a çekilir.
  • 64. Definition of Ready  Sprint’e dahil edilecek PBIların ‘Hazır’ durumda olması gerekir. Scrum’ın bununla ilgili standart bir tanımı yoktur. Bir kontrol listesi değil, rehberdir. Tüm kriterlerin mükemmel olması beklenmez. Scrum Takımı tarafından ilk Sprint öncesinde belirlenmelidir.  Bir Sprint’te tamamlanacak kadar ‘Küçük’,  Planlamaya yönelik ‘Büyüklüğü Belirlenmiş’ -> Story Point / Adam*Saat,  Geliştirme ve testler için gerekli ‘Kabul Kriterleri’ yeterli detayda ve ölçülebilir,  Detaylarının ‘Geliştirme Ekibi Tarafından Anlaşılmış’ olması.
  • 65. Sorumluluklar İş Geliştirme Ekibi Product Owner Scrum Master Tahminler Product Backlog Öncelikleri Çevik Koçluk İşin Koordinasyonu Definition of Done Sürecin Doğru Uygulanması Teknik Kararlar Sprint Planlama Toplantısı
  • 67. Quiz – Scrum Foundations
  • 68. Burn-Down Grafiği – Durum 1  İş büyüklükleri ilk tahminlenenden daha fazla çıkmış olabilir.  Planlanan işlerle ilgili büyüklüğe etki eden yeni durumlar ortaya çıkmış olabilir.  Devamında ilerleyişi dikkatle izlemek gerekir.
  • 69. Burn-Down Grafiği – Durum 2  Scope Creep: Sprint devam ederken yeni işler ekleniyor olabilir.  Bu işlerin kim tarafından eklendiğini belirleyip, bu davranışı sonlandırmak gerekir.
  • 70. Burn-Down Grafiği – Durum 3  Plateau: İşlerin bir kısmı beklenenden daha zor olabilir.  İnsan kaynağıyla ilgili beklenmeyen durumlar oluşmuş olabilir.  Sprint’teki işler gözden geçirilir. Öncelikli işler mümkün olduğunca bitirilmeye çalışılır.
  • 71. Burn-Down Grafiği – Durum 4  Çok Fazla İş: İşlerin geneli beklenenden daha zor / büyük.  Tahminleme süreci gözden geçirilmeli. Sprint içindeki öncelikli işlerin bir kısmını tamamlamaya çalışmalı.
  • 72. XP (Extreme Programming) ve Pratikleri
  • 73. Extreme Programming (XP)  Scrum, proje yönetim seviyesinde işlerin önceliklendirilmesi ve planlama ve gözden geçirmelerin yapılması gibi hususlara odaklanır.  XP ise yazılım pratiklerine odaklanan çevik bir modeldir.  Kent Back, Extreme Programming Explained, 1999  Roller;  Coach ~ Scrum Master  Customer/Proxy ~ Product Owner  Programmers ~ Dev. Team  Tester ~ Dev. Team  Iteration (1-4 Hafta) ~ Sprint Embrace Change
  • 74. Kaliteli Kod? Any fool can write code that a computer can understand. Good programmers write code that humans can understand. (M. Fowler)
  • 75. Sade Tasarım  Sade tasarım ve kod;  Anlaşılması,  Bakımı ve değişiklik yapması,  Testi kolaydır.  Gold Plating:  İhtiyaç duyulmayan ekstra işlevler karmaşıklık getirir.  Overengineering de tasarım ve kodun karmaşıklığını artıracaktır. Kodunu sıklıkla gözden geçir ve temizle Gereksinimi karşılayan en basit çözümü ara
  • 76. Refactoring  Hedef: Kodun davranışını değiştirmeden tasarımını iyileştirmek.  « Yazılım geliştirmek aşçının yemek pişirmesi gibidir. »  Yemek pişirmeye devam etmek için arada biriken bulaşıklar yıkanmalı.  Zaman baskısı, tasarım prensiplerinin izlenmemesi vs. -> Teknik Borç  Refactor: Teknik borcun azaltılması amaçlanır.  Düzenli olarak gerçekleştirilmelidir. (Örn: Red-Green-Refactor) Mevcut kodu nasıl daha iyi tasarlarım? Nasıl daha basit, anlaşılır ve kolay güncellenir duruma getiririm?
  • 77. Bazı Kod Semptomları (Code Smells) Semptom Açıklama Bloaters Okunabilirliği ve güncellenmesi zorlaşmış kod segmentleri. Uzun metotlar, büyük sınıflar, uzun parametre listeleri vs. Object-Orientation Abusers Nesne tabanlı prensiplerin-patternlerin doğru uygulanmadığı noktalar. Change Preventers Bir yerde güncelleme yaptığınızda başka birçok yer bundan etkileniyorsa güncellemek zorlaşır. Dispensables Çıkarıldığında(dead code) veya tekleştirildiğinde(duplicate ise) kodu daha temiz hale getirecek kısımlar. Couplers Birbirine birçok noktadan bağımlı olan sınıflar.
  • 78. Kodlama Standartları  Hedef: Belirlenen standartlara dayalı olarak kodlama yapmasını sağlar. Kodun yazarı dışında anlaşılırlığını, dolayısıyla bakımı kolaylaştırır.  İsimlendirme (dosya, paket, sınıf, metot, değişken, sabit vs.)  Kodun stili (indentation, boşluklar, parantezlerin, operatörlerin kullanımı, vs.)  API dokümantasyonu (@param, @return vs.)  Programlama dillerinin kendi rehberleri bulunuyor. (Java Code Conventions)  Başlangıç noktası, ekip uyarlayabilir.
  • 79. Test-Driven Development Bu döngü devamlı geri bildirim sağlar. (Hem lokalde, hem CI ortamında). Bir disiplin oluşturur, tüm birim testleri geçene kadar kod tamamlanmamış sayılır. (Kod önce yazıldığı takdirde birim testler göz ardı edilebilir.) İyi tasarıma, metotların bütünlüğüne (cohesion) destek olur. 1. Koddan önce testlerini yaz, testler başarısız sonuç verir, 2. Tüm testler geçene kadar kodlamayı yap, 3. Refactor, 4. Testini otomatize et, 5. Her bir committe geçtiğini doğrula. Değişiklikler ve refactor için takıma güven verir. Debug’ı en aza indirir.
  • 80. Continuous Integration Develop Unit Test Commit Automated Build Automated Unit Test CITool  Devamlı Geribildirim: Build ve birim test sorunlarının erken tespit edilerek aksiyonların alınması.  Kodun ortak havuzda en güncel haliyle ve build edilebilir olarak saklanması hedeflenir.  Geliştiriciler en güncel durumu yansıtmak için sıklıkla commit yapar.  Her commit sonrası çalıştırılması beklenir.
  • 82. Continuous Integration vs. Delivery vs. Deployment Otomasyon: İnsan hatasını en aza indirir, hızlı geri bildirim sağlar. Time-to-market süresini kısaltır.
  • 83. Pair Programming  Sürücü: İşin detaylarına odaklanır, kodlamayı yapar.  Navigatör: Büyük resme odaklanır, genel tasarım prensipleri ve kodlama standartlarını gözetir.  Roller arası geçiş yapılır.  Test-Code-Refactor döngüsünde ideal çözüm için ortak çalışırlar:  Bir sonraki adımda gerçekleştirilmesi gereken nedir?  Bunu nasıl test edebiliriz?  Testin geçmesi için yazılabilecek en sade kod nasıl olmalı?  Yazdığımız kodu nasıl refactor edebiliriz? Çift akıl-> Daha az hata, daha kaliteli kod. Partner baskısı; test ve refactorün göz ardı edilmesi riskini azaltır. Bilgi ve tecrübe aktarımını destekler.
  • 84. Collective Code Ownership  Bireysel Sahiplikte;  Bireylerin tam sorumlu oldukları kod segmentleri vardır.  Kodu anlayan kişinin sadece yazan olduğu anlayışı hakimdir.  Kodun sahibi dışında güncelleme yapılması zordur.  Kolektif Sahiplik: Kod sorumluluğu tüm ekip tarafından paylaşılır.  Kod segmentleri kişilere bağımlı değildir.  Senin, benim kodum ayrımı yoktur. Ekibin kodu…  Herhangi bir geliştirici, herhangi bir kod segmentini güncelleyebilir.  Sade tasarım, kodlama standartları, pair programming gibi pratikler de bunu destekler.
  • 85. Sustainable Pace  Hedef: Eve yorgun halde dönmek, bitmiş halde değil…  Sürdürülebilir bir tempoda çalışmalı,  Üretken çalışabilmek için limitlerimizin farkında olmalı,  Fazla mesai mümkün olduğunca yapılmamalı (iş-özel hayat dengesi),  Üretkenliği azaltan hususlar belirlenmeli ve azaltılmalı;  Uzun toplantılar, gereksiz dokümantasyon, işin sürekli bölünmesi (telefon vs.) Over-commitment yapma Kapasiteye göre iterasyonu planla ‘Hayır’ demeyi öğren
  • 86. Multitasking Kaynaklı İş Kaybı Quality Software Management: Systems Thinking, Gerald Weinberg
  • 87. Small Releases  Hedef: Müşteriye çabuk iş faydası sağlamak ve hızlı geri dönüş alarak aksiyonları belirlemek.  Her bir iterasyonun(1-4 hafta) sonunda kabul testleri geçen yazılımı teslim et.
  • 88. Customer Tests  Hedef: Fonksiyonların kabul kriterlerinin sağlandığının doğrulanması.  Sistem Testi veya Kabul Testi jargonu da kullanılır.  Son kullanıcı bakış açısıyla fonksiyonlar test edilir.  İyi pratik otomatize edilmesidir (Selenium vs.).  Sürüm teslimatının ön koşuludur.
  • 90. Çevik Metrikler Value Neutrality: There are no good news or bad news, there is only current reality / data.  Ölçümler tek başına performansı göstermez, birer indikatördür.  Proje ve ekibin içindeki özel durumla beraber değerlendirilmelidir.  Rework Oranı; gereksinimlerin görece net olduğu bir projede düşük veya görece belirsiz olduğu bir projede yüksek olabilir.  Hata Yoğunluğu; kompleks bir projede daha yüksek olabilir.  Ölçümler için spesifik hedefler yerine trendler üzerine odaklanılması tavsiye edilir.
  • 91. Örnek Metrikler Delivery Metrics Business Metrics Velocity Revenue Code Coverage Costs Test Automation Rate Customer Satisfaction Defects (Density, Detection Rate) Employee Satisfaction Coupling Lead & Cycle Time Cyclomatic Complexity Innovation Rate (percentage of new vs. maintenance work) Depth of Inheritance Usage Build Failures