Agile yöntemlerden olan Scrum’ın Pratikteki Uyarlanması’nı incelediğimiz yazı dizisine, Scrum Çıktıları’nı konu alan 5.bölüm ile devam ediyoruz.

Sprint Review

Her Sprint sonunda yapılması gereken iki toplantı vardır. Bunlardan ilki biten sprinti gözden geçirdiğimiz Sprint Review toplantısıdır. Bazı yerler Sprint Demo olarak da değerlendirebiliyor.

– Bir aylık bir Sprint için 4 saat (timeboxed) olarak belirlenmiştir. Daha kısa süreli sprintler için orantılı olarak bu süre kısaltılmalıdır. –

Sprint Review toplantısında müşteri ve ekip bir araya gelir ve birlikte 2 şeyi gözden geçirirler:

• Completed Output – Müşteri tamamlanan çıktıyı dener ve geri bildirimlerde bulunur. Bu geri bildirimler ile Product Backlog listesinde düzenlemeler yapılır. Biz buna adaptaston (Adaptation) diyoruz.
• Project Progress – Product Owner projenin performansını hesaplamak ile sorumludur. Yaptığı performans çalışmasını bu toplantıda müşteriye sunmalıdır. Müşteriye verilecek olan en önemli bilgi, tahminlenen proje tamamlanma süresi ve tarihidir.

Bu arada önemli bir konu da “Çıktı”yı tanımlama anlama şeklidir. Herkesçe aynı şekilde algılanmalıdır.

Increments

Her Sprint sonunda bir ürün veya çalışabilir bir yazılım parçası çıkarılmaldır. Scrum’da, müşteri için anlamlı ve fonksiyonel olan bu yazılıma “Increment” denir.

Increment’in temel özelliği potansiyel olarak canlıya alınabilir (Potentially Releasable) olmasıdır. Fakat bu illa canlıya almamız gerektiği anlamına gelmez, böyle bir zorunluluk yoktur. amaç sadece müşteriye gerçek bir deneyim sunmaktır. Müşteriden gelecek olan geri bildirimleri daha sağlıklı almamızı sağlar. Scrum proje geliştirme sürecinde değişikliklere uyum sağlamayı hedefler. Dolayısı ile geri bildirimler uyarlamanın temelini oluşturur. Adaptasyon ancak bu şekilde sağlanabilir.

Increment’in potentially releasable olması, Product Backlog ögesinin %100’ü tamamlandı (Done) anlamındadır. En ufak bir eksiklik (%99.99) bile olsa bu o ögenin tamamlanmadığı anlamına gelir ve o öge bir sonraki sprintlerde geliştirilmek üzere tekrar Product Backlog listesine eklenir.

Peki, bir ögenin %100 tamamlanmış olup olmadığını nasıl belirleriz?

Definition of Done

Definition of Done, yani “Çıktı”nın tanımı, herkesin aynı şekilde anlayabileceği şekilde, açık, iyi tanımlanmış ve belgelenmiş olması gerekir. Bu tanım, her bir Product Backlog ögesi için yapılması gereken ortak işlemleri açıklar.

Bu ortak işlemler;

• Development Processes: Geliştirme sırasında yapılması gereken tüm süreçler: Analiz, dizayn, kodlama, entegrasyon, test, dokümantasyon
• Quality: Geliştirilen ürün parçasının, fonksiyonları ve kabul kriterlerinin kontrol edilmesi.
• Non-functional Features: Geliştirilen ürün parçasının teknik olamayan özelliklerinin isterlere göre geliştirilmesi ve kontrolü.

Teknik olmayan özellikleri, performans, güvenlik, kullanıcı deneyimi (User Experience – UX), ölçeklenebilirlik (scalability), sürdürülebilirlik (maintainability) ve bunun gibi özelliklerdir. Bunlar fonksiyonel olmadıkları için, Product Backlog içinde bir öge olarak yer alamazlar. Bu yüzden her Product Backlog ögesinin non-funtional özellikleri bulunduğu Sprint içinde geliştirilmeli ve definition of done içinde yer almalıdır.

Sprint Retrospective

Sprint bittiğinde bir sonraki Sprint’e geçmeden yapılması gereken son aktivite geliştirmemize yatırım yapmaktır. Yürüttüğümüz Sprint’lerin daha iyi olmasını hedeflenip, iyileştirme çalışmaları yaptığımız bu aktivite Sprint Retrospective toplantılarıdır.

– Bir aylık bir Sprint için 3 saat (timeboxed) olarak belirlenmiştir. Daha kısa süreli sprintler için orantılı olarak bu süre kısaltılmalıdır. –

Bu toplantıda, bir sonraki sprint süreçleri için küçük bir iyileştirme çalışması yapılır. Gerçekleştirilebilir olması için bu çalışma küçük tutulmalıdır. Ayrıca ölüçülebilir olmalıdır böylece uygulandığında başarılı olup olmadığı görülebilir.

Sprint Retrospective, geliştirme süreçlerini iyileştirmek için yapılan bir çalışmadır ama çözüm üretilen bir çalışma değildir. Agile yöntemlerde çözüm üretimi için yapılan aktiviteler de mevcuttur ama yeri retrospective değildir.

Continuous Refactoring

Sprint Retorspective sürecin iyileştirilmesiyle ilgilidir. Çözümün ise sürekli (continous) refactoring ile geliştirilmesi gerekiyor.

Refactoring işlemi, geliştirilen kodun davranışını değiştirmeden yeniden düzenlenmesi işlemidir.

Agile geliştirme süreçlerinde mimari için bir ön çalışma (Upfront Design) yapılmaz. Mimari, geliştirme süreci ile beraber eş zamanlı gelişir. Bu yüzden de zaman zaman mimari zayıf kalabilir. Bunu önlemek için sürekli olarak refactoring işlemini yapmak oldukça önemlidir.

Bu yazı dizisine ait tüm bölümlere aşağıdaki linklerden ulaşabilirsiniz:

• Scrum Farkındalığı ve Uyarlanması Part 1: Scrum Nedir?
• Scrum Farkındalığı ve Uyarlanması Part 2: Sprint ve Ögeleri
• Scrum Farkındalığı ve Uyarlanması Part 3: Scrum Rolleri
• Scrum Farkındalığı ve Uyarlanması Part 4: Scrum Development
• Scrum Farkındalığı ve Uyarlanması Part 5: Scrum Çıktıları (Outputs)

İlkim Dilara KADAKALOĞLU