Agile Pratikleri Üzerine
Selamlar,
Bugün çalıştığım takımda yapmış olduğumuz birkaç pratikten bahsedeceğim.
Yaklaşık 1 yıl kadar önce agile metodolijisi ile çalışan bir takımda backend developer olarak işe başladım. Daha sonrasından scrum master görevini de üstlendim. Bu bir yıllık süreçte işlerimizi kolaylaştıran güzel pratikler edindik takım olarak. Bu pratikleri başlıklar altında aktarmaya çalışacağım.
Story Point kavramımız nasıldı? Nasıl oldu?
Basitçe yazılımı eforlandırma olarak tanımlayabildiğimiz bu kavramı doğru uygulayabilmek takımların en zorlandığı konuların başında geliyordur desem abartmış olmam sanırım. Genel olarak adam/gün uzerinden yapılan story point değeri hesaplama şekline bizler de dahil olduk. Biraz daha detaylandırayım; Biz takım olarak 2 haftalık sprintler koşuyoruz. Ve her sprint sonunda yeni sprint için sevgili PO’muzun backlog’ta önceliklendirdiği iş listesinden yeni sprint icin işlerimizi seçiyoruz. ve bu aldığımız her işi ne kadar sürede bitirebileceğimiz konusunda bir efor veriyoruz.
Buraya kadar her şey güzel. Buradan sonrasında eskiden yaptığımız formülden bahsedeyim şimdide. Planlamada her işimiz icin belirlerdiğimiz SP değeri kişi bazlı ve gün bazlı oluyordu. Örnek vermek gerekirse; Backend tarafında bir servis açılması gerekiyor. Bu servisi açarken deneyimi olan ben 1 gün içerisinde açabilirim derken junior bir arkadaşımız ya da takıma yeni gelmiş bir arkadaş 2, 3 günde açabilirim diyordu. Böylece işin gerçek eforunu vermemiş oluyorduk, kişinin becerisine bağlı olarak işin eforu belirlenmiş gibi oluyordu. İkinci bir handikap ise 2 haftalık sprint koşuyoruz demiştim. Yani 10 iş günü çalışıyoruz. böyle olunca da herkes 10 gün içerisinde ne kadar iş alabileceğini hesaplıyordu. Planlama sonunda bir kişinin aldığı toplam SP değeri maximum 10 oluyordu. Sprint sonlarında velocity chartımızı incelemek istediğimizde hep aynı ortalamada commitment hep ayniı ortalamada tamamlanan iş degeri görmüş oluyorduk. Yani ekibin performansı doğru bir sekilde hesaplanamıyordu.
Bu kavramı şu şekilde evirdik; Planlamalarımızda işi ekipçe size’lıyoruz artık. Bu eforlandırmayı ise fibonacci sayılarını (1, 2, 3, 5, 8, 13, 21, 34, 55, 89) baz alarak yapıyoruz. Sizing yaparken belli başlı kritik soruları soruyoruz. Örnek vermek gerekirse; Yine backend tarafının client’a bir servis açması gerekiyor. Sorduğumuz sorular:Bu iş için backend tarafının başka bir servise entegre olup veri alması gerekir mi? Yoksa sadece kendi tuttuğu bir logic mi var? Başka bir ekip ile çalısması gerekecek bir konu var mi? projede bu servisi açabilecegimiz farklı altyapı gerektiren işlem yapılmalı mı? vs. gibi sorulara göre işi eforlandırabiliyoruz. Ya da en ufak bir text değişikliği bizim için artık 1SP. Peki performans nasıl etkileniyor bundan? Boylece ekip iş bitirebilme hızına göre bir sprintte daha fazla SP eritebilir. Ya da mevcut hızını koruyabilir. Ekibin performansı daha doğru ölçümlenebilir artık. Aramıza yeni katılan bir arkadaşımız için değişen tek şey bi sprint içerisinde ne kadar çok SP eritebildiği oluyor. Deneyimli kişi bir sprintte 150 SP eritebilirken ekibe yeni katılan bir arkadaşımız 50 SP eritebilecek sekilde işini alır. Ve zamanlar deneyim kazandıkça daha fazla SP eritebilecektir zaten.
Biz şimdi bu yeni kavramla ilerliyoruz. Sonuçları daha geniş zamanda göreceğiz. Şuan icin memnunuz :)
Test edilmeyen işimiz kalmaması için neler yapıyoruz?
Planlamalarımızı yaparken her development işi için bir jira açarken buna karşılık bir de test jirası açıyoruz. Bir işin teste gitmeden once developmentının tamamlanıp bildirilmesi gerekiyor. Bunu ikili ilişkilerimizle bu zamana kadar hallediyorduk zaten, testter arkadaşımız dailylerde ya da kendisi jiraları inceleyerek ya da development ekibinin bildirmesiyle işlerini listeye alıyordu. Ama kolaylaştırmak güzeldir :) Başka bir ekibin uyguladığı çok güzel bir pratiği onların destegi ile biz de kendimize uyarlamaya başladık. Planlamada her development işi için bir test jirasi açıyoruz demiştim. Bunun için jira üzerinden otomatik mail atma kurgusunu ayarladık. Şöyle ki: Biz developerlar olarak islerimizin geliştirmesini tamamladıktan sonra yani D.o.D’larımızı tamamladıktan sonra “Geliştirme Done” statusuna alıyoruz. Daha sonra “Geliştirme Done” olan maddelerimiz icin bir filtre oluşturuyoruz ve Testter arkadaşımıza her gün belli saatte(tamamen kendine bağlı, sadece haftada bir iki kere olacak sekilde de ayarlanabilir) “Geliştirme Done” olan maddeler mail olarak gidiyor. O da planlamasını istediği gibi yapabiliyor. Tabiki bunu kişisel iletişimimiz kesmek adına yapmadık :) İşimizi kolaylaştırmak için her şey:)
Daily’lerimizde olmazsa olmazlarımız
Uzaktan çalıştığımız icin web üzerinde toplaşıyoruz herkes gibi. Yöneticimizin güzel bir önerisi ile Scrum Master olarak her daily’de konuşan arkadaşın işlerinin olduğu jira boardını yansıtıyorum. Boylece aslında ilerletilmiş ama jira uzerindeki statusu sprintin son günü değişmiş işlerimizden dolayı tepetaklak olan burndown chartımız artık çok daha doğru ilerliyor :) Ve herkes kimin hangi işin detayıyla ilgilendiğine daha iyi hakim olmuş oluyor.
Grooming toplantılarının faydası
Normal şartlarda 1 aylık bir sprint için 8 saatlik planlama toplantısı yapılır. Biz iki haftalık sprint koştuğumuz için planlama toplantılarımız 4 saat oluyor. Ekip ilk kurulduğunda bu süreyi aşma sorunu yaşamıyorduk. Ancak ekip buyumeye başladıktan sonra planlama toplantımızın süresinin çok uzadığını fark ettik. Grooming yapma kararı aldık. PO’muzun product backlog’tan sprint backlog’una taşımak istediği maddelerin detaylarını dinlediğimiz, kabaca parçaladığımız ve ortama bir efor verdiğimiz grooming toplantılarımız sonrası sprint planlama toplantılarımızda time box’ı aşmadığımızı gözlemledik.
Nasıl eğleniyoruz?
İşe başladıktan bir ay kadar sonra yeni ekibimiz kuruldu ve hemen ardından uzaktan calışmaya geçtik. O zamandan bu zamana ekibimiz büyüdü, değişimler oldu. Ve birbirini tanımayan birçok insan beraber çalışır halde oldu. Ekip birbiri ile ne kadar samimi ise enerjinin o kadar yüksek olduğunu ve aynı oranda başarılı işler çıktığını hepimiz deneyimlemişizdir. Biz iki haftada bir belli bir günde “Kahve molası” yapıyoruz. İki şartımız var. Kameralar açık ve kahveler ellerimizde olsun :) Hiç iş konuşmuyoruz. İlk zamanlar birbirimizi çok tanımadığımız için ister istemez iş konuşuluyordu ama en sonki toplantımızda iki arkadaşım araba pazarlığı yapıyordu :) Bir de tavsiyem cuma günü mesai sonlarına doğru bu molanızı vermeniz. Gerçekten haftayı stressiz bitirmiş oluyorsunuz ve o sohbet bir iki hafta sonra çok tatlı uzuyor :)
Bu pratikler bizde çok işe yaradı belki size de fikir oluşturur diye paylaşmak istedim. Scrum 2020'de de deneyselliğin daha fazla vurguladığını göz önünde bulundurursak deneyelim, basitleştirelim:)
Ha bir de işimizi yaparken eğlenelim :)
