BAŞA DÖN

Celal Bayarın tapusu Köşkten çıktı

Cumhurbaşkanlığında dijitalleştirme projesi kapsamında birçok belge hassas işlemlerden geçirilip dijital ortama aktarılıyor.

Projeyle ilgili basında çıkan haberlerden birini sizinle paylaşmak isterim.

 

Haber; Radikal gazetesine ait.

Cumhurbaşkanlığı Genel Sekreteri İsen, tapu belgelerini Bayar ın torununa takdim etti.

ANKARA- Cumhurbaşkanlığı arşivlerinin dijital ortama aktarılması, Köşk’te ‘51 yıldır bekleyen bir tapuyu’ da gerçek sahipleriyle buluşturdu. Arşiv taramasında ortaya çıkarılan ve 3. Cumhurbaşkanı Celal Bayar’a ait olduğu belirlenen tapu belgeleri, Cumhurbaşkanlığı Genel Sekreteri Mustafa İsen tarafından Bayar’ın torunu Emine Gürsoy Naskali’ye takdim edildi. Naskali, tapunun Celal Bayar Köşkü olarak bilinen Ankara Atatürk Bulvarı’ndaki 2 katlı eve ait olduğunu belirterek, “Yeni bir yere ait sürpriz bir tapu değil. 27 Mayıs sonrası malum şartlar altında Köşk’ten ayrıldıkları için alamadıkları tapu” dedi. 
İsen, Cumhurbaşkanlığı arşivinin dijital ortama geçirilmesi çalışmaları sırasında buldukları bir dosyanın içinde Bayar’a ait kişisel tapu belgelerinin yer aldığını söyledi. 
Tapuların hikâyesini Bayar’ın torunu Naskali, Radikal’e anlattı. Kendilerine aktarılan tapuların Ankara Atatürk Bulvarı’nda bulunan ve Celal Bayar Köşkü olarak bilinen 2 katlı eve ait olduğunu belirten Naskali, “Anneannemle dedemin evine ait tapular. Zaten biz o evi devrettik. Bizim için bilinmeyen bir yere ait bir tapu değil. 27 Mayıs’ta malum şartlar altında Köşk’ten ayrıldıkları için orada kalmış” diye konuştu. Naskali, Atatürk Bulvarı’ndaki Celal Bayar Köşkü’nün yapılış hikâyesini de anlattı. Bayar ve eşi Reşide Bayar’ın Ankara’ya ilk geldiklerinde Keçiören’de bir evde kaldıklarını anlatan Naskali, Celal Bayar’ın Keçiören’den Çankaya’ya gidiş-gelişleri sırasında atların dinlenebilmesi için evin bulunduğu arsayı satın aldığını söyledi. Daha sonrasında ise yaşamak için bir ev fikrinin oluştuğunu belirten Naskali, “Anneannem yaşamak için 2 katlı bir ev istiyor ve Etnografya Müzesi’nin mimarı Arif Hikmet Koyunoğlu’na gidiliyor” diye konuştu. 

3 milyon evrak var
Bir süredir devam eden Köşk arşivlerinin dijital ortama aktarılması kapsamında, Cumhurbaşkanlığı’nda hummalı bir çalışma sürdürülüyor. 20 kişilik bir ekip, 3 milyon evrakı teker teker inceleyerek dijital ortama geçiriyor. Çalışmalar sırasında gerekli oldukça dışarıdan uzmanların bilgisi ve görüşüne de başvuruluyor.


Çalışmalarımızda dikkat ettiklerimiz

Blog'da daha önce bir kaç yazı da geçen çeviklik [1],[2] iş üretmemizi ciddi manada etkiliyor. Hızlı kararlar alıp, sıkı takipçisi olabiliyoruz. Ekip içinde nelere dikkat ettiğimize dair kısa bir eposta yazarken alttaki yazı ortaya çıktı. Nelere dikkat ediyoruz, nasıl çalışıyoruz? diye merak edenler için bir kaç ipucu içeriyor.

Projelerimiz kişiye bağımlı olarak gitmiyor, kişiler projelere bağımlı gidiyor. Yani her hangi birimiz herhangi bir projede modifikasyon / geliştirme yapabiliyoruz. Bu bakımdan, yeni bir ek kod yazmadan önce mutlaka ve mutlaka var olan iş parçacığı inceleniyor, mantıksız bile gelse o kodu yazan arkadaşın ne yapmak istediği / yaptığı analiz edildikten sonra geliştirme yapılıyor. Anlaşılmayan noktayı ilgili kişilere soruyoruz.

Yaptığımız çalışmaları önce kendimiz test ediyoruz. Bir link dahi koysak bu link çalışıyor mu çalışmıyormu kontrol ediyoruz. Kendi arkamızı başkasına toplatmamak için elimizden gelen gayreti gösteriyoruz. Bu konuda bazen kaçaklar olsa da günden güne daha iyiye gidiyoruz.

Çalışmalarımıza özen gösteriyoruz. Yaptığımız ufak bir iş dahi olsa, küçük bir pencereden değil, daha geniş bir perspektiften bakmaya çalışıyoruz. İstenilen işi yapmaya başlamadan önce daha sonradan oluşabilecek ihtiyaçları göz önünde bulunduruyoruz.

Hiç değer atanmadığını bildiğimiz bir değişken dahi silerken düşünüyor, emin oluyoruz. Yapacağımız işle bir ilgisi yoksa hiç bir yeri ellemiyor, mıncıklamıyoruz. En iyi kod çalışan koddur felsefesini uyguluyoruz. Fakat bu görülen hataları not etmediğimiz ve ilgilisine bir iş (case) veya bir kod inceleme kalemi (code review) olarak dönmeyeceği anlamına gelmiyor.

Ayarların saklandığı dosyalara yeni değer (value) eklenmedikçe ne commit ediyor ne de push ediyoruz. Herkesin kendine göre db, url vb. gibi ayarları bulunuyor. Eski konfig değerlerine getirmek can sıktığı gibi ekstra uğraşmamız iş kaybına sebep oluyor.

İş takip sistemine ve kod versiyonlama & koruma sistemine (revision control) sonuna kadar bağlı kalıyoruz. İşlerimizi sistemden alıyor, sistem dışı gelenleri sisteme giriyor (takip.erkyazilim.com.tr) ve çalışmalarımızı oradan takip ediyoruz. Kodlarımızı düzenli olarak gönderiyor (push), gönderirken de ilgili iş kalemini (Case ID) veya açıklamasını eklemeyi ihmal etmiyoruz.  Aynı projede farklı kalemlerde uğraştığımızda herkes kendi kalemini gönderiyor (commit & push) ve bir çakışma varsa diğer parçalar ile birleştirmeye (pull & update & merge & push) erinmiyoruz.

Yaptığımız bir işte mutlaka ve mutlaka başka arkadaşın görüşünü alıyoruz. Tek başımıza karar vermeyip, bir birimizin tecrübelerinden faydalanıyoruz. XP denen şeye inanıyor, yeri geldiğinde diğer bir gözün ne kadar başarılı bir şekilde sorunları görüp kolayca çözdüğünü unutmuyoruz.

İşlerin her aşamasında anlamadığımız, takıldığımız konularda bir birimize soru sormaktan çekinmiyoruz. Hiç birimiz soru sorduğumuz için diğerine kızmıyor. Sadece zamanlaması kötü olduğunda üf püf ediyoruz ama mutlaka cevaplıyoruz. :)


Yazılım üretiminden fatura kesimine bir iş akışı modeli

Yazılım firması olsak da bazı işlerimizi dış ürünler kullanarak yapıyoruz. Böylelikle hem tekerleği yeniden keşfetmek ile zaman kaybetmiyor hem de işimizi uzmanlara teslim ediyoruz. Usta olabilmek önemli. İşimizi en severek teslim ettiğimiz yazılımlardan birisi Fogbugz, biz ona kısaca Takip diyoruz.

Yaklaşık 3 yıldır Erkyazılım bünyesinde uyguladığımız bir işleri kategorize etme yöntemi var. Bu sayede önümüze gelen işleri Takip sistemimizde sınıflandırıyor ve müşterilerimize en güzel hizmeti üretmeye çalışıyoruz. (Takip yokken günlük eposta raporlarında bunları tutuyor ve takip ediyorduk, illa bir sisteminiz olması gerekmiyor, sistematiğinizin olması önemli)

Üretimi yeni proje, garanti, bakım ve geliştirme olarak sınıflara ayırdık. Gelen her iş kalemi bunlardan birisine giriyor ve orada hata, özellik, araştırma gibi alt kademelere indirgeniyor.

Yeni proje: Satış tarafından gerçekleştirilmiş, paket halinde satılmış, kapsamı belli (x firması y projesi, y projesinin mobili vb.) üretim süreçlerini kapsıyor.

Garanti kapsamı: Yeni almış olduğumuz bir işin proje kapsamında yapılmasını taahhüt edip yaptığımız işleri koyduğumuz kategori. İşler nitelik açısından bakım kapsamı ile aynı olmakla beraber, garanti ve bakım arasındaki fark, garantini kapsamının sadece sözleşmedeki garanti sürecini kapsaması. (Garanti süresi müşteriden müşteriye  değişiklik arz edebiliyor ama genellikle  1 yıldır.)

Bakım kapsamı: Bakım, garanti sonrası yapılan ve programlarımızdaki bize bakan bazı şeylerin düzeltilmesi, yeni sürüm yüklenmesi vb. sürecine verdiğimiz isim. Burada iki durum söz konusu. Eğer bakım anlaşması yapılmış ise müşteriye ücretlendirme yapılmıyor. Eğer bakım anlaşması yapılmadı ise, şu kadar süre bakım yaptık diye aynı geliştirmedeki gibi dönemsel fatura kesiliyor. Bu yüzden neyin bakım neyin, geliştirme olduğu oldukça önemli.

Geliştirme kapsamı: Adı üstünde olan "geliştirme" var olan projeye yeni modüller/özellikler eklemek,  yani daha önceden olmayan değişiklikler ile ortaya çıkan işleri ve bunların sürecini kapsıyor. Bu kalemdeki her çalışma adam/saat bazında ücretlendiriliyor.

Küçük bir teşekkür: Her nekadar akıllı bir yazılım bizlere yardımcı olsa da, bunları derleyip toparlayan, son rapor hallerini yönetim ve müşterilerimiz ile paylaşan birisine her zaman ihtiyaç var. Bu işi bizde yürüten muhasebe yöneticimiz Bayram Çotur'a buradan kocaman bir teşekkür gönderiyorum :)


Çevik Yazılım Metotlarının Satışa Etkisi ve Müşteri Memnuniyeti

Erkyazılım’ın çevik (agile) yazılım metotlarını benimsemiş olmasının en çok sevindiğim yanı, çevik yazılım yaklaşımının müşteri memnuniyeti sağladığı kadar satış sürecinin de hızlı olmasına olanak sağlaması. Gerkçekleştirdiğimiz projeler çerçeve olarak sektör bazında benzerlik gösterse de (örneğin: Enerji sektörü/online ödeme sistemi gibi) müşterilere göre özelleştirmeleri herbir projeyi oldukça değiştiriyor, kendine özgü hale getiriyor. Çevik metodlar ile proje içindeki her bir yazılım özelleştirme isteğini küçük parçalara bölüyoruz. Bunları müşteriye ayrı ayrı onaylatabiliyor olmak, ya da müşteri istediğinden vazgeçtiğinde geri dönme kolaylığının olması fiyatlandırma konusunda da ölçeklenebilirlik kazandırıyor.

Bildiğiniz gibi, çevik yazılım manifestosu 4 basit ilkenin benimsenmesidir ve bunlar, müşteri memnuniyetinin temelidir. Aynı zamanda bunun tersi müşteri şikâyetlerinin ve yolun sonundan bile geri dönülen yazılım projelerinin temel kaynağıdır.  Bugün yazılım projeleri anlamında iş yapılabiliyorsa bu beklentiler karşılanıyor demektir.  Demek ki, çevik yazılım ilkeleri artık bu bir manifestodan öte, bir iş yapma şekli haline gelmiş.

Bir projeye başlarken, herkesin aynı araçları kullanması güzel bir şeydir. Peki, farklı araçları kullananlar iş yapamayacak mı? Elbette hayır. Bizim müşterilerimiz farklı farklı ürünler ve metodlar kullandıkları halde, proje sürecinde her alternatifte müşterilerimizle iletişimi gerektiği gibi kurabiliyoruz.

Bir ilke de dokümantasyonla uğraşmak yerine yazılımı çalıştır mantığıdır. Detaylı dokümantasyon süreyi ve maliyeti artırdığı gibi, hiçbir zaman çalışan bir yazılım kadar müşteriyi memnun etmeyecektir.

Diğer manifesto ilkesine gelelim. Her sözleşmede keskin kurallar koyulmaya çalışılır. Fakat hiçbir kesin kural, yazılım şirketini müşteri ile hemfikir olmak kadar kazançlı kılmaz. Çünkü en azından ihtiyaçlar adına söylemek lazım; başlangıçta hayal gücü ile tasvir edilen ihtiyaçlar,  projenin ilerleyen aşamalarında daha net belirir. Yazılım şirketi sözleşmeye uymaya çalışırken, müşterinin ihtiyacını karşılamamış olacak. Sözleşmeye uyuldu belki ama nerede müşteri memnuniyeti?

Sözleşmelerde ve teklif metinlerinde ifade edilen cümlelerin dahi yanlış anlaşılma ihtimalleri söz konusudur. Teknik olarak her şeyin yapılabildiği günümüzde, yazılım projelerindeki en büyük maliyet ve “yapılmayanlar listesinin” uzamasının sebebini “farklı yorumlamalar” oluşturmaktadır.

Küçük parçalar halinde yapılan teslimat ve alınan onaylar, sonrasında emin adımlarla ilerlemeyi sağlıyor. Gidilen yolda, yapılmayan iş kalmamış oluyor. Bu yazılım şirketi olarak bizi de memnun ediyor, bizimle çalışan firmayı da memnun ediyor. Aynı zamanda,  firma adına ürün kabulü yapacak olan yetkili, yaptırdığı işleri aşama aşama çalıştığına şahit olduktan sonra, çalışma süreci de asla gergin geçmiyor.

Bunlar üretim ve sonrasında sağladığı kolaylıklar. Bunun bir de satış kolaylaştıran pazarlık kabiliyeti kazandırdığını düşünecek olursak, projeyi küçük parçalara bölebildiğimiz oranda başarı kazanıyoruz.

Aynı zamanda satış sürecinde de müşterimiz verilen teklifin neye göre verildiğini sorgulayabildiği için, aldığı fiyatı değerlendirirken modül bazında tercih yapabiliyor, aldığı iskontonun haricinde bir de önem/aciliyet değerlendirmesi yaparak fiyatı kendi kriterlerine göre aşağı çekebiliyorlar.

Sadece 4 basit ilke bütün bunları sağlıyorsa bence bu manifesto, mutlu müşteri manifestosudur.


Çevik Yöntemler ve CMMI ?

Uzun yıllardır Bilgi yönetimi Portallerinden Kurumsal Portal Uygulamalarına; Kurumsal Entegrasyondan Belge Yönetimine kadar farklı sahalarda iş yapmaya çalıştık.

Bazı işler zamanla olgunlaşıyor. Son 4-5 yılımız Internet sektöründe Web 2.0 teknolojilerini anlama ve uygulamayla geçti diyebilirim.

Portal, Semantik Web, Ontoloji, Türkçe Dil İşleme konuları hep ilgi sahamızda oldu. Hem günlük ticari hayatımızı devam ettirirken hemde ARGE yapmaya gayret gösterdik.

2009 yılından itibaren Data-mining, Elektronik Belge Yönetimi, konularında ARGE fırsatları aradık.

Kasım 2010 tarihinde Tübitak BİLGEM’le ARGE projelerine resmi olarak başlamış olduk.

Tübitak ve süreçlerini anlamak biraz zamanımızı alsada sonunda hergeçen gün yaptığı işi ARGE merkezli, standartlara uygun yapmaya çalışan bir firma olmak bize mutluluk veriyor.

Tübitak’la iş yapmak gerçekten zor diyebilirim. Şimdiye kadar Çevik Metodları benimsemiş firmamızın doküman ağırlıklı bir sürece adapte olması biraz zaman alıyor. Doküman ağırlıklı bir süreç yönetmek yerine 2007 yılında Orhan Kalaycının verdiği seminerde anlattığı gibi Çevik Yöntemleri benimsemiş bir CMMI olgunluk seviyesi olabilir diye düşünüyorum. Bu konuda çalışmalara en azından fikir planında başladım diyebilirim.

Bu fikirlerimi ve isteklerimi sevgili dostum Orhan Kalaycı’yla paylaştığımda aşağıdaki önerileri oldu.

Yöneticiler aşağıdaki soruların cevaplarını aramalı:

  • Müşteri istekleri tam anlaşılmış mı?
  • Yapılan işler müşteri isteklerine göre planlanmış mı?
  • Planlara uygun ilerliyor mui?
  • Test çok önemli - müşteri İstekleri dahil hersey test ediliyor mu?


Detaya girersek liste uzun ama uzun lafın kısası: şirket içinde herkese ara sıra “Ne yapıyorsun? Planın var mı? Ne zaman bitecek? Nerden buldun o süreyi, bitirme süresini” soruları sorulmalı.

En önemli sorulardan birisi : Yaptığın işi nasıl test ediyorsun. Bu testleri otomasyona geçirebilir miyiz?

Yöneticiler aşağıdaki konulara dikkat etmeli:

1. Plan

  • Bütün yazılım geliştirme faaliyetleri (gereksim analizi dahil) planlı olmalı
  • En fazla İki günlük işler halinde küçük parçalara bölünmeli

2. Sayılar

  • Süre maliyet hata sayısı gereksinim sayısı
  • Gereksinimlerin ne kadarı analiz edildi ne kadarı geliştirmede, ne kadarı testten gecti ne kadarı testten kaldı. Bunların hepsi sayısal olarak istenmeli.

3. Test

  • Test otomasyonu
  • Gereksinimlerin test edilme oranları
  • Test ortamı, vb.

Yukarıdaki Orhan Kalaycı’nın yaptığı tespitlerin hepsine katılıyorum.

CMMI konusunda şekle fazla takılmadan CMMI modelinin özüne ve amacına odaklanıp ve mümkün olduğunca sadece belge ağırlıklı şeklen yaklaşımlardan uzak durmayı ve kuralların lafzaatina değil hikmetine yani neden ne amaçla konduklarına odaklanmayı düşünüyorum.
Konu ile ilgilenenler için Emin BORANDAĞ'ın "BASAMAKLI CMMI MODELİ İLE EXTREME PROGRAMMING METODUNUN DEĞERLENDİRİLMESİ" konulu Yüksek lisans tezini, Orhan Kalaycı'nın CMMI ve Çevik Yöntemler dökümanını incelemenizi öneririm