Kanban’ın Scrum’a göre daha ‘çevik’ olduğunu söyleyebiliriz. Sprint’lerin sonunu beklemeden tamamlanan işlerin devreye alınması, Continuous Delivery / DevOps hedefleri ile daha iyi örtüşüyor izlenimi veriyor. Ancak avantajlarının yanında, dezavantajları da var elbette.
Sosyal medyadaki tartışma gruplarında Scrum’ın yeni ürün geliştirme, Kanban’ın ise mevcut ürüne yeni özellikler eklenmesi için daha uygun olduğu fikri ağır basıyor. Bunun nedeni ise mimari ve teknik kaygılara dayanmakta. Kişisel olarak haklılık payı olduğunu düşünüyorum, nitekim oldukça tartışmaya açık bir konu. Kanban’ın ikinci belirgin dezavantajı ise tanımlı aktivitelerinin olmaması ve geliştirme ekibine kimi zaman gereğinden fazla özgürlük tanıması! Bu nedenle Kanban uygulayan birçok takım, Scrum gibi metodolojilerin nesnelerinden faydalanıyor. Esas olarak, tam olmasa da (Sprints vs Continuous Flow), bu iki yöntemin tek bir pota da eritilmesi mümkün.
Scrumban, adında da anlaşılacağı gibi Scrum ve Kanban’ın birleşiminden oluşturulmuş hibrit bir metodoloji (Aslında iki metodolojinin belirli kurallar çerçevesinde birleşiyor olması o kadar hoşuma gitmiyor). Kanban’ın en önemli değeri olan WIP (Work in Process) limitlerini kabul ederken, ihtiyaç duyulduğu kadar gerçekleştirilen toplantılar (Planning, Review ve Retrospection) ile zamanı optimize kullanmayı hedefliyor. Tamamlanan (ve onaylanan) her geliştirmenin canlıya çıkması sayesinde DevOps/ Minimized Cycle Time hedefine bir adım daha yaklaşılıyor.
Konuyla ilgili Boğaziçi Üniversitesi’nde E. Zafer Güney ile gerçekleştirdiğimiz sunumu eklemek istedim. Sunum Scrumban/DevOps dönüşümü için değer odaklı bir dönüşüm yöntemi olarak geliştirmeye başladığımız “DevOps Tactical Adoption Theory” ile ilgili ön bilgilere de yer veriyor.