Bir yazılımın ortaya çıkabilmesi için öncelikle müşterinin ne tür ihtiyaçlarını karşılayacağı belirlenmelidir. Daha sonra bu ihtiyaçlara uygun teknolojilerin ve yöntemlerin belirlenmesinin ardından kodlama ve test etme işlemleri gerçekleştirilerek müşteriye hazır bir ürün sunulur.
Yazılımın geliştirme sürecinin başından itibaren sırayla analiz, plan, tasarım, kodlama ve test süreçleri birbirini takip eden adımlar dizisidir. Bu modele waterfall(şelale) denilmektedir. Bazen bu adımlara destek(maintenance) süresi de eklenmektedir. Bir yazılımın tüm gereksinimleri müşteriden alındıktan sonra bu adımlar takip edilerek son ürün ortaya çıkmaktadır. Ancak uzun zaman alan yazılım projelerinde zaman içerisinde teknolojilerin veya müşterilerin ihtiyaçlarının değişebileceğinden yazılımda da değişiklikler gerekebilmektedir. İki sene süren bir projeyi düşünecek olursak proje başında belirlenen istekler iki sene sonunda mevzuatlar veya iş kuralları veya teknoloji değişikliğinden dolayı bazı ihtiyaçları karşılamayabilir. İş sonunda müşterinin ihtiyaç duymadığı bir ürün ortaya çıkabilir. Diğer taraftan analiz veya planlama sırasında yapılan bir hata ancak test sırasında ortaya çıkabilir. Proje zamanlaması için yapılan tahminler tutamayabilir.
Zaman ve bütçe kısıtlamasının olduğu startup gibi bir şirket için bu tür geliştirme modeli bir süre sonra işletmeye zarar ettirmeye başlar.
Zamanla edinilen tecrübeler geliştiriceleri bu modeli biraz değiştirmeye zorlamıştır. Müşterilerin ihtiyaçlarını guruplara bölerek her ihtiyaç için analiz, plan, tasarım, kodlama ve test süreçlerini yeniden yapılması uygun görülmüştür. Bu model, spiral(sarmal) model olarak adlandırılmıştır. Spiral model agile(çevik) proje geliştirme yaklaşımı içerisinde kullanılan bir modeldir. Burada çeviklikten kasıt değişime ayak uydurabilmektir.
Eğer iki senelik bir proje süreniz varsa, bu model size birinci ayın sonunda müşterinin belirttiği ihtiyaçlardan birini çalışır şekilde ona sunmanızı sağlamaktadır. Müşteriye tüm proje süresi sonunda çalışan bir ürün sunmak yerine, ona her ay yeni bir özelliği devreye alınmış olan bir yazılım ürünü sunulmuş olur.
Örneğin bir hesap makinesi yapmayı tasarlıyorsanız birinci adımda dört işlemi yapabilen bir hesap makinesi yapmak ve müşteriye sunmak yeterlidir. İkinci adımda üslü ve köklü işlemler ihtiyacını karşılayan özellik eklenir. Üçüncü adımda müşteriden yeni bir talep gelir ve trigonometrik hesaplar yapabilen özellikler eklenebilir. Daha sonra gelen geri dönüşlere(feedback) göre belki matris çözebilen özellikler gerekebilir. Burada önemli olan, her adım sonunda müşterinin elinde çalışan bir hesap makinesinin olmasıdır. Eğer waterfall model ile geliştirme yapılırsa tüm özellikler ve testler bittiğinde müşteriye çalışan bir ürün teslim edilir. Belki de müşterinin hiç ihtiyaç duymayacağı matris işlemler özelliğini de eklemiş olabilirsiniz. Şunu unutmamalıyız ki; gereksiz işlere harcanan zaman, işi yapan tarafa gider olarak yazılır.
Agile Manifesto
Agile(çevik) yazılım geliştirme yaklaşımı bir işi küçük parçalara bölerek yapmayı ilke edinen bir disiplindir. Bir ürün veya yazılım aracı veya bir kodlama yöntemi değildir.
Agile (çevik) yazılım geliştirme konusunda, yazılım sektöründe tecrübeli bir ekip tarafından bir manifesto yayınlanmıştır. Manifesto içeriğine ve ilgili kişilere http://www.agilemanifesto.org/ adresinden ulaşabilirsiniz.
Agile manifestonun dört temel ilkesi vardır.
English:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Türkçe:
- Süreç ve araçlardan ziyade bireyler ve etkileşimler
- Kapsamlı dökümantasyondan ziyade çalışan yazılım
- Sözleşme pazarlığından ziyade müşteri ile işbirliği
- Plana bağlı kalmaktan ziyade değişime yanıt vermek
Bu ilkeler ne anlama geliyor?
Manifesto ilkelerinde, yazılım geliştirme sürecinin önünü açan öncelikler belirlenmiştir. Tüm cümlelerde ortak olarak kullanılan “ziyade” kelimesi işte bu öncelikleri vurgulamaktadır.
1. Süreç ve araçlardan ziyade bireyler ve etkileşimler: Yazılımlar bilgisayarlar tarafından çalıştırılan ürünler olsa da yazılımı talep eden müşteriler ve onu geliştiren programcılar insanlardır. Müşteriler ve geliştirici ekip arasında güçlü bir iletişim olmalıdır. Ürünler ve araçlar değişebilir, eskiyebilir ve gözden çıkarılabilir. Fakat birbiriyle uyumlu iyi bir ekibiniz varsa onu gözden çıkaramazsınız. Bu nedenle bireylere değer vermek işletilen süreç ve kullanılan araçlardan daha önemlidir.
2. Kapsamlı dökümantasyondan ziyade çalışan yazılım: Projelerde müşteri ile el sıkışmanın şartı iş sonunda çalışan kaliteli bir yazılımın olmasıdır. Müşteriler kapsamlı dökümanlara para ödemek istemez ama tercihen isterler. Müşteriyi boğmayan ancak ona yeteri kadar bilgi veren bir dökümantasyonunuz olmalıdır. Bu nedenle önceliğimiz çok kapsamlı bir dökümantasyon oluşturmak yerine iyi çalışan bir yazılım olmalıdır.
3. Sözleşme pazarlığından ziyade müşteri ile işbirliği: Müşteri tarafından sunulan şartnameler ve yapılan sözleşmeler her iki tarafa güvenlik duygusu verir. Bir sözleşmeye imza atılır ve belirli bir zamanda yapılacak işler planlanmış olur. Agile süreçlerde her zaman müşteri ile işbirliği ön plandadır. Kararlar beraber alınır, sürekli görüş alışverişi yapılır, teslimatlar sonrasında geri bildirimler alınarak değerlendirmeler yapılır. Yani iş sözleşmesini ve talepleri alıp iş bitiminde görüşmek diye bir şey olmaz.
4. Plana bağlı kalmaktan ziyade değişime yanıt vermek: Agile yani çeviklik bir plana bağlı kalmadan değişime cevap vermek demektir. Zamanla gereksinimler, mevzuatlar iş kuralları değişebileceğinden uyguladığınız çözüm yöntemi de bu değişimlere ayak uydurabilmelidir.
Agile süreçlerde Scrum, Kanban ve Lean gibi proje yönetim yaklaşımları yanında Extreme Programming(XP) gibi yazılım geliştirme yaklaşımları kullanılmaktadır. Extreme Programing yazılım geliştirme yöntemleri, uzun yıllar tecrübe edilmiş ve kendini kanıtlamış yöntemler olarak bilinir. Bunlar arasında Test Driven Development gibi önce test kodunun yazılıp ardından çalışan kodun üretildiği bir yaklaşım vardır. Pair Programming yani eşli programlama diye bilinen iki programcının aynı kodu geliştirdiği yaklaşımlar vardır. Geliştiricilerin birbirlerinin kodunu incelemesi ve yorumlaması(core review) da yine bir diğer yaklaşımdır.
Bütün bu yöntemler yazılımın türüne bağlı kalmadan uygulanabilecek yöntemlerdir. Yani web uygulaması, mobil uygulamalar, oyunlar veya masaüstü uygulamaları gibi her türlü projede çevik yöntemler uygulanabilmektedir.
Neden Agile?
Bu sorunun birinci nedeni agile kavramının değişime cevap verebilme yeteneğidir. Agile geliştirmenin bir diğer nedeni ise çabuk sonuç alma isteğidir. Taleplerin adım adım karşılanıp çalışan ürünlerin müşteriye sürekli teslim edilmesi neticesinde size olumlu veya olumsuz geri bildirimler akmaya başlar. Müşteri ile işbirliği içinde olduğunuzdan doğru şeyi yapıp yapmadığınızı hemen anlayabilirsiniz. Bu sayede harcadığınıza karşılık kazandığınızı görebilirsiniz yani yatırım getirisi (Return on investment) hakkında bilgi sahibi olabilirsiniz. Agile süreçlerde büyük bir yazılımın küçük parçaları ile çalışıldığı için erken yapılan hatalar büyük bir felakete neden olmaz. Diğer bir deyişle hatanın erkenden fark edilmesi sağlanmış olur. Ekiplerin düzgün bir yapıda oluşturulması ile kaynak planlaması da daha mantıklı olacaktır. Örneğin waterfall yöntemi ile yapılan bir yıllık bir projede analiz için gerekli çalışanların işi üç ayda bittikten sonra gereksiz yere projede tutmak istemeyebilirsiniz. Ancak ilerde analiz ile ilgili bir sorun çıkarsa diye tutmak zorunda kalabilirsiniz. Spiral yöntemde ise her döngüde süreç adımları yeniden ele alındığı için bu duruma uygun bir takım oluşturulabilir.