Önceki yazılarımızda Agile Proje Yönetiminin ne olduğundan ve Agile Manifesto’nun temel ilkelerinden bahsetmiştik.
Agile yazılım yöntemleri temelinde benzer fakat süreçlerinde farklılaşan çeşitli alt kollara ayrılmaktadır. Bu kollardan popüler bir tanesi de Scrum yöntemidir. Scrum, kelime olarak rugby oyununda oluşturulan küçük ekiplere verilen isimdir. Bu yöntem 90’lı yıllarda oluşturulmuş, günümüze sürekli bir gelişme halinde gelmiştir.
Scrum, ilk bakışta çok basit kuralları olan bir yönetimsel modeldir. Gereksinimleri açıkça belirli olmayan, değişime açık, karmaşık yazılım projelerinin yönetimi için uygulanması en idealidir. Fakat bu demek değildir ki, gereksinimleri değişime açık olmayan projelerde Scrum kullanılmamalıdır. Scrum’da klasik proje geliştirme yöntemlerinden farklı olarak küçük küçük tüme varım yöntemi en iyi şekilde kullanılmaya çalışır.
Scrum’ın sunmakta olduğu en önemli çıktı sürecin şeffaf bir şekle getirilerek süreç içerisinde aksayan noktaların açığa vurulmasıdır. Scrum böylelikle proje ekibini ortaya çıkan aksaklıkları çözümleyerek sürekli iyileştirme yapması yönünde motive eder.
Günlük toplantılar ile ekip birbirinden sürekli olarak haberdar olur. Böylelikle iletişim artar, proje içerisinde kopukluklar azalır. Günlük Scrum toplantılarının Timebox’ını 10-15 dakika arası tutmak tavsiye edilir.
Burada ekip 3 soruya primer olarak cevap verir;
- Dün ne yaptım?,
- Bugün ne yapacağım?,
- Beni engelleyen sorunlar var mı?
Sprint planning toplantıları ile ekibin bir sonraki adımda hangi isterleri yerine getireceği belirlenir. Bu şekilde küçük iş parçacıkları ile mini-ürünler tasarlamak daha imkanlı hale gelir. Maksimum süre olarak 1 ay belirlenmelidir. Burada belirlenen maddeler, sprint backlog’ta liste olarak tutulur. SPRINT’te ne kadar işin yapılabileceğine geliştirme takımı karar verir.
Sprint Review Toplantısında ise SPRINT süresince neler yapıldığı konuşulur. 1 aylık SPRINT süresinde maksimum 4 saat zaman ayrılır. Amaç bir önceki SPRINT için geri bildirim almak ve iş birliğini arttırmaktır. Bu toplantının sonunda revize edilmiş ürün kapsamı çıkar.
Sprint Retrospective Toplantısı: SPRINT gözden geçirme toplantısı ile SPRINT planlama toplantısı arasında yapılır. 1 aylık SPRINT’te max. 3 saat olarak gerçekleştirilir. Başarılı olunan noktalar da, geliştirilmesi gereken noktalarda görüşülür. Eksik yönlerin düzeltilmesi için iyileştirme planları hazırlanır. Scrum takımı bir sonraki SPRINT’te iyileştirmeleri tamamlamadır ki, KAIZEN kuralını işleyebilmiş olsun. (KAIZEN Kuralı; sürekli gelişme, her zaman daha iyiye gitme)
KAIZEN kültürünün oluşması için Retrospective toplantılarının önemi çok yüksektir. İşler iyi giderken takımın rahatlaması muhtemeldir ve bu toplantılardan yeterli üretkenliği almak zorlaşabilir. Bu tarz bir durumda takımın geliştirilecek bir nokta araması biraz zor bir hal alabilir. Fakat bir iyileştirme yapmak için, illaki işlerin kötü gitmesi gerekmez. Her zaman bir iyileştirme yapılabilecek alan bulmak mümkündür. Agile’ın temelinde sürekli değişim olduğuna göre, sürekli iyileştirme çalışmaları yapmak gereklidir. Sürekli iyileştirme bakış açısının takım içindeki her bir birey için gündelik bir alışkanlık haline gelmesi gerekir. Bu şekilde kendi kendine organize olan, performansı yüksek bir takım oluşabilir
Scrum takımı 5+ kişiden oluşmakta ve çoğu startupta bu kadar çalışan olmayabilir.. Scrumdaki rolleri startup kendi içerisinde dağıtmalı ve scrum’ın kalbinde yatan felsefeyi yakalamaya çalışılmalıdır. Buradan çıkarılması gereken sonuç; yılların deneyimli yazılımcılarının, girişimcilerinin ürettikleri ve kullandıkları metodolojiler bunlardır. Bunları mümkün olduğunca uygulayarak daha sağlam bir proje yönetim süreci geçirilebilir.
