Kategori arşivi: Lean

Siperden Yalınlık Kanban ile Büyük Ölçekli Projelerin Yönetimi

Siperden Yalınlık Kanban ile Büyük Ölçekli Projelerin Yönetimi

Çevirenin Önsözü

Kanban ile büyük ölçekli projeler kitabını çevirmemin nedeni Türkçe kaynak sayısının azlığıdır. Henrik Kniberg’in yazdığı kitaplar gerçekten çok değerli çünkü yaşadıklarını yazıyor, çok sade bir dille açıklıyor. Çeviklik ve Yalınlık gibi üzerine düzinelerce kitaplar yazılmış konuları en güzel haliyle birkaç cümle de anlatıyor. Yazar olarak Henrik birçok ünlü yazarda olmayan bir özelliğe sahip: Yazdıklarını net bir şekilde okuyanın zihninde oluşturabilme yeteneği. Bu özellik Henrik’i diğerlerinden birkaç on adım ileri götürüyor.

Çeviriyi yaparken bir ifadenin Türkçe’de karşılığı varsa bunu kullandım. Örneğin Agile yerine Çevik ifadesini kullandım. Eğer ifadenin Türkçe’de tam karşılığı yoksa ya da Türkçe karşılığı isteneni tam olarak ifade edemiyorsa İngilizce sözcüğü kullandım. Örneğin kaynak kodlarının bulunduğu ortam için trunk ifadesini kullandım çünkü trunk ifadesinin Türkçe’de bir karşılığını bulamadım. Eğer bu ifadeler için önerileriniz olursa lütfen bana yazın ve gerekli iyileştirmeleri beraber yapalım.

Kitabı çevirirken yardım eden ve Türk Dili ve Edebiyatı dersini neden sevmediğimi hatırlatan ama dikkatiyle bütün yanlışlarımı düzelten  Ayşenur Yılmaz’a çok teşekkür ederim.

Cihan YILMAZ

Aralık 2016 – İstanbul
site@yilmazcihan.com
http://yilmazcihan.com

Siperden Yalınlık Kanban ile Büyük Ölçekli Projelerin Yönetimi
Siperden Yalınlık Kanban ile Büyük Ölçekli Projelerin Yönetimi

Kitabı indirebileceğiniz bağlantı:

Siperden Yalınlık Kanban ile Büyük Ölçekli Projelerin Yönetimi yazısına devam et

Kanban ve Scrum, İkisinin de En İyisini Yapmak

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

site@yilmazcihan.com

Kanban ve Scrum, İkisinin de En İyisini Yapmak yazısına devam et

Çeviklikte Gözlem ve Adaptasyon Ne Zaman Kullanılır?

Çeviklikte Gözlem ve Adaptasyon Ne Zaman Kullanılır?

Kurumsal Geçiş Takımı’yla gözlem ve adaptasyonu basit durumlarda kullanmak gayet mantıklı bir yaklaşımdır. Sonuçta bu değişim çabası çok zahmetlidir, bu uygulandıktan sonra daha güçlü olan dönüşüm yaklaşımı düşünülmelidir.

ADAPT

ADAPT, Scrum’ın benimsenmesi için Mike Cohn’un modelidir.

  • Awareness – Farkındalık – içinde bulunulan sürecin kabul edilebilir sonuçlar üretmediğinin farkında olmak.
  • Desire – İstek – Var olan problemlerin adreslenmesi için Scrum’ı benimseme isteği.
  • Ability – Yetenek – Scrum ile başarılı olabilmek için gerekli yetenek.
  • Promotion – Tanıtım – Scrum deneyimlerimizi paylaşarak hem bizim bunu hatırlamamız hem başkalarının bizim başarımızı görmesini sağlamak.
  • Transfer – Aktarım – Scrum’ı kullanmanın etkilerinin şirketin bütün bölümlerine aktarılması.

Daha fazla bilgi için Mike Cohn’un kitabına ya da sunumuna bakabilirsiniz[Cohn – “Succeeding with Agile” – Chapter 2] [Cohn – “Adapting to Agile Keynote”].

Çeviklikte Gözlem ve Adaptasyon Ne Zaman Kullanılır? yazısına devam et

Çevikliği Benimseme ve Çevik Dönüşüm

Destekleyici Kültürde Çevikliği Benimseme ve Çevik Dönüşüm

Bu yazının amacı Çevikliği Benimseme ve Çevik Dönüşüm konularını netleştirmektir. Bu bölümde baskın kültürlerin İş birliği ve Usta-Çıraklık -ve belkide eXtreme Programming için Yetkinlik- olduğu destekleyici kültürde Çevikliği benimseme ve Çevik olmanın ne olduğunu göreceğiz.  Bu bölümde anlatılacak fikirler ve yaklaşımlar Kanban ve Yazılım Ustalığı’na da uygulanabilir. Çeviklik, bu bölümün anahtar fikirlerini göstermek için kullanılacaktır.

Önceden konuştuğumuz gibi Schneider Kültür Modeli organizasyondaki baskın kültürün hangi kültür olduğunu görmemizi sağlar. Çeviklik anlayışının kültür tarafından tamamıyla desteklendiği varsayımıyla basit bir şekilde Çevik Pratikleri benimseme yaklaşımı naif bir görüştür. Maalesef durum bir şekilde bundan daha karmaşıktır. Böyle bir durumda Schneider Kültür Modeli hangi senaryoda olduğumuzu anlamamıza yardım eder fakat ileri bir rehberlik sağlamaz.

Organizasyonel Kültür ve Liderlik’te(In Organizational Culture and Leadership), Schein şunu iddia eder, “kültürün yüzeysel modellerini görmezden gelmeliyiz ve daha derin ve karmaşık antropolojik modeller oluşturmalıyız”[Schein, p.14]. Kültürü birçok farklı boyutta ele alır, örneğin; adetler, gelenek, grup normları, benimsenen değerler, resmi felsefe, oyunun kuralları, kök mecazlar vb. Çevikliği Benimseme ve Çevik Dönüşüm yazısına devam et

Karar Almada Ortamın Önemi

Karar Almada Ortamın Önemi

Bu makalede karar almada ortamın önemini anlatacağım. Bugün izlediğim bir futbol maçında dikkatimi çeken bir forvet oyuncusu bulunuyordu. Bu oyuncu takımının yakaladığı fırsatları bir bir harcadı. Kale önünde, altı pas içinde topu kaleciye nişanladı, çektiği şutlar defans oyuncularına çarptı, verdiği paslar arkadaşlarına ulaşmadan rakipler tarafından kapıldı. Maçın bir bölümünde rakip takım korner kullandı. Kornerden dönen top, kornerin kullanıldığı köşeye geri dönerken bizim ünlü forvetimiz rakip takımdan birini takip ediyordu. O anda bu topun dönüp gol olacağını düşündüm. Çünkü bu adam tam bir başarısızlık abidesiydi ve ne yapsa takımına negatif bir şekilde geri dönüyordu. Eminim demek istemiyorum ama rakibi takip etmese ve rakip boş bir pozisyonda orta yapsa bence gol olmayacaktı. Bu topun gol olması rakibin şansı bizim forvetimizin şanssızlığı değildi. Buna eminim.

Bizim forvetimiz dışarıdan bakıldığından elinden geleni yapıyor, çok çalışıyor, canını dişine takmış ve her şeyini veriyor gibi görünüyor. Tek bir şey dışında bunları yaparken doğru yolu izlemiyor. Çünkü doğru kararlar veremiyor. Dahil olduğu her pozisyonda işleri daha da karmaşık hale getiriyor ve bunun sonucu da takımına olumsuz olarak geri dönüyor.

Bunları neden anlattım? Çünkü yazılım projelerinde görev alanlarda benzer yaklaşımı sergiliyor. Tabi kişinin sahip olduğu role göre yaptığı etkide ortamda farklı oranda değişikliklere neden oluyor. Örneğin bir futbolcu hata yaptığında bu çok önemli olmayabilir ve hatadan geri dönülebilir. Hatalı bir pas verip topu rakibe kaptırabilir. Biraz sonra topu rakipten geri alabilir ve bu, çok büyük bir sorun olmayabilir. Bu tıpkı bir yazılımcının test senaryoları üzerinden geçerken birini atlaması gibi. Fakat teknik direktör maçı kaybederken ve gol atması gerekirken bir forvet çıkarıp bir savunma oyuncusu alıyorsa çok ciddi sıkıntılar var demektir. Bırakın oyunu okumayı bu teknik direktör skor tabelasını bile okuyamıyor diyebiliriz. Bir projenin planlamasında ya da ilerlemesinden sorumlu kişilerin aldığı aksiyonlarda benzerdir. Bu adam ne yaptığını bilmiyor dediğiniz olmuştur. Karar Almada Ortamın Önemi yazısına devam et