24 Mart 2013 Pazar

Agile buluşmanın ardından: Agile & Maintenance

Agile Turkey'in organize ettiği Agile Buluşmalar'ın 6.sı 21 Mart 2013 perşembe günü Astoria AVM Caffe Nero'da gerçekleşti. Uzun bir süredir Silikon Vadisinde çalışmakta olan Hale Yaman'ın, kısa süreli bir tatil için geldiği İstanbul'da bizlere vakit ayırması büyük bir incelikti. Çok sıcak bir sohbet ortamında bizlere "Agile ve Maintenance" konuları hakkında bilgiler verdi. Mevcut deneyimlerini bizlere aktarırken kendisine bolca soru sorma fırsatımız da oldu. Neredeyse konuşulan her kelimeyi aklıma yazmaya çalıştığım bu buluşmayı kaçıranlar bence çok şey kaçırmış oldular. Ancak kaçıranlar çok üzülmesin, konuşulanlardan bir miktarını da olsa aşağıda sizlerle paylaşmak beni mutlu edecektir. (Aşağıdaki notlar, Hale hanımdan alıntılandığı için birinci tekil şahıs şeklinde aktarılmıştır)

Bakım nedir ve kaç çeşittir?
  • Müşteriye ürün teslim edildiği anda artık ürünün bakımı başlar. Eğer ara sürümlerle müşterinin önüne, onun kullanabileceği, henüz tam olarak bitmemiş bir ürün çıkarmış olsanız dahi, ürün çıktıktan hemen sonra bakım süreci işlemeye başlar.
  • Bakım 4 çeşittir. 
    • Hataların düzeltilmesi için bakım. Bu tüm bakım aktivitelerinin yüzde 60'ını kapsar. Yani en çok yapılan bakım çeşidi hataların düzeltilmesi şeklindedir.
    • Uyarlamak için bakım. Mevcut özelliklerin ihtiyaca göre değiştirilmesi. Aslında bu nedenle Agile felsefesine tam uyar. Bakım fikirleri müşteri tarafından gelir.
    • Daha iyi performans ve mükemmelleştirmek için bakım. Bu bakım, üstteki bakımla toplamın yüzde 17-18'ini kapsar. Burada bakım fikirleri bizden (yani yazılım takımından) gelir.
    • Gizli hataları bulmak için bakım. Henüz çıkmamış ancak çıkması muhtemel problemlerin bulunması ve temizlenmesi işi.
Bakım için vakit ve kaynak ayırmanın birkaç yöntemi vardır.
  • Tampon (buffer) zaman ayarlamak. Eğer düzenli olarak dengeli bir şekilde bakım işleri yapıyorsak, her döngüde bir miktar tampon zaman almak mantıklıdır. Scrum'da belli bir miktar bakım işi alınır ve her sprint bakım işi yapılsın ya da yapılması kapatılır.
  • Yeni bir sütun aç. Yani aynen kanban tahtalarında "geliştiriliyor" ya da "test aşamasında" sütunları gibi bir de "bakım" sütunu açabilirsiniz. Her iş eğer bakım ile ilgiliyse o sütuna düşer.
  • Günah keçisi. Her spint takımdaki belli kişi ya da kişileri bakımdan sorumlu destek elemanı olarak seçebilirsiniz. Takımın geri kalanı da yazılıma yeni özellikleri eklemeye devam eder. Tabi bu destek işi pek sevimli gelmez insanların gözüne. Çünkü baya yorucu bir iştir. Ancak bakım işiyle uğraşırken platformu çok iyi öğreneceğinizi ve test yazma kabiliyetlerinizi arttıracağınızı bilmelisiniz.
  • Off-shore günah keçisi. Takım bakım yapmak istemiyorsa bu iş için bazen başka şirketleri görevlendirebilirsiniz. Ben bu yöntem ile pek olumlu sonuç alındığını düşünmüyorum. Ancak zaman zaman uygulandığını biliyorum. Özellikle yetenekli yazılımcıları bünyesine katmak için savaşan start-up'lar, bu yetenekleri sıkıcı bakım işleri ile bıktırmamak için bu yöntemi seçebiliyorlar.
  • Bakım Sprint'i. Bazen bakım ihitiyaçlar öyle birikiyor ki, 2-3 günlük ufak bakım sprint'i yapmak en iyi çözüm olabiliyor. Önerilmiyor, ancak pratikte uygulanıyor. İdealde "Bittinin tanımı (Definition of Done)" iyi ayarlanmalı ve bakıma ihtiyaç olmamalı diyebilirsiniz. Ancak pratikte DoD ne olursa olsun, sizden bağımsız problemler çıkabiliyor.
Bazen bakım konusunda burnunuza kötü kokular gelmeye başlar.
  • Regression'da bulunan hatalar artıyorsa
  • Test kapsamı (test/code coverage) azalıyorsa
  • Refactoring yapmaktan yazılımcılar korkuyorsa, ortada yanlış giden birşeyler var demektir. 
Bakım konusunda birçok "iyi uygulama (best practices)" vardır.
  • Bir hatayı sadece ama sadece bir kere çözün. Yani aynı hatanın birden fazla hortlamasına izin vermeyin. Bunu başarabilmek için şu adımları takip edin.
    • Hatayı bulun ve raporlayın
    • Çözmek için gereken işin bitme süresini tahmin edin.
    • Önceliklendirin. Her hata aynı önceliğe sahip değildir.
    • Kabul (acceptance) ve fonksiyon (functional) test yazın. Bu size ürünün nasıl çalışması gerektiğini bildirecektir.
    • Başarısız olan bir birim testi (unit test) yazın. Hatayı test ile yeniden yaratın.
    • Hatayı çözün.
    • Birim, kabul ve fonksiyon testlerinin geçtiğine emin olun.
    • Regression testlerini yapın.
    • Çözümünüzü yeni sürüm ile çıkın.
  • Sprint öz-değerlendirme toplantıları (sprint retrospectives) kadar hata öz-değerlendirme toplantıları (bug retrospectives) da yapın. Belli hatalar sonrası yapabileceğiniz gibi, düzenli olarak da yapabilirsiniz.
  • O sürümde çözülmüş hataların hepsini mutlaka "sürüm notları (release notes)" içine ekleyin.
  • Mutlaka otomatikleştirilmiş regression testleri oluşturun.
  • Eşli programlama (pair programming) yapın. En verimli eşli programlama, bir uzman ile bir daha az bilgili arasında olandır. Diğer durumlarda sonuç kötü olabiliyor. 
  • Kod gözden geçirme (code review) yapın. Eğer yazılımcılar "code review" yapmıyorlarsa, yazılım süreçlerine "gözden geçiren kişi" gibi alanlar ekleyip bunu zorunlu tutun. 
  • QA elemanları (testçiler) yazılımcılarla aynı takımda olmalıdırlar.
  • Yazılımcı bir özelliği teste göndermeden önce (yani test ortamında başkaları tarafından test edilmeye başlanmadan önce) mutlaka "dev" oramında (kendi makinalarımız değil. Yazılımcıların kullandığı ortak başka bir ortam) "smoke test" yapıp kodunun çalışıp çalışmadığını görmelidir.
  • Eğer bir enkaz devraldıysanız, yani testi olmayan çok eski kodlarda çalışmaya başladıysanız, birer ikişer hikaye (story) alıp test yazarak düzeltmeye başlayabilirsiniz. 
    • Burada birim testi yazmaktan ziyade, öncelikle kabul/fonksiyon testi yazmak önerilir.
  •  "Eğer çalışıyorsa dokunma" felsefesi çok doğru değil. Eğer böyle düşünürsek saatli bomba olarak adlandırılan hataların bir anda ortaya çıkmasına imkan tanımış oluruz. "Technical Dept" olarak bilinen teknik iyileştirme işleri mutlaka azar azar bile olsa hikayeler (stories) ve işler (tasks) ile "ürün özellik listesi (product backlog)" içine girmelidir.
  • Agile ve Scrum, size kaliteli yazılım geliştereceğinizi garanti etmez. Ne kadar süper kod yazarsanız yazın illa bakım ihtiyacı çıkacak. Buna hazırlıklı olmak gerekir. 
Müşteri çoğu zaman bakım için zaman ve para harcamak istemez.
  • Bazen bir nüsibet bin nasihattan iyidir. Önerilerinize kulak asmazlarsa, sonradan çıkacak ani büyük hataları da kabullenmiş olacaklardır. Bir büyük hatada dediklerinizi daha iyi anlayacaklar.
  • Eğer bir proje üzerinde bakım yapmıyorsanız, yaşaması gereksiz olacağından yazılımı öldürmeniz gerekir.
  • Bazen de müşteriden yüzde 10-20 fazla zaman istenir ve tüm bu zamana bakım yedirilebilir.
Hale Yaman uzun bir süredir Scrum Master olduğundan, bizlere birkaç tiyo vermeyi de ihmal etmedi.
  • "Code review", kişisel bir tartışma haline gelebilir ortam gerginleşebilir. Bu durumda SM hemen müdahale etmeli ve kodu yorumlayacak kişileri değiştirmelidir.
  • SM herkesi duymalıdır. Tüm takımın ortasına oturmalıdır.
  • SM ve PO arasında tam güven şarttır. Tabi bu güveni oluşturmak biraz zaman alabilir.
  • SM bir hizmetkar liderdir desek bile, SM pozisyonuna malesef yönetme meraklısı insanlar gelebiliyor. Böyle durumlarda diğer insanların SM olması zor oluyor.
  • Retrospective toplantılarında dışarıdan bir toplantı yöneticisi olması çok faydalı olabilir.
Hale Yaman'ı daha birçok defa dinlemeyi çok isterim. Bu çok değerli bilgileri ve deneyimlerini bizlerle paylaştığı için kendisine teşekkür ederim. Ayrıca tüm agile buluşmalarının organizasyonunu bizzat üstlenen Hande Güneş'e de özel teşekkürlerimi sunarım.

0 yorum:

Yorum Gönder

Template developed by Confluent Forms LLC; more resources at BlogXpertise