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)

Scrum raporları

  • Velocity report
  • Burndown chart
  • Global definition of done
  • Improvement points (retrospektif toplantılarından sonra)

Burndown chart

Velocity report chart

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

Made with Slides.com