Yahu! Agile Manifesto’sundaki değişikliğe açık ne demek?
90’lı yıllardan beri duyula gelen ve kulağımıza küpe olup ta bir türlü anlam veremediğimiz yazılımda değişikliğe açık olmanın faydalarını duya geldik; fakat Agile Manifesto’sunda bahsi geçen değişiklikten ne kastedildiğini anlamadan, tam kavramadan, kulaktan duyma bilgilerle, ayrıtılarına bakmadan gelişi güzel ve kulağımıza hoş geldiği için Agile Metodolojileri adı altında yazılım geliştirme sürecimize yön verdik. “Zenginin malı, züğürdün çenesini yorar” misali, yapbozun parçalarını dizmeye çabalamadan, araştırmadan, neyin ne olduğunu bilmeden Agile’i uygulamaya çalışıp başarısız olduğumuzda Agile arkasından atıp tuttuk, kendimizi yorduk.
Velinimet olan müşterinin isteklerine karşılık verip müşteri memnuniyetini sağlayıp müşterinin işlemesindeki(Business) işletme kuralı(Business Rule) değişimlerine cevap vermek elbette en çok şirket yöneticilerinin yanında müşterileri da memnun eder. Peki böyle bir hadisenin vuku bulması sadece kulaktan dolma bilgiyle olur mu? Git iki seminere katıl, göz ucuyla gazetede göz gezdirir gibi Agile ile ilgili bir iki tanıtım kitapçığına göz at. Gel, de ki Agile(Scrum, XP, Lean, …) uyguluyorum(!) Uygularsın tabi(!) Başarısız olduğunda Agile arkasından atıp tutmayı da bilirsin(!) Efendim ne imiş Agile Megile(mecayl), yazılım süreci bunların hepsi boşmuş(!) Ne demişler, çok bilmişten kork demişler(Bu arada ben çok bilmiş değilim :)). Çünkü bilmediklerinin farkında değiller.
Bu kadar gevezelik yeter, biraz da konuya dalalım. Bilmem Agile Manifesto’suna bakma fırsatınız oldu mu, Agile Manifesto’su şöyle der:
Bilgisayar Bilimi(Bilgisayar Müh., Yazılım Müh., …) ile uğraşan ister stajyer olsun ister piyasada senelerce bilişim alanında çalışan olsun Yazılım Mühendisliği derslerinde veya değişik kaynaklardan göz ucuyla edinmiş bilgilerine dayanarak Agile Manifesto’sundaki özet bilgiyi dayanak göstererek Agile Metodolojilerinde süreç, dokümantasyon, söz verme, plan, tasarım, … yoktur demelerinin yanında Agile Metodolojileri değişime açıktır derler. Peki süreç, dokümantasyon, plan, söz verme, tasarım, … olmadan yazılımda değişiklikten söz edilebilir mi? Düşünmek gerek. Gerçekten böyle birşey mümkün olur mu, bunlar olmadan?
Agile Manifesto sitesini bir ziyaret edin, tekrar okuyun. Bu sefer dört manifestonun üstündeki ve altındaki yazıları dikkatlice okuyun. Agile Manifesto’sunu imzalayan kişilere bir bakın. Bu manifestoyu imzalayan kişilerin kendileri süreç, dokümantasyon, plan, söz verme, tasarımın, … önemini kendi ağızlarıyla var güçleriyle bağıra bağıra seslerini biz duyalım, anlayalım ve uygulayalım diye koskocaman yazmışlar, koymuşlar. Biz de burada oturup şöyle, böyle diye çene yoruyoruz. Hiç Kent Beck’in kitabını, Martin Fowler’in tasarım kalıplarını, Robert C. Martin’in tasarım prensiplerini, Ken Schwaber ve Jeff Sutherland’in metodolojilerini ve Dave Thomas’ın insana değer vermenin ne demek olduğunu okuduk mu? TDD, MV-C/VM/P, SOLID, Scrum, Clean Architecture ve Pragmatic Programmer birşey ifade ediyor mu?
Agile Manifesto’sunda imzasını atan kişilerin eserlerine ve hayatlarına baktığımızda herbiri yazılımın değişikliğe açık olması için var güçleriyle 70’lı yıllardan bu yana metotlar, mimariler ve prensipler ortaya koyup, değişikliğe açık nasıl olunurmuş, gösterdiler. Değişikliğe açık olmanın sadece metodolojiyi bilmekle değil metodolojiyi bilmenin yanında planın, analizin, tasarımın, geliştirmenin, testin, dağıtımın ve bakımın değişime cevap vermesiyle mümkün olacağını hep beraber söylüyorlar.
Değişikliğe açık olmak bir yazıda sığsaydı ve anlaşılsaydı stajyerlerim ve takım arkadaşlarım gelip bana Agile’de dokümantasyon, plan, mimari, test, süreç, … yoktur demezlerdi :).
Umarım değişikliğe açık olmak nediri birazcık anlatabilmişimdir. Değişikliğe açık yazılımın nasıl geliştirileceğine dair ileriki yazılarımda kaleme alacağım konular aşağıdaki gibidir:
· Proje Kapsamı(Project Scope) ve İş Kuralı(Business Rule) nedir ve hangisi değişikliğe açıktır?
· Mimari mi yoksa özelliklerin geliştirilmesi daha önemli?
· Scrum, User Story, Estimate, Target, Commitment nedir?
· Yazılım geliştiricisi açısıdan Teste Dayalı Geliştirme(Test Driven Development)
· Otomatik(Automated) Testler: Unit Test, Integration Test ve Functional Test
· Çok Katmanlı Mimari ve Clean Architecture
· Değişikliğe açık olmak için gereken Yazılım Tasarım Prensipleri(SOLID, DRY, KISS, SoC, …)
· Yazılım Tasarım Kalıpları
· Continuous Integration ve Continuous Delivery
Ve diğerleri.
Okuduğunuz için teşekkür ederim. Size birşey kattıysam ne mutlu bana.
