Tag Archives: Enterprise Agility Transformation

Ç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

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

Çevik Yazılım Geliştirmede Verimi Artırma – Çok Görevlilik, Görev Değiştirme ve İçerik Değişikliği

Çevik Yazılım Geliştirmede Verimi Artırma – Çok Görevlilik, Görev Değiştirme ve İçerik Değişikliği

 

Bu yazının amacı çalışırken verimimizi düşüren durumlar olan Çok Görevlilik, Görev Değiştirme ve İçerik Değişikliği’ni net bir şekilde anlatabilmektir. Çok Görevlilik, Görev Değiştirme ve İçerik Değişikliği üç terimde sıkça birbirinin yerine kullanılmaktadır. Anlatılmak istenen aynı ya da benzer konularda olsa birbirinin yerine kullanılan bu terimleri anlamanın doğru olacağını düşünüyorum. Umarım yazının sonunda hem bu kavramları net bir şekilde anlamış olacağız hem de verimliliğimizi düşüren bu durumların farkına varıp bireysel gelişimimiz için aksiyonlar alabilir olacağız.

Continue reading Çevik Yazılım Geliştirmede Verimi Artırma – Çok Görevlilik, Görev Değiştirme ve İçerik Değişikliği

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