5 Ocak 2014 Pazar

Agile Buluşmanın Ardından: Scrum with Distributed Teams

Agile Turkey'in düzenlediği Agile Buluşmaların 9'uncusu 31 Ekim 2013 günü Astoria AVM'de bulunan Caffe Nero'da gerçekleşti. VNGRS'de Scrum Master olan Birge Elif Basık ile çok keyifli bir sohbet gerçekleştirdik. Birge Hanım bizlere, farklı ülkelerde elemanları olan yazılım takımarında Scrum'ı nasıl uyguladıkların, Scrum uygulamasında yaşadıkları sorunları ve nasıl çözdüklerinden bahsetti. 2 saatlik buluşma sırasında konu sadece "dağıtık takımlarda Scrum" başlığına saplanmadı. Scrum deneyimlerinden bizlere onlarca ipucu da aktardı. Özellikle oluşturdukları kurum kültürü beni çok etkiledi. Elimden geldiği kadar aktarmaya çalışacağım.

Dağıtık takımlar derken aslında elemanlarının bir bölümünün farklı coğrafyalarda çalıştığı takımlardan bahsediyoruz. Özellikle günümüzde maddi getirileri sebebiyle çokça tercih edilen "outsourcing" nedeniyle karşımıza sıkça çıkmakta. Ben de yaklaşık bir sene 2 üyesi Amerika'da olan bir takımda çalışmıştım. Normalde Scrum uygulaması sırasında yaşanan problemlerin üstüne, beraber omuz omuza çalışmamanın getirdiği yeni sorunlar eklenmesi nedeniyle dağıtık Scrum bir hayli mücadele gerektiriyor. Oluşan yeni dinamikleri iyi algılamak, oluşan yeni düzene ayak uydurmak gerekiyor.

Dağıtık Scrum ile alakalı internette ciddi kaynaklara ulaşabilirsiniz. Detaylara girmeden önce birkaçını listeyelim.
Dağıtık Scrum için 3 türden bahsediliyor. 
  • İzole Scrum (Isolated Scrum): Bu türde takımın tümü diğer ekiplerden başka bir coğrafyada bulunuyor. Çoğunlukla kendi içlerinde ekstradan bir ürün sahibi (Product Owner) oluyor. Scrum yerine iteratif waterfall'lar uygulayabiliyorlar. Tabi bu nedenle kodu sahiplenme ve entegrasyonda problemlerle karşılaşıyorlar. "Onlar-bizler" ayrımı ciddi bir engel olarak karşılarına çıkıyor.
  • Dağıtık Scrum'ların Scrum'ı (Distributed Scrum of Scrums): Farklı coğrafyalardaki üyelerin kendi içerinde Scrum uygulamasına, sonrasında Scrum-of-Scrum toplantıları ile alt-takımların birbirleri ile koordine olmasına dayalı bir sistem. İletişim problemleri halen burada da ciddi bir sorun.
  • Tam Dağıtık Scrum (Fully Distributed Scrum): Yazılım takımı üyelerinden bir kısmının diğerlerinden farklı mekanda bulunmaları ve takımca tek Scrum uygulanması durumu. 
Birge Hanımın Scrum Master'lığı yaptığı takımlar Amerika ve Türkiye'de üyeleri bulunan takımlar ve tek bir Scrum uygulaması var. Yani karşımızda tam dağıtık Scrum uygulaması var.

Kişiler, Ritüeller ve Scrum

3 ayrı takım, 3 ayrı ürün sahibi (PO) ve 3 iş listesi (backlog) var. PO'lar backlog'lardan sorumlular. Baş Ürün Sahibi (Chief Product Owner) dedikleri bir kişi de var. CPO'nun ana görevi ROI (Return on Investment)'yi maksimumda tutmak.

Takımlar arada "Grooming Meeting" ya da "Backlog Refinement Meeting" denilen buluşmalar ile gelecekte karşılarına çıkacak hikayeleri değerlendiriyorlar. Amaç şu: Takım planlama toplantısında bir hikayeyi ilk kez görmemeli. Bu toplantılar ile alakalı detaylı bilgi için yazdığım yazıyı okuyabilirsiniz.

"Pre-Grooming" adı verdikleri bir toplantıları daha var. PO ve takım liderleri gelecekte üzerinde çalışabilme ihtimalleri olan konuları takımla konuşmadan önce değerlendiriyorlar. Burada kabul kriterleri (acceptance criteria) dahi konuşuluyor. Buna ön eleme diyebiliriz sanırım.

İlk hafta pazartesi retrospective yapılıyor. İlk haftada Grooming ve Pre-Grooming toplantıları da yapılıyor. 2 hafta olan Sprint'lerde 2 gün 2'şer saatten 4 saatlik bir planlama toplantısı oluyor. Bunun nedeni Amerika ve Türkiye'deki tüm Scrum takımının hazır bulunmasını sağlamak.

Efor tahminleri (estimations) hikayelerin zorluk derecelerine göre hesaplanıyor. Takımın baz aldığı hikayeler belirlenmiş. Takım zorluk derecesini baz hikayelere bakarak veriyor.

Retrospective toplantıları Amerikadaki üyeler ile beraber yapılıyor. Her defasında farklı bir yöntem deneniyor, zira bu toplantının verimliliği için çok önemli bir yöntem. Bazen sadece güzel olaylardan bahsediliyor, bazen de ciddi eleştiriler belirtiliyor. Toplantı sonunda -iyi ya da kötü- mutlaka aksiyon alınacak noktalar belirleniyor.

QA takımı test senaryolarını yazıyorlar, ama takımdaki herkes test yapabiliyor. Bu da esneklik ve "multi-functionality" sağlıyor. QA takımı Scrum Master'a düzenli olarak geribildirimlerini iletiyorlar.

Her sprint'in mutlaka bir amacı (goal) oluyor. Bu planlama toplantısı ile belirleniyor. Demo ya da Review toplantıları QA ve POlara yapılıyor. Sprint sonunda "başardın/başaramadın (success/fail)" belirlenmiyor.

Otomatikleştirilmiş testler (automated tests) sayıca çok fazla. Bu da yapılan işi kaliyesinin yüksek tutulması için elzem.

Hata temizlemek için Sprint içerisinde %20'lik bir tampon zaman mutlaka ekleniyor. Bunu boş bir PBI (Product Backlog Item) gibi düşünebiriliz.

Bütün takımların sprint'leri senkronize. Yani aynı anda başlıyor ve aynı anda bitiyor.

Evrensel bir "Bittinin Tanımı (Definition of Done)"na sahipler. Bir işin "done" olması o işi PO'nun kabul etmesi, "done-done-done" olması da o işin canlı ortama çıkmış olması demek. Bittinin tanımı ve tüm bu süreçler Amerika ve Türkiye'deki üyeler tarafından ortak olarak belirlenmiş.

GitHub üzerinden yönettikleri kodun yazarı dışında biri tarafından "review" edilmesi mecburi. Bunu "pull-request"ler üzerinden gerçekleştiriyorlar.

Operasyon yani devops'lar güvenlik testlerini gerçekleştiriyor.

Daily Scrum Toplantıları

Amerika ve Türkiye'de bulunan gruplar arası 7 saat zaman farkı olması ciddi bir problem. Tüm takım üyeleri, günün yalnızca 2 saati beraber çalışabiliyorlar. Bu, ortak saatler dışında oluşan her ihtiyaç için bir gün beklemek demek. Bu önemli sorunu çözebilmek için günde 2 kez "Daily Scrum" toplantısı yapıyorlar. Sabahki 15 dakikalık toplantı Türkiye'de çalışan takım üyeleri arasında oluyor. Öğleden sonraki kameraların açık olduğu 15 dakikalık toplantıda ise Amerika'daki takım üyeleri ile Türkiye'deki takım üyelerinden bir ya da birkaçı bulunuyor. "Daily Scrum" toplantılarına çok önem veriyorlar, zira bu toplantılar takımı sürdürülebilir işbirliği içerisinde tutması açısından çok önemli bir yere sahip.

İletişim 

Dağıtık gruplar arası iletişimin verimli olması ve herkesin tek bir takım gibi hissetmesi çok önemli. Bu nedenle zaman zaman "coffee time" adını verdikleri, kameraların açık bulunduğu bir ortamda sadece paylaşımda buluyorlar. Yani Amerika-Türkiye arası sadece muhabbet etmek için kendilerine zaman ayarlıyorlar. Belli ki tüm takım üyeleri arası verimli bir iletişim onlar için çok önemli.

Mutlulukların da tüm bireyler arası paylaşılması gerektiğine inanıyorlar. Amerika ya da Türkiye farketmez, insan ilişkilerini yakinen gözlemliyorlar. Takım içi "güven kurmak" herşeyden önemli. "Takım üyeleri kendilerini her yönüyle bir takım olarak hissetmeliler" diyor Birge Hanım.

Birge hanımın "takım içerisinde iş arkaşından öte arkadaşız" demesinden çok etkilendiğimi belirtmeliyim. Eğlenmeye vakit ayırıyorlar. Hatta okyanuslar ötesine zaman zaman çiçek gönderdikleri dahi oluyor.

Takım üyeleri iletişim için işe yarayan her teknolojiyi kullanıyor. Google Hangout ve HipChat bunlara dahil. Atlassian Jira etkin biçimde kullanılıyor. GitHub ise kaynak kodun yönetildiği yer. QA safhasına gelindiğinde dallar (branch) birleştiriliyor (merge).

Yolculuklar

Amerika Türkiye arası seyahatlere önem veriyorlar. Yüzyüze iletişimden daha verimli hiçbir yöntem olamaz. O nedenle sık sık takım üyeleri ziyaretlerde bulunuyor. Bu konu hakkında okudum farklı deneyimlerin hemen hemen hepsi düzenli yolculukların faydalarından bahsediyor. Düzenli olarak yolculuk etmenin ve zaman zaman bile olsa omuz omuza çalışmanın getirisinin yolculuk için ödenen masraftan çok daha fazla olduğu belirtiliyor.

Motivasyon ve Kurum Kültürü

Takım için motivasyon daima yüksek tutulmalı. Şirketin CIO ve CTO'su üzerinde çalıştıkları ürünün ve şirketin vizyonunu paylaşıyorlar. Bu da çalışanların enerjisini belli bir vizyon üzerine odaklamalarını sağlıyor.

Kurumda oluşturmaya çalıştıkları kültürün ana değerleri olarak "Achieve, Improve, Speak Up"ı belirlemişler. Yani "Başar, İyileştir, Çekinmeden Konuş". Bu değerler, motivasyonun ve toplam enerjinin odaklanması, şeffaflığın sağlanması ve sürekli iyileştirme ve daha iyiye gitmek için kilit noktalar. İtahat etmek yerine karşısındakini düzeltmek ve ürünü sahiplenmek böylece özendirilmiş oluyor.

Takım üyelerinin teknik bilgi ve becerilerinin gelişmesi çok önemli. Bu nedenle kitap ve eğitim ihtiyaçları değerlendirilip karşılanmaya çalışıyor.

Takıma uyabilecek, zeki ve uyumlu insanları bulmak konusunda hassaslar. Ekip arkadaşlarından tutkulu ve kendini geliştirecek özelliğe sahip olması bekleniyor. Bu da kurum ve takım kültürüne ne kadar değer verdiklerinin bir kanıtı bence.

Verimlilik

Dağıtık takımların -ve dağıtık olmayan takımların- ana sorunlarından biri de verimliliği yüksek tutmadaki zorluktur. Takım üyeleri ciddi bir biçimde Pomodoro tekniğini uyguluyor. Çalışanlar 25 dakika bölünmeden çalışıyor, sonra da ara veriyorlar. Pomodoroyu daha etkin uygulayabilmek için bir uygulama da geliştirmişler. 25 dakikalık pomodorosuna başlayanların uygulamadaki ikonu kırmızıya dönüyor. Siz birine birşey soracaksanız eğer, önce bu uygulamaya bakıyorsunuz. İşaret kırmızı ise pomodoronun bitmesini bekliyorsunuz. Sıkça bölünen yazılımcılar için şiir gibi bir çözüm doğrusu:)

Her takım üyesi, sabah o gün içerisinde yapmayı düşündüğü pomodoroları planlıyor. Mesai sonunda ise kendi kendinin retrospective'ini yapıyor. Bu en beğendiğim yöntemlerden biri açıkcası.

Her iki grubun verimli çalışması sonucu ortaya 15 saat sürekli geliştirme yapılan bir ortam çıkmış. Bunu bir avantaj olarak görüyorlar. Tabi şunu da belirtiyorlar: mesai saatlerine sağdığız.

Geçmiş Hatalardan Alınan Dersler

Geçmişte deneyip olmadığını gördükleri noktaları da bizimle paylaştı Birge Hanım. Eskiden Amerika ve Türkiye gruplarının retrospective toplantıları ayrı oluyormuş. Hikayeler Amerika ve Türkiye ekipleri arasında bölünüyormuş. Hatta planlama toplantılarının 2. bölümüne Amerika ekibi girmiyormuş. Tüm bunlara son vermişler. Artık tek bir takım gibi tüm bireyleri dahil ediyorlar.

İtiraf etmeliyim ki, dağıtık Scrum uygulaması yanında oluşturdukları kurum kültürüne de hayran oldum. Birge hanımı ve tüm VNGRS çalışanlarını canı gönülden tebrik ederim. Umarım onların başardığı bu sinerji ve kültür, çalıştığımız şirket ve takımlar için de örnek olur, bizleri bir üst basamağa taşır.

0 yorum:

Yorum Gönder

Template developed by Confluent Forms LLC; more resources at BlogXpertise