Denizyıldızı Retrospektif

Bestseller Denizyıldızı Retrospektif

Bu yazımda Bestseller ile Denizyıldızı Retrospektif tecrübemden bahsedeceğim. Bestseller, kurumdaki diğer Scrum Takımları’na bakışla küçük bir takım fakat Scrum yapabilmek için optimum kişi sayısına sahipler. Scrum Takımı’nın kaç kişiden oluştuğu önemlidir. Çünkü büyük takımlar(6 fazlası) iletişimi takip etmekte zorlanırlar ve şeffaflık bozulur. Bunun sonucunda süreçte iyileştirme yapmak zorlaşır. Süreçte iyileştirme yapamıyorsanız yerinizde sayıyorsunuz demektir. Yerinizde saymamak için iyileştirmeler yapmalısınız, iyileştirme yapabilmek için şeffaf ortamda doğru gözlem yapmalısınız. Bu nedenle Çevik ve Yalın yaklaşımlarda az çoktur anlayışı bulunur.

az çoktur

Çoğu zaman 1 + 1 < 2’dir. Çok nadir durumlarda 1 + 1 > 2 olabilir.

1+1+1+1+1+1+1+1+1 >= 9 olmaz. Neden? Çünkü takım olmak bireylerin yan yana oturması ve sabahları 15 dakika ayakta durarak dün ne yaptım, bugün ne yapacağım, önümde engel var mı, sorularını yanıtlamaları değildir.

Bu ne demek oluyor? Takım olmak 1+1>2 olmasıdır. Bunun içinde bireylerin birbirilerinin yaptıkları işleri takip edebilmeleri ve anlamaları gerekir. Günlük Scrum Toplantıları’nda dün ne yaptım sorusuna cevap veren bir Geliştirme Takımı üyesinin söyledikleri diğer üyeler tarafından anlaşılmıyorsa, bu topluluk bir takım değildir. Yan yana oturan insanlar topluluğudur. Bu konu üzerinde çok duruyorum çünkü büyük takımlar, takım olmanın önündeki en büyük engellerden biridir.

Denizyıldızı Retrospektif yazısına devam et

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

Scrum Toplantıları ve Ritüelleri

Bu yazıda hızlıca Scrum Toplantıları ve Ritülleri konusunda bilgi vereceğim. Scrum uygulayanların bazıları bu aktivitelere toplantı, bazıları ritüel, bazıları etkinlik bazıları sadece aktivite diyor. Scrum’ın iskeletini oluşturan bu aktivitelerde nelere dikkat etmek gerekiyor? Şimdi hep beraber hızlıca bakalım.

 

https://www.slideshare.net/cihanyilmaz88/scrum-toplantlar-ve-ritueller

Scrum Toplantıları ve Ritüelleri

  1. Scrum
  2. Deneycilik
    • Şeffaflık
    • Gözlem
    • Adaptasyon

Scrum Toplantıları

  1. Toplantılar
  2. Günlük Scrum
    • Toplantının birincil amacı Geliştirme Takımı’nın senkronize olmasıdır.
    • 15 dakikadan uzun sürmemelidir!
    • Toplantının ikincil amacı yapılan hatalı bir iş varsa Geliştirme Takımı tarafından bunun ortaya çıkarılmasıdır. Yani risk kontrolüdür.
    • Dün ne yaptım?
    • Bugün ne yapacağım?
    • Önümde engel var mı?
    • Geliştirme Takımı üyeleri yukarıdaki sorulara cevap vererek bilgi paylaşırlar.
  3. Sprint Planlama
    • Toplantının amacı; gelecek Sprint yapılacak işlerin planlamasını yapmaktır.
    • Sprint uzunluğunun %5’i kadar zamanda tamamlanmalıdır. 4 haftalık Sprint’lerde 8 saat…
    • NE ve NASIL bölümlerinden oluşur.
    • NE bölümünde Ürün Sahibi geliştirilmesini istediği iş maddelerini açıklar.
    • NASIL bölümünde Sprint İş Listesi oluşturulur.
    • Geliştirme Takımı üyeleri analiz ve tasarım yaparlar.
    • NASIL bölümüne Ürün Sahibi katılmak zorunda değildir.
    • Toplantının girdisi Ürün İş Listesi, çıktısı Sprint İş Listesi ve Sprint Hedefi’dir.
    • Geliştirme Takımı, aşağıdaki parametreleri göz önünde bulundurur ve maliyet verir.
      1. Belirsizlik
      2. Karmaşıklık
      3. Risk
      4. Efor
  4. Sprint Değerlendirme Toplantısı
    • Toplantının amacı geçen Sprint’te tamamlanan özellikleri Scrum Takımı dışındaki paydaşlarla paylaşmaktır.
    • Toplantıyı yöneten kişi Ürün Sahibi’dir.
    • Paydaşlar ve Geliştirme Takımı, Ürünü Sahibi tarafından davet edilir. 4 haftalık Sprint’lerde 4 saatle sınırlıdır.
    • Geliştirme Takımı üyeleri, bitirilen maddeleri açıklar ve gelen soruları cevaplandırır.
    • Geliştirme Takımı üyeleri, nelerin iyi gittiğini ve gitmediğini paylaşabilir, yaşanan problemlerin nasıl çözüleceğini anlatabilirler.
    • Paydaşlar geri bildirimde bulunur.
    • Süper Ürün Sahibi, bu toplantıda belli olur. Paydaşlardan gelen geri bildirimleri değerlendirir ve değerli olanları Ürün İş Listesi’ne ekler.
    • Sprint Değerlendirme Toplantısı, Sprint Planlama Toplantısı için önemli bir girdi sağlayabilir.
    • Gelecek Sprint’te yapılacak işlere kısaca değinilebilir.
  5. Sprint Retrospektif Toplantısı
    • Toplantının amacı, son Sprint’in Scrum Takımı için nasıl geçtiğini değerlendirmektir.
    • Scrum Takımı, takım dışındaki kişilerde dahil, kişileri, ilişkileri, süreçleri ve araçları değerlendirebilir.
    • 4 haftalık Sprint’lerde 3 saatle sınırlıdır.
    • Toplantının başında bir önceki Sprint Retrospektif Toplantısı’nda alınan aksiyon kararlarının yerine getirilip getirilmediğine bakılır.
    • Scrum Takımı uygun görüyorsa takım dışındaki paydaşları toplantıya davet edebilir. Scrum Takımı’nın işini yapış şeklinde değişiklikler için plan oluşturulur.
  6. Detaylandırma Aktiviteleri
    • İş Listesi Maddeleri oluşturulur ya da var olanlar detaylandırılır.
    • İş Listesi Maddeleri sıralanır.
    • İş Listesi Maddeleri’ne maliyet verilir.
    • Her zaman bir toplantı olmak zorunda değildir. Her türlü aktivite, iletişim detaylandırma için yararlı bir şekilde kullanılabilir.

Scrum Toplantıları’ndaki Pratikler

  1. İYİ PRATİKLER
    • Planlama Toplantısı’nın «NASIL YAPACAĞIZ» bölümünde kağıt, kalem, beyaz tahta, görselleştirme kullanılması
    • Planlama Toplantısına girmeden önce detaylandırma çalışmasının yapılmış olması
    • Planlama sonrası takımın, şeffaflığı artırmak için yapmayı taahhüt ettiği iş listesi maddelerini paydaşlarla paylaşıp Sprint ile ilgili bilgi vermesi
    • Doğru kapasite hesabı için planlanmayan ancak Sprint içersinde acil yapılan işlere Sprint sonunda ya da Günlük Scrum’da maliyet verilmesi
    • Geliştirme Takımı’nın işleri en fazla 8 ideal saat olarak bölmeye çalışması
    • Son retrospektif toplantısında konuşulan aksiyonların Sprint Planlama sırasında dikkate alınması
    • Planlama toplantısının başında, takımın metriklerini inceleyerek o Sprint’in performansını ve çıktılarını diğer Sprint’lerle karşılaştırması
    • Ürün İş Listesi maddelerinin INVEST(INDEPENDENT, NEGOTİABLE, VALUABLE, ESTİMABLE, SMALL, TESTABLE) formuna uygun hazırlanması
  2. KÖTÜ PRATİKLER
    • Toplantıların geç başlaması, geç bitmesi, toplantı tarihlerinin değiştirilmesi
    • Scrum Master’ın veya Ürün Sahibi’nin bazen proje yöneticisi gibi davranması ve takım üyelerine iş atama eğiliminde olması
    • Planlama toplantısında Ürün Sahibi’nin Geliştirme Takımını daha fazla iş almaya zorlaması
    • Ürün Sahibi’nin işlerin NASIL yapılacağına karışması
    • Ürün Sahibi’nin detaylandırılmamış ve planlamaya uygun olmayan Ürün İş Listesi maddeleriyle planlama toplantısına gelmesi
    • İşlerin analiz, kodlama, test gibi genel adımlara bölünmesi
  3. ENNNNN KÖTÜ PRATİKLER
    • Geliştirme Takımı’nın Sprint Planlama Toplantısı’nın “Nasıl Yapacağız” bölümünde detaylı analiz, tasarım yapmaması
    • Ürün İş Listesi maddelerinin;
      • Yeterince detaylandırılmamış olması
      • Öncelikli olmaması
      • Analiz, kodlama, test şeklinde Sprint’lere dağıtılması
      • Kabul kriterlerinin olmaması
      • Maliyetinin verilmemesi
      • Çok büyük ve genel yazılmış olması

Teşekkürler.

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

Teknik Borç Nedir?

Teknik Borç Nedir?

Bu makalede Teknik Borç Nedir, Teknik Borcun Türleri, Teknik Borcun Maliyeti ve Teknik Borcun Sonuçlarına değinmeye çalışacağım. Hikayemiz şöyle başlıyor. Üç arkadaş öğle yemeğinde konuşuyorlar:

– Sabah yazılım geliştirme ekibiyle toplantımız vardı. Bireysel kredi başvuru raporlarına iki yeni alan eklemelerini istedik. Bu iki alanı ne kadar zamanda teslim edecekler, biliyor musun?

– İki alan olduğuna göre arkadaşlarında keyifleri yerindeyse iki günde bitirirler herhalde.

– Ahahaha. Gerçekten yazılımcı olmak varmış. Adamlar yata yata para kazanıyorlar! Bütün gün bilgisayar başında otur ve hiçbir şey yapmadan dünyanın parasını kazan. İki alan için dört hafta süre verdiler desem ne dersin?

– Bu işe girmeliydik derim…

Teknik Borç Nedir? yazısına devam et