8 Şubat 2013 Cuma

Yazılım projelerini daha hızlı bitirmek mümkün mü?

Projelerin ne zaman biteceğinin tahmini, yazılım camiası için kronik bir problemdir. Müşteriler, proje yöneticileri ve tüm yazılımcılar zamanlarının bir bölümünü planlama ve öngörülerde bulunarak geçirirler. Projenin kapsamı, donanımsal ve yazılımsal gereksinimler, projenin kaç kişi ile geliştirileceği, geliştiren takımda çalışacakların özellikleri, projenin kaç adam gün süreceği ve ne kadar para harcanacağı gibi sorular için cevap aranır. Tasarımlar yapılır, müşteri istekleri tartışılır ve ortak bir noktada anlaşılmaya çalışılır. Her şey konuşulduktan sonra, eğer müşteri harcanacak para konusunda bir problem olduğunu düşünürse yada projenin pazara çıkış tarihinde bir gecikme olacağı öngörülürse, şu soru sorulur: "Peki bu proje nasıl daha hızlı biter?"

Bir projeyi kapsamını daraltmadan daha hızlı bitirmenin akla hemen gelebilecek birkaç yolu var. Eminim aşağıdaki yollar sizin yada proje yöneticinizin de aklına gelmiştir.
  • Projede çalışacak kişi sayısını arttırmak. Daha çok çalışan ile aynı işi daha kısa sürede bitirmek
  • Mesai süresini arttırmak. Daha çok ve uzun süre çalışarak işleri yetiştirmeye çalışmak
  • Testlerden vazgeçmek. Test için harcayacağın vakti yeni gereksinimler geliştirmek için harcamak
Bu yöntemlerin işe yarayıp yaramadığını sorgulamadan önce bir noktayı aydınlatmakta fayda var. 

Bizim proje diye adlandırdığımız şey çoğu kez sadece "yazılım geliştirme" olarak düşünülür. Ancak unutmayın ki, programlama bir projenin sadece küçük bir bölümüdür. Yazılım geliştirme bittikten sonra "bakım ve onarım" fazı (maintenance & bug fix period) başlar. Bu dönemde çıkan hatalar temizlenir, mevcut uygulamalar güncellenir ve isteğe göre yeni özellikler eklenir. Genele baktığımızda müşteri sadece yazılım geliştirme sürecinde para ödemez. Tüm süreçte para harcar. O nedenle bir projeyi daha kısa sürede bitirmek müşteri için önemli bir sorudur. Projeyi daha kısa sürede tamamlamak için ya yazılım geliştirme süresini azaltmalı, ya da bakım ve onarım süresini kısaltmalısınız.

Yazılım geliştirme süresini nasıl kısaltabiliriz

Yazılımın doğası gereği gereksinimler sürekli değişir. Gereksinimlerin değişkenliği projelerin yazılım süresini uzatan en önemli etmenlerden biridir. Gereksinimler birkaç nedenle değişkenlik gösterir.
  • Müşteri çoğunlukla ne istediğini bilmez
  • Müşterinin zamanla fikri değişir
  • Unutulan gereksinimler zamanla farkedilir
  • Yazılım geliştikçe müşteri bazı gereksinimleri çıkarır yada ekler
  • Teknik sorunlar yada çözümler nedeniyle yeni gereksinimler oluşur
  • Test sırasında yeni bulgulara ulaşılır, tasarım ve gereksinimler etkilenir
  • Kullanıcılardan olumlu geribilirim gelmezse birçok gereksinim atılır, yenileri oluşur
Yazılım Yöneticileri Zirvesi 2013'de iken Avea oturumunda bir proje hakkında duyduğum şu sözler beni  etkilemişti: "Projeminiz başında planladığımız 100 hikayenin, proje sonunda kaçta kaçı gerçekleşmiş diye inceledik. Proje sonunda bitirdiğimiz 100 hikayenin yalnızca 50si en başta belirlediğimiz listede bulunuyordu. İlk gereksinim listesinden oluşturulan 50 hikaye, gerçekleştirmeye değer bulunmamıştı. Proje sonunda gerçekleştirilmiş olan diğer 50 hikaye ise yazılım esnasında ortaya çıkan gereksinimlerle şekillendi." Bu sözler çok net bir şekilde ne demek istediğimi sanırım anlatıyor.

Aynı değişkenlik "tasarım"da da vardır. Tasarım da aynen gereksinimler gibi evrimleşerek gelişir. İlk tasarımınız hiçbir zaman en son elinizde olan tasarımla birebir örtüşmez. "Yeteri kadar kısalıkta ön-tasarım (just-enough up-front design)" sizin projenize başlamanıza yeter. Geliştirme sırasında daha defalarca kez tasarım yapacak, değişen gereksinimlere göre tasarımınızı günceleyeceksiniz.

Yazılım geliştirme süresini kısaltmanın yollarını şöyle sıralayabilirim.
  • Müşteri ile birlikte çalışmak. Müşteriler (yada müşteri adına üründen sorumlu kişiler) ile durumu düzenli olarak "çalışan yazılım" ile gözden geçirmek. "Review" toplantıları bunun için tasarlanmıştır.
  • Kısa döngüler ile tekrarlamalı (iterative) yazılım geliştirmek. Değişen gereksinim ve tasarıma ayak uydurabilmek için kısa aralıkarla planları yenilemek, yeni planlar yapmak. Tasarımın yazılım sürecinde evrimleşmesine izin vermek.
  • Proje kapsamını küçük parçalara bölmek. Bu ancak kısa döngüler halinde yazılım geliştirmekle başarılabilir. Küçük parçalar (stories and tasks) daha kolay geliştirilir, risk en aza indirgenebilir. 
  • Daha yetenekli/mutlu/motive yazılımcılar ile çalışmak. Bunu başarabilmenin yolu çalışanların kendilerini geliştirebilecekleri, daha motive olabilecekleri ortam sağlamaktan geçer.
  • Daha verimli çalışmak. Bu ancak ve ancak yazılımcıların bölünmeden çalışabilmesi ile mümkündür. Takımınızda gelen istekleri karşılayacak bir "ürün sahibi (product owner)" bulundurarak ve 2 haftalık "time-box" zamanlarda sprint'ler gerçekleştirerek bunu başarabilirsiniz.
  • Düzenli olarak gözden geçirmek, sürekli iyileştirmek. Gözden geçirme toplantıları (retrospective meetings) ile çalışanların verimliliğini düşüren sorunları bulup çözmek. Sürekli daha iyiyi aramak, sorgulamak (kaizen).
Değinmem gereken bir nokta da yazımın başında listelediğim yollar.
  • Projede çalışan sayısını arttırmak çoğunlukla ek iletişim problemleri, yönetimsek sorunlar ve yazılım disiplinini korumada güçlükler nedeniyle pozitifden ziyade negatif bir etki yapar. Bir artı birin iki etmediği durumlardan biri de bu durumdur.
  • Mesai süresini arttırmak çalışanlarda yorgunluğa neden olur. Motivasyonu düşürür ve iç enerjinin düşmesine neden olur. Amaç sürdürülebilir bir tempo (sustainable pace) olmalıdır. Çalışanlar özel hayatlarına vakit ayırabilmelidir.

Bakım ve onarım süresini nasıl kısaltabiliriz

Bakım ve onarım süresini etkileyen ana etken yazılım kalitesidir. Yazılım kalitesi kavramını biraz açma istiyorum. Bir yazılımı kaliteli olarak niteleyebilmek için asgari şu özelliklere sahip olması gerekir.

  • Genişleyebilir olmak. Çoğunlukla modüler bir yapı kurarak sağlanabilir. Yeni özellikler ekleyebilmenin kolay olması gerekir.
  • Bir hata ayıklandığında yeni hatalar çıkmaması. Bu kaliteli yazılımın en belirgin özelliğidir. Test yazmakla ve TDD ile yazılım geliştirerek gerçekleştirilebilir.
  • Önemli hatalardan arınmış olmak. Canlıda çıkan hata sayısının az olması da denebilir. 
  • İşlevler ve akışların doğru çalışması. Yani geliştirilen özelliklerin doğru çalışması, uygulamanın kullanıcının beklediği şekilde tepki vermesi.
  • Güvenlik açıklarının olmaması. Ne kadar özenle yazarsak yazalım, güvenlik açığı olan bir uygulama hem kendine hem de yazan kuruma zarar verir. Güvenlik açıklarının kapatılmış olması gerekir.
  • Çalışanların bilgi seviyesinin fazla olması. Yazılım takımlarında çalışanlar sık sık değişir. Bilgi bir sonraki çalışana aktarılamaz ise yavaş yavaş azalır ve bir süre sonra kaybolur. Yazılımın bakım ve onarımını yapacak olan takımın mutlak ve mutlak bilgisini arttırması gerekir. Bu da teknik ve platform bilgisini paylaşmakla olur. Eşli yazılım geliştirme yöntemlerden biri olabilir.
Bakım ve onarım süresini kısatmak üstte belirttiğim özelliklere sahip kaliteli yazılımlar geliştirerek olur. Bu amaç için de agile yazılım pratiklerini (ya da XP prensiplerini) uygulamak büyük fayda sağlayacaktır.

Testerden vazgeçmek yapabileceğiniz en kötü adımlardan biridir. Testler sadece yazılımın işleyişini test etmezler. Ayrıca zamanının büyük bir kısmını kod okuyarak ve anlamaya çalışarak geçiren yazılımcıların işini kolaylaştırır. Tasarımların evrimleşerek gelişebilmesine olanak tanır.


Sözün Özü: Agile yazılım geliştirme pratikleri

Üstte belirttiğim tüm pratiklerin, agile yazılım geliştirme pratikleri arasında olduğunu belirtmemde fayda var. Burada yola çıkarak bir projeyi nasıl daha kısa sürede bitiririz sorusuna şöyle cevap verebiliriz: Agile yazılım geliştirme yaparak daha kısa sürede bitirebilirsiniz.

0 yorum:

Yorum Gönder

Template developed by Confluent Forms LLC; more resources at BlogXpertise