Kanban ve Scrum, İkisinin de En İyisini Yapmak
Kitabı çevirmemin iki nedeni var. Birinci neden Çeviklik ve Yalınlık konularında Türkçe kaynak eksikliğidir. İkinciyse Çevik Bildiri’de çoğu zaman dikkat edilmeyen, önemsenmeyen bir cümle, Çevik Bildiri’nin ilk cümlesidir. “Daha iyi yazılım geliştirme yollarını, uygulayarak ve başkalarının da uygulamasına yardım ederek, bu yolları ortaya çıkarmak…” Kanban ve Scrum öğrenildikçe daha fazla kullanılacaktır.
Kitaplarını okuduğum, konuşmalarını dinlediğim, seminerlerine katıldığım, videolarını izlediğim, Çeviklik ve Yalınlık topluluğuna inanılmaz katkıları bulunan insanlar var. Çeviklik’i ve Yalınlık’ı öğrenmemi sağladılar. Umarım bu kitapla birilerinin öğrenmelerine yardımcı olabilirim.
Çeviklikle tanışmam kaos halini alan işlerimizi düzene sokmak için neler yapabileceğimi düşünmekle başladı. Bir müşteri telefon ediyordu ve onun işlerini yapmaya başlıyorduk. Bir müşterinin talebini geliştirmeye çalışırken akışa* ulaşabildiğim çok az oluyordu. Bir şeyler geliştirmeye çalışırken daha büyük bir müşteriden baskı geliyorsa her şeyi bırakıp yangını söndürmeye çalışıyordum. On dakika içinde üç-dört farklı müşterinin projeleri arasında gidip geldiğim çok oldu. En sonunda hangisinin sesi en yüksek çıkıyorsa onunla ilgileniyordum. Bir düzen yoktu.
Dünya üzerinde bu sorunu yaşayan tek şirket olmadığımızı biliyordum. Araştırmaya başladığımda Çeviklik ve Scrum’la tanıştım. Çeviklik’in özü olan deneycilik felsefesiyle onbir yaşındayken kuzenimin verdiği felsefe kitapçığında tanışmıştım ve sevmiştim. Buna rağmen iş hayatımda uzun süre determinizmi savundum. Her şeyi önceden bilip planlayabileceğimi ve planı oluşturduktan sonra herhangi bir engelle karşılaşmayacağımı savunuyordum. Yazılım geliştiricinin müşteriyle iletişim halinde olmaması bunun yerine arada birilerinin olması ve yazılım geliştiricinin sadece kod yazması gerektiğini düşünüyordum. Belki o zaman müşterilerle fazla muhatap olmak işimden zevk almamı engellediği için böyle düşünüyordum.
Çeviklik’i anladıkça bir plan oluşturup sadece planı takip ederek başarılı olamayacağımı anladım ve müşteriyle her zaman iletişim halinde olmam gerektiğine karar verdim.
Kitapta göreceğiniz gibi Agile yerine Çevik sözcüğünü, Agility yerine Çeviklik sözcüğünü kullandım. Eğer Türkçe’de Scrum’ı ifade etmemizi sağlayacak bir sözcük olsaydı onu kullanırdım. Scrum, Rugby’de oyuncuların kafa kafaya verdikleri toplanma hareketidir. Türkçe’de bunu karşılayan bir ifade yok. Bu nedenle Scrum dedim. Kanban, Japonca görsel kart anlamına geliyor. Yine Türkçe’de bu şekilde ifade etmek anlamlı gelmiyor. Hâlbuki Çevik, Çeviklik İngilizce Agile’den çok daha güzel, okuyanın zihninde ışık yakıyor. Bu nedenle Türkçe’de anlamlı bir karşılığı olan bütün ifadeleri Türkçe karşılıklarıyla yazdım. Türkçe’ye çeviremediğim özel ifadeler için sizin aklınıza gelen bir şeyler olursa lütfen paylaşın.
Teşekkür
Yaptığım çevirilerde kullandığım Türkçe sözcükleri seçerken aslında ne kadar önemli bir iş yaptığımı hatırlatan ve yardımcı olan arkadaşım Mehmet Bozok’a teşekkür ederim. Kitap bittikten sonra ilk okuyan ve çeviriyle ilgili “anlamak için sadece bir defa okuyorum” gibi olumlu yorumlar yapan Âdem Topal’a çok teşekkür ederim. İngilizce waste ifadesinin yerine israf sözcüğünü kullanabilirdim, çok uzun sürede kullandım. Alper Tonga’nın Kanban; Evrimsel Değişim – S01E01 yazısını okuduktan israf sözcüğünün yerine çöp sözcüğünü kullanmaya başladım. Alper’in çöp sözcüğünü kullanmasının nedeni çöpün somut olarak bir varlık ifade etmesidir. Çöp, kötü kokusu, çirkin görüntüsü olan ve kurtulmamız gereken herşey olabilir. Bu tanımın yanında israf sözcüğü kulağa çok soyut geliyor. Bu soyut anlam aksiyon almamız için uyarıcı bir nitelik taşımıyor. Çöp ifadesini topluluğa kazandırdığı için Alper Tonga’ya teşekkür ederim.
Kitabı çevirirken yardım eden ve Türk Dili ve Edebiyatı dersini neden sevmediğimi hatırlatan ama sonsuz dikkatiyle bütün yanlışlarımı düzelten biricik kardeşim Ayşenur’a çok teşekkür ederim.
Bu kadarcık küçük bir kitapta bu kadar çok bilgi vermelerine rağmen okuyucuyu sıkmayan bir kitap yazdıkları için Henrik Kniberg ve Mattias Skarin, çok teşekkür ederim.
*Belki bütün işlerde akış vardır ama yazılım dünyasında çok daha önemlidir çünkü aklınızda binlerce şeyi tutmanız ve çok kısa zamanda hatırlamanız gerekir. Akış, sizi üst benliğe ulaştırabilir. Eğer yazılım geliştirici değilseniz şuan söylediklerim anlamsız geliyor olabilir, bir yazılım geliştiriciye sorun! ☺O, ne dediğimi biliyor.
Cihan Yılmaz
Ekim 2016 – İstanbul
Kanban ve Scrum, İkisinin de En İyisini Yapmak İçerik

Kitabı indirebileceğiniz bağlantı:
Çevirenin Önsözü
Mary Poppendieck’in Önsözü
David Anderson’un Önsözü
Giriş
Kitabın Amacı
Bölüm 1 – Kıyaslama
Özetle Scrum
Özetle Kanban
Scrum ve Kanban birbiriyle nasıl ilişkilidir?
Scrum ve Kanban, ikisi de süreç için bir araçtır
Araçları anlamak için kıyaslayın, yargılamak için değil
Hiçbir araç tam değildir, hiçbir araç mükemmel değildir
Scrum, Kanban’dan daha fazla kurala sahip
Kendinizi sadece bir araçla sınırlamayın!
Scrum rolleri belirler
Scrum’da iterasyonların süresi sabittir
Takım #1(Tek Ritim)
Takım #2(Üç Ritim)
Takım #3(Gelişen Olaylar Güdümlü)
Kanban, Çalışılan İşleri iş akışındaki adımlara göre, Scrum, Çalışılan İşleri iterasyon bazında sınırlandırır
İkisi de deneyseldir
Örnek: Kanban’da Çalışılan İşi Sınırlama Deneyi
Scrum, Sprint içindeki değişikliklere karşıdır
Scrum Duvarı her Sprint’te yeniden oluşturulur
Scrum’da çapraz fonksiyonel takımlar kuraldır
İş Maddeleri bir Sprint’e sığmak zorundadır
Scrum’da iş maddelerinin büyüklük tahmini ve takımın hızı önemlidir
Scrum ve Kanban aynı anda birçok ürün üzerinde çalışmaya izin verir
Scrum ve Kanban, ikisi de Yalın ve Çevik’tir
Küçük farklar
Scrum’da önceliklendirilmiş İş Listesi kuraldır
Scrum’da günlük toplantılar kuraldır
Scrum’da burndown grafikler kuraldır
Scrum Duvarı, Kanban Duvarı’na karşı
Tek parça akış
Kanban’da Bir Gün
Kanban Duvarı bu şekilde olmak zorunda mı?
Kanban Duvarı’mızda hangi kolonlar olmalı?
Kanban Duvarı’mızdaki kolonların limitleri kaç olmalı?
Kanban limitleri ne kadar katı olmalı?
Bölüm 2 – Durum Çalışması
Gerçek Hayatta Kanban
Operasyonel İşlerin Doğası
Neden değişim?
Nereden başladık?
Geliştirme açısından operasyonun görünümü
Operasyon açısından geliştirmenin görünümü
Başlarken
Takımlar başlarken
Atölye çalışması
Paydaşlara hitap
İlk Duvarın Oluşturulması
İlk Kanban Modeli
Resimdeki Satırlar
İlk Çalışılan İş limitini belirleme
Çalışılan İş limitine saygı gösterme
Duvarda konuşma
Taşma bölümünün belirlenmesi
Hangi işler Duvar’da
İşlerin büyüklüğünü nasıl verdik?
Tahmin edilen büyüklük ne demek? Teslim süresi mi, çalışma zamanı mı?
İşleri nasıl yaptık?
Günlük toplantılar
İterasyon planlama
İşe yarar bir planlama çalışması bulmak
Bir hikaye
Planlamanın yeniden keşfi
Yaklaşım 1 – Değiştirmek ve yeniden gözden geçirmek
Yaklaşım 2 – Uzmanlar gözden geçirir ve sonra tahmin yapılır
Neyi ölçmeli?
Değişim nasıl başladı?
Önceden
Sonradan
Olgunluğun oluşması
Çalışılan İş düşerken kısıtlar ortaya çıkar
Kanban Duvarı zamanla değişecektir, duvar tasarımınızı taşı oyarak yapmayın
Denemekten ve başarısız olmaktan korkmayın
Retrospektifle başlayın!
Deney yapmaktan vazgeçmeyin!
Yazarlar Hakkında
Henrik Kniberg
Mattias Skarin
Cihanım yazdıklarının hepsini okuyamasam da yaptıklarını imrenerek takip ediyorum. Bundan 10 yıl önce deselerdi ki Cihan Türkiye’de yaygınlaşmaya başlayan bir stratejinin en büyük kaynak sahiplerinden ve sahiplenicilerinden biri olacak diye bir tebessüm eder top varsa basketbol oynayalım der konuyu kapatırdım😊 Allah başarını daim etsin
🙂 Teşekkürler Halil Abi. Şimdi hayatımda bir özlem, bir eksik basketbol! Umarım o günlere döneriz 🙂