26 Aralık 2012 Çarşamba

Definition of Done'nın gücü

Yazılım geliştirenler bilirler. Yazılım aslında bir problemi çözülebilir küçük parçalara ayırıp çözme işidir. Küçük parçalar ne kadar küçük ve anlaşılırsa çözmesi de o kadar kolay olur.

Mesela amacımız kullanıcı giriş ekranları ve modulü olsun. Elimizdeki bu problem, veritabanı tasarımından arabirime, iş mantığından site konfigurasyonuna kadar onlarca küçük parçadan oluşur. Her bir parçayı, yani her bir işi bitirip bir başkasına geçeriz.  Peki bir işin bitip bitmediğini nasıl anlarız?


Bu ilginç bir soru aslında. Veritabanında tabloların yaratılıp yaratılmadığını nasıl anlarız diye sormak gibi. Yapan bizsek bir işin bitip bitmediğini de biliriz. Bu soru çok anlamsız gibi gelebilir, ama işin aslı biraz farklı. Şimdi biraz detaya girelim.

Agile der ki, bir parçanın bitip bitmediğini, daha da doğrusu istediğimiz kalitede bitip bitmediğini belirleyen bir çeklist olmalıdır. Proje üzerinde çalışanlar, üzerinde çalıştığı işleri ve kalitelerini bu çekliste bakarak kontrol ederler. Bu çeklistler, yazılım/analiz görevleri (i.e. task) için olduğu gibi, hikayeler (i.e. story), sürümler (i.e. release) ya da döngüler (i.e. spring, iteration) için de olabilir.

Biz bu çekliste "Definiton of Done" yani "bitti'nin tanımı", kısaca DoD diyoruz. Başarılı yazılım geliştirmede anahtar etmenlerden biri DoD'dir. Bir bakıma takımın belirlediği "minimum kalite eşiği"dir. Takımların tüm elemanları ile ortaklaşa belirlediği, kaliteli yazılım yapabilmek için yapmayı taahhüt ettiği kurallardır.

Bu kuralların/çeklistin belirlenmesi ve uygulanması safhasında dikkat edilmesi gereken birkaç ipucu.
  1. Bu çeklistin belirlenmesi en öncelikli iştir. Eğer hala belirlemediyseniz, tüm takımca bir odaya kapanın ve belirleyin.
  2. Her takımın farklı bir DoD listesi olabilir. Ancak şirket size bir şablon liste sunabilir. Bu aslında şirketin benimsediği kalite standartları açısından anlaşılır bir durum.
  3. Yazılım ve analiz görevleri için ayrı DoD listeleri oluşturabilirsiniz.
  4. Hikayeler (i.e. story), döngüler (i.e. spring, iteration), sürümler (i.e. release) ve canlıya çıkış (i.e. production release) için ayrı listeler hazırlayabilirsiniz.
  5. Ana kural, "kurallara uymaktır". Eğer kurallardan bir yada birkaçını uygulayamayacaksanız, listeden kaldırın. 
  6. Ütopik bir liste hazırlamaktan kaçının. Kimse birinci günden bu kültürü oturtamaz.
  7. Düzenli olarak retrospective toplantılarında listeyi gözden geçirin. Listeden bazı kuralları çıkarıp bazı yeni kurallar eklemek isteyebilirsiniz.
  8. Bazı kurallara "gerekirse" diye not düşebilirsiniz. Her bir task için acceptance test yazmaya gerek olmadığı aşikar.
Size daha önce üzerinde çalıştığımız DoD'lardan örnekler vereyim. Uygulanmasının biraz zor olduğunu itiraf etmeliyim. Ama size fikir verebilmesi için iyi olacağı kanaatindeyim.

Yazılım görevleri (i.e. task) için DoD 

  • Unit testler yazıldı
  • Koda yeteri kadar yorum girildi (kod kendini dökümente ediyor)
  • Kod yazıldıktan sonra refaktör edildi (kod yazarı tarafından gözden geçirildi)
  • Continuous integration sunucularında default/unit test build'leri yeşil (unit testler geçiyor)
  • Kod, belirlenmiş format ve isimlendirme kurallarına göre düzenlendi
  • Önceden hazırlanmış test hikayeleri (i.e. test cases) olabildiğince otomatize edildi
  • Ortama özel konfig değerleri (i.e. environment specific properties) belirlendi

Hikayeler (i.e. story) için DoD

  • Bütün yazılım görevleri bitti
  • Analiz ve kapsam dökümanları (i.e. scoping documents) yaratıldı
  • Demo edilecek senaryolar belirlendi
  • Analiz, tasarım ve test hikayeleri dökümente edildi
  • Hikayeler için kritik hatalar giderildi
  • Sprint'in en başında en-baştan-tasarım (i.e. up-front design) yapıldı
  • Hikayeler için performans beklentileri belirlendi
  • Kod başkaları tarafından gözden geçirildi (i.e. code review)
  • Sistemler arası entegrasyon test edildi
  • Integration ve functional testler (ya da acceptance testleri) yazıldı

Sprintler için DoD

  • Bütün hikayeler Product Owner tarafından kabul edildi
  • Sprint gözden geçirme toplantısında (i.e. Sprint Review Meeting) tüm demo senaryoları üzerinden geçildi
  • Continuous integration sunucusundaki integration ve functional dahil tüm build'ler yeşil
  • Test kapsamı (i.e. code/test coverage) hesaplandı ve gözden geçirildi
  • Kritik ve major hatalar giderildi. Diğer hatalar gözden geçirildi
  • Tüm kod gözden geçirilmeleri (i.e. code review) tamamlandı

Sürümler için DoD

  • Tüm performans ve güvenlik testleri yapıldı ve geçti
  • Sürüm notları (i.e. release notes) hazırlandı
  • Sürüm güncelleme planı (gerekirse) hazırlandı
  • Tüm kritik ve major hatalar temizlendi
Peki sizin kalite kurallarınız nedir?

0 yorum:

Yorum Gönder

Template developed by Confluent Forms LLC; more resources at BlogXpertise