Murat Uysal

bir matematik mühendisi olarak hislerim ve deneyimlerimden süzülen yazılar dizisi

Scrum Notlarım


Scrum yapısını bireysel anlamda araştırıp öğrenmiş olsam da çok ayrıntılı şekilde uygulayacağım bir kurum fırsatım olmadı. 

Daha ayrıntlılı öğrenmek adına notlar almak için burayı seçtim. Hızlıca doğrudan paylaştım, düzenlediğimde daha iyi bir içerik olacak.

En kısa özeti ile yapıyı özetlemeye çalışacağım.

Product Owner:

Bir yazılımın ihtiyaçlarını belirler ve bu noktada işleri listeler. Bu listeler bu teknik içerisinde "Product Baclog" olarak geçmektedir. Bu backlog bilgileri ürünün ihtiyaçlarını belirler ve dinamik bir listedir. Bu listede silme ve ihtiyaca göre yeni eklemeler yapılabilmektedir. Product Owner en etkili roldür, çünkü ekibin tüm çalışması bu kişinin ürün analizlerine göre şekillenir.

En önemli 2 işi var diye düşünüyorum.

- Ürünün ihtiyaçlarına göre işleri listeler.
- Takımın en etkili çalışabileceği şekilde işleri sıralar.


Scrum Master:

En üst yönetici gibi bir görünümü olsa da, aslında hizmetkar yöneticidir. Bu yönetici emir ve direktif vermek yerine sistemin scrum kuralları doğrultusunda çalışmasını sürmesini sağlar sadece. Ekibin ihtiyaçlarına yanıt verir. Ekibin daha verimli çalışması için aralarında koordinasyon sağlayan kişidir.


Product owner için teknikleri geliştirir, daha doğru bir liste oluşması noktasında metotlar geliştirir. Benim yorumum bu kişi innovatif yönetim teknikeri denebilir gibi geldi. Yani herkesin üstü gibi ama aslında herkesin daha iyi çalışmasını temin ediyor. 

Ekip için ise, sprintlerin yönetimini izler ve daha iyi bir sonuç için ekibe bilgi ve ortam sağlar. Koçluk eder ve scrum sisteminin tam olarak uyulduğu bir yöntem sağlar.

Yazılım Takımı

Ekip self-managed bir ekiptir. Belirli bir kişi veya üst kurul yönetmez. Ekip kendisi içerisinde herkesin en faydalı olduğu noktada çalışmasını sağlayan bir yapıda gelişir. Herkes en faydalı olduğun noktada yer alır ve sprint içerisinde en iyi işi çıkarmaya çalışır.


Sprint

Sprint bir hedef iş listesidir. Bu işlerin sırası ve önemi product owner tarafından scrum master gözetiminde gerçekleşir ve splint hedefleri belirlenir. Ekip bu splint doğrultusunda çalışarak bazı enstrümanlara sahiptir. 

Bunlardan bazıları, planlama, günlük scrum, geliştirme ve değerlendirme şeklindedir.

Splint sanki bir proje gibi belirli hedefleri olan iş listeleridir. Bu hedefler doğrultusunda splint işleme alınır.

Einstein'ın "bir problemi çözebilmek için yeterince küçük parçalara böl ama fazla değil şeklinde" bir sözü vardır. Tam böyle değilse de buna benzer bir manası var. Burada o amaçlanıyor bence. Yani bir projeyi küçük daha alt projelere bölüyoruz ve alt projeler tamamlandığında üst büyük proje de tamamlanmış oluyor.


Splint iptal edilebilir bir olgudur ve bu yetki sadece ve sadece product owner a aittir. Ancak takım ve scrum master splint iptali gerektiğini düşündüğünde bu konuda product owner a bilgi verebilir ve product owner bu bilgi doğrultusunda iptal kararı alma veya almama hakkına sahip olur.

Daily Scrum

Bu işlem ekibin bir sonraki 24 saatini netleştirmeyi hedefleyen bir görüşmedir. 15 dk süren bir toplantıdır. 

Sprint Review

Bir sprint sonunda herkesin katıldığı ve product owner tarafından biten işlerin belirlendiği bir listedir. Biten işlerin durumu herşeyin nasıl gittiği bu toplantıda belirlenir. Splint içindeki her detay netleştirilir ve herkes kendi tespitlerini paylaşır.


Sprint Retrospektifi
 
Sprint review sonrası, bir sonraki sprinte geçiş öncesinde sprint için bir önceki notlar ve öğretiler uygulamaya alınmaya çalışılır. Yani neyi doğru neyi yanlış yaptık notları değerlendirilerek bir sonraki sprint için düzenlemelere karar verilir. Sprint planı öncesi tüm sonraki süreç değerlendirilir. Scrum master bu noktada ekibi cesaretlendirir ve koordinasyon sağlar. 

Ayrıca bu adımın bence en önemli gördüğüm bir adımı da şudur, her ekip üyesi her işin bitti noktasındaki "BİTTİ" tanımını net olarak anlamaktadır. Yani kendi alanı dışında bile olsa tüm işlerin bitti denildiğinde nasıl bir kapsamdan söz edildiği söylenmektedir. Yani benim de şahsen yaşadığım en büyük sorun genelde bu idi. Yani ekipte diğer kişiler kendi alanı dışındaki konuları bilmemesi bir nebze faydlaı gibi görünür. Ancak bunun sonucu kişinin diğer modülleri ve alanları düşünmeden kendi verilen işini yapıp kenara çekillmesi ile sonuçlanır. Bu noktada da tabi birbiri ile uyumsuz çalışan modüller olur.


Events

Scrum da en sevdiğim şey diyebilirim. Normalde toplantı kavramı vardır ve bu kavram herkesin uzun uzun herşeyi konuştuğu ama aslında birşey konuşmadığı noktaya kadar uzayan şeyler haline gelebilir. Bu noktada da en önemli kelimeyi unutmamışlar. "Time Boxed" yani zaman sınırlı bir görüşme öğesidir. Bu zaman sınırını aşmadan süreç izlenir, işler ile ilgili özet ve sonuç odaklı görüşmeler sağlanmaktadır.


Aşağıdaki linkten en ayrıntılı halini görebilirsiniz.



Comments are closed