Yazılım Geliştirme Süreçleri
Herkese merhaba,
Uzun zamandır Medium’da yazılım üzerine paylaşımlarda bulunmak istiyordum fakat şimdiye dek pek fırsat olmadı. Bugün yazılım süreçleriyle birlikte bu alanda paylaşımlar yapmaya başlıyorum. Fırsat bulabilirsem haftalık olarak bu konunun devamı niteliğindeki yazılarla devam edeceğim.
Şimdi hazırsak başlayalım.
Yazılım geliştirmek neye benzer?
Yazılım geliştirmek neye benzer, nasıl görünür gibi sorulara cevap ararken yazılım endüstrisinin değişimine de şahitlik edeceğimiz bir yolculuğa çıkacağız. Fakat yazılım geliştirme süreçlerini konuşmadan önce daha basit bir örnekle yola çıkalım. Diyelim ki bir ev yaptırmak istiyorsunuz. Bunun için muhtemelen ilk yapacağınız şey, bu iş ile uğraşan inşaat firmalarıyla iletişime geçip nasıl bir ev istediğinizi anlatmak olacaktır. 2 yatak odalı, şu boyutlarda salonu olacak, şurada balkon olmasını istiyorum vb. isteklerinize istinaden firma size çeşitli önerilerde bulunacaklardır. Bu öneriler sonucu sizde isteklerinizi gözden geçirip, revize edebilirsiniz. İhtiyaçlar kararlaştırıldıktan sonra firma size bir kat planı ile tekrar gelecek. Burada da gerekli düzenlemeleri yapıp kat planları istediğiniz şekilde olduğunda artık inşaat firması daha detaylı bir plan oluşturmak için çalışmaya başlayacak. Bu planda da tesisatın,prizlerin nerede olacağı gibi detaylar yer alacak. Bunun sonunda da artık evi inşa etmeye başlayacaklar. Evin yapımı sürerken denetlemeler olacak ve bu denetlemelerde örneğin prizler planlandığı yerlere konuldu mu? Tesisat yapıldı mı ? gibi kontroller yapılacak. Tüm bu işler tamamlandığında size evi gösterecekler, sizde eğer onay verirseniz artık evde oturmaya başlayacaksınız. Tabii oturmaya başladıktan sonra bir de evin bakımı olacak.
Yukarıda bir ev yaptırırken geçirdiğimiz süreçleri inceledik. Şimdi bir ev yaptırmakla yazılım geliştirmenin birbirine benzer ve farklı yönleri neler onları inceleyelim. Benzerliklerden başlayacak olursak; yazılım geliştirirken de tıpkı ev yaparken olduğu gibi öncelikle gereksinimlere, ihtiyaçlara bakıyoruz. Ardından müşterimizin isteklerine çeşitli öneriler getiriyoruz ya da bazen bir prototip oluşturarak “İstediğiniz şey bunun gibi mi?” diyerek bu prototipi müşterimize sunuyoruz. Buradan onay aldıktan sonra sıra yazılım mimarları ve geliştiricilerine gelir. Öncelikle sistemi ve mimariyi tasarlayıp ardından ekiplerin nasıl çalışacağı belirlenir. Böylelikle tasarım tamamlanır. Buradan sonra kodlama ve test kısmı başlar. Burada da tüm bileşenler test edilir. Hepsi tamamlandığında tüm süreç birleştirilir ve entegrasyon testleri vb. yapılır. Yazılımcılar geliştirmelerinin tamamlandığını düşündüğünde UAT(Kullanıcı kabul testi) ‘ye gönderir. Burada kullanıcı “Tamam, istediğimiz bu” ya da “Hayır, bu, bizim istediğimiz gibi değil” diyebilir. Eğer onay verilirse production ortamına çıkılır. Proda çıkıldıktan sonra bazı hatalar çıkabilir ya da kullanıcılar bazı değişiklikler isteyebilir. Bu süreçte yazılımın bakım sürecidir.
Görüldüğü gibi bir ev inşa etmekle yazılım inşa etmek aslında oldukça benzer süreçlere sahipler. Yukarıda incelediğimiz süreç “Şelale Metodu” olarak adlandırılır. Şelale metodu, fazdan faza geçilerek ilerlemenin sağlandığı bir metoddur. Başlarda yazılım geliştirme süreçlerinde çokça tercih edilse de kullanıldıkça bazı sorunlar ortaya çıktı. Örneğin; Bir işin gereksinimlerini 1–2 yıl önceden tahmin etmek oldukça zordur. Her an istekler ya da pazar değişiklik gösterebilmektedir. Ayrıca süreç ortalama 1–2 yıl olduğu için yazılımcılar ya da mimarlar gereksinimleri yanlış yorumlayabilirler. Bu gibi bir durumda bu yanlış tasarım, implementasyon ve onaylama süreçlerinin tamamı bitene kadar fark edilmeyecektir. Ya da benzer şekilde entegrasyon hataları da tüm yazılım geliştirme fazında uzun süre fark edilmeyebilir.
Bu gibi problemlerden dolayı şelale modelinin çeşitli varyasyonları ortaya çıktı. V-model, Sashimi ve RUP modeli örnek gösterilebilecek modellerdir. Bunlar dışında bilinen bir model de spiral modeldir. Spiral model yine şelale modelinden türeyen, risk odaklı bir modeldir. Yazılım geliştirme süreçleri bu şekilde farklı gereksinimlere çözüm arayarak evrimleşmeye devam etmiş ve günümüzde Agile adı verilen düşünce sistemi ortaya çıkmıştır. Yalnız burada dikkat çekilmesi gereken nokta Agile, bir model değildir. Agile bir düşünce biçimidir.
Yazılım endüstrisinde başarılı olan birçok kişi bir araya gelip “Bizi başarılı yapan şeyler neler?” diye kendilerine sordular. Bu soruya cevap olarak bugünkü Agile Manifestosunu ve prensiplerini dile getirdiler. Scrum, Kanban ve XP, Agile prensiplerine uygun metodlardır. Bu 3 modelin dışında da sonraları agile prensiplerine uygun birçok model ortaya çıkmıştır. Bu modellerin tamamının en temelde hedeflediği şey 1–2 yıllık uzun geliştirme süreçlerini kısa sürelerde tekrar eden biçimde ayırmaktır. Kısacası tüm süreçleri tek ve büyük bir fazdan oluşturacağımıza önce belirli tanımlamalar yapıp ardından bunun için gereken geliştirmeyi ve testi yapıp, sonrasında da kullanıcılardan geri bildirim alarak, öğrenerek ilerleyip tekrarlı bir döngü halinde sonraki kısım için devam edilir. Böylece pazara hızlıca adapte olunabilir, değişiklikler sizin için bir norm halini alır.
Her şey iyi güzel fakat yazılım endüstrisi de bu duruma kendini hızlı bir şekilde adapte etmelidir. Bunun için bir yazılımcı kodunu commit ettiğinde sürekli bir entegrasyon olmalıdır. Bu eklemelerin ardından sistemin çalışıp çalışmadığı otomatize edilmiş testlerle sınamamız gerekir. Kısacası siz yeni bir kod eklediğinizde tüm testler otomatik çalıştırılarak her şeyin doğru olduğundan emin olmak gerekir. Böylece bir kod eklenir eklenmez tüm işlemler otomatik yapılır.Bunun sonucunda da manuel yapılan hatalar ve deployment maliyeti azalır. Tabii tüm bu değişimler geliştiriciler ve operasyon birimleri arasında yeni bir ortaklığa yol açtı, bunun sonucu olarakta DevOps kültürü ortaya çıktı.
Agile küçük ölçekteki projelerde başarılı sonuçlar elde etmeye devam ettikçe insanlar bu sefer “Acaba bu yöntemi büyük projelerde uygulayabilir miyiz?” diye sormaya başladılar. Böylece Scaled Agile Framework, Large Scale Scrum gibi metodlar ortaya çıktı. Açıkçası ne kadar yazılım geliştirme süreci 1–2 yıldan daha ufak parçalar halinde bölünerek ilerleme yönüne evrilmesiyle büyük başarılar elde etse de insanlar bundan daha efektif ve daha hızlı öğrenmeyi, uygulamayı ve bununla birlikte ucuz olmasını sağlamak istiyordu.
Bu durum da Lean Startup ve Design Thinking gibi kavramları hayatımıza soktu. Bu konularda da aklıma ilk gelen eserler Zappos Ceo’su Tony Hsieh’in Mutluluk Dağıtmak ve Eric Ries’in Lean Startup kitapları. Bu fikirlere örnek verecek olursak; Tony Hsieh ve Zappos’u örnek alalım. Zappos fikri ilk ortaya atıldığında insanların çevrimiçi ayakkabı satın almak isteyip istemediğini kimse bilmiyordu. Bunun için tam teşekküllü bir altyapı kurmak yerine öncelikle basit bir web sitesi oluşturdular ve sipariş alıp alamayacaklarına baktılar. İlk sipariş aldıklarında da bir ayakkabı mağazasına gidip sipariş edilen ayakkabıyı satın alarak müşteriye gönderdiler. Fİkirlerinin başarılı olduğunu gördüklerinde de altyapıyı geliştirmeye başladılar. Bu düşünce çalışanların yalnızca oluşan çıktılara değil sonuca odaklanmalarına da yol açtı.
Tüm bu süreçler ve metodolojiler değiştikçe yazılım endüstriside bu puzzle ın bir parçası olduğunu anladı. Böylece çalışan motivasyonu, büyüme planları, psikolojik durumlar ve bunun gibi birçok soft konuyu daha düşünmek zorunda olduğumuzu anladık.
Son birkaç yıl içerisinde yazılım endüstrisi bu şekilde büyük bir değişim geçirdi ve hala bu büyük değişim devam ediyor. Daha iyi sonuçlar almaya, daha doğru ilerleme kaydetmeye, sorunları daha hızlı ve güvenilir biçimde çözmeye çalışıyoruz. Bunun için de geliştirdiğimiz yazılımın yaşam döngüsünü kavrayabilmek, süreçlere hakim olmak büyük önem arz ediyor.
Podcast| Youtube | Slack | Facebook | Twitter | Instagram | Kodcular
