Tag Archives: Scrum Master

Çevik Yaklaşımlarda İşin Maliyetini Belirleme

Çevik Yaklaşımlarda İşin Maliyetini Belirleme

İki Aziz Nesin Hikayesi

Bu yazı dizisinde Çevik Yaklaşımlarda İşin Maliyetini Belirleme konusunu ele alacağım. Geliştirilecek bir işlevselliğin veya bir projenin maliyetinin belirlenmesi(yapılacak işin büyüklüğünü belirleme) işinin nasıl gerçekleştirilebileceğine, iyi pratiklere, maliyet vermenin maliyetine, tahmin işinin ne kadar gerekli olduğuna değineceğiz. Ayrıca geleneksel proje yönetimini kullanan organizasyonlarda karşılaştığım birkaç örneği paylaşacağım.

İşlevselliklerin ya da projelerin maliyeti belirlenirken birkaç yaklaşım dikkatimi çeker.

  1. Üst yönetim bunun için herhangi bir bitiş tarihi belirledi mi? Sanki üst yönetimdeki kişiler bu projeyi geliştirecek! Tarihi bu kişiler belirlerse işi gerçekleştiren kişiler daha hızlı üretme yetkinliğine kavuşacak gibi-evet, evet…pazara çıkış zamanı vb. şeyleri aklınıza getirdiğinizi biliyorum-… Belki tarih belirlenebilir fakat takımdaki kişilerin görüşleri alındıktan sonra gerçekçi bir tahmin yapılarak.
  2. Teknik lider ya da mimar olan kişilerden işin büyüklüğü bilgisi istenir. Araştırılmadan ve tahmin yapabilecek kadar bilgi sahibi olunmadan bu soruya cevaplar dönülür.

 

Aziz Nesin hikayesi olabileceğini düşündüğüm birkaç örneği paylaşmak istiyorum. Continue reading Çevik Yaklaşımlarda İşin Maliyetini Belirleme

Büyük Takımlar mı Küçük Takımlar mı

Büyük Takımlar mı Küçük Takımlar mı?

Neden “Büyük Takımlar mı, Küçük Takımlar mı” konusunu seçtim?

 

  • Her gün bir takım içinde, ailemizden çok iş yerinde zaman harcıyoruz. Bu nedenle çok önemli bir konu olduğunu düşünüyorum.
  • Çünkü farkında olmadığımız, gizli bir sorun olduğunu düşünüyorum.

 

Farkındalık yaratmak amacıyla bu konuyu seçtim. Amacım yapılan araştırmaları ve deneyimleri aktarmak.

 

Jeff Bezos’a göre iki pizza ile doyan bir takım ideal büyüklükte bir takımdır. Bu mecazın altında aslında oldukça değerli deneyimler ve bilgiler yatmaktadır. Hadi şimdi takımların yaşadıklarına bakalım!

 

İletişimin Bedeli

Richard Hackman, Yale Üniversitesi’nde, 20 yıl sonra da Harvard Üniversitesi’nde profesörlük yaptı. Richard Hackman bir toplum bilimciydi ve hayatını, takım performansı, etkili liderlik ve kendi kendini yöneten takımlar ve organizasyonlar üzerine araştırmalara adamıştır.
Richard Hackman takımlar arasındaki iletişim yolunu hesaplamak için aşağıdaki formülü belirlemiştir: Continue reading Büyük Takımlar mı Küçük Takımlar mı

Bestseller ile Deniz Yıldızı Retrospektif

Bestseller ile Deniz Yıldızı Retrospektif

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.

Continue reading Bestseller ile Deniz Yıldızı Retrospektif

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