Category Archives: Extreme Programming / Agile

Çevik Yazılımın Rönesansı

Yazilim dünyasinda tas üzerinde tas kalmiyor :) Dogru bilinenler ve uygulamalar artik kendiliginden ortadan kalkmaya yüz tutuyor. Bunlarin basinda garip toplantilar var. Digerlerine diger yazilarimda deginecegim.

Düsünsenize ortada yazilim ekibi bile kalmamis, tek bir yazilimci kocaman bir ajan ordusunu orkestre ediyor ve toplanmaya gönüllü olanlar sadece yönetici tayfasi, cünkü yapacak baska isleri yok. Gözünüzde canlandirin bi… Toplanti odasinda tek bir yazilimci var ve en az 5-6 tane yönetici, scrum master, menicır, bilmem nerenin baskani vs oturuyor. Sadece toplantilar degil, bu yönetici tayfasi da ortadan kalkacak. Ajanlarin onlarin yerine gecmesi an meselesi :)

Cevik olmak icin ne gerek miyordu?

– Yönetici tayfasi
– Programciya neyi nasil yapildigini söylemek
– Takimi programci, analizci, testci diye ayirmak.
Cevikligin özünde ne vardi?
– Yapilacak tüm yazilimla ilgili isi yazilim ekibine devredip, aradan cekilmek

– Yazilimcilarin isine karismamak
– Tüm kararlari onlarin vermesini ve sorumlulugu almalarini saglamak.

Simdi bir bakiyorum da, artik yapay zeka ile full cevik yazilim yapabilmek icin tüm imkanlar bir araya gelmeye baslamis gibi görünüyor.

Cevik yazilimin rönesansi bu.

Çevik Süreçler Neden Dikiş Tutturamadı

Çevik süreçlerin tam olarak ne olduğunu kavramamış, çevik süreçler ile bir proje uygulamamış, scrum yaparak çevik olduğunu ve çevik süreçlerin bir işe yaramadığını zanneden şahısların “agile is dead” naralarını unutmadık. Ben de çevik süreçler öldü diyorum, lakin ekliyorum: “yaşasın çevik süreçler”. Çevik süreçlerin yıldızlarının bundan sonra nasıl parlayacaklarını ve tam anlamıyla yazılım geliştirme süreçlerine hakim olacaklarını kendi yazılımcı perspektifimden sizinle paylaşmaya çalışacağım.

Bir yazılım sistemi belli bir büyüklüğe ulaştıktan sonra, kendi dinamiklerini oluşturarak, yeni özellikler eklenmek suretiyle geliştirilmesini engeller hale gelir. Bunun başlıca sebebi, mevcut mimarinin yeni özellikleri taşıyacak yapıda olmamasıdır. Bunu bilen yazılımcılar iki nokta arasındaki en kısa mesafeyi seçmek yerine, en az dirençle karşılacakları patikayı yeğlerler. Bunun neye sebebiyet verdiğini çok iyi biliyoruz: teknik borç! Burada yazılımcının büyük oranda suçu olmadığını düşünüyorum. Daha ziyade yazılımdan bihaber yöneticiler zaman baskısı oluşturarak, işi aceleye getirmektedirler ve aslında başarısızlığın temelini ilk saniyeden itibaren atmaktadırlar. Bu duruma yazılımcılar tepki vermeyerek ve kimsenin etlisine, sütlüsüne karışmayarak ortak olmaktadırlar. Lakin şöyle yöneticilerin karşılarında ağız birliği yaparak, dik durabilseler ve “madem bu işi biz yapıyoruz, o zaman ne zaman biteceğine de biz karar veririz” diyebilseler, çok daha güzel işler ortaya koyabilecekler.

Yazılımda bu sorun ile başa çıkmanın tek bir yolu mevcut, o da refactoring olarak adlandırılan kodun yeniden yapılandırılmasıdır. Teoride her yazılımcının yeniden yapılandırmanın ne anlama geldiğini bildiğini düşünebiliriz. Lakin pratik açıdan baktığımızda, yeniden yapılandırma işleminin nasıl yapıldığı konusuna çok az sayıda yazılımcı hakimdir. Bunun da başlıca sebebi, yazılım testleri üzerinde olan hakimiyetsizliktir.

Refactoring tek başına yapılması mümkün olmayan bir işlemdir. Yapılan her değişiklik bir yan etki doğurabileceğinden, bu etkinin tespit edilebilmesi zaruridir. Bu kontrolü bir yazılımcının elden yapması mümkün değildir. Bu sebepten dolayı burada bir otomasyon ihtiyacı doğmaktadır. İhtiyaç duyulan kapsama alanına sahip olduğumuzu farz ettiğimizde, otomatik çalışan testler refactoring esnasında oluşan tüm yan etkileri tespit etmeyi mümkün kılacaklardır. Özetleyecek olursak, aslında yazılım sisteminin sürekli gelişimi için ihtiyaç duyduklarımız yeniden yapılandırma, test yazılımı ve test otomasyonudur. İşte çevik süreçlerin temelini de bunlar oluşturmaktadır. Eğer sürekli müşteri gereksinimlerini koda dökebiliyor ve mevcut sistemi genişletebiliyorsanız, çeviksiniz! aksi tektirde yazılımcılık oynuyorsunuz!

Çevik süreçler bünyesinde yer alan çevik metotların ana amacı yazılımda sürdürülebilirliği hedefliyor olmalarıdır. Burada sürdürülebilirlik terimini teknik açıdan ele almamız gerekmektedir. Sürdürülebilirlik bir yönetici için başka, bir yazılımcı için daha başka, bir patron için çok daha başka bir anlam ifade etmektedir. Ama doğru olan yaklaşım hangisidir? Şüphesiz herkes kendince doğru yaklaşım içindedir, çünkü beklentiler değişiktir. Lakin tekrar altını çizerek sormak istiyorum, teknik olarak sürdürülebilirlik ne anlama gelmektedir? Bunun cevabını verebilmek için öncelikle işin müşteri kısmını incelememiz gerekiyor.

Bir yazılım sistemi müşteri gereksinimleri doğrultusunda şekillenir. Yazılımcı olarak nihai amacımız, müşteri gereksinimlerini tatmin edecek bir sistem oraya koymaktır. Bu yüzden doğal olarak müşteriye kulak vermemiz ve ne istediğini iyi anlamamız gerekmektedir. Lakin müşteri ne istediğini tam olarak bilmekte midir? Ne yazık ki bu sorunun cevabı hayıdır. Burada yazılımcı olarak bizim için iki sıkıntı oluşmaktadır. Birincisi nasıl bir sistem oluşturmamız gerektiği sorusudur, ikincisi bu sistemin mimarisinin nasıl olması gerektiğidir. Bu iki sorunun da cevabını düşünerek, bulmamız mümkün değildir. O yüzden bir an önce kolları sıvıyarak, müşteriye yarım yamalak dile getirdiği gereksinimleri için kısa bir zaman dilimi sonunda bir şeyler göstermemiz gerekmektedir ki müşteri ne istediğine dair fikir üretmeye başlayabilsin. Bu yüzden çevik süreçlerde bir ya da iki haftalık iterasyonlar sonunda müşteriye mutlaka tespit edilen miktardaki özelliğin çalışır durumda olduğu sistemler sunulur. Bu prototipler müşteriden alınan geribildirimler doğrultusunda onun kullanacağı ürün olana kadar geliştirilir. Lakin burada tekrar sürdürülebilirlik konusuna değinmemiz gerekmektedir. Teknik olarak bu nasıl sağlanabilir? Bunun iki yöntemi mevcuttur: Teknik borç ve teslimiyet ya da kararlılık ile uygulanan “yap/boz” mentalitesi.

Eğer bir bina yapımı söz konusu ise, atılması gereken temelin ve uygulanmak istenen mimarinin bilinmesi gerekmektedir. Bu değişmez iki parametre yapılan binanın kaderidir. Eğer inşaat mühendisleri ve mimarlar yazılım yapmaya başlasalardı, hiç zorluk çekmeden bu işe adapte olabilirlerdi, çünkü günümüzde de yazılım bir bina inşaatı gibi ele alınmaktadır. Durum böyle olduğu için yazılım projelerinin çok büyük bir kısmı belli bir zaman sonra çıkmaza girerek, hem yazılım sistemini oluşturanları hem de müşterisini zorda bırakmaktadırlar.

Tekrar teknik sürdürülebilirlik sorusuna geri dönelim. Teknik sürdürüleiblirliğin bedeli ne yazık ki ağırdır. Öncelikle yazılımla uğraşan herkesin bu bedeli maddi ve manevi olarak ödemeye hazır olması gerekmektedir. Maddi açıdan baktığımızda yöneticilerin sürdürülebilirliği sağlamak adına daha fazla zamana ihtiyaç duyulduğunu ve bunun maliyeti artıracağını anlamaları, manevi açıdan baktığımızda yazılım mühendislerinin işin çıkmaza girdiğinde radikal kararlar vererek, refactoring teknikleri yöntemleri ile mevcudiyeti yeniden şekillendirme iradesine sahip olmaları gerektiğini görmekteyiz.

Günümüzde yapılan yazılımı yirmi sene önceki şekli ile kıyasladığımızda, aslında kafalarda fazla bir şeylerin değişmediğini görebilmekteyiz. Çoğu yazılım projesi yirmi sene önceki kafa yapısı (mindset) ile uygulanmaktadır. Yirmi sene önce aktif olarak hayatımıza giren çevik metotlar ihtiyaç duyulan dönüşümü sağlayamadılar. Bunun nedeni ne olabilir? Çevik süreçler performans gösterebilmek için çok radikal değişimlere ihtiyaç duymaktadırlar. Bu programcıların çalışma tarzlarından başlayarak, firmanın sahip olduğu yazılım geliştirme kültürüne kadar uzanana bir alanı kapsamaktadır.

Çevik süreçler programcı perspektifinden bakıldığında test güdümlü yazılım gibi radikal bir metodun uygulanmasını talep etmektedir. Yazılım birimlerini test etme konusunda pek kafa yormamış ve bu konuda tecrübesi olmayan bir yazılımcıdan test yazarak, yazılıma devam etmesini istemek, bir cobol yazılımcısına bugünden yarına nesne tabanlı program yazdırmaya çalışmak gibi birşeydir. Nitekim ikibinli yılların başlarında görev başında olan yazılımcıların bu fikri benimsemeleri mümkün olmadı. Onlar hep testlerin yazılımın en sonunda uygulanan bir aktivite olarak gördüler. Her zaman angarya olarak görülmüş test yazma olayının birden bire gündemin en başına oturarak, tüm gidişata yön verme fikrine o jenerasyon ne yazık ki adapte olamadı. Tekrar hatırlamakta fayda görüyorum. çevik olabilmeniz için yani müşteri gereksinimlerine her daim yazılım ile karşılık verebilmeniz için yeniden yapılandırma yapmak zorundasınız. Test olmadan yeniden yapılandırma yapılamaz. Bu yüzden çevik süreçlerin en temelinde bu iki prensip yatmaktadır: yeniden yapılandırma ve testler. Olay sadece test güdümlü yazılım ile bitmiyordu. Eşli programlama, sürekli entegatasyon, iterasyon bazlı yazılım gibi birçok çevik süreç metodu mevcut yazılım süreçlerini yer yer tersine çevirdiğinden dolayı, bu durum yazılımcılara sudan çıkmış balık hissi yaşatmakta ve adaptasyonu zorlaştırmaktaydı.

O dönemin yazılım sektöründe çalışanlarını şelale (waterfall) yazılım süreçlerinden geldiklerini unutmamamız gerekmektedir. O zamanın yazılım ekipleri müşteri gereksinimlerini en ince detayına kadar anladıktan ve kağıda döktükten sonra yazılım yapmaya başlarlardı. Burada bir senelik bir ön çalışma ve akabında yine birkaç sene sürebilen yazılım geliştirme sürecinden bahetmekteyiz. O gün olsun, bugün olsun yazılım projelerinin başarısız olmalarının ana sebeplerinden birisi ne yazık ki budur. Müşteri gereksinimleri doğrultusunda bir yazılım sistemine ihiyaç duyar. Müşterinin bu gereksinimleri piyasa şartları ile günlük bazda bile değişime uğrayabilirken, şelale yöntemleri ile birkaç sene kapalı kapılar arkasında yapılan yazılımın, bu zaman dilimi sonunda müşteri gereksinimlerine ne kadar az hitap edebilme potansiyeline sahip olduğunu görebilmekteyiz. Nitekim yazılım projelerindeki başarısızlık, müşteri gereksinimlerinin ne oranda karşılık göremediği ile çok yakından bağlantılı.

Hala ikibinli yılların başlarındayız ve çevik süreçlerin var olma savaşını yakından inceliyoruz. Şimdi o zamanlar yazılımın nasıl yapıldığını ve uygulanan mimarileri yakından inceleyerek, çevik süreçlerin neden tutunamadığını görmeye devam edelim.

İkibinli yılların başlarında Java programlama dili sahip olduğu ekosistemi ile tüm yazılım camiasına hakim olmaya başladı. O zamanlar EJB (Enterprise Java Beans) ile uygulama sunucularında yazılım yapanlar çok iyi hatırlayacaklardır. Tarih hep tekerrürden ibarettir, lakin umarım o günleri hiçbir yazılımcı tekrar yaşamak zorunda kalmaz. O devrin yazılım yöntemleri, araç ve gereçleri çevik süreçler için hazır değildi. Siz ne kadar iyi niyetli de olsanız ve test güdümlü yazılım ile birim testleri yazsanız bile, entegrasyon, onay/kabul testleri ve benzeri testlerin otomatik çalıştırılmaları onlarca ya da yüzlerce dakikanızı almaktaydı. Çok küçük bir değişilik yaptığınızı düşünün. Uygulamanın tekrar paketlenerek, uygulama sunucusunda çalışır hale gelmesi en az on dakikanıza mal olmaktaydı. Bunu çok defa yaşamış bir programcıyım. Çeviklik geribildirimle doğrudan orantılıdır. Yaptığınız şey size ne kadar hızlı geribildirim sağlarsa, o hızda değişilik yapabilirsiniz. Çevik olabilmek için yeniden yapılandırmamız gerekiyor. Bunun için testlerin sağladığı geribildirime ihtiyacımız var. Aynı şekilde sürekli entagrasyon yaparak, sistemin hangi derecede entegre olduğu geribildirimine ihtiyaç duymaktayız. Tüm çevik metotlar geribildirim prensibine dayanmaktadır. Geribildirim sağlanmadan, yaptığımız işin neresinde olduğunu anlamamız mümkün değildir. Geribildirim alma süresinin uzaması, bu o oranda çeviklikten uzaklaşma anlamına gelmektedir. Nitekim uygulama sunucularından kaynaklanan sebeplerden dolayı çok zaman alan test otomasyonu ilerleyebilmek adına devre dışı bırakılmak zorunda kalındı. O devrin EJB projelerine göz attığımız taktirde ya hiç ya da çok çok az oranda test koduna sahip olduğunu görebiliriz. Aynı durum bugün yapılan projeler için bile geçerlidir. Birçok güncel projede bir tane bile test metodu bulunmaması hiç şaşırtıcı değildir. Projelerin neden sürdürülebilir olmadıklarını ortadadır.

İkibin onlara kadar uygulanan yazılım prensip ve mimarileri de ne yazık ki çevik süreçler için gerekli ortamı oluşturamadı. Bahsetmiş olduğum zaman diliminde monolitler revaçtaydı. Durumun bugün bile değişik olduğu söylenemez. Trendin ama microservice mimarileri ile değiştiğine şahit olmaktayız. Peki bir monolit çevik süreçler ile geliştirilemez anlamına mı gelmektedir bu? Bu monolitin büyüklüğü ve bünyesinde barındırdığı kod kalitesi ile doğrudan ilişkili bir durum.

Çevik süreçler ile bir monoliti geliştirmek mümkün. Ama bu ne yazık ki belli bir büyüklüğe kadar sağlanabilir. O kritik büyüklüğe erişildikten sonra, sistemin küçük ve birbirinden bağımsız parçalardan oluşuyor ve geliştirilebiliyor olması gerekmektedir. Yani burada modüler bir yapıya ihtiyaç duyulmaktadır. Lakin bir monolit ne kadar modüler bir yapıda da olsa, tek bir parça olarak entegre edilmesi gerekmektedir. Burada yine test otomasyonu sorunları baş göstermektedir. Bunun yanı sıra entegrasyon süreleri uzamakta ve hızlıca yapılması gereken değişiklikler zaman almakta ve çeviklikten ne yazık ki ödün verilmesi zazuri bir hale gelmektedir. Tekrar hatırlayalım: hızlı bir şekilde geribildirim alınamayan ortamlarda çevik olunması imkansızdır.

Çevik bir yazılım ürünü yani her yeni müşteri gereksnimi ile yeniden yapılandırılabilen ve sürekli değişiklik ile başedebilen bir yazılım sistemi için belli başlı yazılım prensiplerinin, tasarım şablonlarının ve yazılım mimarilerinin uygulanması zaruridir. En basit hali ile clean code, solid prensipleri ve modüler bir mimariye ihtiyaç duyulmaktadır. Bunların uygulandığı bir proje test kültürü ile birleştiğinde her yeni müşteri gereksnimi ile hamur gibi yoğrulabilen yazılım ürünleri ortaya çıkamaktadır. Ama günümüzde bile birçok projede test kodunu bir yana bırakın clean code ya da solid prensiplerinden eser bile bulmak mümkün değildir. Testler olmadığından dolayı programcılar artık binlerce satırdan oluşan sınıfları değiştirmeye korkar olmuşlardır. Bu korkunun mevcut olduğu bir yerde nasıl yeni müşteri gereksinimleri hayat bulabilir?

Teknik açıdan baktığımızda, birçok sebepten dolayı çevik süreçlerin uygulanabilir olmadıklarını ve bu yüzden bir zaman sonra terk edildiklerini görebilmekteyiz. Lakin bunu tümüyle teknik sorunlarla ilişkilendirmek doğru değildir. Bunun yanı sıra firmalarda oluşan yazılım geliştirme kültürlerini ve organizasyonel yapıları da yakından incelememiz gerekmektedir.

Zaman içinde, çevik süreçlerin popülerliğinden de istifade edilerek benim fake agile olarak tabir ettiğim ve yazılımda çevikliği ima eden ama bunu sağlamaktan çok uzak sözde çevik süreçler oluştu. Bunların başında scrum geliyor. Scrum yakından incelendiğinde, aslında yakından, uzaktan çeviklik ile hiçbir alakası olmayan bir şey olduğu görülmektedir. Scrum ne çeviklik namına bir çevik metot ihtiva etmektedir ne de scrum ile çevik bir yazılım ürünü geliştirmek mümkündür. Çevik olmak için çevik metotlara ihtiyaç duyulmaktadır. Bunlar teknik anlamda yazılımcılar tarafından uygulanan metotlardır. Test güdümlü yazılım ya da eşli programlama gibi çevik metotları sadece yazılımcılar uygulayabilirler. Tüm çevik metotlar yazılımcılar için ve onların çevik hareket edebilmeleri için oluşturulmuşlardır. O yüzden çevik süreçler yardımı ile yazılım yapıyoruz denildiğinde, incelenmesi gereken nokta, çevik metotların ne oranda yazılımcılar tarafından yaşanıyor olduklarıdır.

Scrum ve benzeri yapılar ne yazık ki extreme programming gibi gerçek çevik metotların önüne geçtiler ve organizasyonlara çevik oldukları hissini verdiler. Kendini iyi hissetmekten öteye götüremeyen bu yaklaşımlar yazılım yapanların “çevik çalışıyor olmamıza rağmen, gerekli performansı alamıyoruz” söylenimlerine yol açtılar. Scrum ve benzeri yapılar ne yazık ki gerçek çevik süreçlerin adlarını karaladılar ve diskredite olmalarına sebep oldular. Bugün baktığınızda çevik olmayan bir yazılım ekibi bulamazsınız. Herkes scrum yapıyor ve herkes çevik. Ama ortaya çıkan yazılım ürünlerine göz attığımızda, hepsinin aynı dertlere sahip olduklarını ve aslında müşteri gereksnimlerine cevap veremeyecek yapıda, teknik ve mimarı açıdan tükenmiş olduklarını görmekteyiz.

Çevik süreçlerin önünü kapatan diğer bir durumda, yazılım ekiplerinin organizasyon yapısı olmuştur. Klasik bir yazılım ekibinde yazılımcı, testçi, analizci, sürümcü, proje yöneticisi gibi rolleri görmek mümkündür. Bir fabrika bandında üretim için uygun olan bu rol bazlı kadrolaşma, yazılım için ne yazık ki büyük sorular doğurmaktadır. Çevik süreçler yazılım, test, analiz, sürüm ve canlı işletme sorumluluğunu (production) yazılım ekibini oluşturan yazılımcılarda görmektedir. Yazılımcılar yazılım ile ilgili her şeyi yapamazlar mantığı doğru değildir. Mühendislik altyapısına sahip bu kişilerin günümüzde sadece kod yazmak için uygun olduklarını düşünmek en kibar ifadeyle onlara yapılan haksızlıktır. Nitekim Google tarafından uygulanan SRE (Site Reliability Engineering) ve DevOps gibi akımlara baktığımızda, yazılım ekibinin yazılım için gerekli tüm işlevleri yerine getirdiklerini görmekteyiz. Yazılımın, testin, analizin ve sürümün ayrı ekipler tarafından yapıldığı ortamlarda, çevik süreç faydalı olamamaktadır. Bu tür ayrıştırıcı organizasyonel yapılar olduğu sürece, çevik yazılım yapmak ne yazık ki mümkün değildir.

Yazılımda teknik sürdürülebilirlik için gerekli etkenleri ele almaya çalıştım. İsmi illa çevik süreç olmak zorunda değil. Lakin sürdürülebilirlik için atılması gereken somut adımlar var. Yazılımcının ana görevi sadece kod yazmak değildir. Mevcut organizasyonel yapılar bunun doğru olduğu fikrini savunsalar da teknik sürdürülebilirlik için yazılımcılara daha fazla sorumluluk verilmesi gerekmektedir. Yeni gereksinimlerin ivedilikle yazılım ürününe entegre edilebilmeleri için kodun her daim hamur gibi yoğrulabilmesi gerektirmektedir. Bunu sadece ve sadece yazılımcılar yapabilirler. Bunun için yüksek seviyede teknik beceriye ihiyaç duyulmaktadır. Bu da mühendisliğin hakkını verebilen yazılımcılarla mümkün olabilecek bir iştir.

Buraya kadar bahsetmiş olduğum nedenlerden dolayı çevik süreçler ne yazık ki hak ettikleri yere gelemediler ve haksız yere işe yaramaz damgasını gördüler. Ama ben bu durumun değişme sürecine girdiği düşüncesindeyim. Çevik süreçlerin işlemesini engelleyen unsurların yavaş yavaş kaybolmaya başladıklarına şahit olduğumuz bir dönemden geçiyoruz. Bu unsurlardan bazılarını yakından inceleyelim.

Artık günümüzde monolitlerin terk edilmeye yüz tutmuş bir mamarı türü olduğunu görmekteyiz. Modern yazılım sistemleri küçük ve birbirlerinden bağımsız çalışan modüllerden oluşmakta. Bunu sağlamak için microservice, webservice, rest ve soa gibi mimariler ve kubernetes, docker ve cloud gibi altyapı ve teknolojiler tercih edilmekte. Belli bir büyüklüğü geçmeyen ve otonom çalışan kod birimlerinin bakımı, geliştirilmesi, test edilmesi, sürümlenmesi ve işletilmesi geçmişe nazaran çok daha kolay.

Günümüzde yazılım ekiplerinin yapıları da değişmeye başladı. Örneğin Google bünyeside SRE olarak bilinen takımlar, test etmeden işletime kadar uygulamanın her yönüyle ilgileniyorlar. Birçok yeni ekip iki pizza prensibine göre oluşturuluyor. İki pizza ile doymayan bir ekip, büyüklüğü itibari ile monolite dönebilecek yapılar oluşturma eğilimi gösterebilmektedir. Küçük ekip ve tek sorumluluk prensibi kolay değiştirilebilir ve geliştirilebilir yazılım birimleri için sihirli bir formül haline geldi.

Bunun yanı sıra yazılımcılar eskiye nazaran tasarım prenbipleri, tasarım şablonları ve yazılım mimarileri konularında daha donanımlı hale geldiler. Clean code, software craftşman ve devops akımları, yazılımcıların teknik olarak daha da iyi olmaları için gerekli fikir ve pratikleri ihtiva ediyorlar. Ayrıca günümüzde eskiye kıyasla yazılımda teknik sürdürülebilirliği destekleyici, sonar, jenkins, git gibi birçok açık kaynaklı ürün bulmak mümkün.

Müşteri cephesinde de bazı değişiklilerin meydana geldiğini görmekteyiz. Müşteri eskisi gibi artık yıllar sonra kullanmaya başlayacağı bir yazılım ürünü siparişi vermek istemiyor. Müşteri bugün siparişini verdiği yazılım ürününün ilk sürümünü birkaç hafta sonra kullanmaya başlamak isteyebiliyor. Buna sadece çevik süreç ve iterasyon bazlı çalışma ile cevap vermek mümkün. Ayrıca müşteri için bir yazılım ürününün kullanılabilirlik seviyesi de değişmiş durumda. Piyasa rekabetinden doğan yeni gereksinimlerinden dolayı müşteri yıllarca beklemek yerine, sürekli geliştirilen, gereksinimler doğrultusunda adapte edilen ve her daim kullanılabliir yazılım ürünlerine yönelebiliyor.

Yirmi sene öncesi çevik süreçler ve tdd, bdd, pair programming, ci, refaçtoring, solid gibi çevik metotlar uygulanmaya başlandığında devir monolitlerin hakim olduğu mimarı devirdi . Çevik süreç ile bir monolit geliştirmek sadece iyi bir niyetten öteye gidemedi ve bu yüzden çevik süreçlerin bir işe yaramadığı düşünüldü. Oysaki container ve microservice dünyası için çevik süreç biçilmiş bir kaftan. Yıldızı söndüğü zannedilen çevik süreçler bulut bilişim ile ne olduklarını ispatlayacaklar.


Not: Eğer extreme programming gibi safkan bir çevik sürecin nasıl işlediğini merak ediyorsanız, size pratik agile isimli ücresiz kitabımı tavsiye etmek isterim. Çevik süreçler hakkındaki yazılarıma buradan, buradan ve buradan ulaşabilirsiniz.


EOF (End Of Fun)
Özcan Acar

Yazılım Dünyasının Hızlı Çözüm Üretmek İle Olan İmtihanı

Yazılım neden vardır sorusu sorulduğunda, benim aklıma gelen ve benim için en anlamlı cevap yazılımın müşterinin gereksinimlerini tatmin etmek için var olduğudur. Müşteri piyasa ihtiyaçlarından doğan gereksinimlerini tatmin etmek ya da piyasa rekabetinde avantaj sağlamak için yazılıma yönelir. Yazılım müşterinin piyasa şartlarında ayakta kalkmak için kullanacağı en kıymetli araç haline gelebilir. Sektörüne göre yazılım olmadan bir firmanın piyasa işlevini yerine getiremediğini, rakiplerine yenik düştüğünü ve yök olduğunu ya da yetersiz yazılım yüzünden yok olma riski ile karşılaştığına tanık olmak mümkündür.

Yazılımın artık çok kıymetli bir konumda olduğu konusunda hemfikir olduğumuzu düşünüyorum. Böyle bir ihtiyacın olması yazılım sektörünün temelini oluşturuyor. Firmalar ihtiyaçları doğrultusunda ya kendi yazılım takımlarını oluşturuyorlar ya da mevcut yazılım ürünlerini satın olarak bu konudaki ihiyaçlarını tatmin etmeye çalışıyorlar.

Burada yapı olarak çok değişik iki dünyanın karşı karşıya geldiğini görmekteyiz. Bir tarafta çok hızlı değişen piyasa koşulları neticesinde oluşan yeni müşteri gereksinimleri, diğer tarafta o kadar çok da hızlı müşteri gereksinimlerine adapte olmayan yazılım ürün/ürünleri. Müşteri bulunduğu piyasada önde gidebilmek için kullandığı yazılım ürününde hızlıca değişiklik yapılmasını talep edecektir. Lakin yazılımdaki en büyük problemlerden birinin bu noktada oluştuğuna tanık olmaktayız. Ne yazık ki kurumsal çerçevede geliştirilen yazılım ürünlerde istenilen değişikliklerin rekabetin önünü açacak hızda yapılamadığını görmekteyiz. Bunun başlıca sebebi yazılımda silolaşmaya gidilmesidir.

Günümüzde yazılım değişik vasıflara sahip grupların birlikte çalışarak yerine getirilen bir aktivitedir. Yazılımcılar kod yazmaktan, testçiler bu kodu test etmekten, oplar yazılan ve test edilen kodu canlıya almaktan sorumludur. Sadece bir önceki cümle içinde bile üç değişik meslek gurubunun adı geçti. Bunlara analizcileri, proje yöneticilerini ve ürün sahiplerini de eklersek, aslında çok değişik nitelikteki insanların bir araya gelerek, yazılım oluşturduklarını görmekteyiz. Ama bu gerçekten böyle olmak zorunda mıdır? Asıl sıkıntılar buradan kaynaklanıyor olabilir mi? Neden yazılım silolardan oluşan değişik ekiplerin elinden geçerek, oluşmak zorunda?

Yazılımla uğraşan herkes bilir. Yazılımcı ekibi yazdıkları kodun canlıya alınmasından, canlıyı (production) koruyup, kollayan op ya da admin ekibi de yazılımdan bihaberdir. Op ya da adminler her zaman canlının canlı kalması için ellerinden gelen her türlü işlemi yaparlar ve yeni yazılım ürünleri ya da mevcut yazılım ürünlerinin yeni sürümlerini canlıya almak için kırk dereden su getirirler. Onların uzun checklisteleri vardır. Bu listeler canlıyı korumak amacılıdır lakin hem yazılımcıları canlarından bezdirirler hem de değişikliklerin hızlıca canlıya alınmasını engellerler. Bu sadece op ya da adminlerle sınırlı bir durum değildir. Yazılıma yeni bir özelliğin eklenip, canlıya alınması aylar sürebilmektedir. İş ne yazık ki değişik silolarda çalışan değişik nitelikteki çalışanların tüm resmi göremeyerek, sadece kendi siloları bünyesindeki çalışmalara odaklanmalarından dolayı uzayaip gider.

Durumu kısaca özetleyecek olursak… Bir tarafta hzli değişeçen piyasa koşullarına adapta olmak isteyen müşteri ve yazılımdan olan beklentileri, diğer tarafta değişik silolarda organize olmaya çalışan ve yeterli hızda müşteri isteklerine cevap veremeyen yazılım ekipleri. Burada kaybeden kimdir? Her iki taraf da!

Yazılım sektörü ve camiası uzun bir süredir problemin farkında ve yer yer çözüm üretmeye çalışıyor. Bu çözümlerden birisi DevOps olarak bilinen akım. DevOps benim tanımıma göre yazılımı yapan, canlıda işleten ve her türlü yetki ve sorumluluğa sahip yazılımcıdır. Lakin yine bu konuda da işin sulandırılması sağlanmış ve yazılımcı ekibine gerekli tüm yetki ve sorumluluk verileceği yerde, op ve adminlerin biraz yazılımdan anlayacak ve gidişata destek olacak şekilde yeniden konuşlandırılması sağlanmış ve silo düşüncesine sağdık kalınması yeğlenmiştir. Hala hazırda birçok kurumsal altyapıda devopsları, testçileri ve yazılımcıları beraber çalışır durumda görmek mümkündür. Bir şekilde, yazılım sistemini oluşturan yazılımcıların aynı zamanda canlı için sorumluluk taşıyabilecekleri ve bu görevi yerine getirebilecekleri inancı hala oluşmamıştır. Bunun sebebi nedir?

Bunun başlıca sebebi yöneticilerin yazılımın nasıl işlediğinden bihaber olmaları ve yazılım için gerekli organizasyonel yapıyı oluştururken klasik kurumsal kadrolaşma ve iş yapma şablonlarından faydalanmalarıdır. Klasik organizasyonel yapılarda birileri bir ürünü oluşturur, birileri gerekli tasarımı yapar, birileri kalite konotrulünden sorumludur ve birileri de bu ürünleri pazarlar. Roller ve iş tanımları birbirlerinden keskin bir şekilde ayrıdır ve herkesin görevi detaylı olarak tanımlıdır. Lakin bir yazılım ürünü söz konusu olduğunda, ürünün pazarlanması haricinde gerekli tüm işlerin yazılımcılar tarafından yapılabileceğini söyleyebiliriz. Bunun en güzel örneğini Extreme Programming gibi gerçek çevik yazılım metotlarının uygulandığı projelerde görmek mümkündür. Böyle birçok projede yazılımcı olarak çalışmış birisi olarak söyleyebilirim ki gerçek bir çevik süreç içinde yazılımcılar her türlü sorumluluğu üstlenebilirler ve doğru olan zaten budur.

Klasik iş ayrımı verimliliği artırmak ve vasıf bazlı ücretlendirmeyi mümkün kılmak için kapitalizmin oluşturduğu bir prensiptir. Örneğin klasik bir fabrika üretiminde bant üzerinde oluşan ürün kademeli olarak değişik ellerden geçer. Ürünün oluşumuna katkı sağlayan her el belli bir vasfa sahiptir ve çok hızlı bir şekilde kendi üzerine düşen görevi yerine getirir. Eğer ürüne dokunan el gerekli vasfa sahip değilse, ürünün oluşturulma süreci uzar ve bu maliyeti artırır. Bu yüzden vasıflar silolar bünyesinde gruplaştırılır ve ürün üzerinde iş gücü olarak uygulanır. Seri şekilde üretim yapıldığı sürece bu tarz bir iş gücü organizasyonunun faydalı olduğunu söyleyebiliriz. Lakin nasıl bir ürünün ortaya çıkacağı belli olmayan durumlarda, bu silolaşma ne yazık ki iş koordinasyonu, bilgi ve vasıf yetersizliği ve tüm resmi görememe gibi durumlardan ötürü istenilen sonucun sağlanması konusunda yetersiz kalmaktadırlar. Bunun ispatını günümüzde uygulanan bilimum yazılım projelerinde görmek mümkündür.

Yazılım endüstrisinin yaptığı işten verim almak için ihtiyaç duyduduğu tüm araç, gereç ve metodolojiler gözünün önünde durmaktadır, lakin bunları kullanmak yerine nedendir bilinmez, iş gücünü silolaşmaya götürmekte inat etmektedir. Extreme Programming gibi çevik süreçler yazılımın nasıl yapılması gerektiği konusunda gerekli tüm metotları ihtiva etmektedirler lakin sahip oldukları inovasyon gücü göz ardı edilmektedir.

Çevik süreçlerde bilimum sorumluluk yazılım ekibindedir. Yazılım ekibi müşteriye kulak verir, gerekli yazılımı yapar ve çok kısa aralıklarla oluşan yazılım ürününü müşteriye gösterek, geri bildirim sağlar. Bu geri bildirim ile istikametini belirler. Kendisi yazar, kendisi test eder, kendisi canlıya alır ve kendisi hataları giderir. Google Site Reliability Engineering ismi altında bu prensibi uygulamaktadır. Google yazılım ürünlerinde bütün işi çekip, çeviren yazılımcılardan oluşan takımlardır.

Yazılım endüstrisi kör değil. O da gidişatın doğru olmadığının farkında ve DevOps gibi yerinde ama uygulanışı absürd olan yöntemler geliştirilmekte. Yazılımdan anlamayan sistem adminlerini birkaç günlük bulut eğitimlerine göndererek, onların DevOps olması sağlanamaz. DevOps ile kasıt, canlı ile arasında hiçbir engel kalmamış ve canlının sorumluluğnu da üstlenmiş, yani bu işi a dan z ye yapabilen yazılımcılardır. Bunu anlaması neden bu kadar zordur? Karşımızda bu işin üniversitede eğitimini almış ve her türlü mühendislik çözümü üretebilen yüksek vasıflı yazılım ve bilgisayar mühendisleri durmaktadır. Onları bir kenara koyup, “siz sadece kod yazın” demek, yaşadığımız sorumların başlıca nedenidir.


Özcan Acar
EOF (End Of Fun)

Alan Borcu (Domain Debt)

Buradaki yazımda teknik borcun ne olduğunu, nasıl oluştuğunu ve nasıl ödenebileceği konusuna değinmiştim. Teknik borç kodu doğrudan ilgilendiren ve projenin sürdürülebilirliğini etkileyen bir durumdur. Bu yazımda teknik borç kadar dikkat görmeyen, lakin yazılım projesinin kaderini teknik borçlanmaya nazaran daha belirleyici olan alan borçlanmasından bahsetmek istiyorum.

Her yazılım sisteminin hitap ettiği bir alan (domain) vardır. Bu alanda yer alan iş süreçleri yazılım sisteminin şekillendirilmesinde yön verirler. Yazılım sisteminin merkezinde alan modeli (domain model) yer alır. Alan modeline dayalı olmayan ya da alandaki iş süreçlerinden doğan gereksinimleri tatmin edemeyen yazılım sistemi oluşturulma hedefine ulaşamamıştır ve alan kullanıcıları tarafından kullanılabilecek yapıda değildir.

Bir önceki paragrafta yer alan teknik terimleri bir örnek üzerinde inceleyelim. İnternet üzerinden sipariş yapmak için kullanılan bir sistemin hitap ettiği alan internet tabanlı alışveriştir (online shopping). Yazılım sisteminin merkezinde yer alan alan modelindeki öğeler (entity) müşteri, sipariş, ürün, adres, ödeme şekli, fatura, alışveriş sepeti gibi yapılardır. Alan kullanıcıları sipariş veren müşteriler ya da gelen siparişleri gözden geçiren çalışanlardır. Örneğin bir müşterinin sipariş verebilmesi için önce seçtiği ürün ya da ürünleri alışveriş sepetine eklemesi gerekmektedir. Siparişin temelini bu örnekte alışveriş sepeti oluşturmaktadır. Bunun yanı sıra müşterinin adres ve ödeme bilgileri sipariş esnasında girmesi gerekmektedir. Sistem çalışanları yönetim paneli aracılığı ile gelen siparişler hakkında bilgi edilebilirler. Burada iş süreçleri devreye girmektedir. Mevcut bir siparişin nasıl yönetildiğini bir iş süreci belirler. Bu iş süreci siparişin yönetimi ile ilgili tüm detayları ihtiva eder. Yazılım sistemi bu detayların koda dökülmüş halidir. İş süreçlerinden gereksinimler doğar ve yazılım sistemi bu gereksinimleri tatmin etme görevini üstlenir.

Oluşturulan yazılım sistemi sadece gerçeği modellemeye çalışan bir araçtır. Bu model gerçeğe ne kadar yakın ise, o oranda yazılım sisteminin kullanımı kolaylaşır ve teşvik edilir. Oluşturulan modelin gerçek ile örtüşür hale gelebilmesi için yazılım ekibinin yazılım sistem sahibi yani müşterileri ile sıkı diyalog halinde olmaları gerekmektedir. Bu her zaman geçerli olmamakla birlikte, sadece müşteri nasıl bir sistem sahibi olmak istediğini bilebilir. Burada yazılım ekibinin öncelikli görevi müşteri gereksinimlerini tespit etmek, iş süreçlerini anlamak ve buradan yola çıkarak bir alan modeli oluşturmaktır. Alan modeli ve iş süreçlerinin implementasyonu gerçeğe ne kadar yakın olurlarsa, projenin başarılı olması o oranda artacaktır. Bunun eksikliği müşterinin kullanmayı reddettiği ve gereksinimlerini tatmin etmeyen bir yazılım ürünü olacaktır.

Bu açıklamalar ışığında alan borçlanmasının ne olduğunu ve nasıl oluştuğunu inceleyelim. Alan borçlanmaları oluşturulan alan modeli ve iş süreçleri implementasyonlarının mevcut ve gelecekteki yeni gereksinimleri tatmin etmek üzere yapılan çalışmaların zora girmesi ile kendilerini gösterirler. Alan borçlanmalarının oluşma şekillerini şu şekilde sıralamak mümkündür:

  • Yazılım ekibi müşteriyi ve gereksinimlerini yeterince anlamadığı için yazılımı yanlış bir model üzerine inşaa eder. Model gerçekleri yansıtmadığı için yazılım ekibi müşteri gereksinimlerini implemente etmekte zorlanır.
  • Mevcut alan modeli genel tutulduğundan ve alt alanlarda (subdomain) ortak kullanıldığından çok sıklıkla değişikliğe uğrar ve alt alanların ihtiyaçlarını tatmin edemez hale gelir. Bu şekilde yapılmak istenen değişiklikler zorlaşır, çünkü model tüm alt alanları destekleyecek esnekliğe sahip değildir.
  • Müşterinin gerekli bilgileri sağlamaması neticesinde yazılım ekibi doğru düşündüğü şekilde modeli oluşturur. Yeni gelen bilgiler doğrultunda modelin yetersiz olduğu tespit edilir. Bu proje bünyesinde geniş çaplı bir yeniden yapılandırma (refactoring) gereksinimi doğurabilir. Bu çapta bir yeniden yapılandırma için gerekli zaman olmadığı için mevcut alan modeli uygulamanın çeşitli yerlerinde oluşturulan yerel alan modellerine dönüştürülerek (mapping) tekrar kullanılır.
  • Programcılar genel alan modelinde yer alan öğelerden bazılarını yerel implementasyonlarında tekrar (reuse) kullanırlar. Lakin kullanım bağlamı (context) değiştiği için kullanılan ögeler yetersiz kalabilir. Aynı zamanda genel alan modelinde yapılan değişiklikler ögelerin başka bağlamda kullanıcılarını kırılgan hale getirebilir.

Kimi zaman bilgi yetersizliği, kimi zaman yanlış anlaşılmalar ve kimi zaman zaman yetersizliği alan borçlanmasına sebep verebilmektedir. Teknik borçlanmalara kıyasla alan borçlanmaları bir projenin tamamen durma noktasına gelmesine sebep olabilmektedirler. Bunun önüne geçmek için yazılım ekibinin alan eksperleri ile sıkı bir diyalog içinde olmaları ve ortak bir alan dili oluşturmaları gerekmektedir. Bu ortak dil programcıların ihtiyaç duyulan alan modelini oluşturmalarını ve gerekli şekilde kullanımını kolaylaştırıcı nitelikte olacaktır.

Alan borçlanmasını önlemek için müşteri ve yazılım ekibi arasında sıkı bir diyaloğun ve ortak bir alan dilinin oluşturulması gerektiğinden bahsettim. Peki teknik olarak alan borçlanmasını önlemek için kullanılabilecek yöntemler var mıdır? Teknik borcun ödenmesinde olduğu gibi alan borçlanmaları da kod yeniden yapılandırılarak ödenebilirler. Bu çok masrafla bir uğraşı haline dönüşebilir. Durumun bu hale gelmesini önlemek için projenin başlangıç safhalarında gerekli önlemlerin alınması gerekmektedir. Bu yöntemler nelerdir?

Domain Driven Design (DDD) olarak bilinen yöntemde sınırlı bağlam (bounded context) olarak bilinen bir metot mevcuttur. Bu metot ile sınırlı geçerlilik alanı bulunan alan modelleri oluşturulur. Modeller birbirlerinden bağımsızdır ve geçerli oldukları alanlar belirlidir. Modellerin ya da sahip oldukları parçaların tanımlandıkarı bağlam haricinde kullanılmları yasaktır. Bu şekilde bir model bir sorumluluk prensibi uygulanmış olur. Tek sorumluluk prensibinden de bildiğimiz gibi bir yazılım öğesinin birden fazla sorumluluk taşıması onun kırılganlığını artırır. Sınırlı bağlam bunu önleyici bir yöntemdir ve oluşturulan alan modellerinin tek bir sorumluluk ile tanımlanmalarını mümkün kılar.

Teknik ve alan borçlarıyla başetmenin en verimli yöntemi oluşmalarını engellemektir. Bunun için kullanılabilecek yöntemlerin başında çevik süreçler gelir. Örneğin test güdümlü yazılım yeniden yapılandırma süreci kolaylaştırır. Hızlı bir şekilde yapılabilen yeniden yapılandırma kodu rehin alan her türlü borcun ödenmesini kolaylaştırır. Ama kanımca çevik süreçlerde her türlü borçlanmayı engelleme potansiyeline sahip başka bir yöntem daha mevcuttur. Bu yöntem aracılığı ile belli zaman dilimlerinde yeni sürümler oluşturularak, gelinen durum müşteri ile paylaşılır. Müşteriden alınan geribildirim aracılığı ile model hataları kısa zamanda farkedilir ve gerekli düzeltmeler gerçekleştirilir. Burada çevik süreçler bünyesinde yer alan yazılım metotlarının tamemen geribildirim döngüleri üzerine kurulu olduğunu söylemek doğru olacaktır. Test yazımı, sürekli entegrasyon, eşli programlama, sürekli yeni sürüm oluşturmak her daim geribildirim alınmasını ve gerekli rota değişikliği yapılamasını mümkün kılar. Bu bağlamda teknik ve alan borçlarının aslında yetersiz ya da mevcut olmayan geribildirimi döngülerinden kaynaklandığını söylemek yanlış olmayacaktır.

Teknik borç konusunun yazılımcılar arasında sıkça dile gelen bir konu olduğuna şahit olmaktayım. Lakin alan borçlanması o kadar sıkça dile gelen bir konu değildir. Her yazılım projesinde alan borçlanmasına şahit olmak mümkündür. Kod kalitesi ne kadar iyi olursa, olsun yanlış bir alan modeli yeni değişikliklerin yapılmasını zorlaştıracaktır. Bu duruma gelmemek için öncelikle alan borçlanmasını da ciddi bir proje riski olarak görülmesi ve projenin başlangıcından itibaren bu konuya gerekli önemin verilmesi gerekmektedir.


EOF (End Of Fun)
Özcan Acar

Agile Türleri

Coca Cola’nın kaç türü var, bilirsiniz… Cola light, Cola zero, Cola classic…. Çevik süreçler için de aynı şey geçerli. Ben çevik süreçleri agile zero, agile light ve hardcore agile ya da classic agile olarak üç bölüme ayırıyorum.

Agile Zero

Çalışma ortamında çevikliğe dair hiçbir ibare yoktur.

Belirtileri

  • Projede hiçbir birim, entegrasyon ya da onay/kabul testi yoktur.
  • Proje kesinlikle zamanında yetişmez.
  • Yeni müşteri gereksinimlerinin uygulamaya eklenmeleri çok zaman alır, çünkü uygulama mimarisi esnek ve değiştirilebilir yapıda değildir. Öyle olsa bile testlerin olmaması, kodun ve mimarinin yeniden yapılandırılması engeller.
  • Uygulamada çok bug vardır ve çoğu keşfedilmemiştir.
  • Uygulama elden test edildiği için hem çok zaman kaybedilir hem de test geniş kapsamlı yapılamaz.
  • Entegrasyon çok zaman alır ya da yer yer mümkün değildir, çünkü uygulama sürekli entegre edilmemiştir.
  • Sürüm belli bir yazılımcının bilgisayarında alınır. O yazılımcı tatile gittiğinde başka bir kurban yazılımcı seçilir. Buna kısaca releaser hopping ismini veriyorum.
  • Müşteriye belirli aralıklarla çalışan bir prototip sunulamaz, çünkü uygulama entegre edilemediğinden çalışır halde değildir.
  • Yazılımcılar stres altındadır ve fazla mesai yapmaya zorlanırlar.
  • Her şey önceden planlanmaya çalışılır. Buna müşteri isteklerinin tam teşekküllü yazılım öncesi tespiti de dahildir.
  • Yazılım öncesinde uygulama mimarisi bir mimar tarafından tespit edilmiştir. Yazılımcılar bu mimaride öngörülen şartlara uymak zorundadırlar. Yeni müşteri istekleri ile mimarinin adapte edilmesi söz konusu iken, kod birim testleri eksikliğinden dolayı yeniden yapılandırılamaz. Böylece uygulama mimarisi yeni müşteri isteklerini taşıyacak şekilde adapte edilemez. Zaten mimar böyle bir şeye içgüdüsel olarak karşıdır. Kısaca yazılımcının uygulama mimarisini değiştirme konusunda inisiyatifi yoktur.
  • Müşteri için piyasadaki rekabet şartlarının değişmiş olabileceği bilindiği halde, sürüm zamanları uzun tutulur. Bu uzun bir zaman diliminden sonra müşteriye sunulan sürümün müşterinin işine yaramayacağı anlamına gelebilir. Kısa zamanlı sürümlerle müşterinin fikri alınmış olsa idi, bu sorunun önüne geçilebilirdi.
  • Son kullanıcılar tonlarca bug bulup, yazılımcıların uzun bir süre bu bugları temizlemek için uğraş vermelerine sebep olurlar. Böylece yeni müşteri gereksinimlerinin implementasyonu geriye atılır.

Agile Light

Scrum gibi bir çevik süreç kullanılıyordur. 

Belirtileri

  • Ekip sadece Scrum kullanarak gerçekten çevik olduğunu düşünür.
  • Projede hiçbir birim ve entegrasyon testi olmayabilir.
  • Çeviklik sadece proje yönetiminden (sprint planlaması ve uygulaması) ibarettir.
  • Sprint sonunda müşteriye çalışır bir sürüm/prototip sunulabilir.
  • Yeni müşteri gereksinimlerinin uygulamaya entegrasyonu çok zaman alır, çünkü test güdümlü yazılım ya da eşli programlama metotları uygulanmaz. Uygulamaya yeni gereksinimlerin eklenebilmesi için uygulamanın yeniden yapılandırmaya ihtiyacı olabilir. Test güdümlü çalışma neticesi olarak geniş kapsamlı birim test seti olmadığı taktirde, uygulamayı yeniden yapılandırmak harikiridir.
  • Ekip yazılımcılar ve testçiler olarak iki guruba ayrılır.
  • Uygulamayı test etmek için geniş çaplı onay/kabul test setleri hazırlanır. Onay/Kabul testlerini hazırlayan testçi ekibidir. Onay/kabul testleri yazılımcılar tarafından geliştirilen birim testlerin yerine hem geçemezler hem de yazılımcılar tarafından kodu yeniden yapılandırmak (refactoring) için kullanılamazlar, çünkü koşturulmaları saatler alır.
  • Uygulama bir sürekli entegrasyon sunucusu kullanılarak entegre ediliyor olabilir.
  • Agile Zero da uygulama mimarisi için söylediklerim agile light için de geçerlidir.

Agile Classic

Ekip katıksız olarak çevik süreç metotlarını uygular. 

Belirtileri

  • Ekibin parçası olan her yazılımcı test güdümlü yazılım yaparak geniş kapsamlı birim testi seti oluşturur. Test güdümlü çalışma zorunluluğu yoktur. Önemli olan testlerin gerçekleri yansıtacak şekilde kodu kapsamalarıdır (code coverage).
  • Proje yönetimi Scrum’da olduğu gibi iterasyon bazlı yapılır. İterasyon uzunluğu 2-4 hafta arasıdır.
  • Jenkins ya da Bamboo gibi bir sürekli entegrasyon sunucu kullanılarak kod devamlı entegre edilir.
  • Kodu yaptığı değişiklikle kıran yazılımcının masasına bunu gösteren bir oyuncak ayı bırakılır. Bu oyuncak ayı kodu kıran bir yazılımcıdan diğerine el değiştirir. Her yazılımcı kodu kullandığı versiyon kontrol sistemine eklemeden önce (commit) tüm birim testlerini koşturarak, kodun içinde bulunduğu durumu kontrol eder. Çalışmayan ya da kırık kod eklenmez.
  • Yeni müşteri istekleri zorluk çekilmeden uygulamaya dahil edilir, çünkü testler sayesinde kodun yeniden yapılandırılması (refactoring) kolaydır.
  • İterasyon sonunda müşteriye çalışan bir prototip sunulur. Müşteri isterse bu prototipi aktif olarak günlük işinde kullanmaya başlar.
  • Yazılımcının sorularını cevaplamak için ya müşteri ekibin yakınlarındadır ya da müşteriyi temsil eden bir vekil vardır. Yazılımcı sorularını doğrudan müşteriye ya da vekiline yöneltir. Müşteri ile yazılımcı arasına analist, proje yöneticisi, firma sahibi ya da başka bir şahıs giremez.
  • Ekipte Scrum Master ya da Product Owner gibi roller yoktur. Ekibin dadıya ihtiyacı yoktur. Ekip içindeki yazılımcılar her şeyden sorumludur.
  • Ekip uygulamayı müşteri isteklerinin öncelik sırasına göre geliştirir. Uygulamaya hangi özelliğin ekleneceğini her zaman müşteri belirler.
  • Yazılımcılar mesailerini sekiz saat ile sınırlı tutarlar. Daha fazlasına gerek yoktur, çünkü yazılım geliştirme süreci planlandığı şekilde ilerler.
  • Her iterasyon sonunda yazılımcılar bir araya gelerek, geçmiş iterasyonu analiz ederler (retrospective). Her yazılımcı düşündüğü artı ve eksiler hakkında düşünce beyan eder. Maksat başkası hakkında olumsuz fikir beyan etmek ya da sorumlu bulmak değildir. Bu da bir geri bildirim türü olduğu için ekip içinde bulunduğu durumu daha iyi kavrar ve tespit edilen olumsuzlukların bir sonraki iterasyonda meydana gelmelerini engeller.
  • Uygulama mimarisi yazılım sistemi ile geliştirilir. Her yazılımcı inisiyatif kullanarak, uygulama mimarisini güncel implemente edilen müşteri gereksimini taşıyacak şekilde adapte edebilir.

Ne zaman çevik oluruz? Kodu hamur gibi yoğurabildiğimizde!


EOF (End Of Fun)
Özcan Acar

Yazılımda Çeviklik İflas mı Etti?

Çevikliğin Böylesi başlıklı yazımı okudunuz mu? O yazımda çevik kelimesinin yerli yersiz her şey için kullanıldığını ve bu yüzden anlam erozyonuna ugradığından bahsetmiştim. Bu yazımda çevikliğin tanımını yapmaya çalışacağım.

Martin Fowler bu link üzerinden ulaşabileceğiniz yazısında şöyle diyor:

… lack of rigorousness is part of the defining nature of agile methods, part of its core philosophy. … Any attempt to define a rigorous process that can be tested for conformance runs contrary to [the agile] philosophy.

Martin Fowler yazılımda çevikliğin belli bir çerceveye sokulmuş bir süreç (process) olarak tanımlanmasının mümkün olmadığını, bunun çeviklik filozofi ve düşüncesine ters düştüğünü söylüyor.

Bazı kesimler Martin Fowler’in sözlerini çevikliğin iflası olarak yorumlayabilirler. Onların mutlaka katıksız bir tanımlamaya ihtiyacı var, çünkü ipe sapa gelmeyen bir şeyin pazarlamasını yapmak mümkün değil. Bu yüzden çeviklik filozofisinin sadece bir kısmını ihtiva eden yarım yamalak çevik süreçler tanımlamaya ve satmaya çalışıyorlar. Onlar için önemli olan elle tutulur, gözle görülür ve ölçülebilir bir süreç tanımlaması yapmak. Eğer A, B, C adımlarını uygularsan, X, Y neticesini elde edersin diyebilmek istiyorlar. Keşke müşteri gereksinimleri odaklı yazılım bu kadar basite indirgenebilseydi!

Bu sebeptendir ki birçok sözde çevik süreç ile istenilen neticeler elde edilemiyor, çünkü sürecin ihtiva ettiği adımları birebir uygulamak her projede mümkün olmuyor. Doğal olarak bu durumda sürecin yeniden tanımlanıp, ihtiyaçlar doğrultusunda yeniden yapılandırılması gerekiyor. Sözde çevik süreçler bu değişime izin vermedikleri için yazılımda çeviklik yarı yolda kalıyor.

Benim Çeviklik Tanımım

Ben yazılımda çevikliği bir soğanın kabukları gibi iç içe geçmiş, değişik katmanlardan oluşmuş bir yapı olarak görüyorum. En üst katmanda değişikliklere karşı koymadan, onlarla beraber yaşayabilmek için gerekli olan cesaret yer alıyor. Yazılımda çeviklik cesaret ile başlar ve en içteki katmana kadar varlığını sürdürür. Değişiklikle yaşamak ve yeni yollar, yöntemler keşfetmek için birey ve ekip bazında casaret gereklidir. Bunun olmadığı yerde sadece sözde çeviklik olabilir.

Sözde çevik süreçlerde cesaretin yerini sabit süreç tanımlamarı alır. Bunlar tek tek ve sırayla atılması gereken adımlardır, bir nevi yemek tarifidir. Değişikliğe bu şekilde bilinçaltı karşı konulmaya ve her şey daha kontrol edilir hale getirilmeye çalışılır. Yazılım projelerinde değişmeyen tek parametrenin değişikliğin kendisi olduğunu düşünecek olursak, sabit süreç tanımlamaları ile buna karşı koymanın imkansız olduğu ortadadır. Sabitlik isminden de anlaşıldığı gibi dinamizmin karşıtıdır ve ani değişikliklere cevap verebilecek nitelikte ya da değişikliklere adapte olacak yapıda değildir. Değişikliğe karşı koymanın tek yolu, ona karşı koymamak ve onunla beraber yaşamayı ögrenmekten, bunun yolu da cesaret ve cesaretli olmaktan geçer.

Casaret aynı zamanda müşteriye devamlı ne istediğini sorabilmektir. Bu amaçla yazılımda çeviklik çok kısa döngülerin doğurduğu geribildirimlerden beslenir. Bu döngülerin başında proje gidişatını yönlendirmek için kullanılan iterasyon bazlı planlama yer alır. Değişikliğin her an damdan düşer gibi projeyi alt üst edebilecegini varsaydığımızda, buna karşı koymanın en kolay yolu, projeyi kısa ve tanımlanmış zaman dilimlerinde müşterinin gereksinimlerini tatmin edecek seviyeye getirmektir. Bu örneğin bir ya da iki haftalık bir zaman dilimini ihtiva eder. Bu zaman diliminde müşteri kendisi için önemli olduğunu düşündüğü gereksinimlerini tespit edip, gerçekleştirilmek üzere yazılım ekibiyle paylaşır. Yazılım ekibi müşterinin seçmiş olduğu gerekli gereksinimleri hayata geçirir. Ekip seçilen gereksinimlerin öngörülen zaman diliminde tamamlanır tarzda olmasına dikkat eder. Öngörülen zaman dilimi tamamlandığında müşteriye çalışır bir prototip sunulur ve kendisinden geribildirim sağlanır. Bu noktatan itibaren müşteri gidişati kontrol edebilir bir araca sahiptir: çalışan bir prototip. Çoğu zaman müşteri bu prototipe bakarak sahip olduğu gereksinimleri doğru olarak tanımlamadığının farkına varır. Bu kendisi ve yazılım ekibi için bir geribildirimdir ve değişikliğin habercisidir. Bir sonraki çalışma safhasında (iterasyon) ekip bu geribildirimden beslenerek, müşterinin gereksinimlerini tam anlamıyla tatmin edecek değişikliklere gider.

Geribildirim alma çevikliğin ana temellerinden birisini teşkil etmektedir. Müşteriye ne istediğini sorarak, iterasyon bazlı çalışıp prototipler oluşturarak, sürekli entegre edip, entegrasyon seviyesinin ne durumda olduğunu sorgulayarak, birim testleri yazıp, uygulamanın test edilbilirliğini ölçerek birçok katmanda geribildirim ediniyoruz. Bu bizim yazılımcılar olarak müşteri gereksinimlerinin ifade edilmesi ile yazılımcılar tarafından tatmin edilmesi arasında nerede durduğumuzu anlayayıp, tartabilmemiz için çok önemli bir veri olma özelliği taşımaktadır.

Teknik olarak yazılımda çevikliği incelediğimizde çevik olmanın çekirdeğinde çok önemli bir metodun yer aldığını görmekteyiz: uygulamayı yeniden yapılandırma. İngilizce refactoring olarak isimlendirilen bu yöntem, biz yazılımcılara yeni müşteri gereksinimleri ile uygulamayı hamur gibi yogurma yetisi kazandırmaktadır.

Birçok sözde çevik süreci ya da çevik süreçlerin uygulandığı projeleri yakından incelediğimizde, başarısızlıklarının sebebinin uygulamayı hamur gibi yoğurma kabiliyetlerinin olmadığından kaynaklandığını söylemek mümkündür. Bazı sözde süreçler uygulamanın yeniden yapılandırılabilme özelliğine oluşturdukları gidişat planında yer bile vermemektedirler. Bir uygulamanın müşteri gereksinimlerine cevap verebilmesi için yeniden yapılandırılabilmesi gerekmektedir. Bunun ne olduğunu bile bilmeyen ya da tanımlayamayan bir çevik süreç nasıl çeviklik ibaresi olma savına sahip olabilir? Bunu anlamak güç!

Belki çevikliği tanımlamak kolay değil. Belki bu sebepten dolayı herkes her şeye çevik ismini takabiliyor. Ama bildiğim bir şey var, o da birim testi yazmadan ve sürekli refactoring yapmadan çevik olunamayacağıdır. Bu ikisinin nasıl yapılması gerektiğine dair birçok kaynak bulmak mümkündür. Martin Fowler’in Refactoring isimli kitabı yazılımcılara bu konuda ilham kaynağı olacaktır. Refactoring’i mümkün kılmak için birim testleri yazılması gerekmektedir. Bunu isteyen test güdümlü (Test Driven Development), isteyen klasik tarzda uygulamayı kodladıktan sonra yapabilir. Test güdümlü yazılımı şiddetle tavsiye etmekle beraber, klasik birim test yazılımını da hor görmüyorum. Uygulamayı hamur gibi yoğurabilmek için otomatik çalışan her türlü birim testi mübahtır. Bu birim testleri yeniden yapılandırma sürecinde oluşan hataları yazılımcıya gösterirler. Bunun yanısıra yazılımcının özgüvenini artırarak, daha cesaretli bir şekilde yeniden yapılandırma sürecine dahil olmasını sağlarlar. Birim testleri olmadan mantıklı çercevede uygulamanın yeniden yapılandırılması mümkün değildir.

Müşteri gereksinimlerini tatmin etmek için oluşturulan bir uygulama, üç katlı bir apartman gibi sabit bir yapı değildir. Uygulama devamlı değişiklige maruz kalır, çünkü müşteri kendi çalışma sahasında değişikliğe maruz kalmaktadır. Bunun doğal olarak uygulamaya yansıması gerekmektedir. Aksi taktirde uygulama müşterinin güncel gereksinimlerini tatmin edemez. Müşterinin gereksinimlerini tatmin edemeyen bir uygulama, işe yaramayan bir uygulamadır.

Demek oluyor ki “Birim testi yoksa refactoring yok. Refactoring yoksa çeviklik yok. Çeviklik yoksa, müşteri yok (olur)”. Benim çeviklik konusundaki formülüm bu.

EOF (End Of Fun)
Özcan Acar

Çevikliğin Böylesi

Son zamanlarda yazılımla yakından ya da uzaktan ilişkisi olan herkesin ağzında olan kelime; çeviklikten bahsediyorum. İngilizce de agile, lean gibi kavramlar kullanılıyor ve artık her şey için kullanılmaya başlandı. Gören de zannederki artık her proje çevik yazılım yöntemleri ile yapılıyor, her şey yolunda.

2010 senesinde Londra’da yapılan Domain Driven Design exChange konferansında Eric Evans, yazılımda çevikliğin anlamının kaybolduğunu çünkü artık her şeyin çevik olarak isimlendirildiğini söylemişti. Ne kadar haklı. Aşağıdaki fotografı bir trende çektim. Artık iş verenler bile çevik kelimesini kullanarak yazılımcıları oltaya düşürmeye çalışıyor. Çevik bir fare, çevik bir klavye belki de çevik bulut (agile cloud) bile kullanıyorken bulabiliriz kendimizi yakında. Yaşasın hayatın her safhasında karşılaştığımız çeviklik.

Son günlerin en moda çevik terimlerinden birisi Scrum. Avrupa’da artık birçok proje Scrum ile yapılıyor. Proje yöneticileri Scrum’la oturuyor, Scrum’la kalkıyor. Scrum yazılımda yeni bir dönemin başlangıcı. Diğer çevik süreçler on, on beş yıldır piyasada olmalarına rağmen, Scrum iyi pazarlandığı için çeviklik deyince ilk akla gelen süreç oluyor. Şahsen Scrum yöntemleri beni elektrik gibi çarpmamış olsa bile (çok fazla etkilenmediğim anlamında), Scrum doğru uygulandığında bir projede çevikliğin başlangıcı olabilir. Bugüne kadar birçok Scrum projesinde çalıştım ve doğru düzgün uygulandığını görmedim. Eski proje yöneticileri şimdilerde Scrum Master olmuşlar ve eski yöntemleri ile projeleri sürdürmeye devam ediyorlar. Kafalarda değişen fazla bir şey olmamış. Scrum’ı elbise olarak almışlar, kendi bedenlerine uydurmaya çalışmışlar. Bu bir yere kadar doğru olabilir, ama daha doğrusu Scrum elbisesini alıp, bedeni ona göre uydurmaktır. Scrum harfiyen ne istiyorsa proje ve çalışmalar ona göre şekillendirilmelidir. Ama mevcut kafalar değişmedikçe Scrum ve diğer çevik süreçlerin başarılı olmaları mümkün değil. Çeviklik, eski kafaların eski yöntemlerle yaptıkları işleri kendi yöneticilerine satmak için kullandıkları bir kavram haline geldi. Scrum projelerinde edindiğim tecrübeleri size aktararak çevikliğin nasıl yarı yolda kaldığını ve gerçek çevikliğin ne anlama geldiğini aktarmaya çalışayım.

Katıldığım ilk Scrum projesini hatırlıyorum. Sıkı bir mülakatın ardından projeye alındım. Mülakat esnasında bana bir sürü Java bulmacası soruldu. Maksat ne kadar derin Java bilgisine sahip olduğunu anlamaktı. Ama test güdümlü yazılım ya da JUnit hakkında bir kelime bile edilmedi. Aynı tarzda mülakatlar ile başka programcılar da projeye dahil edildi. Onlarda da durum farkli değildi. Ben programlarımı test güdümlü yazmaya gayret gösterdim. Ama bazı programcılar kırık kodları versiyon kontrol sistemine ekledikleri için testlerim çoğu zaman çalışmıyordu. Bu beni çok rahatsız eden bir durumdu. Test yazmaya önem vermeyen bu tür programcılarla çok ağız dalaşımız oldu. Sürekli entegrasyon serveri kullanılmıyordu, test güdümlü çalışılmıyordu, müşteri gereksinimleri kullanıcı hikayeleri olarak hazırlanmamıştı. Hangi kullanıcı hikayesini ne kadar zaman diliminde tamamlarız diye tahmin etme oturumları yapılmıyordu. Ama bir Scrum ekibi ve projesiydik. Her sabah on beş dakika asker gibi sıraya girip, Scrum toplantımızı yapardık. Bunun neresi çeviklik, neresi Scrum. Günde on beş dakika toplantı yaparak çevik olunmaz! Zaman kaybından başka bir şey değildir, göz boyamacadır.

Çalıştığım diğer bir Scrum projesinde Scrum’ın doğru adapte edilmesi için gayret gösterilmişti. Bir sürekli entegrasyon serveri ve yazılım metriklerini takip etmek için Sonar sunucusu kullanıyorduk. Zaman yetersizliğinden dolayı programcılar test yazmaya önem vermıyorlardı. Ayrıca uygulama bir uygulama sunucusu içinde çalışmak zorunda olduğu için test yazmak kolay değildi. Mevcut testlerin hepsi entegrasyon testi tarzındaydı. En ufak bir değişiklikte bile yeniden bir EAR paketi oluşturup, tüm uygulamayı uygulama sunucusuna çekmek gerekiyordu. Uygulama sunucusunun ayağa kalkması beş dakika sürüyordu. Yazılım geliştirme tamamen uygulama sunucusu ile iç içe geçmiş durumdaydı. Uygulama sunucusunu kullanmadan yazilim yapmak mümkün değildi. Test eksikliğinden ve uygulamanın bir uygulama sunucusuna çekilmesi gerektiğinden, uygulamayı yeniden yapılandırmak çok zordu. Uygulamayı uygulama sunucusundan bağımsız bir hale getirmek için çaba sarfetmemiz gerektiği konusunda çok dil dökmeme rağmen bu gerçekleşmedi. Sonuç olarak çevik değildik, çevik olamadık. Her yeni bir ekleme ile uygulamayı değiştirmek daha da zora girdi. Eğer programcılar ölmedilerse hala yaşıyorlar.

Çevik Nasıl Olunur?

Çevik olmak öncelikle cesaret ister. Gelenekleri bir kenara itip, yeniden başlamayı gerektirir. Felç geçirmiş bir insanın yeniden konuşmayı ya da yürümeyi öğrenmesi gibi çeviklikte her şeyi unutup, yeniden öğrenmeyi gerektirir. Çevik olmayı zor kılan da budur. İnsanlar alışkanlıklarından kolay kolay vaz geçemezler. Radikal değişimleri sevmezler. Yeniliklere kolay kolay adapte olamazlar. Dünya yerinde dursun isterler. Ama yazılım yapmak gibi dinamik bir ortamda değişmeyen tek şey değişikliğin kendisidir. Bununla yaşamak her babayiğidin harcı değildir. Cesur olanların, yeniliklere açık olanların işidir. Buraya kadar olan çevikliğin edebi tanımıydı. Şimdi gelelim teknik tanımlamasına.

Çevik olmayı ben hamur yoğurma ile kıyaslarım. Hamuru, içinde yeterince sıvı olduğu sürece yoğurabilirsiniz. Sıvı azaldıkça hamuru yoğurmak zorlaşır. İçinde sıvı kalmamış hamuru yoğuramassınız. Bu analogiden yola çıkarak çevikliğin yazılımdakı tanımlamasını yapalım. Hamur oluşturduğumuz yazılım sistemi, sıvı birim testleri, yoğurma ise yeniden yapılandırmadır (refactoring). Birim testleri olmadan yazılım sistemini yoğuramassınız (yeniden yapılandıramassınız), ama her yeni müşteri gereksinimi ile sizden yazılım sistemini yoğurmanız beklenir. Oluşturduğunuz uygulamaya yeni müşteri gereksinimlerini eklemek, yani uygulamayı yoğurmak zorundasınız. Bu işi yapmak yani programcı olarak çalışmak istiyorsanız başka alternatifiniz yok. Patronunuz ve müşteriniz sizden uygulamayı yoğurmanızı yanı kendi isteklerine cevap verecek şekilde geliştirilmenizi bekler. Birim, entegrasyon ya da onay/kabul testleri yazmıyorsanız uygulamayı yoğururken sıvı buharlaşacak ve siz belli bir noktadan itibaren uygulamayı yoğuramama rizikosuyla karşı karşıya kalacaksınız. Ama sizden yoğurmaya devam etmeniz beklenecektir. Birçok proje ya da geliştirilen uygulama bu sebepten dolayı başarısız olmaktadır. Devam etmek istiyorsanız uygulamaya sıvı katmanız gerekir. Oluşturacağınız yeni testler hamurunuz için yeni sıvı olacaktır. Bu testler hamuru tekrar yumuşatır ve yoğrulmasını kolaylaştırır. Programcı testleri kullanarak uygulamayı yeniden yapılandırabilir (refactoring). Bu hamuru yeniden yoğurabilme yeteneğini kazanmak demektir. Testler yoksa yeniden yapılandıramaz. Yeniden yapılandıramassa uygulama sıvı eksikliğinden katılaşır ve yoğrulamaz hale gelir. Çevikliğin ve esnekliğin gizli anahtarları testler ve yeniden yapılandırmadır. Bu iki anahtarı kullanmayı bilen programcı çeviktir. Tüm çevik olma hevesinin temelinde bu iki element yatar. Bu iki elementin olmadığı yerde çeviklik olamaz. Uygulamayı istekler doğrultusunda yoğuramadıktan sonra ne proje yönetiminin, ne Scrum’ın ne de çok iyi programcılardan oluşan ekibin bir anlamı kalır. Proje yöneticisi istediği kadar tavana zıplasın; katılaşmış bir uygulayı yeni kod yazarak yumuşatamayız, sadece test yazarak ve devamlı refactoring yaparak bu amaca ulaşabiliriz. Yazılımda işin özü budur: hamuru devamlı yoğrulacak kıvamda tutmak. Hamuru yoğurabilmek demek müşteri gereksinimlerine cevap verebilmek demektir, yani anında görüntü. Anında görüntüyü katılaşmış bir hamurla, yani yazılım sistemi ile yapamayız. Çıkarılması gereken sonuç çok basit aslında: sadece çevik süreç uygulayan projeler yoğrulabilir hamur üretir ve müşterinin yeni gereksinimlerine cevap verebilir.

Çevik olabilmek için çevik yazılım metotlarına hakim olmak gerekir. Her sabah on beş dakika toplantı yaparak elde edilebilecek bir durum değildir bu. Çevikliği anlayanlarla, anlamayanlar arasındaki fark budur. Çevikliği anlamayanlar çeviklik buzulunun (eisberg) su üstündeki kısmını görürler. Su üstünde görünen kısım, su altında kalan kısımdan çok küçüktür. Asıl çeviklikle haşır, neşir olma su altında olur. Her şeye Scrum, lean, agile diye isim verenler su üstünde yaşarlar, suyun altında olup bitenlerden bihaberdirler, çünkü derine dalmaya korkarlar. Onlar değişikliği zaten sevmezler. Eski çalışma tarzlarına çeviklik etiketini yapıştırıp hayatlarına devam ederler. Çeviğiz diye kendilerini ve etraflarındaki insanları kandırırlar. Hamuru yoğururken sıvı tükenmeye yakın panik olurlar. Ne yapacaklarını şaşırırlar, neden böyle oldu diye kara kara düşünürler. Çevik olduklarına kendileri de o kadar inanmıştir ki, suçu çeviklikte bulurlar. Çevikliği sevmemeye başlarlar. Onlar için suçlu olan çevik olma paradigmasıdır. Bilmezler ki çevikliğin hakkını verememişlerdir, çünkü ne olduğunu tam olarak kavrayamamışlardır. Değişikliğe açık olmadıkları için kavramaları da kolay değildir.

Gelelim çevik olmayı anlayanlara. Onlar bahsettiğim iki anahtarın sahibidir. Test güdümlü kod yazmayı bilirler ve her fırsatta bunu uygularlar. Bunun yanısıra refactoring konusunda uzmandırlar. Her yeni müşteri gereksimi ile daha önce verdikleri tasarım kararlarını revide ederler. Uygulamanın katılaşmaya başladığında mevcut tasarımın yetersiz olduğunu anlarlar ve bu tasarımı bozup, yeni bir tasarım yapmaktan çekinmezler. Cesurdurlar. Bilirler ki ellerindeki testler yeniden yapılandırma işlemini mümkün kılar. Buradan çıkardığımız ilk sonuç şudur: çevik olabilmek için test güdümlü yazılım yapmak önem taşımaktadır. Test güdümlü yazılım yapılamıyorsa, o zaman uygulamanın büyük bir kısmını kapsayacak şekilde test kodu yazılmalıdır. Oluşturulan testlerin otomatik olarak çalışması gerekmektedir. Yeniden yapılandırma (refactoring) işlemlerinin birçok yan etkisi olabilir. Onları hızlı bir şekilde lokalize edebilmek için otomatik çalışan testlere ihtiyaç duyulmaktadır. Testlerin olmadıği ya da yetersiz olduğu projelerde programcılar yeniden yapılandırma işlemine cesaret edemezler. Cesaret edemedikleri için yazılım sistemi her gün biraz daha katılaşır ve bir zaman sonra yoğrulamaz hale gelir. Eğlencenin bittiği an budur. Bu noktadan itibaren programcılar için cehennem azabı başlar. Fazla mesailer yapılır, beraber ağıtlar yakılır, kollektif çığlıklar atılır, sende mi Brütüs, sana o kadar emek verdik, yaptıkların bize caiz mi diye yazılım sistemine yüklenilir. Ama Brütüs suçsuzdur. O beni yoğurmayın dememiştir ki. Yoğurma cesaretini programcılar gösterememiştir.

Gerçek çevikliğin temelinde gerçek yazılım mühendisliği metotları yatar. Birincisi test güdümlü yazılım; ikincisi yeniden yapılandırma (refactoring); üçüncüsü eşli programlama; dördüncüsü sürekli entegrasyon; beşincisi basit tasarım; altıncısı iteratif sürüm oluşturma; yedincisi ….

Bu metotların hepsi insanların bilgisayarları icadı ve program yazmaları ile birlikte yer yer uygulanmış metotlardır. Hiç biri yeni icat edilmemiştir Ama bundan on, on beş sene önce Extreme Programming (XP) olarak topluca karşımıza çıktılar. XP bünyesinde proje yönetimi için de metotlar barındırmaktadır. XP bu metotları Scrum’dan almıştır. Ama Scrum bünyesinde XP’nin sahip olduğu çevik metotlar yoktur. Bu yüzden içinde çalıştığım hemen hemen her Scrum projesi sadece kağıt üzerinde çevik olabilmiştir. Saha’ya inildiğinde çevikliğin bir tane atomuna bile rastlamak mümkün olmamıştır.

Sadece proje yönetmek ve programcıların ne yaptığını kontrol etmek için icat edilmiş sözde çevik süreçleri kullananlara sesleniyorum buradan. Gerçek çevik yazılım metotlarını kullanmadığınız sürece çevik olmanız bir hayal olarak kalacaktır. Bu yüzden sürdürdüğünüz birçok proje 130 km/h ile duvara tosluyor. Cesaret edip işin temeline inmeniz gerekiyor. Daha fazla mühendis olup, çevik metotlara hakim olmanız gerekiyor. Her gün on beş dakikalık toplantılarınızdan vaz geçin demiyorum. Bu yerinde bir aktivite. Ama zaman ayırıp bir mühendis kafasıyla sistematik olarak çevik yazılım metotları ile ilgilenin, onları öğrenin, onlara hakim olun, onlari uygulayın. Her Scrum projesini testlerin yine en son safhada yazıldığı ya da zaman yetersizliğinden dolayı yazılamadığı bir ortama çevirmeyin. Profilime ben de kulağa hoş gelen Scrum Master ünvanını koyarım. Ama bu benim ne kadar çevik metotlara hakim olduğumu yansıtmaz. Ünvanlardan çok, hakim olduğunuz gerçek çevik yazılım metotları ile övünün. Hamuru yoğuran ünvan değildir. Hamuru yoguran tecrübeli beyin ve sistemli ve sonuç getiren metotlar kullanmaya alışmış ellerdir. Gerçek yazılım mühendisleri ile düzmece mühendislerin arasındaki fark işte budur. Parayla satın alınan sertifikalar programcıyı programcı yapmaz. Bu sevdadan vazgeçin. Bu sözde çevik yöntemlerle ne dünyayı kurtarırsınız ne de yazılım dünyasına artı bir değer katarsınız.

Çekirdekte gerçek meselenin uygumalayı devamlı yoğurmak olduğunu göz ardı eden bu sözde çevik yöntemler, çevik teriminin her halt için kullanılması ve enflasyona uğramış olması, çevikliğin içinden çıkılamaz bir hale gelmesine sebep olmuştur. Kafalar iyice karışmıştır. Hangi yöntem çeviktir, nasıl çevik olunur, bu sorulara artık kimse net olarak cevap verememektir. Çeviklik artık ifade gücünü yitirmiştir. Bu gerçekten üzücü bir durum. Bir nevi komplo. Sanki eski şelale (waterfall) yöntemleriyle büyümüş bir zümre çevikliği ortadan kaldırmak için iş birliği içindedir. Böyle birsey yok doğal olarak. Fantazim yine kanatlandı.

Beni bir Scrum düşmanı olarak görmeyin. Doğru uygulandığında iyi bir başlangıç olabilir. Ne yazik ki Scrum’ın doğasından kaynaklanan bir sorun bu; Scrum’ı doğru uygulamak hemen hemen imkansız; her türlü uygulama tarzına açık; somut değil; isteyen istediği tarafa çekiyor, bu yüzden ortaya çok komik görüntüler çıkıyor. Scrum doğru uygulandığı taktirde ve proje bünyesinde XP vari yazılım metotları kullanıldığında bir proje tam anlamıyla çevik olabilir. Onun haricinde bu imkansız.

Çeviklikte her şeyin başı çevik mühendislik metotlarıdır. Bunun başında test güdümlü yazılım ve refactoring gelir. İçinde bu elementleri barındırmayan bir süreç çevik yazılım süreci olamaz. Para basmak ve dandik sertifikalar dağıtmak için oluşturulmuş sözde çevik süreçlerden uzak durmakta fayda var. Cesaret gösterip işin özüne inelim. Yeniliklere açık olalım. Yazılım mühendisi isek o zaman bir mühendis gibi çalışalım, sistemli ve metotlu. Buna izin verilmediği yerde durmayalım, baş kaldıralım. Yazılımda çeviklik sadece çevikliği kavramış mühendislerle mümkündür. Eski kafa bir proje yöneticisini Scrum Master yaparak proje çevikleştirilemez. Projede çevikliği yazılım mühendisleri ateşler, meşaleyi onlar ileri götürür, Scrum Master olmuş birisi değil. Onlar en fazla seyirci olabilirler. Sahada maçı oynayan çevik yazılım mühendisleridir. Çeviklik konusunda bunun harici her şey hikayedir.


EOF (End Of Fun)
Özcan Acar

Test Güdümlü Yazılımın Tasarım Üzerindeki Etkileri

Yazılımcı olarak çalıştığım projelerde geleneksel ve çevik yazılım süreçleri hakkında tecrübe edinme firsatı buldum. En son kitabım bir çevik süreç olan Extreme Programming hakkındadır. Edindiğim tecrübeler doğrultusunda çevik süreçlerin, klasik yazılım süreçlerine nazaran bakımı ve geliştirilmesi daha kolay yazılım sistemlerinin oluşturulmasında daha avantajlı olduğunu söyleyebilirim.

Bu yazımda sizelere test güdümlü yazılım sürecinin, yazılım tasarımı üzerindeki etkilerini bir örnek üzerinde aktarmak istiyorum. TDD ile birlikte oluşan tasarım, kendiliğinden oluşan birşey değildir. Testler şekil aldıkça, oluşturmak istediğimiz tasarımın modeli de gözümüzde canlanmaya başlar. Oluşturduğumuz testler, programın gelecekteki kullanıcılarını (client) simule ettiği için, programın nasıl kullanılacağını testler bünyesinde gözlemlemek kolaylaşmaktadır. Bu süreç, sınıfların ve metotların kullanıcı gözüyle (client) tasarlanmasını sağlar. Bu sayede basit ve kullanışlı API (Application Programming Interface)’ler oluşur. Test güdümlü yazılım tasarımı devamlı zorlar ve yetersiz kaldığı yerlerde refactoring yöntemleriyle yenilenmesini sağlar. Bu süreç sayesinde kendisini devamlı yenileyen ve yeni gereksinimlere cevap veren bir tasarım oluşur.

Bu yazıyı PDF olarak edinebilirsiniz.

  Test Güdümlü Yazılımın Tasarım Üzerindeki Etkileri (183.5 KiB, 8,043 yükleme)


EOF (End of Fun)
Özcan Acar

Extreme Programming Hakkında Bazı Soru ve Cevapları

Kullanıcı hikayesi (user story) nedir?

XP projelerinde müşteri gereksinimlerinin yer aldığı kullanıcı hikayeleri oluşturulur. Bir kullanıcı hikayesi sistemin tipik bir özelliğini bir ya da iki cümle ile anlatan araçtır. Örneğin üye girişi olan bir sistemde, şöyle bir kullanıcı hikayesi düşünülebilir:

Kullanıcı isim ve şifreni kullanarak sisteme giriş yapar.

Kullanıcı hikayeleri hikaye kartlarına (story card) yazılır. Bu kartlar sürüm ve implementasyon planları yapılırken kullanılır. Her kullanıcı hikayesinin implementasyon zamanı programcılar tarafından tahmin edilir. Müşteri kullanıcı hikayelerine öncelik sırası vererek implementasyon sırasını tayin eder. Programcılar tarafından yapılan tahmin ve müşteri tarafından belirlenen öncelik sırası kullanıcı hikayesinin üzerinde yer aldığı hikaye kartlarına not edilir. Ayrıca müşteri tarafından oluşturulan akseptans (onay/kabul) testleri hikaye kartlarının arka bölümüne not edilir.

Bir kullanıcı hikayesinin büyüklüğü ne kadar olmalı?

Bu sorudaki büyüklük sıfatı ile kullanıcı hikayesinin kaç günde implemente edilebilir olduğu kastedilmektedir. Programcılar tarafından kullanıcı hikayelerin implementasyon süreleri gün bazında tahmin edilir. Bir kullanıcı hikayesinin en fazla dört yada beş günde implemente edilebilir yapıda olması gerekmektedir. Daha fazla zaman gerektiren kullanıcı hikayelerinin müşteri tarafından bölünerek, küçültülmeleri gerekmektedir.

Kullanıcı hikayelerini kim oluşturur?

Kullanıcı hikayelerini müşteri oluşturur, çünkü gereksinimleri en iyi bilen müşteridir.

XP projelerinde müşterin programcılarla beraber çalışması talep edilir. Müşteri kendi işini bırakıp, nasıl proje için çalışabilir? Başka işi yok mu?

Bu genelde müşterinin kendi işini gücünü bırakıp, projede başka işlerle uğraşması gerektiği şeklinde değerlendirilir, ama durum öyle değildir. Müşterinin programcılara yakın bir yerde olması, programcıların oluşan sorulara kısa sürede müşteri yardımıyla cevap bulmalarını kolaylaştırır. Asıl maksatta budur zaten. Müşteri gün boyunca programcıların sorularına cevap verir. Bunun yanı sıra kendi günlük işlerini takip eder. Çoğu zaman günlük işleri yapabilmek için bir bilgisayar yeterli olacaktır. Müşteri kendi işlerini yaparken ara sıra programcılara zaman ayırarak, soruları cevaplar.

Birden fazla müşteri varsa, hangisinin sözü geçerlidir?

Proje ekibinin karşısında sadece bir müşteri olmalıdır. Eğer birden fazla müşteri varsa, bu şahıslar bir araya gelerek, tek bir şahıs gibi programcı ekibi ile iletişim kurmalıdırlar.

Sürüm planını kim oluşturur?

Sürüm planı müşteri ve programcılar tarafından ortaklaşa oluşturulur. Ne ve hangi sıraya göre yapılması gerektiği müşteri tarafından belirlenir. Bu yüzden sürüm planının oluşumunda müşterinin ağırlığı daha fazladır. Planlama için zaman tahminleri programcılar tarafından yapılır. Bu şekilde programcılar proje planlama sürecine aktif olarak katılarak sorumluluk alırlar.

Sürüm planını ne oranda sabittir?

Proje başında oluşturulan sürüm planı projenin çeşitli safhalarında değişikliğe uğrayabilir. Bu doğaldır. Müşteri yazılım sisteminin ilk sürümleriyle gereksinimlerinin ne olduğunu daha iyi anlayabilir ve mevcut kullanıcı hikayeleri üzerinde değişilik yapılmasını talep edebilir ya da yeni kullanıcı hikayeleri oluşturabilir. Bu durumda sürüm planının değiştirilmesi gerekmektedir.

Sürüm ve iterasyon arasındaki fark nedir?

Sürüm yazılım sisteminin belirli bir versiyondaki halidir. Her yeni sürüm yeni özelliklerin implemente edildiği ve müşteri tarafından produktif kullanılan program versiyonudur. XP projelerinde her yeni sürüm bir ile dört ay süren bir çalışma sonunda oluşturulur. Müşteri tarafından seçilen kullanıcı hikayeleri belirli bir zamansal uzunluğa sahip olan iterasyonlarda implemente edilir. İterasyonlar bir ile dört haftalık zaman birimini kapsarlar.

Bir önceki resimde yer alan sürüm beş iterasyondan oluşmaktadır. Her iterasyon iki hafta sürmektedir. Sürüm onuncu haftanın sonunda oluşturulmaktadır.

Hangi kullanıcı hikayesiyle işe başlanır?

Bu sorunun cevabını sürüm ve iterasyon planı verir. Sürüm ve iterasyon planlarında müşteri tarafından belirlenen kullanıcı  hikayeleri yer alır. Müşteri, kullanıcı hikayeleri için sahip oldukları değere göre öncelik sırası belirler. Sürüm ve iterasyon planlarında kullanıcı  hikayeleri bu öncelik sırasına göre yer alırlar. Programcılar her iterasyonda, o iterasyon için seçilmiş olan kullanıcı hikayelerini öncelik sırası yüksekten düşüğe doğru implemente ederler. Buradaki ana amaç, müşteri için en değerli özelliklerin yer aldığı bir sürümü oluşturarak, müşteri tarafından kullanılabilir hale getirmektir. Bu yüzden her zaman müşteri açısından en değerli olan sistem özellikleri öncelikli olarak implemente edilir.

Kullanıcı hikayesi implementasyonu ne zaman tamamlanmıştır?

Programcılar bir kullanıcı hikayesini test güdümlü implemente ederler. Testler tamamlandıktan sonra akseptans testleri yapılmak üzere kullanıcı hikayesinin yer aldığı hikaye kartı (story card) testçiye (tester) devredilir. Testçi müşteri tarafından tanımlanmış olan akseptans (onay/kabul) testlerini implemente eder. Akseptans testlerini geçen bir implementasyon bitmiş olarak kabul edilir.

Mevcut projeler üzerinde XP uygulanabilir mi?

Bu büyük ölçüde projedeki JUnit testleri oluşturma alışkanlığına bağlı. XP test güdümlü implementasyonu şart koşmaktadır. Eğer programcılar tarafından programlara paralel olarak testler geliştiriliyorsa, test güdümlü implementasyona geçmeleri zor olmayacaktır. Bunun yanı sıra projedeki mevcut iletişim kültürü önemlidir. XP çok yönlü iletişimi gerekli kılmaktadır. Örneğin pair programming gibi tamamen iletişim ve takım işine bağımlı olan bir metot programcılar tarafından ne oranda uygulanabilir, bunun araştırılması gerekmektedir.

Sürekli entegrasyon, test güdümlü yazılım, müşterinin projeye dahil edilmesi, kısa sürelerde yeni sürüm oluşturulması gibi konular XP’yi yeni başlamayan projeler için zor adapte edilebilir kılmaktadırlar. XP’nin yeni projelerde adaptasyonu çok daha kolaydır.

Bir iterasyon süresi ne kadar olmalı?

Bu yazılım sisteminin sahip olması gereken özelliklerle doğru orantılıdır. Eğer iki ay içinde ilk sürüm oluşturulması planlanıyorsa, iterasyon süresi bir ile iki hafta olacak şekilde seçilebilir. Bunun yanı sıra müşteri tarafından oluşturulan kullanıcı hikayelerinin implementasyonu için programcılar tarafından verilen tahminlerin dikkate alınması gerekmektedir. Örneğin programcılar tarafından ortalama her kullanıcı hikayesi için bir ile iki gün tahmin edilmişse,  bir haftalık iterasyonda en az üç en çok beş kullanıcı hikayesi implemente edilebilir. Eğer kullanıcı hikayeleri ortalama dört veya üzeri günde implemente edilebilir durumda ise, o zaman interasyonun en az iki hafta olarak seçilmesi gerekmektedir. İterasyon süresi sabittir ve uzatılamaz, bu yüzden seçilen kullanıcı hikayelerinin seçilen sürede implemente edilebilir yapıda olmaları gerekmektedir.

Akseptans (okay/kabul) testlerini kim oluşturur?

Akseptans testleri kullanıcı hikayesini oluşturan müşteri tarafından tanımlanır. Akseptans testlerinin implementasyonunu programcılar yada testçiler üstlenir.

Kaç tane JUnit testi hazırlanmalı?

Produktif olarak kullanılan her sınıf için bir JUnit testi sınıfı oluşturulması gerekmektedir. Bu sınıf bünyesinde birden fazla test metodu yer alır. Produktif sınıfta bulunan her metodun test edilmesi gerekmektedir. Çoğu zaman oluşturulan test sınıfının büyüklüğü test edilen sınıfın 2-3 katı büyüklüğe sahiptir. Bu test adedi hakkında bir fikir sahibi olmanızı kolaylaştırır.

Kod paylaşımı nasıl yapılır?

Kod paylaşımını kolaylaştırmak için bir versiyon kontrol sisteminin kullanılması şarttır. Subversion son zamanlarda kullanılan en popüler açık kaynaklı versiyon kontrol sistemi haline gelmiştir.

Kurumsal Java Akademisi Subversion eğitimi »

Pair programming yaparken tecrübeli bir programcı ile tecrübesiz bir programcının beraber çalışması zaman ve kaynak kaybı değil midir?

Hayır! Pair programming tekniği ile programcıların teknik anlamda ayni seviyeye gelmeleri sağlanır. Tecrübeli programcılar can, tecrübesiz programcılar patlıcan değildir :) Tecrübesiz programcılar için seminer düzenlemek yerine, onlara pair programming seanslarında teknoloji ve proje hakkında bilgi transfer etmek daha mantıklıdır.

Pair programming iki programcının bir kişilik iş çıkarması anlamına gelmez mi?

Pair programming maliyetli bir yöntemdir. Lakin iki programcının beraber aynı implementasyon üzerinde çalışmasından sinerjiler doğar. Pair programming iş kalitesini yükseltir. Ayrıca pair programming ile kodun ve tasarımın iki değil dört göz ile kontrol edilmesini sağlanır.

XP projelerinde mimariyi ve tasarım nasıl oluşur?

Mimari (altyapı) proje öncesinde yapılan keşif safhasında (Exploration Phase) oluşur. Programcılar müşteri tarafından oluşturulan kullanıcı hikayelerini okudukça, neye ihtiyaç duyduklarını anlarlar ve ona göre altyapıyı geliştirirler.

Proje öncesi detaylı tasarım oluşturulmaz. Tasarım test güdümlü implementasyon esnasında programcılar tarafından oluşturulur. Eğer programcılar implementasyon esnasında sorunlarla karşılaşırlarsa, refactoring yöntemleri kullanarak tasarım üzerinde değişiklik yaparlar. Unit testleri refactoring işleminin yapılmasını kolaylaştırır. Yapılması gereken değişiklikler sonraya bırakılmaz, çünkü bu ilerde maliyetin yükselmesine sebep olabilir.

XP projelerinde mimariyi ve tasarımı kim oluşturur?

Programcılar.

Bilgi bankası olan bir sistemde test güdümlü yazılım nasıl uygulanır?

Bunun çeşitli yöntemleri vardır. Öncelikle bilgi bankası işlemlerinin DAO (Dao Access Object) tasarım şablonu kullanılarak bir interface sınıf arkasında saklanması en mantıklı çözümdür. Mock sınıflar kullanılarak DAO katmanı simule edilebilir. Bu sistemin diğer bölümlerinin test güdümlü implementasyonunu kolaylaştırır. DAO kullanıldığı taktirde, gerçek bilgi bankasına olan bağımlılık azaltılır. DAO interface sınıfını değişik türde implemente ederek, bilgi bankası yerine başka bir yapıda kullanılabilir.

Hibernate ve IBatis gibi bir framework kullanılması durumunda, test güdümlü yazılımı mümkün kılabilmek için bu frameworklerin sunduğu interface sınıflar (SessionFactory, Session vs.) mock nesneler ile simüle edilebilir.

Planlama pokeri nedir?

Programcı bir kullanıcı hikayesini implementasyon öncesi tüm detaylarıyla bilmek zorunda değildir. Bir kullanıcı hikayesini en son detayına kadar kavramaya çalışmak zaman kaybı olabilir, çünkü kullanıcı hikayesinde yeralan müşteri gereksinimi değişikliğe uğrayabilir. Bu genelde müşterinin programın ilk sürümlerini görmesiyle gerçekleşir. Çalışır bir program aracılığıyla müşteri gereksinimlerini daha iyi kavrayacak ve gerekli değişiklikleri talep edecektir. Bu sebepten dolayı implementasyona başlamadan önce kullanıcı hikayesinin ihtiva ettiği tüm detayları tespit etmek faydalı olmayacaktır, çünkü kullanıcı  hikayesi değişikliğe ugrayabilir. Programcı ekibin kullanıcı hikayesi hakkında implementasyon için gerekli zamani tahmin edebilecek kadar bilgiye sahip olması yeterli olacaktır.

Programcılar müşteri tarafından seçilen kullanıcı hikayesinin implementasyon süresini tahmin ederler. Bu tahminler planlama pokerinde yapılır.

Planlama pokeri yapılmayan tahminler bazen sağlıklı sonuçlar vermeyebilir. Bir programcı tarafından yapılan tahmin diger programcıları etkiliyebilir. Yada bazı programcılar herhangi bir sebepten dolayı tahmin etme sürecine aktif olarak dahil olmayabilirler. Bu gibi sebeplerden dolayı oluşan tahmin süreleri yanıltıcı olabilir. Daha geçerli tahminler elde edebilmek için planlama pokeri oynanır.

Planlama pokeri için kullanılan kartlar bir önceki resimde yer almaktadır. Her programcı bu kartların bir setine sahiptir. Planlama pokeri şu şekilde oynanır: Bir moderator ilk kullanıcı hikayesini okur. Müşteri bu kullanıcı hikayesi için implementasyon süresinin ne olduğunu sorar. Programcılar kısa bir zaman düşündükten sonra hep beraber planlama poker kartlarından birisini seçerek gösterirler. Çoğu zaman kullanılan kartlardakı değerler farklı olacaktır. En çok süreyi ve en az süreyi tahmin eden programcılardan bu sonuca nasıl vardıklarının açıklanması istenir. Verilen bilgiler dogrultusunda ortak bir değer bulunur.

Tahminler için hikaye puanları (story points) kullanılır. 1 hikaye puanı örneğin 1 iş günü (8 saat) olabilir. Programcılar her kullanıcı hikayesini kendi başına tahmin etmek yerine, kullanıcı hikayelerini birbirleriyle kıyaslıyarak tahminde bulunurlar. Örneğin kullanıcı hikayesi A için 2 hikaye puanı tahmin edilmişse, kullanıcı hikayesi B bu değer göz önünde bulundurularak tahmin verilir. Eğer kullanıcı hikayesi B A dan üç katı daha büyükse, o zaman B için tahmin 2×3 = 6 hikaye puanı olarak verilir.

Load Factor nedir?

Bir kullanıcı hikayesinin ideal şartlarda implementasyonu için gerekli zaman dilimi ile normal şartlarda implementasyonu için gerekli zaman dilimi farklı olacaktır. Örneğin programcılar gün boyunca yazılım haricinde toplantı, bilgi alışverişi gibi işler için zaman ayırmak zorundadir. Bir programcının sekiz saatlik bir iş gününde sekiz saat program yazabilmesi ideal zaman dilimi olarak tanımlanır. Toplantı ve diğer işler için kullanılan zaman ideal zaman diliminde çikartıldığı zaman normal zaman dilimi elde edilir. Kullanıcı hikayelerinin tahminlerinde ideal ve normal zaman dilimlerinin göz önünde bulundurulması gerekmektedir, aksi taktirde kullanıcı hikayesi için yapılan tahmin gercekleri yansıtmıyacaktır. Gerçekci bir tahmin yapabilmek için load factor olarak bilinen değer kullanılır. Bu değer bir kullanıcı hikayesinin implementasyonu için kullanılan zamanın ideal zamana bölünmesiyle elde edilir. Örneğin bir kullanıcı hikayesi için 1 iş günü (8 saat) tahmin edilmiş ve programcı kullanıcı hikayesini 2 iş gününde tamamlamış olsun. Bu durumda load factor 16 / 8 = 2  olacaktır. Load factor için 2 ila 5 arasında bir değer normaldir. Tahmin yapılırken tahmin edilen implementasyon zamanı load factor ile çarpılır. Örneğin programcı bir kullanıcı hikayesini 2 iş gününde implemente edebileceğini düşünüyorsa, kullanıcı hikayesi için tahmin süresi 2 değil, 2 iş günü x 2 load factor = 4 olmalıdır. Bu şekilde daha gerçekci tahmin elde edilir.

Programcılar load factor değerini göz önünde bulundurarak, tahminde bulunurlar.

Spike solution nedir?

Eğer programcılar bir kullanıcı hikayesi için tahminde bulunamazlarsa küçük çaplı bir demo implementasyonu yaparak implementasyon süresini tahmin etmeye çalışırlar. XP dilinde bu işe spike solution ismi verilir. İdeal şartlarda bu işlemin sürüm planlama oyunundan önce yapılmış olması gerekir. Buradan sürüm planlama oyunu için kullanıcı hikayelerinin oyun öncesi hazırlanmış olması gerektiği sonucunu çikartabiliriz.

Programcılar yaptıkları denemeler sonunda kullanıcı hikayesi için tahmin verebilecek duruma gelirler.
 

Özcan Acar

Neden sürekli entegre edilmeli?

Oluşturduğunuz yazılım sistemini sürekli entegre etmiyorsanız, zamanı gelince toptan entegre etmek zorundasınız.  Bunun, neden yazılım hayatınızda karşılaşabileceğiniz en büyük sorun olabileceğini bir örnek vererek açıklamak istiyorum.

Şimdi şunu hayal edin: Yeni bir otomobilin tasarlanması projesinde yer aldınız. Otomobil tasarlandı ve otomobili oluşturan parçalar 5 değişik ülkede, 20 değişik firma tarafından üretildi. Bu ülkelerde kullanılan uzunluk ve ağırlık birimleri (metre, kg vs.) değişik olabilir. Görev dağılımı esnasında yanlış anlamalardan dolayı üretilen parçalar birbirine uyumlu olmayabilir. Eğer tüm parçalar üretildikten sonra bir çırpıda tüm otomobili oluşturmak isterseniz, üretim sürecinde meydana gelen hataları daha önceden tespit edemediğiniz için, yamuk yumuk bir otomobil ortaya çıkacaktır. Ama üretim esnasında koordineli bir şekilde otomobili parça parça bir araya getirip, parçalar uyuşuyor mu diye kontrol etmiş olsaydınız, meydana gelen uyuşmazlıkları çok erken tespit ederek, gerekli değişiklikleri yapabilirdiniz. Bu yazılım sektörü için de geçerli.  Oluşturulan sistem komponentleri ne kadar erken entegre edilirse, oluşan uyuşmazlıklar o kadar erken tespit edilir ve gerekli değişiklikler yapılabilir.

Sürekli entegrasyon çevik süreçlerde çok önemli bir yazılım metodudur. Sistem üzerinde yapılan her değişiklik sürekli entegrasyonu otomatik olarak gerçekleştiren sunucu tarafından kontrol edilir.  Yazılımda kırılmalar oluşması (compile hataları, eksik sınıflar vs.) durumunda, tüm ekip sürekli entegrasyon sunucusu tarafından uyarılır. Bu geribildirim sayesinde entegrasyonun ne safhada olduğu anlaşılır.

Sürekli entegrasyon hakkında diğer bir makalemi

http://www.kurumsaljava.com/2008/11/26/surekli-entegrasyon-continuous-integration/

adresinden edinebilirsiniz.

Özcan Acar

Çevik Sürece Geciş Nasıl Olmalı?

Extreme Programming ve Scrum gibi çevik süreçlerin popüler olmasının sebebi, müşteri gereksinimlerini tatmin edebilen yazılım sistemlerinin oluşturulma sürecini kolaylastırmalarında yatmaktadır. Bu böyle olunca, yazılım firmaları, yıllarca şelala (Waterfall) metodundan çektikleri sıkıntılardan kurtulmak amacıyla çevik süreçlerin adaptasyonuna yönelmektedirler. Doğal olarak burada firmaların çevik sürecin adaptasyonu esnasında kafalarında oluşan bazı sorular var. Bunlardan en önemli iki soru şöyle: Continue reading →

XP Plan Poker Kartları

Mike Cohn un sahibi olduğu Mountain Goat Software firmasından sipariş verdiğim planlama poker kartları bugün bana ulaştı. Bunlar bizim bildiğimiz poker kartlari değil. Kimse benim poker oynadığımı düşünmesin :) Bu kartlar planlama oyununda programcılar tarafından kullanıcı hikayelerinin implementasyon süresini tahmin etmek için kullanılıyor. Continue reading →

Çevik Süreç Nedir?

Yazılım sektörü yıllardan beri kan kaybediyor. Ama artık taze kan bulundu ve hastalığın tedavisi kolaylaştı. Çözüm çevik süreçler!

Günümüze kadar uzanan süreçte yazılım sektöründe yapılan projeler nereye varacağı belli bile olmayan büyük maceralar haline gelmiştir. Bunun başlıca sebebi kullanılan yazılım yöntemlerinin gereksinimlere cevap verecek yapıda olmamasıdır. Çevik süreçler bu sorunu çözecek nitelikte.

Bu bölümde

  • yazılım yaparken hedefin ne olduğunu,
  • çevikliğin ve çevik sürecin ne olduğunu,
  • çevik manifesto ve prensiplerinin ne anlama geldiğini,
  • çevik sürecin diğer yazılım metotlarına kıyasla hangi farklılıkları beraberinde getirdiğini,
  • hangi çevik süreç türlerinin mevcut olduğunu,
  • bir çevik süreç olan Extreme Programming’in ne olduğunu,
  • Extreme Programming’in hangi değer, prensip ve teknikler üzerine kurulu olduğunu

yakından inceleyeceğiz.

Bu yazıyı PDF olarak edinebilirsiniz.

  Çevik Süreç Nedir? (219.4 KiB, 13,010 yükleme)

Sürekli Entegrasyon (Continuous Integration)

Sürekli entegrasyon (Continuous Integration = CI) kod üzerinde yapılan her değişikliğin ardından, tüm sistemin çalışır durumda olduğunu, yapılan değişikliğin sistemin bazı bölümlerinde kırılmalara yol açmadığını tespit etmek için kullanılan yöntemdir. Kırılmaları tespit edebilmek için testlere (JUnit) ihtiyaç duyulmaktadır. Bu testler, yapılan değişikliğin neticesi olarak yeni bir yapı (build) hazırlandıktan sonra otomatik olarak çalıştırılır. Yapılan değişiklik yeni yapının bir parçası olduğu için, testlerde oluşan hatalar, yapılan değişikliğin sistemi kırdığı anlamına gelmektedir. Bu durumdan tüm programcılar haberdar edilerek, hatanın bir an önce giderilmesi ve testlerin her zaman olumlu sonuç vermesi sağlanır. Sürekli entegrasyon ile programcılar tarafından kod üzerinde yapılan çalışmalar neticesinde her zaman çalışır bir sürümün oluşması sağlanmış olur.

Bu yazıyı PDF olarak edinebilirsiniz.

  Sürekli Entegrasyon (Continuous Integration) (479.7 KiB, 5,816 hits)
You need to be a registered user to download this file.

Test Güdümlü Yazılım – Test Driven Development (TDD)

 

Günümüzde kurumsal projelerin büyük bir bölümü geleneksel yazılım  metotları ile gerçekleştirilmektedir. Müşteri gereksinimleri en son detayına kadar kağıda döküldükten sonra, programcılar dokumente edilen gereksinimler doğrultusunda yazılımı gerçekleştirmektedirler. Eğer proje bütçesi yeterli ise, yazılım süreci sona erdikten sonra testler hazırlanarak, yazılım sistemi test edilmektedir. çoğu zaman hiçbir unit testin yapılmadığı sistemlerin firmalar tarafından kritik iş alanlarında kullanıldığını görmek mümkündür. Bu tür yazılım sistemlerinde oluşan hatalar (Bug)  firmanın sunduğu hizmetleri kısıtlamakta ve en kötü ihtimalle firmanın para kaybetmesine sebep olmaktadır.

Geleneksel tarzda oluşturulan yazılım sistemlerinde oluşan hataları gidermek çok pahalıya mal olabilmektedir, çünkü yazılım bittikten sonra tespit edilen hatalar yazılım sistemindeki tasarım açıklarını gözler önüne serebilir ve bu gibi kardinal hataların ortadan kaldırılması ya imkansız yada çok zor olabilir. Bunun yanı sıra yazılım sona erdikten sonra oluşturulan testlerin test kapsama alanı geniş olmadığı için kodun bazı bölümleri test edilememekte ve böylece hata tespiti zorlaşmaktadır. Bu şekilde yazılım esnasında ortaya çıkmayan hatalar, daha sonra sistem kullanıcıları tarafından keşfedilmektedirler. Bu aşamada geç kalınmıştır: ya sistem çalışmaz durumdadır, yada sistem kullanıcısı istediği işlemi doğru olarak gerçekleştirememiştir. Durumu kısaca şöyle özetleyebiliriz: “yazılım sistemi müşterinin gereksinimlerini tatmin edecek kaliteye sahip değildir”.

Ne yazık ki birçok firma için kullandıkları yazılım sistemlerindeki kalite problemleri firmaya zarar verici durumdadır. Bu kalite problemleri bir taraftan oluşan sistem hataları, diğer taraftan kodun bakımı ve geliştirilmesinin zor olmasından kaynaklanmaktadır. Oluşan sistem hataları  firmanın giderlerini artırmakta ve yazılım sisteminin istikrarsız ve güvenilmez olmasına sebep vermektedir. Bu sorunların temelinde test konseptlerinin bir yazılım sistemi için hayat sigortası olduğunun anlaşılamamış olması yatmaktadır.
 

Bu yazıyı PDF olarak edinebilirsiniz.

  Test Güdümlü Yazılım - Test Driven Development (TDD) (416.9 KiB, 10,322 yükleme)

Extreme Programming Nedir?

En popüler çevik süreçlerden ( Agile Process) birisi XP olarak bilinen Extreme Programming’dir. Kent Beck ve arkadaşları tarafından 1996 yılında Chrysler firmasında yapılan bir proje bünyesinde oluşan XP, ihtiva ettiği basit ama bir o kadar etkili yöntemlerle yazılım sektöründe yeni bir rüzgarın esmesini sağlamıştır.

XP ile oluşturulan çevik süreçte müşteri ve gereksinimleri merkezi bir rol oynamaktadır. Yazılım esnasında XP ile tam belirli olmayan ve çabuk değişikliğe uğrayan müşteri gereksinimlerine ayak uydurulabilir. Bu konvensiyonel yazılım metodlarda mümkün değildir, çünkü proje öncesi müşteri gereksinimleri en son detayına kadar kağıda dokülmüştür. Oluşan bir dokumentasyon baz alınarak, yazılım gerçekleştirilir. Proje ilerledikçe müşteri tarafından yapılması istenen değişikliklerin maliyeti çok yüksek olacaktır, çünkü mevcut yapı (tasarım – design) istenilen değişiklerin yapılmasını engelleyebilir yada yeni bir yapılanmaya gidilmesi gerekebilir. XP, kullanıldığı projelerde formalite ve bürokrasinin mümkün en az seviyeye çekilmesine önem verir. Çevik olabilmek için az yükle yola çıkılması gerekmektedir. Bu yüzden proje öncesi geniş çapta tasarım ve dokumentasyon oluşturulmasi izin verilmez. Bu kesinlikle dokümentasyon ve tasarım oluşturulmadan çalışıldığı anlamına gelmez!

XP Değerleri

XP dört değer üzerine kuruludur: Basitlik (Simplicity), İletişim (Communication), Geridönüm (Feedback) ve Cesaret (Courage).

XP’nin özü bu dört değer içinde yatmaktadır. Bu değerler yaşandığı taktirde XP ögrenimi ve kullanımı kolaylaşır. Bu değerlerin geçerlilik bulmadığı ortamlarda XP’nin uygulandığı söylenemez. XP ile verimli bir çevik süreç oluşturabilmek için bu değerlerin hepsinin kabul görmesi ve uygulanması gerekmektedir.

Bu değerlerin ne anlama geldiğini yakından inceliyelim. XP basit yöntemler aracılığıyla sonuca ulaşmak ister, çünkü sadece bu şekilde hızlı ve düşük maliyetli projeler gerçekleştirilebilir. Bunun yanısıra basit çözümlerle oluşturulan programın bakımı ve geliştirilmesi kolaydır. Basit çözümler kolay anlatılır ve adapte edilir. Bu zaman kazanılması anlamına gelmektedir.

Yazılımda en önemli konulardan birisi kalite kontrolüdür. XP projelerinde kalite kontrolü geridönüm (feedback) üzerinden sağlanır. Programcılar yazdıkları testlerden geridönüm alarak kaliteyi sağlarlar. Kısa zamanlarla yeni sürüm oluşturularak müşteri ve kullanıcılardan geridönüm aracılığıyla programın gereksinimleri tatmin edip, etmedigi kontrol edilir. Yazılım esnasında sürekli entegrasyon yapılarak, programın en son durumu hakkında geridönüm sağlanır. XP’nin uygulanabilmesi için değişik katmanlarda geridönüm mekanizmalarının oluşturulması gerekmektedir. İnsanlar için su ne ise, XP için geridönüm odur.

Tüm proje çalışanlarının sürekli olarak aralarında iletişim kurmaları gerekmektedir. Bireyler arası yüz yüze görüşmeler büyük önem teşkil etmektedir. Sadece bu sayede sağlıklı bilgi transferi gerçekleşebilir. Böylece yanlış anlaşılmalar ve bilinmeyenler ortadan kaldırılır. Eğer takım içinde iletişim ve interaksiyon güçlü ise, dokümentasyon oluşturma ve kullanma gereksiz hale gelebilir. Bu zaman kaybını önler. Dokümentasyon yazılımı ve kullanımı başka sebeplerden dolayı gerekli olabilir, ama projenin başarısı için dokümentasyon öncelikli rol oynamamaktadır.

Basit çözümler, geridönüm ve iletişim için cesaret gereklidir. Bu saydığımız değerler bireyler arası interaksiyonu ve iletişimi artıracağı için, bireylerin kendi iç dünyalarını terk edip, takımın bir parçası olmalarını kolaylaştırırlar. Bu kişisel gelişmeyi sağlar ve temelinde kişisel cesaret yatar.

XP Prensipleri

XP değerlerinden yola çıkarak onbeş XP prensibi oluşturulmuştur. Bunlar:

Rapid Feedback

Hızlı geridönüm

Sık ve hızlı geridönüm edinmek, projenin gidişatını olumlu etkiler. Geridönüm sayesinde yanlış anlaşılmalar ve hatalar ortadan kaldırılır.

Assume Simplicity

Basitliği tercih etmek

Basit çözümler kolay implemente edilir ve kısa zamanda oluşturulur. Bu geridönümün de hızlı bir şekilde gerçekleşmesini sağlar. Basit çözümlerin kavranması ve anlatılması daha kolaydır. XP programcılardan o anki gereksinimi tatmin etmek için basit çözümü bekler. Programcı gelecekte oluşabilecek eklemeleri ve değişiklikleri düşünmemeli, sadece ve sadece kendisinden o an için bekleneni en basit haliyle implement etmelidir.

Incremental Change

İnkrementel değişiklik

Basit çözümler uygulasak bile, yazılım sistemleri zaman içinde karmaşık bir yapıya dönüşebilir. Yapılan en ufak bir değişiklik bile, sistemin düşünmediğimiz bir bölümü üzerinde hata oluşmasına sebep verebilir. Oluşabilecek bu hataları kontrol altında tutabilmek için değişikliklerin ufak çapta olması gerekmektedir. Büyük değişiklikler beraberinde büyük sorunları getirebilir. Bu sebepten dolayı değişikliklerin ufak çapta ve sıklıkla yapılması gerekmektedir.

Embracing Change

Değişimi istemek

İlerliyebilmek için kendimize bir yön tayin etmemiz ve yeniliklere açık olmamız gerekiyor. Yeniliklere açık olmak cesaret gerektirir. Bilinmeyenle ugraşmak, rahatsız edici olabilir, ama başarıyı elde edebilmek için değişimi istemek gerekir.

Quality Work

Kaliteli iş

XP projelerinde kaliteli işin ortaya konabileceği bir ortamın oluşturulması geremektedir. Hiçbir programcı hatalı program yazmak istemez. Çalışma ortamınında etkisiyle yüksek kalitede yazılım yapmak  hem programcının özgüvenini artırır, hemde müşteriyi tatmin edici ürünlerin ortaya konmasını sağlar.

Teach Learning

Öğrenmeyi öğret

XP programcı takımlarında tertipcilik ve kıdem farkı yoktur. Tecrübeli programcılar bilgilerini daha az tecrübeli programcılarla paylaşarak, hem bilginin çoğalmasını sağlarlar, hemde takım arkadaşları ile teknik olarak aynı seviyeye gelirler. Programcılara komutlar vererek iş yaptırmak yerine, kendiliğinden bazı şeyleri öğrenerek, görevlerini yerine getirmeleri sağlanmalıdır.

Small Initial Investment

Az baslangıç yatırımı

XP en modern ve pahalı araç gereçlerle projeye başlanmasını beklemez. Başlangıç giderleri ne kadar düşük tutulabilirse, projenin iptali durumunda kayıplar o oranda az olacaktır. Başlangıçta tüm takımın dar bir finansman korsasını giymesi sağlanarak, proje için daha önemli görevlere odaklanmaları sağlanır. Bunu bir örnekle açıklıyabiliriz. Proje başlangıcında en son Oracle bilgibankası ve kullanıcı araçları (Toad gibi bir client program) satın alınarak, tüm ekibe bu bilgibankasını ve araçları nasıl kullanacaklarına dair seminer verilebilir. Bu çok masraflı ve bir o kadarda gereksiz bir şeydir. Projeye open source ve ücretsiz olan HSQL yada PostgreSQL bilgibankası ile başlanabilir. Programcı ekip böylece ne bir hafta tanımadıkları bir ürün için harcamış olurlar, ne de büyük masraflar yapılarak şu an için gerek olmayan bir altyapı komponenti satın alınmış olur. Gerekli araçlar zamanı geldiğinde edinilmelidir.

Play to win

Kazanmak için oyna

XP takımları kazanmak için oynar. Her zaman gözlerinin önünde nihayi sonuç vardır: programı tamamlamak ve müşteriye teslim etmek. XP programcı takıma tünelin sonundaki ışığı görmek için gerekli tüm imkanları sunar.

Concrete Experiments

Somut denemeler

Verdiğimiz kararların sonuçlarını kontrol edebilmek için denemeler yaparız, çünkü alınan kararlar her zaman doğru olmayabilir. Bir kontrol mekanizmasına ihtiyacımız  olduğu belli. Bu da somut denemeler aracılığıyla nerede olduğumuzu testpit etmekdir. Bu somut denemeler yazılım sistemleri içinde geçerlidir. Örneğin testler hazırlıyarak, oluşturuduğumuz mimari ve tasarımı kontrol ederiz.

Open, honest Communication

Açık ve samimi komunikasyon

Projenin başarılı olabilmesi için bireyler arasında açık ve samimi türde bir komuniksyonun olması gerekmektedir. Birçok projede bu böyle değildir. Çogu zaman bireylerin korkuları, deneyimsiz olmaları yada kendilerini çok beğenmeleri ve diğerlerini kendilerinden alt safhada görmeleri, açık ve samimi bir komunikasyon ortamının oluşmasını engeller.

Work with people’s instincs, not against them

Takımın içgüdülerini kullan, onlara karşı koyma

Bireysel içgüdü yanısıra, bireylerin oluşturdugu takımların da içgüdüsü vardır. Eger takım birşeylerin doğru gitmediği hissine sahipse ve bunu dile getiriyorsa, o zaman birşeyler yolunda gitmiyor demektir. Takımın içgüdüsüne kulak verilmelidir. Bunun göz ardı edilmesi, proje için olumsuz sonuçlar doğurabilir.

Accepted Responsibility

Sorumluluk üstlenmek

Sorumluluk birilerine verilmemeli, bireyler kendileri sorumluluk üstlenmeliler. Eğer bir bireye ya da bir takıma yapılması zor bir projenin sorumluluğu yüklenirse, bu birey ya da takım için motivasyonun düşmesini ve kaybetme korkusunun pekişmesini hızlandırır. Eğer bireyler ya da takımlar kendi sorumluluklarını kendileri seçerlerse, hem yaptıkları işte kendilerini iyi hissederler, hem de yüksek motivasyon ile üstlendikleri işi başarıyla tamamlarlar.

Local Adaptations

Sürecin ortam şartlarına adapte edilmesi

Büyük bir ihtimalle her takımın XP’yi Kent Beck’in anlattiğı tarzda harfiyen ugulaması mümkün değildir. Atalarımızında dediği gibi her yiğidin yogurt yeyiş tarzı başkadır. Amaç XP’yi harfiyen uygulamak değildir, amaç kısa bir zamanda projeyi başarılı bir sonuca ulaştırmaktır. Eğer proje XP’de yapılacak modifikasyonlarla başarıya ulaşacaksa, o zaman süreç üzerinde bu modifikasyonlar yapılmalı ve uygulanmalıdır. Bunda bir sakınca yoktur.

Travel light

Az yükle yolculuk yapmak

Projede hızlı ilerleyebilmek için fazla bir yükle yola çıkılmaması gerekmektedir. Beraber çalışmayı kolaylaştırmak için kullanımı kolay araç ve gereçler seçilmelidir. Formalitelerden uzak durulmalıdır.

Honest Measurement

Doğru ölçüm

Proje gidişatını kontrol edebilmek için değişik türde ölçümlerin yapılması gerekmektedir. Örneğin hazırlanan unit testleri ile sınıfların işlevleri kontrol edilir. Yapılan ölçümler doğru ve samimi yapıldıği taktirde kontrol mekanizması olarak kullanılan ölçümlerin bir anlamı vardır. Programcılar tarafından samimi ve doğru yapılmayan ölçümler projenin gidişatını olumsuz yönde etkiler.

XP Teknikleri (XP Practices)

Dört XP değer ve onbeş XP prensibi ondört XP tekniği ile desteklenmektedir. XP teknikleri programcıların XP değer ve prensiplerini uygulamada yardımcı olur. Kent Beck tarafından hazırlanan ilk XP versiyonunda oniki teknik yeralmaktaydı. Diğer çevik süreçlerin de etkisiyle Standup-Meeting’ler ve retrospektif toplantılar XP teknikleri arasına katıldı.

Bunlar:

On-site Customer

Programcıya yakın müşteri olarak tercüme edilebilir.

XP projeleri müşteri gereksinimlerine odaklı ilerler. Bu yüzden müşteri ve sistem kullanıcılarının projeye dahil edilmeleri gerekmektedir. Müşteri gereksinimlerini ekibe bildirir. Programacıların implementasyonu gerçekleştirebilmesi için müşteri tarafından dile getirilen gereksinimleri anlamaları gerekmektedir. Yanlış anlaşılmaları ve hataları gidermek için programcıların müşteri ve sistem kullanıcıları ile diyalog halinde olabilmesi gerekmektedir. Bu sebepten dolayı müşteri veya sistem kullanıcılarının programcıların erişebileceği bir uzaklıkta olmaları gerekir. Tipik XP projelerinde müşteri ve programcılar aynı odada beraber çalışırlar. Müşteri ekibin sorularını zaman kaybı olmadan cevaplar ve projenin ilerlemesine katkıda bulunur.

Standup-Meeting

Ayakta toplantı

Proje çalışanlari her gün 15 dakikayı aşmayan ve ayakta yapılan toplantılarda biraraya gelirler. Bu toplantının amacı, projenin gidişatı hakkında bilgi alışverişinde bulunmaktır.

Planning Game

Planlama oyunu

XP projeleri iteratif ve inkrementel yol alır. Bir sonraki iterasyonda yapılması gereken işleri planlama oyununda görüşülür ve sürüm ve iterasyonun içeriği tespit edilir. Planlama oyununa müşteri, kullanıcılar ve programcılar  katılır. Müşteri ve kullanıcılar daha önce kullanıcı hikayesine (user story) dönüştürdükleri isteklerine öncelik sırası verirler. Programcılar her kullanıcı hikayesi için gerekli zamanı tahmin ederler. Kullanıcı hikayelerinin öncelik sırası bu tahmine bağımlı olarak değişebilir. Planlama oyunlarında sürüm ve iterasyon planları oluşur.

Short Releases

Kısa aralıklarla yeni sürüm

XP projelerinde yeni implemente edilen ve değişikliğe uğrayan komponentler yeni sürümler oluşturularak müşteri ve kullanıcının beğenisine sunulur. Bu sayede hem müşteriler çalışır durumda olan programdan faydalanabilir hem de yeni sürümü inceliyerek, gereksinimleri ile örtüşüp, örtüşmediğini kontrol edebilirler. Eğer yeni sürüm müşteriyi tatmin edecek durumda değilse, gereksinimler değişikliğe ugrayabilir. Bu değişiklikler bir sonraki iterasyonda göz önünde bulundurularak, müşteri istekleri ile yüksek derecede örtüşen bir programın oluşturulması sağlanır.

Retrospective

Geriye  bakış

Proje çalışanları düzenli aralıklarla geriye bakarak, meydana gelen sorunları gözden geçirirler. Buradaki amaç gelecekte bu sorunların tekrarını önlemektir. Geriye bakış bir ila altıaylık zaman birimleri için tüm proje çalışanları yada seçilen bireyler tarafından yapılır. Geriye bakış toplantıları yarım gün ila üç gün arasında sürebilir.

Metaphor

Mecaz

XP projelerinde hazırlanan program için bir veya birden fazla, programın nasıl bir işlevi olacağını ekibin gözünde canlandırmalarını saglıyacak mecazi isim, öğe yada resimler kullanılır. Bunlar proje çalışanlarının ortak bir payda da buluşarak, ne yapılması gerektiği hakkında bir fikir sahibi olmalarını kolaylaştırır. Örneğin bir shop sistemi yazılımı yapılacak. Burada metaphor olarak alışveriş sepeti kullanılabilir. Alışveriş sepetini duyan her programcının aklında, bir shop sisteminin programlanması gerektiği fikri doğar.

Collective Ownership

Ortak sorumluluk

XP projelerinde programcılar ortak sorumluluk taşırlar. Bu her kod parçasının herhangi bir programcı tarafından gerekli durumlarla değiştirilebileceği anlamına gelir. Böylece yapılması gereken işler aksamaz, çünkü belli kod bölümlerinden belli programcılar sorunlu değildir. Aksine her programcı programın her bölümü üzerinde çalışma hakkına sahiptir. Bir programcının işe gelmemesi durumunda, başka bir programcı kolaylıkla onun görevlerini üstlenebilir.

Continuous Integration

Sürekli entegrasyon

Sistem değişiklikleri ve yeni komponentler hemen sisteme entegre edilerek test edilir. Sürekli entegrasyon sayesinde yapılan tüm değişiklikler her programcının sistem üzerinde yapılan değişiklikleri görmesini sağlar. Ayrıca sistem entegrasyonu için gerekli zaman azaltılır, çünkü oluşabilecek hatalar erken teşhis edilerek, ortadan kaldırılır.

Coding Standards

Kod standartları

Programcılar tarafından aynı kalitede kod yazılımı yapılabilmesi için, kod yazarken kullanılacak kuralların oluşturulması gerekmektedir. Kodun nasıl formatlanacağı, sınıfların, metot isimlerinin ve değişkenlerin nasıl isimlendirileceği kod standartlarında yeralir.

Sustainable Pace

Kalıcı tempo

XP projelerinde programcılar haftalık belirli mesai saatlerini aşmazlar. Gereğinden fazla çalıştırılan ve yorulan bir programcıdan verimli iş yapması beklenemez. Programcıların motivasyonun ve çalışma enerjilerinin yüksek olması için günde sekiz saatten fazla çalışmalarına izin verilmemelidir. Bazen fazla mesai saatlerine ihtiyaç olabilir. Eğer durum devamlı böyle ise, bu proje gidişatında bazı olumsuzlukların göstergesi olabilir.

Testing

Test etmek

Oluşturulan programların kalite kontrolünden geçmesi gerekmektedir. Bu yazılım esnasında oluşturulan testlerle yapılır. Programcılar komponentler için unit testleri hazırlar. Sınıf bazında yapılan bu testlerle komponentlerin işlevleri kontrol edilir. Müşteri gereksinimlerini test etmek için akseptans testleri hazırlanır. Komponentlerin entegrasyonunu test etmek için entegrasyon testleri hazırlanır.

Simple Design

Sade tasarım

Programcılar üstlendikleri görevleri (task) en basit haliyle implemente ederler. Bu programın basit bir yapıda kalmasını ve ilerde değiştirilebilir ve genişletilebilir olmasını sağlar. Sade bir tasarım yazılım sisteminin kompleks bir yapıda olmasını önler. Bunun yanısıra basit tasarımlar daha kolay ve daha hızlı implemente edilebilir. Basit bir implementasyonu anlamak ve anlatmak daha kolaydır.

Refactoring

Yeniden yapılandırma

Tasarım hataları yazılım sisteminin daha ilerde tamir edilemiyecek bir hale dönüşmesine sebep verebilir. Bu yüzden bu hatalar hemen giderilir. Bu yeniden yapılandırma işlemine refactoring ismi verilir. Hazırlanan unit testleri ile yapılan değişikliklerin yan etkileri kontrol edilir. Bu açıdan bakıldığında unit testi olmayan bir sistem üzerinde yeniden yapılandırma işlemi hemen hemen mümkün değildir, çünkü değişikliklerin doğurduğu yan etkileri tespit etme mekanizması bulunmamaktadır.

Pair Programming

Eşli programlama

XP projelerinde iki programcı aynı bilgisayarda çalışır. Bu sayede programcıların kısa bir zaman içinde aynı seviyeye gelmesi sağlanır. Ayrıca bu kalitenin yükselmesini sağlar.

XP Rolleri

Bir çevik projede ekip çalışanlarının sorumluluk alanlarını tanımlamak için roller tayin edilir. Her rol beraberinde bazı sorumluluklar ve tanımlanmış haklar getirir. Bu roller statik değildir. Ekip içinde değişik kişilere değişik roller verilebilir ve daha sonra rol değişikliği yapılabilir. Proje gereksinimleri doğrultusunda yeni rollerin oluşturulması mümkündür.

Müşteri (Customer)

Projenin var olma sebebi müşteridir. Müşteri ihtiyaç duyduğu ve gereksimlerine cevap verebilecek bir yazılım sistemi için yatırım yapan kişidir. XP projelerinde şu atasözümüz geçerlidir: “parayı veren düdüğü çalar!”.

Proje bünyesinde ne programlanması gerektiğini müşteri tayin eder. Müşteri yapılması gerekenleri kullanıcı hikayeleri (user story) oluşturarak ifade eder. Programcılar müşteriye bu süreçte yardımcı olurlar. Ama kullanıcı hikayelerinin oluşturulma sorumluluğu büyük ölçüde müştiriye aittir. Her kullanıcı hikayesi yazılım sisteminin bir özelliğini tanımlar. Programcıların implementasyonu gerçekleltirebilmeleri için kullanıcı hikayesini anlayabilmeleri gerekmekedir. Sadece bu durumda implementasyon süreci için bir tahminde bulunabilirler. Ayrıca oluşturulan kullanıcı hikayelerinin test edilebilir yapıda olması gerekmektedir.

Müşteri çalışma alanı (domain knowledge) hakkında bilgiye sahip olan kişidir. Programcılar müşteriye karşılaştıkları sorunları çözmek için sorular sorabilirler. Bu soruların cevabını en iyi verebilecek şahıs müşteridir.

Hangi kullanıcı hikayelerinin implemente edileceğine müşteri karar verir. Bu konuda müşteriye herhangi bir sınırlama getirilmez. Müşteri seçer ve programcılar implemente eder.

İmplemente edilen kullanıcı hikayelerini kontrol etmek amacıyla müşteri akseptans testleri tanımlar. Bu testler programcı yada testçi tarafından implemente edilir. Akseptans testleri kullanıcı hikayesini doğru implemente edilip, edilmediğini kontrol edici bir mekanızmadır.

Programcı

Sistem analizi, tasarım, test ve implementasyon programcılar tarafından yapılır.

Müşteri tarafından hazırlanan kullanıcı hikayelerinin implementasyon süresi programcılar tarafından tahmin edilir. Bu programcıların XP projelerinde proje planlama sürecine dahil edildikleri anlamına gelmektedir. Geleneksel projelerde bu tahminleri teknik bilgiye sahip olmayan yöneticiler yapmak zorundadır. Bu yüzden bu tahminler genelde gerçekleri yansıtmaz.

Her programcı test güdümlü (TDD – Test Driven Development) ve bir takım arkadaşıyla beraber çalışır. Pair programming olarak bilinen, iki programcının birlikte yazılım yapması, kısa zamanda kod hakkındakı bilginin tüm programcılar tarafından paylaşılmasını kolaylaştırır. Ayrıca pair programming programcılar arasında iletişimi ve takım içinde çalışabilme özelliğini artırır. Test güdümlü çalışmak bakımı ve geliştirilmesi kolay kodun oluşmasını sağlar. XP projelerinde programcılar herhangi bir satır kod yazmadan önce gerekli test sınıflarını oluşturarak implementasyona başlarlar.

Programcılar oluşturdukları testler yardımıyla hergün bir veya birden fazla şekilde modül entegrasyonu gerçekleştirirler. Sürekli entegrasyon programcılar tarafından oluşturulan modülleri entegre eden bir süreçtir. Her programcı bu süreçten geridönüm sağlıyarak, kendi yaptıklarının ne derecede sisteme entegre olduğunu ölçebilir.

Proje Menajeri

Proje menajeri müşteri ve programcıları bir araya getirir. Onların beraber çalışabilecekleri ortamların oluşmasını sağlar. XP proje menajeri tek başına proje planlamasından sorumlu değildir. Programcılara görev atamaz, onların kendi başlarına seçim yaparak, sorumluluk almalarını kolaylaştırır. Toplantı ve diğer buluşmaları koordine eder, takımın karşılaştığı sorunları ortadan kaldırmak için gerekli olanları yapar.

Koç

Çevik süreci tanıyan ve nasıl uygulanması gerektiğini bilen experdir. Koçun görevi proje başlangıcında çevik takımı oluşturmak yada bir araya getirmek ve onlara belirli bir süre rehberlik yapmaktır. Koç projede sorun çıktığı zaman yada takım XP yöntemlerinin dışına çıktığında müdahale eder. Zaman zaman koç implementasyonda aktif olarak rol alır. Örneğin unit testlerin nasıl doğru bir yapıda oluşturulabileceğini diğer programcılara gösterebilir.

Testçi

Müşteri tarafından oluşturulan akseptans testlerini implemente eden programcıdır. Aynı zamanda JUnit ve entegrasyon testlerinin implementasyonunda takım arkadaşlarına yardımcı olur.

Haklar ve Sorumluluklar

Proje çalışanları çoğu zaman içgüdüsel korku hissedebilirler. Bunun en büyük sebebi belirsizliktir. Ne ve nasıl yapılması gerektiği bilinmediği taktirde ekip içinde huzursuzluk doğar. Bu projenin başarısını negatif etkiler.

Projenin başarılı olabilmesi için çalışanların hissettikleri korkunun aza indirilmesi yada yok edilmesi gerekmektedir. XP bu konuda proje çalışanlarına bir takım hakların tanınması gerektiğini dikte eder. Hangi rollerin hangi haklara sahip olduğunu yakından inceliyelim.

Müşteri Hakları

Müşterinin sahip olduğu haklar şu şekilde özetlenebilir:

  • Müşteri bütçe ve zaman planlaması yapabilmek için neyin yapılabilir olduğunu ve hangi zaman biriminde yapılabileceğini bilme hakkına sahiptir.
  • Müşteri fikir değiştirerek, gereksinimler üzerinde değişiklik yapma ve yeni gereksinimlerin implementasyonunu talep etme hakkına sahiptir.
  • Müşteri programcılar tarafından sağlanabilecek en yüksek verimi ve değeri elde etme hakkına sahiptir.
  • Müşteri projede somut ilerlemeyi görme hakkına sahiptir. Bu kısa aralıklarla oluşturulan yeni sürüm ve akseptans testlerine olumlu cevap veren yeni implementasyonlarla sağlanır.
  • Müşteri  bir sonraki sürümde implemente edilecek kullanıcı hikayelerini seçme hakkıda sahiptir.

Programcı Hakları

Programcının sahip olduğu haklar şu şekilde özetlenebilir:

  • Programcı takım arkadaşlarına soru sorma ve cevap alma hakkına sahiptir.
  • Programcı kullanıcı hikayeleri için implementasyon zaman tahmini yapma hakkına sahiptir. Programcı tahminler üzerinde değişiklik yapma hakkında sahiptir.
  • Programcı, kendisine görev verilmesi yerine sorumluluk alma hakkında sahiptir.
  • Programcının herzaman yüksek kalitede iş çıkarma hakkı vardır.
  • Programcının hangi öncelik sırasına göre neyi yapması gerektiğini bilme hakkı vardır.

Süreç İşleyişi

XP projelerinde projenin gidişatını genel olarak şu şekilde özetliyebiliriz:

  • Müşteri gereksinimleri ihtiva eden kullanıcı hikayelerini oluşturur. Bunlara öncelik sırası atar. Programcılar her kullanıcı hikayesi için implementasyon zamanını tahmin ederler.
  • Müşteri  programcılarla beraber iterasyon(1-2 hafta) ve sürüm (1-2 ay) planını hazırlar. Her sürüm birden fazla iterasyon ihtiva eder ve müşteri tarafından kullanılacak özellikte çalışır bir sistemdir.
  • Müşteri ilk iterasyon (1 hafta) için gerekli kullanıcı hikayelerini tahminleride dikkate alarak seçer.
  • Programcılar iterasyon için seçilen kullanıcı hikayelerini implemente ederler. Kafalarda oluşan sorular müşteriye danışılarak cevaplandırılır.
  • İterasyon sonunda programcılar müşteriye çalışır bir sistem sunarlar. Müşteri sistemi değerlendirerek programcılara geridönüm sağlar.
  • Edinilen tecrübeler ışığında bir sonraki iterasyon planlanır. Eğer müşteri yeni gereksinimlerin implemente edilmesini isterse, bunlar için tekrar kullanıcı hikayeleri oluşturulur ve tahminler yapılır. Eğer yeni kullanıcı hikayeleri yoksa, mevcut kullanıcı hikaye listesinden en yüksek öncelik sırasına sahip olanlar seçilir ve bir sonraki iterasyondan implemente edilir.
  • İlk sürüm sonunda oluşan yazılım sistemi müşteri tarafından produktif olarak kullanıma alınır. Başka sürümler planlandıysa bir sonraki iterasyonla devam edilir.

XP Proje Safhaları

Bir XP projesi değişik safhalardan oluşur. Her sahfa, bünyesinde kendine has aktiviteler ihtiva eder. Bir sonraki resimde bir XP projesinde olması gereken safhalar yeralmaktadır.

XP projesi şu safhalardan oluşur:

  • Keşif safhası (Exploration Phase): Projenin başlangıcında keşif safhasını oluşturan aktiviteler yeralır. Bu safhada müşteri kullanıcı hikayelerini (user story) oluşturur. Programcılar teknik altyapı için gerekli deney (spike) ve araştırmayı yaparlar.
  • Planlama Safhası (Planning Phase): Keşif safhasını planlama safhası takip eder. Bu safhada müşteri programcılar yardımıyla iterasyon ve sürüm planlarını oluşturur. İterasyon planlaması için oluşturulan kullanıcı hikayelerinin implementasyon süresi programcılar tarafından tahmin edilir. Müşteri kullanıcı hikayelerine öncelik sırası vererek, iterasyonlarda hangi kullanıcı hikayelerinin öncelikli olarak implemente edilmeleri gerektiğini tespit eder. Programcılar tarafından herhangi bir kullanıcı hikayesinin implementasyon süresi tahmin edilemesse, programcılar spike solution olarak bilinen basit bir çözüm implemente ederek, kullanıcı hikayesinin gerçek implementasyonu için gerekli zamanı tahmin etmeye çalışırlar.
  • İterasyon ve Sürüm Safhası (Iterations to Release Phase): Kullanıcı hikayelerinin implementasyonu iterasyon ve sürüm safhasında gerçekleşir. Bir iterasyon bünyesinde implemente edilmesi gereken kullanıcı hikayeleri müşteri tarafından belirlenir. İmplementasyonunun işlevini kontrol etmek için müşteri tarafından akseptans testleri belirlenir. Bu testler programcılar yada testçiler tarafından implemente edilir. Her iterasyon sonunda müşteriye, çalışır bir yazılım sistemi sunulur. Bu şekilde müşterinin sistem hakkındaki görüşleri alınır (geridönüm). İterasyon son bulduktan sonra çalışma hızını tahmin etmek için bir önceki iterasyonunda elde edilen tecrübeler kullanılır ve iterasyon planı bu değerler doğrultusunda gözden geçirilir. Bir önceki iterasyonda oluşan hatalar bir sonraki iterasyonda gözden geçirilmek ve giderilmek üzere planlanır.
  • Bakım Safhası (Maintenance Phase): Bu programın bakımının ve geliştirilmesinin yapıldığı safhadır. Bu safhada kullanıcılar için egitim seminerleri hazırlanır ve küçük çapta eklemeler ve sistem hatalarının giderilmesi için  işlemler yapılır. Müşterinin istekleri doğrultusunda bir sonraki büyük sürüm için çalışmalara başlanır. Bu durumda tekrar keşif safhasına geri dönülmesi ve oradan işe başlanması gerekmektedir.

Bu yazıyı PDF olarak edinebilirsiniz.

  Extreme Programming Nedir? (210.6 KiB, 8,532 yükleme)