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

* 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

Scrum

Scrum raporları

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

Biz ne yapabiliriz?

Scrum-but || Kanban