Bu makalede çevik yazılım geliştirmede iş değeri neden bu kadar önemli anlatmaya çalışacağım. Çevik Yazılım Geliştirme Bildirisi’nin ilk prensibi der ki;
“En önemli önceliğimiz değerli yazılımın erken ve devamlı teslimini sağlayarak müşterileri memnun etmektir.”
İş değerinin, ölçülmesi ve ne olduğunun anlaşılması zor olabilir. Geliştirilen bir özelliğin size ne kadar değer katacağını hesaplamak bazen çok zor bazen çok kolay olabilir.
Bu makalede Çevik Yazılım Geliştirmede adapte olabilirlik konusunu anlatmaya çalışacağım. 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. Çevik Bildiri’deki ilkelerdeyse 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. Çevik Yazılım Geliştirmede Adapte Olabilirlik yazısına devam et
Bu makalede yazılım geliştirmede görünürlük konusunu anlatmaya çalışacağım. Çevik Yazılım Geliştirme Bildirisi değerlerinde müşteri ile yakın iletişim ve ürünü geliştiren kişiler arasında işbirlikçi bir yaklaşımdan bahsedilir. İlkelerinde ise kısa döngüler halinde geliştirilen özellikleri müşteriye sunmak ve müşteriden gelen geribildirimler ile ürüne yön vermekten böylece ürünün görünürlüğünü artırmaktan bahsedilmektedir. Her döngünün sonunda gerçekte ne kadar ilerlendiği böylece rahat bir şekilde herkes tarafından görülebilir. Çevik yazılım geliştirme ile görünürlük döngü başında yüksektir, döngünün ortasına doğru görünürlük düşer ve döngünün sonunda görünürlük tekrar yükselir. Burada anahtar nokta döngünün kısa olmasıdır. Eğer müşterinin istemediği bir özellik geliştiriliyorsa kısa tutulan döngü sonunda hemen ortaya çıkar. Çevik Yazılım Geliştirmede Görünürlük yazısına devam et
Bu yazımda sizlere yazılım projelerinde değişiklik maliyeti konusunu anlatmaya çalışacağım. Diğer bir deyişle proje gerçekleştirilirken yapılan hatanın organizasyona olan maliyetini anlatacağım. Böylece yazılım geliştirilirken aslında her bir aktivitenin ne kadar önemli olduğunu göreceğiz. Aktiviteler kullandığımız yaklaşıma bağlı olarak değişmektedir. Örneğin geleneksel yazılım geliştirme yaklaşımında Eşli Programlama diye bir aktivite bulunmazken aslında hatalar yapılır yapılmaz yakalanma şansı kaçırılmaktadır. Halbuki Çevik yaklaşımları kullanan takımlar Eşli Programlama’yı kullanarak hatalar yapılır yapılmaz yakalamakta ve gerekli değişikliği yapabilmektedir. Projenin tamamı düşünülerek bu açıdan bakıldığında Çevik yaklaşımlar büyük bir israfın önüne geçilebileceğini göstermektedir.
Yazılım projelerinde değişikliğin maliyetini hesaplayan çalışmayı yapan kişi Barry W. Boehm’dur. Boehm, Waterfall modelini ilk defa bilimsel makalesinde anlatan Royce gibi TRW için çalışan aynı zamanda Güney Kaliforniya Üniversitesi’nde hocalık yapan bir profesordür. 1957’de Hardvard’ta lisans eğitimini tamamlamıştır. Yüksek lisans ve doktora derecelerini 1961 ve 1964 yıllarında Kaliforniya Üniversitesi’nden almıştır. 1989 – 1992 yılları arasında Amerika Savunma Bakanlığı’nda Direktör olarak çalışmıştır. 1973 – 1989 yılları arasında TRW’de Savunma Sistemleri Şefi olarak görev yapmıştır. Yazılım geliştirme süreçlerini etkileyen birçok çalışması bulunmakla birlikte en büyük etkiyi WinWin Spiral Model ve Software Engineering Economics adlı çalışmalarıyla yapmıştır.(1)
Eşli Programlama’da amaç aslında bir akış oluşturmaktır. Akış derin düşünce durumudur. Birçok yazılım geliştirici akışı sadece yalnız ve sessizken yakalayabileceğini deneyimlemiştir. Bu nedenle biriyle iletişim halindeyken bu derin düşünce durumunun yakalanılamayacağı düşünülür. Aslında her iki eşte aynı konuya odaklanırsa bu mental durum yakalanabilir.
Eş olmadaki en zor durum Sürücü bir yazım hatası yaptığında dilini tutmaktır. Merak etmeyin büyük ihtimalle Sürücü’de yaptığı hatayı fark etti fakat oraya dönmesi birkaç saniyelik zaman alacaktır. Erkenden konuşmak akışı bozabilir.
Eş olma yaratıcılık için bulunmaz bir ortam oluşturur. Yaratıcılık, zihinsel zeka gibi değildir. Yaratıcılık, iş birliği ve iletişim ile ortaya çıkar. Yaratıcılığın büyük çoğunluğu aslında sizin fikirlerinizin tekrar size anlatılmasıyla meydana gelir.