Yazı dizisinin önceki bölümleri :

• Agile (Çevik) Yazılım GeliÅŸtirme Süreçleri
• Agile Süreçler II : Genel Süreç Ä°ÅŸleyiÅŸi
• Agile Süreçler III : Release Süreç Ä°ÅŸleyiÅŸi

Notlar

• Agile’da bir kartın done olarak iÅŸaretlenebilmesi için tek koÅŸul testlerden geçmesidir.
• Agile’da çok sık yapılan iÅŸlemlerin bir ÅŸekilde otomatize edilmesi (otomatik testler, çok sık yapılan iÅŸlemler için scriptler yazılması vs.) gereklidir.
• Hız tahmini yaparken son 3 iterasyonun ortalaması alınır.
  • (bu uygulama için burn down chart yapılmalı)

Agile Tasarım Yaklaşımları

• Sade bir tasarım olmalı : (önem sırasına göre)
  • Projedeki kodlar bütün otomatik testlerden geçmeli
  • Duplicate kod yazılmamalı (bunun için araçlar var)
  • Koda bakınca çok kolay bir ÅŸekilde anlaşılmalı (kod kendini dokümante etmeli).
  • Çözümün birden fazla class’a ve/veya çok fazla metoda baÄŸlanmamış olması (minimum programlama elementi kullanılması, yani gereksiz patternlar gibi elementlerin kullanılmaması) gereklidir.

Agile Prensipleri

• Ä°nsanların, bireylerin arasındaki iletiÅŸim süreçlerden daha önemlidir.
• Çalışan yazılım kapsamlı dökümantasyondan daha önemlidir.
• Müşteriyle iÅŸbirliÄŸi yapmak sözleÅŸmelerden, ÅŸartnamelerden daha önemlidir.
• Proje başında bir plan yapmaktansa, bu planı proje süresine yayıp daha esnek bir süreç elde edilmelidir.

Story oluşturmada INVEST Kuralı :

I (Independet) : Storyler birbirinden bağımsız olmalı.

N (Negotiable): kendi başına bir anlam ifade etmeli, bağımlı olmamalı. İçersinde başka user storyler barındırmamalı.

V (Valuable): Mutlaka bir deÄŸer ifade etmeli.

E (Estimatable): Büyüklük verilebilir olmalı.

S (Small): Yeterince kısa ve küçük olmalı.

T (Testable): Test edilebilir olmalı.

Ekler

• Agile & Scrum Release Burndown Charts
• Kazanılmış DeÄŸer Yönetimi -3
• Agile Yazılım GeliÅŸtirme ve Scrum