Eksik Gereksinim Analizleri ve Neticeleri

Bir yazılım ürününün kontrollü ve istenilen nitelikte ortaya çıkabilmesi için gereksinim analizi yapılması gerekmektedir. Gereksinim analizi kısaca müşterinin piyasa koşullarından doğan gereksinimlerinin tespit edilmesidir. Bu analiz müşteri ne ister sorusunun cevabını vermelidir. Aksi taktirde müşterinin ihtiyacı olmayan bir ürün ortaya çıkma riski oluşabilir. Bu yazımda bu tür gereksinim analizlerinin doğru yapılmadığı durumlarda doğabilecek sıkıntılardan bahsetmek istiyorum.

Günümüz projelerinde Jira vari sistemler kullanılarak müşteri gereksinimleri kullanıcı hikayeleri (user story) olarak kanban board üzerinde sprint backlog ya da genel backlog içinde yer alırlar. Bu kullanıcı hikayeleri müşteri ile yapılan görüşmeler sonunda tespit edilen gereksinimlerin kağıda dökülmüş halleridir. Bir kullanıcı hikayesi sonuç itibarı ile uygulama bünyesinde oluşturulması istenen bir özelliğin kısa bir özetidir. Örneğin “kullanıcı isim ve şifresini kullanarak, sisteme giriş yapar” bir kullanıcı hikayesidir. Yazılımcılar plannıng poker oturumlarında bu tür kullanıcı hikayelerinin hangi zaman diliminde implemente edilebileceklerini tahmin etmeye çalışırlar. Genelde story point olarak tabir edilen bir derecelendirme yöntemi ile tahminler yapılır. Herkesin bildiği gibi bu tahminler aslında gerçekleri yansıtmaz, lakin proje yönetimi nedendir bilinmez bu tahminlerin yapılmasında ısrar eder.

Bir kullanıcı hikayesinin içeriği yanı sıra onay/kabul kriterlerinin de (acceptance criteria) tanımlanmış olması önem taşımaktadır. Şahsen onay/kabul kriteri tanımlanmamış bir kullanıcı hikayesine elimi bile sürmezdim, çünkü hangi kriterlere göre daha sonra bu kullanıcı hikayesinin çalışır halde olduğunu ispatlayabilirdim! Bu mümkün değil. Bu sebepten dolayı kullanıcı hikayesini oluşturan kişinin, bu genelde gereksnim analizi yapan ürün sahibi (product owner) olabilir onay/kabul kriterlerini de eklemesi gerekmektedir. Yukarıdaki örnek kullanıcı hikayesinin onay/kabul kriterleri şu şekilde olabilir:

• Kullanıcı ismi ya da sifresi yanlış ise, kullanıcıya “Lütfen doğru bilgiler ile giriş yapınız” hatası gösterilir.
• Kullanıcı ismi alanı boş bırakılarak, login butonuna tıklandı ise, kullanıcıya “Lütfen kullanıcı ismini giriniz” hatası gösterilir.
• Şifre alanı boş bırakılarak, login butonuna tıklandı ise, kullanıcıya “Lütfen şifrenizi giriniz” hatası gösterilir.
• Kullanıcı ismi ve şifre doğru ise, login işlemi gerçekleştirilir ve kullanıcı ana sayfaya yönlendirilir.

Yazılımcı oluşturacağı implementasyonu bu onay/kabul kriterleri doğrultusunda şekillendirir. Burada ATDD (acceptance test driven development) tam da onay/kabul kriterlerine karşılık gelen bir implementasyonun oluşmasını sağlayacaktır. Bu implementasyon ne bir eksiklik ne de bir fazlalık ihtiva edecektir. Genellikle yazılımcı test güdümlü çalışmadığında “belki kullanılır, su metot da olsun” eğilimi ile fazladan kod yazabilir. Test güdümlü yazılımda oluşturulan kullanıcı ve program arayüzünin (APİ – application programming ınterface) ilk kullanıcısı testler olduğu için, yazılımcı bu api arkasında sadece gerekli ve yeterli olan implementasyonu oluşturarak, ilerleyecektir.

Buraya kadar kabaca gereksinim analizinin nasıl bir kullanıcı hikayesine, oradan da koda dönüşebileceğine değindik. Sonuç itibarı ile gereksinim analizinden doğan kullanıcı hikayeleri ürün sahibi (product owner) ile yazılımcı ekibi arasındaki kontratı temsil etmektedirler. Ürün sahibi ne istediğini (bunlar müşterinin istekleri ve gereksinimleridir) kullanıcı hikayeleri olarak formalleştirir ve yazılım ekibine implemente edilmek üzere devreder. Yukarda bahsettiğim kullanıcı hikayesi çok basit bir örnek, bu yüzden büyük çapta arzu edilmeyen bir şeylerin implemente edilme olasılığı çok düşük. Ayrıca onay/kabul kriterleri de tanımlı olduğundan, yazılımcı bu kriterler doğrultusunda çok hızlı bir şekilde gerekli implementasyonu oluşturabilir. Şimdi daha büyük çaplı ve karmaşık kullanıcı hikayelerinin oluşturulmasında bir takım hatalar yapılması durumunda, oluşabilecek problemlere değinmek istiyorum.

Bizden gerekli verilerin yüzlerce kolonu olan bir excel dosyası olarak export edilmesinin istendiğini düşünelim. Böyle bir kullanıcı hikayesinde yazılımcının görmek istediği ilk şey hangi verinin hangi kolondo yer alacak oluşudur. Bu amaçla ürün sahibinin böyle bir mapping oluşturarak, kullanıcı hikayesine eklediğini varsayalım. Onay/kabul kriteri olarak da “kullanıcı export butonuna tıklayınca, veriler excel dosyası olarak indirilir” tanımlı olsun. Şimdi bu örnek üzerinden nelerin yanlış gidebileceğine yakından göz atalım.

Daha önce 200+ kolonu olan bir excel dosyası oluşturdunuz mu bilmiyorum, lakin çok eğlenceli bir uğraş değil. Ana problemlerden birisi verilerin nereden geleceğini tespit etmektedir. Bu ürün sahibinin görevidir ve hangi verilerin nereden alınacağını oluşturacağı mapping bünyesinde tanımlar. Bunun yanı sıra bu verilerin hangi kolona yerleştirileceği bilgisi de bu mapping bünyesinde yer almak zorundadır. Şimdi biz haftalar süren çalışmalar sonunda export özelliğini çalışır hale getirmiş olalım ve uygulama bu yeni özelliği ile müşteriye/kullanıcılara yeni bir sürüm bünyesinde sunulmuş olsun. Kullanıcılar doğal olarak bu özelliği kullanarak, ilk excel dosyalarını oluşturacaklar ve bize ulaşan bilgilere göre export özelliği istedikleri verileri ihtiva etmeyecek. Durum bir bug olarak tekrar bize iletiliyor ve hatayı girememiz talep ediliyor.

Ortada gerçekten bir hata var mı? Ben böyle bir durumu daha önce yaptığım bir projede yaşadım ve bundan sonra olanları aktararak, nelerin yanlış yapıldığına değinmek istiyorum, çünkü yazılımcı ekibi gereksinimi doğru implemente etmemekle suçlandı. Bakalım suçlu kim!

Öncelikle amaç hiçbir zaman suçlu aramak olmamalıdır. Bu zayıf insanların işidir ve kesinlikle böyle süreçlere dahil olmamak gerekir. Bunun yerine sürecin neresinde hata yapıldı ve bu hatanın bedeli ne oldu sorusuna cevap aranması gerekmektedir. Sonucu biliyoruz, ama buraya nasıl gelindi?

Tekrar kullanıcı hikayesine bir göz atalım. Bu kullanıcı hikayesi bünyesinde 200+ kolon ihtiva eden bir mapping tablosu mevcut. Bize iletilen bugda belli kolonlarda verilerin eksik olduğu bilgisi mevcut. Tekrar kullanıcı hikayesindeki mapping tablosuna baktığımızda boş kalan kolonların nedenini görebiliyoruz: bu kolonlar için sadece belli tipte bir veri tanımlanmış (Drugtype.MIXTIRE ) ve yapılan export işlemi diğer tiplerdeki verileri (örneğin DIVISION) ihtiva etmiyor ve göz ardı ediyor. Aşağıda bu mapping tablosunda yer alan 44. ve 45. satırları görmekteyiz. 44 ve akabinde bu gruba dahil kolonlarda MIXTIRE türünde verilerin kullanılması gerektiğinden bahsediliyor. Gelen bug raporunda ise MIXTIRE harici diğer verilerin excel dosyasında yer almadığından bahsediliyor.

Verilerin hangi yapıda olduklarını anlamak için aşağıdaki enum sınıfına bir göz atalım:

public enüm DrugType{
MIXTIRE,
DIVISION,
COMPLETED_PRODUCTS,
DIVIDED_PRODUCTS
}

Kullanıcı hikayesinde sadece MIXTIRE tipinde olan verilerin export edileceğinden bahsediliyor. Bu durumda yazılımcı kullanıcı hikayesinde yer alan veriler doğrultusunda gerekli implementasyonu gerçekleştirmiştir. Ama kullanıcılar DIVISION ya da başka tipte olan verileri de export etmeye çalıştıklarında, gerekli kolonlar boş kalmaktadır.

Ürün sahibi ile yaptığımız bir kriz toplantısında bize bunun bir bug olduğunu ve diğer tipteki verilerin de export edilmesi gerektiğini söyledi. Hemen şunu belirteyim: ortada bir bug yok! Bu bir change request, çünkü kullanıcı hikayesinde ne yer alıyorsa, yazılımcı ekibi onu implemente etmiştir. Bunu bu şekilde ürün sahibine aktardığımızda, “ben refinement toplantılarında bunu sözlü olarak söylemiştim” cevabını aldık. Ürün sahibi ne yazık ki kusura bakmasın! Kullanıcı hikayesinde ne yazıyorsa, gerçek o dur ve yazılımcı ona göre hareket eder. Bir takım toplantılar esnasında konuşulanlar eğer kullanıcı hikayelerine not düşülmesse, geçerlilikleri yoktur. Bu yüzden ürün sahibinin böyle bir argüman ile gelmesi kabul edilemez. Eğer bir kullanıcı hikayesi ürün sahibi ile yazılım ekibi arasında bir kontrat vazifesi rolünü üstlenerekse, bu durumda gerekli bütün bilgilerin kullanıcı hikayesi bünyesinde yazılı olarak yer alması gerekmektedir.

Ben çoğu zaman bir kullanıcı hikayesini implemente eden bir yazılımcının gördüğü eksikleri kullanıcı hikayesine not düşmeden ürün sahibi ya da diğer yazılımcılar ile bilateral çözmeye çalıştığına şahit oluyorum. Bu çok tehlikeli bir durum arz etmektedir. Eğer bir eksik varsa ve bunun ne olduğu tespit edilmişse, hiç zaman kaybetmeden kullanıcı hikayesine gerekli not düşülmeli ve kontrat yenilenerek, yapılması gerekenler somutlaştırılmalıdır. Oluşturulan implementasyonun garantisi her zaman bu kontrattır.

Bahsetmiş olduğum export konusundaki ana problem analizi yapan şahsın ya da ürün sahibinin export için gerekli olan analizi geniş kapsamlı yapmamış olmasıdır. Oluşturması gereken mapping tablosunun daha kapsamlı olması gerekiyordu. Bunun yanı sıra ürün sahibi oluşturulan bu yeni özelliği test ederek, kabul etmiştir. Yani en geç test esnasında bu hatanın göze batması gerekirdi, lakin böyle bir şey olmadı.

Yazılımcı olarak kendimizi sadece onay/kabul kriterlerini baz alarak gerekli implementasyonu yaptığımızda garantiye alabiliriz. Bu yüzden mutlaka ve mutlaka onay/kabul kriterlerinin kullanılması gerekliliği DOR (definition of ready) bünyesinde tanımlı olmalıdır.

Kısaca özetleyecek olursak:

• Her bug olarak gelen repor bir bug olmayabilir. Çoğu zaman bu bir change requestdir ve gereksinim analizi yapan ekip işini doğru yapmadığı için bu eksikliği etrafına bug olarak lanse edebilir.
• Yazılımcılar önlerine gelen her kullanıcı hikayesini içerik olarak doğru olup, olmadığını sorgulamalıdırlar. Eğer eksik olduğunu düşündükleri noktalar varsa, kullanıcı hikayesini reddetme hakkına sahiptirler. Ürün sahibi tespit edilen eksiklikleri tamamlamakla yükümlüdür.
• Toplantılarda sözlü olarak yapılan tespitler mutlaka kullanıcı hikayelerine not düşülmelidirler. Bu şekilde kontrat yenilenir ve bu bilgiler göz ardı edilmez.
• Yazılımcılar onay/kabul kriteri olmayan kullanıcı hikayelerini reddetme hakkına sahiptirler. Onay/kabul kriteri olmayan kullanıcı hikayeleri saatli bomba gibidirler. İmplementasyonun kullanıcının elinde patlama ihtimalleri çok yüksektir.
• Ürün sahibi tanımladığı onay/kabul kriterlerini elden yaptığı testler aracılığı ile kontrol eder. Yazılımcı her onay/kabul kriteri için bir onay/kabul testi yazar. Bu testleri otomatik olarak çalışır ve kullanıcı hikayesinde yer alan uygulama özelliğinin çalışır durumda olduğunun kanıtıdırlar.
• DOR bünyesinde yer alan kriterlere uymayan kullanıcı hikayeleri yazılım ekibi tarafından sahibine geri gönderilir.
• DOD (definition of done) bünyesinde yer alan kriterlere uygmayan kullanıcı hikayesi implementasyonları ürün sahibi tarafından yazılım ekibine geri gönderilir.

EOF (End Of Fun)
Özcan Acar