Category Archives: Enterprise Agility Transformation

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ü

Kitabı ç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 sonsuz dikkatiyle bütün yanlışlarımı düzelten biricik kardeşim Ayşenur’a çok teşekkür ederim.

Cihan YILMAZ

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

Kitabı indirebileceğiniz bağlantı: Siperden Yalınlık Kanban ile Büyük Ölçekli Projelerin Yönetimi (129 downloads)

 

 

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

 

 

Kanban ve Scrum, İkisinin de En İyisini Yapmak

Kanban ve Scrum, İkisinin de En İyisini Yapmak

 

Kanban ve Scrum, İkisininde En İyisini Yapmak

 

Kitabı indirebileceğiniz bağlantı: Kanban ve Scrum, İkisinin de En İyisini Yapmak (120 downloads)

 

Kanban ve Scrum,  İkisinin de En İyisini Yapmak

Çevirenin Önsözü

Mary Poppendieck’in Önsözü

David Anderson’un Önsözü

Giriş

Kitabın Amacı

Bölüm 1 – Kıyaslama

Scrum ve Kanban Nedir?

Ö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ı?

Scrum ve Kanban benzerlikler

Scrum ve Kanban farklılıklar

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

Continue reading Kanban ve Scrum, İkisinin de En İyisini Yapmak

Scrum Roller ve Sorumluluklar

Scrum Roller ve Sorumluluklar

 

Bu sunumda sizlere Scrum Roller ve Sorumluluklar nelerdir konusunu özetlemeye çalışacağım. Makaleyse daha derin ve gerçek hayattan bilgiler isteyenler için yazıldı.

Scrum, felsefe olarak deneyciliğe dayanır. Scrum’ın doğru şekilde işleyebilmesi için Şeffaflık, Gözlem ve Adaptasyon olmalıdır.

Scrum’da üç rol bulunur. Bu roller, Ürün Sahibi, Geliştirme Takımı ve Scrum Master’dır. Şimdi bu üç rolün sahip olduğu sorumluluk nelerdir konusuna değineceğim.

 

Ürün Sahibi

İş Listesini yönetir. Birincil önceliği İş Listesi’ni yönetmektir. İş Listesi’ni yönetmek demek, ürünü yönetmek demektir. Ürünle ilgili yapılacak bütün geliştirme İş Listesi’nde bulunur. Ürün Sahibi, İş Listesi’ni yönetirken şunlara dikkat eder:

  • Yatırım Getirisi
  • Risk
  • İş Değeri
  • Teknoloji

İş Listesi’nin sahibi Ürün Sahibi’dir. İş Listesi herkes tarafından erişilebilir ve anlaşılabilir olmalıdır. Continue reading Scrum Roller ve Sorumluluklar

Winston Royce & Waterfall & Çeviklik

Winston Royce & Waterfall & Çeviklik

Geleneksel yazılım geliştirme metodunun babası Winston W. Royce, yazılım geliştirme alanında öncü olarak kabul edilir. California Institute of Technology’de Fizik Bölümü’nde lisans öğrenimini tamamladıktan sonra yine aynı enstitüde Havacılık Mühendisliği üzerine yüksek lisans yapmıştır. Julian David Cole’un gözetiminde yine Havacılık Mühendisliği alanında doktorasını tamamlamıştır. 1961 yılında ise ünlü otomotiv şirketi TRW’de çalışmaya başlamıştır. TRW, Türkiye’de otomotiv alanında bilinsede aslında havacılık üzerine de çalışmaları bulunmaktadır. Royce, TRW şirketinin havacılık ile ilgili geliştirmeler yapılan bölümünde proje yöneticisi olarak çalışmıştır. Bu dönemde yazılım projelerinin nasıl daha kolay, daha kaliteli ve daha ucuz geliştirilebileceğine dair çalışmalar yürütmüştür. Bu çalışmaları yürütürken akademik yaklaşımını sergilemiş ve yaptığı çalışmaları anlattığı “Managing The Development Of Large Software Systems” adlı makaleyi 1970 yılında yayınlamıştır. Royce’un makalesi yazılım ürünlerinin geliştirilmesi süreçlerine tarihteki en büyük etkiyi yapmıştır ve bu etki günümüzde de devam etmektedir.

 

Winston Royce makalesinde açıkladığı yaklaşımlara herhangi bir isim vermemiştir. En basit haliyle bugün Waterfall dediğimiz metoda “basit” diyordu. 1976 yılında Bell ve Thayer adında iki TRW çalışanı “Software Requirements : Are They Really A Problem?” adında yayınladıkları makalelerinde Waterfall terimini ilk defa kullanmışlardır.
Royce’un makalesi incelendiğinde görülür ki sadece Waterfall -Royce’un deyimiyle basit– olarak bilinen modelden bahsetmez aynı zamanda artımlı ve modelleme yaklaşımlarını da anlatır. Sanırım artımlı ve modelleme yaklaşımlarını Waterfall’ın altında anlatması ve Waterfall’ın bunlara nazaran daha kolay bir sürece ve bakıldığında daha anlaşılır bir şekle sahip olması Waterfall’ın benimsenmesini kolaylaştırmış ve günümüze kadar gelmesini sağlamıştır. Artımlı ve modelleme yaklaşımlarını anlatırken Waterfall modeliyle ilgili problemlerin çözümünü aradığını görürüz. Bu amaçla modelleme yaklaşımında analiz aşamasından önce adına “Preliminary Program Design” dediği bir aşama koymuş ve burada projenin bir modelinin yapılması gerektiğini söylemiştir. Artımlı yaklaşımda ise yine Preliminary Program Design aşamasını koymuş ve bundan sonra gelen her aşamada aslında sürecin tekrarlanmasını savunmuştur. Bu yaklaşım günümüzdeki iterasyon bazlı geliştirme yaklaşımının temeli olmuştur. Continue reading Winston Royce & Waterfall & Çeviklik

Ç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”].

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