Çeviklik, Yalınlık, Scrum, Kanban, eXtreme Programming(XP) konularında ne yazık ki Türkçe kaynak sayısı yok denilecek kadar az! Bu açığın kapatılması gerektiğini düşünüyorum. Ülke olarak İngilizce bilen kişi oranımız çok düşük. İnsanların bir konuyu öğrenebilmesi için ilk önce İngilizce öğrenmesi gerekiyor. Gerekmemeli! Eğitim sistemimizde böyle büyük bir yanlış var! Tek başıma bu yanlışı düzeltemem fakat bireylse çaba gösterebilirim. Bu büyük yanlışın ynaında bireyler olarak bizimde yanlışımız var. Birey olarak yaşıyoruz! Halbuki toplum olarak yaşamalıyız! Kendimiz için yaşıyoruz ve kendimizin dışında hiçbir şey önemli değil!
Keşke herkes, iyi bildiği bir konuda birkaç kitap yazabilse ya da çevirebilse, o zaman ülkemizin insanı için bir şeylerin yolunu kolaylaştırmış oluruz.
Ç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 Poker Planlama konusunu anlatacağım. Poker Planlama, Ç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. Poker Planlama, 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.
Ç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 ç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 bilir 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:
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ı!
Ç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→