Hangi Çevik Yöntem Daha İyidir?

Elif Hilal Ersoy
Oyun ve Uygulama Akademisi
5 min readMar 19, 2022

“Nedir Bu Çeviklik?” yazısında çeviklik kavramına, çıkış noktasına, çeviklik ilkelerine ve uygulamalarına giriş yapmıştık şimdi çevik yaklaşımlar içerisinde hangi yöntem daha iyidir, sizlerle onu tartışacağız :)

Scrum vs Kanban

Çevik yaklaşımlar içerisinde birden fazla araç ve yöntem vardır. Birden fazla araç ve yöntem olmasının mantığı yazı yazmak için hangi kalem daha iyidir mantığı ile aynıdır, içinde bulunacağımız duruma bağlıdır. Farklı yöntemler çevikliği nasıl bir yolda ve sınırlar içerisinde olacağını gösterir. Örneğin Scrum kural olarak süresi önceden belirli ve sınırlı olan geliştirme zamanı yani sprintler ve çapraz fonksiyonlu takımlar ile çalışmayı öğütler. Kanban ise görsel panolar kullanmayı ve aynı anda üzerinde çalıştığınız iş sayısını kısıtlamayı önerir. Yöntemlerin önerdikleri şeyleri anlamak ve elimizdeki duruma göre doğru araçları seçmek başarılı olmanıza yardım edebilir.

Kanban nedir? Kanban Japoncada görsel kart anlamına gelmekte olup ilk kez yalın üretim felsefesi içerisinde ortaya çıkmıştır. Genel olarak üretim ve malzeme akışında kullanılan neyi, ne zaman, ne kadar? üreteceklerini ve nereye göndereceklerini söyleyen üretim yönetim aracıdır. Üretimde kullanılan bu araç, çevik değer ve prensiplerle harmanlanarak bir çevik yöntem haline getirilmiştir. İlk olarak 2004 yılında Microsoft da kullanılmıştır. Üzerinde çalışılan iş sayısı (yani working progressive biz ona kısaca wip diyelim) limitlenmelidir ve bu limite ulaşıldığında yani başlanan işler bitmeden yeni bir işe başlanmamalıdır. Kanban proje yönetim şeklini değiştiren bir yaklaşım olmuştur ve var olan bir sürecin aşamalı olarak evrimleşmesini desteklemiştir. Bu evrim çeviklik ve yalınlık değerleri ile uyumludur. İnsanların çalışma düzenlerinde tek seferde büyük bir değişim olmasını istemez, bunun yerine aşamalı bir şekilde değişimi teşvik eder. Değişime neden ihtiyaç olduğu bilgisi hem çalışanlar hem de yöneticiler tarafından anlaşılmalı ve değişim için fikir birliğine varılmış olması gerekmektedir. Kanban ile başlangıç yapmak isteyen bir takımın ilk yapması gereken şey, iş sürecini görselleştirmek olmalıdır. Süreç içerisindeki işleri küçük ve anlamlı parçalara bölmek gerekmektedir. İş parçaları dijital yada fiziksel kartlara yazılabilir sonrasında iş parçasının iş akışında durumunu görmek için dijital yada fiziksel pano yardımı ile görselleştirilmelidir. Görselleştirme işini yaparken panoyu kolonlara bölebilir her bir kolona isim verebilirsiniz. Kolonlarda yer alan isimler iş akışındaki adımlar olmalıdır. Adım adım ilerlediğimizi düşünelim;

  • İlk adım, kendi iş akışınız neyse onu olduğu halde görselleştirmek,
  • İkinci adım, wip limitlemek yani her adımda aynı anda kaç iş olur ona karar vermek, (ilgili adımda wip ulaşıldığı anda kendinden önceki adımda iş parçacığı çekilemez..)
  • Üçüncü adım, teslim süresini ölçmek ve iyileştirmeye çalışmak. Teslim süresi demek parça işin teslim süresidir. Tahminlenebilir hale gelebilir yada kısıtlamak için değişiklikler yapabilirsiniz. Problemler ile ilgili aksiyonlar alarak süreci iyileştirebilirsiniz.

Kanban size sadece başlangıç verir ve özgür bırakır..

Scrum nedir? Scrum’a genel bir bakış atacak olursak scrum bir çerçevedir. Adım adım size ne yapmanız gerektiğini söylemez. Scrum’ı güçlü kılan onu içerisinde bulunduğunuz belirli durumlara göre adapte edebilirsiniz. Hem scrum hem kanban adaptif yöntemlerdir diyebiliriz yani kural sayısı azdır. Bakıldığında göreceli olarak scrum kanbana göre daha fazla kurala sahiptir. Scrum size kanbandan daha fazla kısıt ve takip etmeniz gereken daha fazla kural verir. Bu nedenle sizi kanbana göre daha fazla kısıtlar. Örneğin, süresi belli döngüler scrumda bir kuralken kanban da bu kural değildir.

Scrum 3 tane rol, 3 tane eser, 5 tane etkinlik ve bunları birbirine bağlayan bazı kurallar içermektedir. Scrum bu hali ile bir çerçeve olarak tanımlanmıştır. Bu çerçevede bahsedilen 3 adet rol vardır bu rollere sahip üyeler scrum takımını oluşturur. Bu roller; Product Owner (ürün sahibi), Developer Team (yazılım ekibi) ve Scrum Master (scrum uzmanı) olarak tanımlanmıştır. Scrum takımının içerdiği rolleri ve sorumluluklarını anlamak için kullanabileceğimiz 3 adresleme yöntemi düşünebiliriz. Bunlar;

Doğru ürünü yapmak (Product Owner rolüne adreslenmiştir.) Product Owner sorumluluğu ürünün vizyonunu tanımlamak, ürün ile ilgili yapılacakların bir öncelik sıralamasını belirlemek ve değeri göz önünde bulundurarak geliştirme takımının hangi iş parçacıkları üzerinde çalışacağına karar vermektir. Tek başına bu kararları vermek elbette kolay değildir böyle durumlarda paydaşlar ile görüşerek ürünü daha iyi anlamaya çalışır ve doğru bir ürün geliştirmek için ürün iş listesi hazırlar.

Bu ürünü doğru bir şekilde yapmak (Developer Team rolüne adreslenmiştir.) Ürünün ortaya çıkması için yapılması gerekenlerin, görevlerin icra edilmesidir. Developer team, Product Owner’ın getirdiği fikirleri hayata geçiren, can veren ekiptir.

Söz konusu ürünü hızlı yapmak (Scrum Master rolüne adreslenmiştir) İcrayı gerçekleştiren takımın işi yaparken karşılaştığı bir takım engeller varsa o engeli kaldırmasını sağar, scrumı en iyi bilen kişi olarak scrum çerçevesini düzgün şekilde kullanılması, kuralların takibini sağlamak ile görevlidir.

Product Owner doğru görevler için doğru aksiyonlar alırsa ve iştirakler ile iyi bir iş listesi ortaya çıkarırsa, ürün iş listesinde doğru bir sıralama yaparsa, developer team kaliteyi göz önünde bulundurarak ürünün içinde defectler (hatalar) oluşmadan üretimi yapabilirse, bu süreci scrum master desteklerse, bu 3 rol dengede tutularak ürün ortaya çıkarılırsa, scrum yapısına gelinmiş demektir.

Scrum’ın 3 eseri vardır. Product Backlog, Sprint Backlog ve Increment.

  • Product Backlog (ürün iş listesidir) Product Owner ile yakın ilişkili eserdir. Ürün sahibi yani Product Owner paydaşlar ile yapmış olduğu görüşmeler sonrası ürüne eklenmesi gereken her türlü yeni özelliği yada her tür değişikliği içeren ürün ile alakalı bir iş listesidir. Ürün ile alakalı her şeyi içeren makro plandır. Geleneksel iş listesinden farkı önceliklendirilmiş olmasıdır. Product Owner tarafından hazırlanır, önceliklendirme önemlidir, öncelik sırasına göre çalışmalar geliştirilir.
  • Sprint Backlog (sprint iş listesi) Developer Team ile ilişkili eserdir. Önündeki döngü süresi içinde yapılacak (en az 1 en çok 4 haftalık döngü sürelerine sprint denilir), Product Backlog içerisinden seçilen öncelikli işler ile alakalı ne yapıyoruz, nasıl bir icra planı var bunu gösteren eserdir. Developer team işi yapan insanlardır ve bu planı güncel tutmaktan sorumlulardır.
  • Increment (ürün parçası) Üzerinde çalışılan ürünün küçük, değerli ve anlamlı bir parçasını teslim etmek demektir.

Scrum özellikle her döngü sonunda, çalışır durumda bir ürün parçasını yani müşteri için anlamlı ve bir memnuniyet sağlamalıdır.

Scrum’ın kendisine ait bir kılavuzu vardır . Scrum’ı ortaya çıkaran kişiler tarafından yazılan ve hala güncellenmeye devam eden bir metindir. Kılavuz scrumı anlamak isteyen kişiler için eserlerin başında geliyor. www.scrumguides.org inceleyebilir ve scrum konusunda derinlemesine bir bilgilendirme alabilirsiniz. Yine www.scrum.org sitesi üzerinden de scrum hakkında okuma metaryelleri mevcut. Bu iki siteyi ziyaret ederek Scrum ile ilgili bilgilerinizi arttırabilirsiniz.

Genel tabirleri ile günümüzde yaygın olarak kullanılan “Kanban” ve “Scrum” Çevik yaklaşımlarını açıklamaya ve karşılaştırma yöntemi ile anlatmaya çalıştım.

Sonraki yazılarda görüşmek üzere.. :)

--

--