Nisan, 2013 | Bayram Üçüncü

Scrum Kavramları

13 Nis

Scrum yaklaşımı üç ana kavram üzerinde inceleyebiliriz. Bunlar: product backlog, sprint backlog ve burn-down chart şeklindedir. Bu elemanlar Scrum yaklaşımı ile geliştirme yaparken takımlara yardımcı olan, yön veren ve projedeki şeffaflığı sağlayan elemanlardır.

Product Backlog (İstekler listesi)

Bir projede takımın tamamlaması gereken işler listesidir. Bu liste müşterinin ürününde ihtiyaç duyduğu ve yapılmasını istediği işlerin listesidir. Scrum yaklaşımının kilit bileşeni olan kullanıcı hikayeleri (user story) bu listenin temelini oluşturmaktadır.

Product Backlog listesi Product Owner tarafından yönetilir. Product Owner kullanıcı hikayelerini (user story) listeye eklemek ve çıkarmakla sorumludur. İstekler listesi müşteri ve Product Owner tarafından öncelik sırasına göre sabit bir şekilde oluşturulur. Bu sabit öncelik sırası Scrum kavramını kilit noktasıdır. Çünkü müşteri için en değerli hikayeler listede en üst sırada yer alacaktır. Kullanıcı hikayeleri eklendikçe listedeki diğer hikayelerle karşılaştırılıp müşteriye göre uygun öncelikli bir yere koyulacaktır. Sprint süresince product backlog listesine kullanıcı hikayeleri eklenmeye devam edebilir. Ancak Sprint tamamlanana kadar eklenen istekler Yürütülmekte olan Sprint turuna sokulmaz ve takıma sunulmaz.

User Stories (Kullanıcı hikayeleri)

Daha önce de belirtildiği gibi Product Backlog listesi öncelik sırsına konulmuş kullanıcı hikayeleri listesidir. Bir kullanıcı hikayesi müşteriye göre değer ifade edecek şekilde kartlara yazılır. Kullanıcı hikayesi geliştiriciye iş önceliği ve önem değerini anlatmak için yazılır. Kullanıcı hikayeleri bir pano üzerine dikey sırada olacak şekilde asılır. Kullanıcı hikayeleri INVEST diye kısa bir isimle adlandırılan kurallar dizisini içerirler. Aşağıdaki listenin baş harflerini birleştirdiğimizde INVEST kelimesi oluşur.

Indipendent(Bağımsızlık): Kullanıcı hikayesi kendi başına bir içeriğe sahip olmalıdır. Diğer kullanıcı hikayelerine bağlı olmamalıdır.
Negotiable(Tartışılabilir): Kullanıcı hikayeleri, bir sprint döngüsüne girene kadar her an değiştirilebilir.
Valuable(Değer): bir kullanıcı hikayesi son kullanıcı için bir değer ifade etmelidir.
Estimable(Tahmin yürütülebilir): Bir kullanıcı hikayesinin süresi tahmin edilebilmelidir.
Sized appropriately(Makul boyut): Kullanıcı hikayeleri plan, görev ve öncelik bakımından derecelendirilmesi ele alınabilmesi için çokkompleks yapıda olmamalıdır.
Testable(Test edilebilirlik): Kullanıcı hikayeleri test edilebilirliği mümkün kılmalıdır.

Sprint Backlog(Sprint Listesi)

Bir Sprint turunda takımın yapacak olduğu işlerin listesidir. Product Backlog listesinin bir alt kümesi olarak düşünülebilir. Product Backlog içerisinde ürüne ait tüm kullanıcı hikayeleri yer alırken Sprint Backlog içerisinde Sprint içerisine alınmış hikayeler ve görevler yer alır. Bir Sprint döngüsü için seçilen bir kullanıcı hikayesi görevlere bölünerek takımda bulunan üyelere dağıtılır.

Görevler ise kullanıcı hikayelerini oluşturan iş birimleri olarak düşünülebilir. Her bir iş birimi bir takım üyesine atanır. Örneğin bir kullanıcı giriş ekranının tasarlanması veya bir ürün kataloğunun hazırlanması birer görev olarak düşünülüp takım üyelerine dağıtılabilir. Bu görevler kartlar üzerine yazılarak bir görev panosuna iliştirilir. Ancak günümüzde gelişmiş yazılımlarla görev panoları yerine bilgisayar ortamında da kayıtlar tutulabilmektedir.

Sprint listesi aynı zamanda iş bitim grafiği(burn-down chart) için de gerekli bilgileri hazırlamaktadır. Her Sprint turunda Sprint panosu boşaltılır. Kalan işler olursa product backlog listesine geri iade edilir.

Born-down chart (İş sonu grafiği)

Sprint turu sırasında takım üyeleri görevlerini yerine getirildikçe kalan iş ve yapılan iş arasındaki korelasyonu belirten bir grafik ortaya çıkmaktadır. Bu grafik takım üyelerine veya yöneticilerine fikir vermektedir. Aynı zamanda takımın iş için istediği sürelerin yeterli olup olmadığı ve işin zamanında tamamlanıp tamamlanamadığı konusunda da fikir veren bir grafiktir. Grafiğin İngilizce adı olan burn-down, sözlük anlamı olarak yanıp bitmek şeklinde ifade edilmektedir. Bunu bir mumun yanarken zamana göre boyunu izlediğimizde bu şekilde bir grafik ortaya çıkar. Scrum yaklaşımında da yapılacak olan işler bittikçe zamana göre azalacak ve belirlenen süre sonunda sıfırlanacaktır.

Scrum Nedir?

10 Nis

Çevik yazılım geliştirme ilkelerinin uygulandığı iteratif bir geliştirme yaklaşımıdır. Scrum yaklaşımı “Sprint” diye adlandırılan zaman dilimlerinden oluşmaktadır. İki veya dört haftalık bu zaman dilimleri sonunda teslimata hazır çalışan programların ortaya koyulması amaçlanmaktadır.

Çalışmalar ürün yöneticisi(product owner) tarafından yapılacaklar işler listesindeki(product backlog) önem sırasına göre dizilir. Sprint’ler oluşmadan önce yapılacaklar listesinden bir iş seçilir ve takım ile iş teslim taahhüdü yapılır.

Her şeyin sorunsuz olması ve teslimin zamanında yapılabilmesi için ScrumMaster diye adlandırılan bir lider, takımın önündeki engelleri kaldırmakla sorumludur. Her gün ayakta yapılan yarım saatlik toplantılarda takım ile teslime engel olabilecek sorunlar ve son durumlar hakkında konuşmalar yapılır.

Aşağıdaki resimde Scrum sürecini anlatan grafiksel bir temsil bulunmaktadır.

Her bir Sprint süresi 2-4 haftadır. Takımlar proje yöneticisi(ScrumMaster) ile her Sprint başlangıcında toplantı yaparak geliştirilecek özellikleri belirlenir. Bu süreçteki özellikler daha önceden oluşturulmuş ve sürekli güncellenen yapılacak işler listesinden(Product Backlog) önem sırasına göre seçilir. Seçilen özellikler Sprint Backlog deinlen yeni bir listeye yazılır. Artık Sprint döngüsü başlamıştır ve sadece ellerindeki Sprint listesiyle ilgilenirler. Bir sonraki Sprint döngüsü başlayana kadar Product Backlog listesine bakmazlar.

Her gün ayakta yapılan ve en fazla 15 dakika süren toplantılar(Dailit Stand-Up) ile sorunlar ve ilerleme durumları ele alınır. Sprintler sonunda teslimata hazır çalışan bir program ortaya çıkar.

Scrum yönteminin sağladığı en büyük faydalardan biri şeffaf ve raporlanabilir bir geliştirme sürecine sahip olabilmektir. Raporlar sayesinde geçen zaman ve kalan zaman grafiklerine bakılarak durum gözlemi yapılabilmektedir.

Kaynak: ProAgile .Net Development with Scrum

Specification Pattern (Şartname Tasarım Kalıbı)

3 Nis

Specification tasarım kalıbı, bir nesne içerisindeki mantıksal (boolean) yapıdaki iş kurallarının, dışarıdan almasını sağlamak amacıyla oluşturulmuştur. İş kuralları, birbirini takip eden zincirli bir yapıda olup daha karmaşık bir iş kuralını da ortaya çıkarabilir.

Kod Örneği

Desenin anlaşılabilmesi açısından bir kod örneği ile devam etmek istiyorum. Kod örneğimizi bir iş nesnesi üzerindeki mantıksal kuralları ele alarak geliştirmeye çalışacağız. Örneğimizde bir ürünü temsil eden tip üzerinden ilerleyeceğiz.

Ürün tipinde, stok durumunun yeterli olup olmadığını belirleyen bir mantıksal iş kuralını dışarıdan temin edecek şekilde modelleyerek ilerleyelim.

Altyapımızı oluştururken öncelikle şartname niteliğinde bir interface hazırlamalıyız.

public interface ISpecification<T>
{
    bool IsSatisfiedBy(T candidate);
}

Şartnamemizde, bu şartnameyi uygulayan sınıfların tipinden bir generic “T” parametresi verilmiştir. Bu sayede şartname tipi dışarıdan alınabilir şekilde genelleştirilmiştir.

ISpecification<T> tipine T parametresi yerine vereceğimiz ve iş nesnesi olarak kullanacağımız ürün tipini, adını Product olacak şekilde belirliyoruz.

public partial class Product
{
    public decimal Stock {get; set; }
}

Artık bu tipimize bir iş kuralı belirlememiz gerekmektedir. İş kuralımızı kısaca stok miktarının kritik olduğu durumu gözetecek şeklide belirleyebiliriz. Stok miktarı 50’nin altına düşerse şartımız çalışacaktır.

public class IsCriticalStock : ISpecification<Product>
{
     public bool IsSatisfiedBy(Product product)
     {
         return candidate.Stock < 50;
     }
}

Şartnameyi kabul eden bir tip olarak IsCriticalStok isimli sınıf oluşturduk. Artık iş kuralını bünyesinde barındıran bu sınıfımızı Product tipine tanıtabiliriz. Product tipimizi yeniden tasarlayacak olursak;

public partial class Product
{
       private readonly IsCriticalStock isCriticalStock;

       public Product()
       {
           isCriticalStock= new IsCriticalStock();
       }

       public decimal Stock {get; set; }

       public bool IsStockEnough()
       {
            return isCriticalStock.IsSatisfiedBy(this);
       }
}

Bu şekilde iş kuralımızı Product tipine geçirmiş oluruz. Kodun okunabilirliğini arttırmak için Product sınıfını parçalı şeklide “Partial” tanımlayabiliriz.

public partial class Product
{
      private readonly IsCriticalStock isCriticalStock;

      public Product()
      {
          isCriticalStock= new IsCriticalStock();
      }

      public decimal Stock {get; set; }
}

public partial class Product
{
      public bool IsStockEnough()
      {
        return isCriticalStock.IsSatisfiedBy(this);
      }
}

Bu örnek aracılığıyla Specification tasarım kalıbını en basit haliyle incelmiş olduk.