Agile, Scrum ve Kanban

Waterfall metodoloji

* İnşaat iterasyonu

Waterfall problemleri?

• Hızlı gelişen müşteri taleplerine uyum sağlayamamak.
• Rekabetçi ürün çıkaramamak. Güncel trendlerden uzak ürün bir ürünün çıkması.
• Öngörülen eforlara uyulamaması ve uzun vadede deadline'ı yakalayamamak.
• Analiz dokümanlarındaki en ufak bir eksikliğin tüm sürece yansıması.
• Bakım (maintenance) süreci ile tekrar waterfall metodoloji çıkmazına girmek (recursive iteration).

WATERFALLU

KİM DEĞİŞTİRDİ?!

Agile manifesto

• Süreçler ve araçlardan ziyade bireyler ve etkileşimlere,
• Kapsamlı dokümantasyondan ziyade çalışan yazılıma,
• Sözleşme pazarlıklarından ziyade müşteri ile işbirliğine,
• Bir plana bağlı kalmaktan ziyade değişime karşılık vermeye

* Aralarında Martin Fowler'ın da bulunduğu 17 yiğit #2001

değer vermeye kanaat getirdik.

12 temel prensip

• En önemli önceliğimiz değerli yazılımın erken ve devamlı teslimini sağlayarak müşterileri memnun etmektir.
• 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.
• Ç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.
• İş süreçlerinin sahipleri ve yazılımcılar proje boyunca her gün birlikte çalışmalıdırlar.
• 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.
• Bir yazılım takımında bilgi alışverişinin en verimli ve etkin yöntemi yüzyüze iletişimdir.
• Çalışan yazılım ilerlemenin birincil ölçüsüdür.
• Ç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.
• Teknik mükemmeliyet ve iyi tasarım konusundaki sürekli özen çevikliği artırır.
• Sadelik, yapılmasına gerek olmayan işlerin mümkün olduğunca arttırılması sanatı, olmazsa olmazlardandır.
• En iyi mimariler, gereksinimler ve tasarımlar kendi kendini örgütleyen takımlardan ortaya çıkar.
• 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. 

Öne çıkan iki implementasyon

SCRUM

KANBAN

• Agile manifesto ekibinden Ken Schwaber ve Jeff Sutherland.

• 1940'ların sonlarında Toyota'da.
• 2000'li yıllarda IT sektöründe. 

Scrum

• Ekip sayısı: büyük boy pizza kuralı
• Roller
  • Product owner
  • Scrum master (servant leader)
  • Scrum team (herkes!)
• İterasyon
• Toplantılar
  • Sprint planning meeting
    • Sizing (poker cards)
      • En küçük madde ile oranlama
      • Gerçek hayattan örneklerle oranlama
  • Daily stand-up
  • Sprint review (product owner)
  • Retrospective (development team)
  • Grooming session (irregular)

Kanban

• Aslen bir Japon metodolojisidir.
• Pull sistemi ile çalışır.
• Görselleştirme üzerinedir, insan psikolojisinde rahatlatıcı bir etkisi vardır.
  • Maddeler önem sıralarına veya konularına göre kategorize edilebilir. Maddenin üzerinde çalışan kişiyi belirtmek için farklı renkte kalemler veya post-it'ler de kullanılabilir.
  • Maddelerin renkleri application, database, infrastructure gibi şeylere göre kategorize edilebilir.
  • Backlog, todo, WIP (work-in-progress), testing, done gibi farklı süreç grupları açılabilir.
  • Özellikle WIP alanı sınırlı olmalıdır. Bu da genellikle ekipteki çalışan sayısı ile doğru orantılıdır (kapasite).
• Toplantılar:
  • Daily stand-up
  • Demo (~sprint review)
  • Retrospective
• Daily stand-up'lar board önünde yapılır. 
  • Dün ne yaptın?
  • Bugün ne yapacaksın?
  • Yardıma ihtiyacın var mı?
• Sabit bir release tarihi yoktur. İhtiyaç olduğunda ekip canlıya çıkma kararı alabilir.
• Rol zorunluluğu yoktur fakat agile coach rolü olabilir (~scrum master), product owner rolü backlog'u besler, önem sırasını belirler.
• Lead time (creation to done) ve cycle time (WIP to done)

Farkları nelerdir?

• Scrum'da uzun sprint'ler koşulurken Kanban'da bunlar günlüktür.
• Scrum'da takım söz verir, Kanban'da böyle bir durum yoktur.
• Yalnızca Scrum ekibi sprint'i değiştirme hakkına sahiptir. Kanban'da da ekip inisiyatif sahibidir fakat WIP kolonu günbegün ekip tarafından değiştirilmelidir.
• Scrum daha plana dayalıdır. `t` anında projenin neresinde olunduğuna yanıt verebilir. Kanban bununla ilgilenmez. Bir şekilde projenin `t` anındasınızdır ve `t+1`i görmek için devam edersiniz.
• Scrum'da planlama yaparsınız, Kanban'da üretim vardır. %100 verimliliği hedefler. Scrum'da ise planlama toplantılarından ile bu oran biraz daha düşüktür.
• Scrum'da release'ler Kanban'a göre daha seyrektir.
• Scrum, development'taki problemleri görüntüleyebilmekte, planlama+raporlar ile daha başarılıdır.

Günümüz yazılım dünyasına etkileri

• DDD, BDD
• CI/CD
• Dockerizing
• Microservices

Biz ne yapabiliriz?

Scrum-but || Kanban