Çevik(Agile) değer ve prensipleri, geleneksel yaklaşımdan farklarını ele alan, Scrum Çerçevesi ile XP(Extreme Programming) pratiklerinin anlatıldığı detaylı bir sunum.

1. Çevik 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 sonu,
 Sistemin test edilmesi ve müşteri geri bildirimleri proje 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 İş vs. Yazılım
 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
1
0 5 10 15 20 25 30 35
People
Product
Computer Platform
Tools & Processes
Design Reuse
Project Precedence
Schedule Constraints

14. Değer 2:

15. Değer 3:

16. Değer 4:
«The map is not the territory.»

17. Çevik Prensipler
 https://agilemanifesto.org/principles.html
 Çevik Prensipler(12), teknik pratiklerden ziyade ürünün geliştirilmesinde
sürecinde, geleneksel yaklaşımdan farklı daha yeni bir anlayışı temsil
ediyor.
 Yazılımın Düzenli Aralıklarla Teslimatı,
 Takım İletişimi,
 İdeal Yazılım Tasarımı

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

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

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

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

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

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

24. Takım İletişimi - 3
https://agilemanifesto.org
En iyi mimariler, gereksinimler ve tasarımlar kendi
kendini örgütleyen takımlardan ortaya çıkar.
-- Author

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

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

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

28. İdeal Yazılım Tasarımı - 2
https://agilemanifesto.org
Sadelik, yapılmayan işin maksimize edilmesi sanatı,
temel prensiptir.
-- Author

29. İ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.
-- Author

30. Çevik vs. Geleneksel Yaklaşım

31. Çevik Metodolojiler

32. Scrum Framework

33. Scrum Framework
Süreç için bir Framework /
Çerçeve sunar.
Adımları tanımlayan bir Süreç
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

34. 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.
• Burndown grafiği, takım hızı vs.
kontrol edilir.
• Hedeften sapmalar belirlenir.
Adaptasyon
Kontrol sonucundaki bulgulara göre
hangi aksiyonlar alınmalı?
• Süreç adaptasyonu,
• Ürün adaptasyonu
Şeffaflık
• Sürecin ilerleyişi,
• Karşılaşılan engeller,
• Çözüm ve iyileştirme önerileri
Projeyi ilgilendiren her şey şeffaf
bir ortamda paylaşılır. Sırlar
yoktur. TEMEL
İLKELER

35. Scrum – Büyük Resim

36. Sprintler
 Scrum projelerinde bir dizi Sprint ile ilerleme sağlanır.
 Sprint = Mini proje
 XP’de bunlara iterasyon denir.
 2-4 haftalık periyotlar tercih edilir.
 Tipik aktiviteler:
 Tasarım,
 Kodlama,
 Refactor,
 Birim ve Sistem Testleri,
 Kurulum,
 Dokümantasyon
 Sprint kapsamı planlandıktan sonra mümkün
olduğunca değiştirilmez.

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

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

39. 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.
 Gereksinimleri iş faydasına 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. Dolayısıyla ürünün
başarısından sorumlu kişidir.

40. Scrum Master
 Proje yöneticisi rolünü temsil eder.
 Scrum sürecinin doğru uygulanmasını sağlar.
 İyi süreç pratikleri konusunda tüm ekibe koçluk yapar.
 Ekibin karşılaştığı engellerin aşılması için destek olur. (Destekleyici Liderlik)
 Ekibin dış etkenlerden (müşteriden gelen telefonlar vs.) en az ölçüde
etkilenmesine çalışır.
 Scrum rolleri arasında birlikte çalışma yöntemleri konusunda destek olur.

41. Development Team
 3-9 kişilik ekipler.
 Cross-functional (geliştirme, test, mimari, dba admin 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.).

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

43. 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,
•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.
Sprint
Hedefi
Sprint
BacklogTakım Hızı
Product
Backlog

44. Tahminleme ve Takım Hızı (Velocity)
 PBI Büyüklük ve Karmaşıklığı -> Story Point
 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

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

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

47. 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(overdeveloping) yapıyor muyuz?
 PO tarafından kabul edildiği takdirde ürün canlı ortama kurulabilir.
 Review sonucunda Product Backlog revize edilmiş olur.(Adaptasyon)

48. Sprint Retrospective
 Her Sprint sonunda tüm takım katılır.
 Sprint boyunca iyi giden ve kötü giden hususlar neler? (Kontrol)
 Daha iyi çalışmak 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

49. 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 timeboxlara
uyumlu ilerlenmesi konusunda ekibi yönlendirir.

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

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

52. Product Backlog - Örnek
Backlog Item Tahmin Öncelik
Test Aracı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. 1 4
… … 5

53. User Story (Kullanıcı Hikayesi)
 «<Rol / Aktör> olarak, <İş Faydasını> sağlamak için, <Fonksiyonu>
gerçekleştirmek istiyorum.»
 Ö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…

54. Epicler ve Kullanıcı Hikayeleri

55. Sprint Backlog
 Takım üyeleri hangi işleri Sprint’e alacaklarına
kendileri karar verir – self organized.
 Önceliklere göre iş alınır.
 Product Backlog’taki işler teknik tasklara
bölünür. (‘Done’ tanımı kullanılır.)

56. Sprint Backlog - Örnek
Görevler
X Hikayesi Kullanıcı Arayüzünü kodla
X Hikayesi İş mantığını kodla
Veritabanı tablo ve alanlarını oluştur
Birim testlerini kodla
Sistem testlerini hazırla
Yardım Kılavuzunu güncelle
Kod Refactor
Database Refactor
…..

57. 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’,
 Harcanacak efora yönelik ‘Büyüklüğü Belirlenmiş’ -> Story Point,
 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ı.

58. Definition of Done
 İşin tamamlanma kriterlerini ifade eder.
 Hazır tanımından farklı olarak bir kontrol listesidir.
 Herhangi bir kriterin sağlanmaması işin tamamlanmadığını gösterir.
 Done / Not Done
 Kodlaması tamamlanmış ve gözden geçirilmesi(peer review) yapıldı,
 Belirlenen kodlama standartlarını karşılıyor,
 CI ortamında ilgili tüm birim ve entegrasyon testleri geçti, birim test coverage > %80,
 Test ortamında ilgili tüm sistem testleri geçti,
 Kabul kriterlerinin her biri karşılandı,
 İlgili dokümantasyon (kullanıcı kılavuzu, kurulum kılavuzu, tasarım dok.) güncellendi
 Product Owner tarafından onaylandı.
 Done kriterini sağlamayan PBIlar tekrar Product Backlog’a çekilir.

59. Sorumluluklar - Özet
İş Geliştirme Ekibi Product Owner Scrum Master
Tahminler
Product Backlog
Öncelikleri
Çevik Koçluk
İşin Koordinasyonu
Definition of Done
Süreçle Uyumun
Sağlanması
Teknik Kararlar
Sprint Planlama
Toplantısı

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

61. Quiz – Scrum Foundations

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

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

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

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

66. Burn-Down Grafiği – Durum 5
 Parçalanmamış Epicler: Takibi zor olan büyük storyler mevcut.
 Sprint’e alınmadan önce büyük hikayelerin (epic) parçalanması gerekiyor. İdealde 2-3
günü aşmamalı.

67. XP (Extreme Programming) ve Geliştirme
Pratikleri

68. 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 geliştirme 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

69. Kaliteli Kod?

70. Sade Tasarım ve Kod
 Hedef: Bakımı kolay, esnek yazılım geliştirmek
 Mümkün olan en sade tasarım ve kod hedeflenir.
 Sade tasarım ve kod;
 Açıklaması ve anlaşılması kolay,
 Bakımı ve değişiklik yapması kolay,
 Birim testi kolaydır.
 İ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

71. Refactoring
 Hedef: Kodun daha ideal tasarıma ulaşmasını sağlamak – işlevini
değiştirmeden tasarımı 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 kısıtları içinde kod geliştirirken teknik borç da beraberinde birikir.
 Refactor; teknik borcun giderilmesidir.
 Düzenli olarak gerçekleştirilmelidir. (Red-Green-Refactor)
Mevcut kodu nasıl daha iyi tasarlarım?
Nasıl daha basit, anlaşılır ve kolay güncellenir duruma getiririm?

72. Kodlama Standartları
 Hedef: Ekibin belirlenen iyi pratiklere 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 standartları (dosya, paket, sınıf, metot, değişken, sabit vs.)
 Kodun stili (statement, indentation, parantezlerin, operatörlerin kullanımı,
boşluklar vs.)
 Kodun dokümantasyonu (@param, @return vs.)
 Programlama dillerinin kendi rehberleri bulunuyor. (Java Code Conventions)
 Başlangıç noktası, ekip uyarlayabilir.

73. Test-Driven Development
Bu döngü hızlı geri bildirim sağlar. (Hem lokalde kodlarken, 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 ve sınıfları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.

74. Continuous Integration
 Hedef: 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.
 Günde en az bir, tercihen daha sık – her commit sonrası çalıştırılır,
 Geliştiriciler en güncel durumu yansıtmak için sıklıkla commit yapar.
Develop
Unit Test
Commit
Automated
Build
Automated
Unit TestCITool

75. Code Coverage

76. Continuous Integration vs. Deployment vs. Delivery
Otomasyon-> İnsan hatasını en aza indirir, hızlı geri bildirim sağlar.

77. Pair Programming
 Hedef: İzole kodlama yerine bilgi, deneyim ve fikirlerin kodlama
aşamasında paylaşılması.
 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.
 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ı?
 Yeni 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.

78. Collective Code Ownership
 Hedef: Kod sorumluluğunun bireyler değil tüm ekip tarafından
paylaşılması.
 Herhangi bir geliştirici, herhangi bir kod segmentini güncelleyebilir.
 Bireysel sahiplikte bunun aksine;
 Bireylerin tam sorumlu oldukları alt sistemler / modüller vardır.
 Kodu anlayan kişinin sadece yazan olduğu anlayışı hakimdir.
 Kodun sahibi dışında güncelleme yapılması zordur.
 Kolektif sahiplikte; kod segmentleri kişilere bağımlı değildir.
 Sade tasarım, kodlama standartları, pair programming gibi pratikler de
bunu destekler.

79. 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 belli limitlerimiz olduğunu unutmamalı,
 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

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

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

82. Çevik Kalite Metrikleri
Value Neutrality: There are no good news or bad news, there is
only current reality / data.
 Ölçümler tek başına katı gerçeklik değil, 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; ilk defa uygulanan kompleks bir mimaride daha yüksek
olabilir.
 Ölçümler için spesifik hedefler yerine trendler üzerine odaklanılması
tavsiye edilir.

83. Kalite Metrikleri - 2
Delivery Metrics Owner Metrics
Velocity Revenue
Code Coverage Costs
Test Automation Rate Customer Satisfaction
Defects (Density, Detection Rate) Employee Satisfaction
Coupling Lead & Cycle Time
Code Complexity
Innovation Rate (percentage of new vs.
maintenance work)
Depth of Inheritance Usage
Build Failures

84. Kitap Önerileri
Head First Design Patterns,
Eric Freeman , Elisabeth Robson
PMI-ACP Exam Prep,
Mike Griffiths

85. SORULAR?