Category Archives: Waterfall

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

Ç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

Çevik Yazılım Geliştirmede Görünürlük

Çevik Yazılım Geliştirmede Görünürlük

Ç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. Continue reading Çevik Yazılım Geliştirmede Görünürlük