Çevik yaklaşım, Scum Çerçevesi ve XP Pratikleriyle ilgili eğitim sunumu.

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

3. Geleneksel vs. Çevik Yaklaşım

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

12. Değer 1:

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

14. Değer 2:

15. Değer 3:

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.

34. Çevik Metodolojiler

35. Scrum Framework

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

38. Scrum – Büyük Resim

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ı

66. Sprint İlerleyişinin İzlenmesi
 Burn-Down Grafiği

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.

81. Code Coverage

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.

89. Çevik Metrikler

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

92. Kitap Önerileri

93. SORULAR?