Category Archives: Extreme Programming

Çevik Yaklaşımlarda İşin Maliyetini Belirleme 3

Çevik Yaklaşımlarda İşin Maliyetini Belirleme 3

Planning Poker

Çevik yaklaşımlarda işin maliyetini belirleme konulu yazı serisinin üçüncü bölümünde Scrum, eXtreme Programming ve Kanban takımlarında kullanılan Planning Poker(Planlama Pokeri) konusunu anlatacağım. Planning Poker, Çevik Bildiri’ye imza atan 17 kişiden biri olan James Grenning tarafından geliştirilmiştir. Bir eXtreme Programming tekniğidir. Scrum uygulayanlar tarafından faydalı bulunup Sprint ve Release planlamasında kullanılmaktadır. Planning Poker, uzman görüşünü, benzeşimi –karşılaştırmayı- ve küçük parçalara bölmeyi eğlenceli bir şekilde bir araya getirmiştir.

Continue reading Çevik Yaklaşımlarda İşin Maliyetini Belirleme 3

Çevik Yaklaşımlarda İşin Maliyetini Belirleme 2

Çevik Yaklaşımlarda İşin Maliyetini Belirleme

Maliyet Belirleme Teknikleri

Çevik Yaklaşımlarda İşin Maliyetini Belirleme yazı serisinin bu bölümünde farklı maliyet belirleme tekniklerine değineceğim. Bu teknikler, uzman görüşü, benzeşim(karşılaştırma), küçük parçalara bölme teknikleridir. Yapılan araştırmalardan ve araştırmaların sonuçlarından bahsedeceğim.

Uzman Görüşü

Uzman görüşüyle anlatılmak istenen yıllarca sözde çalışarak elde edilen tecrübeden kaynaklanan uzmanlık değildir. İşi geliştiren kişinin uzmanlığıdır. Yazı serisinin ilk bölümündeki örneği hatırlarsanız, evet takım lideri, geliştiriciden çok daha tecrübeli biri fakat geliştirici, geliştirdiği konuyla ilgili yaşanan sıkıntıları, karşılaşılabilecek problemleri, önüne çıkabilecek engelleri en iyi bilen kişidir. Kendi hızını da en iyi geliştirici biliyor dolayısıyla doğruya en yakın tahmini yapabilecek uzman kişi işi yapan kişidir.

Benzeşim

Diğer bir yaklaşım ise benzeşim ya da karşılaştırma da diyebileceğimiz tekniktir. Bu teknikte tahmini yapacak kişi kullanıcı hikayelerini karşılaştırarak şunu söyler: Continue reading Çevik Yaklaşımlarda İşin Maliyetini Belirleme 2

Çevik Yazılım Geliştirmede Risk

Çevik Yazılım Geliştirmede Risk

Bu konu üzerine birçok araştırma yaptım. Ne yazık ki paylaşabileceğim ya da bana birşeyler katabileceğini düşündüğüm bir paylaşım bulamadım. Bu, Çevik Topluluğu için büyük bir kayıp. Özellikle geleneksel yöntemle proje geliştirenlerin savunduğu; “Çevik yaklaşımlar içinde risk yönetimi bulunmuyor; bu nedenle kullananların canı çok yanıyor!” iddialarına cevap niteliğinde birkaç yazı bulurum diye düşünüyordum.

 

Çeviklik hakkında bilgi edinmeye başladığınız ilk dönemlerde Çevikliğin değişen ortama adapte olmak ve değişime hızlıca cevap vermek olduğunu öğrenirsiniz. Derinlere inmeye başladığınızdaysa Çevikliğin aslında baştan sona riski yönetmek olduğunu öğreneceksinizdir. Çevik Yazılım Geliştirme Bildirisi’ndeki değerlerin ve ilkelerin üzerinden verdiğim örneklere devam etmek istiyorum. Çevik Yazılım Geliştirme Bildirisi’ninde üçüncü değer der ki:

 

“Sözleşme pazarlıklarından ziyade müşteri ile işbirliğine değer veririm.”

 

Geleneksel yöntemle geliştirilen projelerdeki en büyük risk uzun analiz, geliştirme, test adımlarından sonra kullanıcı kabulune çıkıldığında müşterinin istemediği bir ürünü geliştirmektir. Müşteri, “benim istediğim bu değil ki, ben bu projeyi onaylamıyorum, istemiyorum ve ödeme yapmıyorum” der. Bu cümleleri geleneksel yöntemle proje geliştiren herkes duymuştur!
Duymadınız mı!

Continue reading Çevik Yazılım Geliştirmede Risk

Çevik Yazılım Geliştirmede İş Değeri

Çevik Yazılım Geliştirmede İş Değeri

Çevik Yazılım Geliştirme Bildirisi’ninilk prensibi der ki;

 

“En önemli önceliğimiz değerli yazılımın erken ve devamlı teslimini sağlayarak müşterileri memnun etmektir.”

 

İş değeri, ölçülmesi ve anlaşılması zor kavramlardan biridir. Geliştirilen bir özelliğin size ne kadar değer katacağını hesaplamak bazen çok zor bazen çok kolay olabilir. Örneğin;

 

Bir bankanın operasyon merkezinde yönetici olduğunuzu düşünün. Faks ile gelen ödemeleri işleme sokabilmek için bu faksın görüntülenmesi gerekir. Daha sonra bu faksın üzerindeki değerleri sizin için sisteme giren veri giriş elemanlarınız veri girişini yapar ve işlemi ileri bir seviyeye taşırlar. Eğer hatalı bir veri girişi olmazsa bir faks için bu işlem ortalama olarak üç dakikada yapılabilir. Üç dakika kısa bir süre gibi görünsede yılda yedi milyon işlem ile uğraştığınızı düşünürseniz aslında bir saniye kazanmak bile büyük bir değer üretebilir. Bu işlemi daha kolay yapabilmek için bir OCR projesi geliştirdiğinizi düşünün. Veri girişi yapan çalışanlarınız bir faksın girişini tamamlayabilmek için üç dakika yerine bir dakika harcayacaklardır. Bu noktada OCR projesinin size kazandırdığı değeri hesaplamak çok kolaydır.

İş değeri, gelir elde etmek, maliyeti düşürmek ya da riski engellemek olabilir. Bunlardan birini elde ediyorsanız iş değerini hesaplamak kolay olabilir. Çünkü ölçülebilir bir metrik bulunmaktadır. Fakat iş değerini ölçemeyeceğiniz durumlarda bulunur. Örneğin geliştirdiğiniz projeyle ilgili bulunduğunuz kurumda olan diğer takımlara servisler vermeniz gerekebilir. Sizin üretiğiniz verileri kullanmak isteyebilirler. Bunun sizin için bir iş değeri bulunmaz fakat bu işleride gerçekleştirirsiniz. Tabi bu takım bazında düşündüğümüzde bir iş değeri değilken, organizasyon seviyesinde düşündüğümüzde bu işin de bir değeri bulunmaktadır fakat bunu ölçmek çok daha zordur. Continue reading Çevik Yazılım Geliştirmede İş Değeri

Çevik Yazılım Geliştirmede Adapte Olabilirlik

Çevik Yazılım Geliştirmede Adapte Olabilirlik

Yine Çevik Yazılım Geliştirme Bildirisi’ndeki değerleri göz önünde bulunduralım. Çalışan yazılıma detaylı dokümantasyondan daha fazla değer verilir. İlkelerdeyse geliştirme sürecinin geç aşamalarında bile değişim hoş karşılanır denir. Her döngü sonunda çalışan yazılım teslim edilir. Çalışan yazılıma yeni özelliklerin adapte edilebilmesi kolaydır.
Geleneksel yaklaşımda ise esneklik analiz aşaması başladığı anda düşer. Değişimi hoş karşılamaz. Geriye dönük yapılmak istenen herşeye karşı çıkılır ve tekrar edilen iş olarak görülür. Halbuki ürün müşterinin istediği yönde evrilebilmelidir. Geleneksel proje yönetiminde bu evrilmeyi gerçekleştirebilmek neredeyse imkansızdır. Yeni bir ürün geliştirmeye başladığınızı düşünün, başlangıç aşamasında tam bir ürün elde etmek istediğinizi düşünüp bir yılda geliştirilebilecek bir ürün için dört aylık analiz çalışması gerçekleştirdiniz. Dördüncü ayın sonunda ise müşterilerinizin beklentisi değişti ve başka özelliklere yöneldiler. Ürününüze yeni özellikler eklemeniz ve müşterinin beklentisi yönünde evrilmeniz gerekiyor fakat siz çoktan ürünün bir yılını planlamıştınız. Yapılan bütün analiz çalışmaları boşa gider. Bu israf demektir. Sokağa atılan para demektir. Bütçenizi değer üretmeden tüketmeniz demektir. Continue reading Çevik Yazılım Geliştirmede Adapte Olabilirlik