Yazılımda Fast Food Scrum

Konuk yazarımız Osman Sönmez'in kendi kişisel tecrübelerini aktardığı blog yazısını sizlerle paylaşıyoruz. Keyifli okumalar.
 
Baştan söyleyeyim yanlışım varsa düzeltin lütfen. 1.5 seneden fazladır projelerimizi Scrum metedolojisi kullanarak yapıyoruz ama ben hala Scrum'ın faydasını anlamış değilim. Scrum ile ilgili ilk bilgileri edindiğimde faydalı bir şey olduğunu düşünmüştüm. Japonlar kullanmışsa iyidir demiştim. Her ithal ettiğimiz şeyi amacına uygun kullanmadığımız gibi galiba bunu da amacına uygun kullanmıyoruz.
 
Scrum'ın ülkemizde veya kendi kullandığımız projelerde uygulanış biçimini Fast Food satan yerlere benzetiyorum. Kısa zamanda çok iş :). Biri yağı döksün, aynı anda biri ocağın altını yaksın, aynı anda biri köfteleri hazırlasın, aynı anda biri siparişleri alsın, aynı anda  biri patatesleri kızartsın, biri ekmekleri hazırlasın, biri patatesleri paketlesin, biri köfteleri paketlesin vs... Herkes koşturuyor, çünkü müşteri buraya geldiğinde 5 dakika içerisinde yemeğini almak istiyor. 5 dakikada bütün bunların hazır olması gerekiyor. 6 dakika  olmaz deniyor, mutlaka 5. dakikada bu müşteriye verilecek. Müşteri memnun mu? Eh... Evet, yemeğini almış mutlu :). Kalite mi? Çok da önemli değil biz müşteriye hızlı bir şekilde yemek vereceğiz demişiz. Mutfaktakiler mi? Çok yorulmuşlar ve şunu anlamışlar ve öğrenmişler: Biz bu şekilde hizmet vereceksek malzemenin önceden  hazır olması gerekiyor, ne yapalım biz geceden malzemeleri hazırlayalım veya bir yere hazırlatalım. Hızlı pişmesi için de yarı pişmiş olsun. Müşteri farklı birşey talep ederse ne yapacağız?
 
 
5 dakikada Hünkar Beğendi yapacak halimiz yok. Elimizdeki malzeme bu. Yeni birşey yapmak için zaman olması gerekiyor. Mutfaktakiler çok yoruluyor, bir ürün çıkıyor ama kalitesi ve geliştirilebilirliği tartışılır, müşteri memnun gibi ama yeni bir şey isterse tecrübeli adam yok, çünkü herkes hızlı köfte üzerine uzmanlaşmış, başka bir şeye vakit verilmemiş.
 
Evet biz Scrum yapmaya başlarken, geleneksel yemekleri bırakmış Fast Food yapmaya başlamışız. Çünkü bize sunulan ve istenen şey tam olarak bu.  Niye Scrum yapıyoruz? Şelale yönteminde işler çok yavaş, bitmiyor, isterleri toplamak çok uzun vs. kaygılarla Scrum yapıyoruz. Aynı iş Scrumda daha çabuk oluyor diyorlar. Hem de mesai yapmadan oluyor diyorlar. Mesai yapmama olayına inanmıyorum çünkü fazla fazla yapıyoruz. Aynı iş oluyor mu? Oluyor gibi ama aslında Akçaabat  Köfte yapmamız beklenirken, biz daha hızlı pişmesi için aynı görünümde başka bir köfte yaptık, daha az lezzetli ama görünümü aynı Akçaabat.
 
 
Evet şimdiye kadar gördüğüm bu. Aslında bize anlatılan Scrum, Akçaabat köfte yap ama kaliteden ödün verme, organizasyona değer ver ve devamlı geliştir değil miydi? Problemlere hemen müdahele et ve süreçleri geliştir değil miydi? Development açısından baktığımda daha içler acısı bir durum görüyorum. Development takımlarına daha çok iş düştüğünü görüyorum. Scrum'da analiz var ama dökümantasyon pek yok diyorlar. Dökümante etmek zaman alırmış :). Developer soru sorar: Bu konuda analiz dökümanı var mı? Şunu ne yapacaktık acaba? Cevap: Ara sor veya yüz yüze sor, tam olarak ne istiyorsunuz? Ara sor veya yüz yüze konuş, mailleş ve bir sürü  mailden ne yapılacağını çıkar, bol bol "Ben sana söylemiştim hatırlamıyor musun?" diyalogları. Scrum yapmak için biyonik developer olmak gerekiyor. Hafızaya al ve bir daha unutmamak üzere kaydet. Çünkü Scrum'da, Şelale yöntemindeki gibi döküman yazılmaz, öyle öğrendik biz. İşimize de geliyor aslında :). Biz  söyledik developer yapsın işte.
 
İsterler pat diye geliyor ya 7.sprint geliyor biz şöyle bir ekran istiyoruz deniyor. Uçsun kaçsın. Biz bunu yaparız ama biraz araştıralım. 2 haftada bitmesi lazım :). Jquery.UI diye bir şey varmış onunla yaparız herhalde. Başlıyoruz yapmaya, yaptık yaptık iyi birşeylerde çıktı. Allah Allah IE8 de çalışmıyormuş bu. Tüh yaparız da dedik. Nerden bileceksin IE8'de çalışmadığını. IE8 müşteri için olmazsa olmaz deniyor. Bir o kadar da IE8 için uğraş. Gece gündüz yetiştirmeye çalış. Keşke buna benzer bir şey isteyeceklerini çok daha önce söyleselerdi, ya da bir analist bunu çok önceden sorgulasa mıydı? Bütün Scrum böyle geçiyor, bitiyor.
 
Sonunda şunu söylüyoruz: Biz ya Scrum'da birşeyleri yanlış yapıyoruz, ya Scrum yanlış ya da bizde bir sorun var. Scrum bizi çok yoran, çok daha kısa sürede aynı işi yapmaya çalıştığımız, düzensiz ve dökümansız çalıştığımız ve en önemlisi çok dağınık bir kodlama yapılan bir ortama doğru götürüyor gibi. Bu şekilde yapılan çalışmaların uzun vadede özellikle development takımlarının gelişimine ciddi negatif etkisi olacağını düşünüyorum. Birilerinin Scrum yapılırken  gerekli Ar-Ge faaliyetleri ve development gelişimi için nelerin yapılması gerektiğini, Scrum içerisinde bir yere koyması gerekir diye düşünüyorum.
*Bu yazı Osman Sönmez'in kendi blogundan alıntıdır.

Thoughtworks Turkey Summit Gerçekleştirildi

Scrum Turkey, Thoughtworks ve Hepsiburada'nın ortak olarak düzenlediği Thoughtworks Turkey Summit, 11 Eylül 2014 Perşembe günü İstanbul Hilton Otel'inde gerçekleştirildi. Yazılım sektöründen 400'den fazla kişiyi bir araya getiren etkinliğin onur konuğu Türkiye'ye ilk ziyaretini gerçekleştiren dünyaca ünlü yazılım üstadı Martin Fowler'dı.
 
 
Keynote konuşması sırasında Continuous Delivery, NoSQL ve Microservices gibi güncel konulara değinen Martin Fowler, katılımcılar tarafından büyük beğeni topladı. Etkinliğin devamında Thoughtworks Türkiye ve Hepsiburada ekibinden konuşmacılar sunumlarını gerçekleştirdiler.
 
 
Türkiye IT sektörünün gelişimine katkıda bulunmayı amaçlayan Scrum Turkey olarak, bir ilki daha başarmaktan büyük mutluluk ve gurur duyuyoruz. Yine ilkleri gerçekleştirmek için çalışmalarımıza devam edeceğiz. Bizi takip etmeye devam edin.
 
Etkinlik fotoğraflarına Facebook sayfamızdan ulaşabilirsiniz.

Agile Pratikler - Ne Var Ne Yok Toplantısı (Daily Scrum)

Agile Pratikler serisinin bir önceki yazısında bir Information Radiators çeşidi olan Niko Niko Takvimi pratiğine değinmiştik. Bu yazımızda hemen hemen her Agile takımın kullandığı Ne Var Ne Yok Toplantısı (Daily Scrum) pratiği ile ilgili bilgiler paylaşacağız.
 
 
Türkçe olarak, Ne Var Ne Yok Toplantısı olarak adlandırılan bu pratik, literatürde Daily Scrum (Scrum terimi) veya Daily Standup Meeting olarak bilinir. Her gün, aynı saatte, aynı yerde ve ayakta yapılan kısa bir toplantıdır. Maksimum 15 dk. olarak gerçekleştirilmelidir. Scrum Master ve diğer paydaşlara rapor verme ve problem çözme toplantısı değildir. Takım, günlük planındaki senkronizasyonu sağlamak amacıyla bu toplantıyı düzenler. Aşağıdaki üç soruya takım üyeleri sırayla cevap verir:
  • Dün ne yaptım?
  • Bugün ne yapacağım?
  • Önümde herhangi bir engel var mı?
Scrum Kılavuzu'nun 2013 ylında yayınlanan yeni versiyonunda bu üç soruda güncelleme yapıldı ve aşağıdaki şekilde güncellendi:
  • Dün takımın Sprint hedefine ulaşması için ne yaptım?
  • Bugün takımın Sprint hedefine ulaşması için ne yapacağım?
  • Önümde takımın Sprint hedefine ulaşmasını etkileyecek bir engel var mı?
Gördüğünüz gibi, yapılan bu güncelleme ile, sorular kişisel bakış açısından çıkarılarak, takım bakış açısı kazandırıldı. Bu güncellemenin etkilerini önümüzdeki günlerde daha net görebileceğimizi umuyorum.
 
 
Ne Var Ne Yok Toplantıları, sadece ayakta durup, takım içerisinde bilgi paylaşımının sağlanması için yapılmaz. Bununla birlikte Sprint içerisinde küçük yön değişimlerinin yapılmasına olanak sağlar. Çok görünür olmasa da, takım üyeleri arasında güven duygusunun oluşması ve kişisel planlamayı cesaretlendirmesi açısından da fayda sağlamaktadır.
 
Ne Var Ne Yok Toplantısı sırasında iki temel problemle karşılaşılır. Bunlardan birincisi, bu toplantının durum raporu verme şeklinde gerçekleştirilmesidir. İkinci problem ise, bu toplantıda bahsedilen problemlerin, bu toplantı süresince çözülmeye çalışılmasıdır. Bu iki temel problemin aşılması için, Scrum Master sorumluluğu üstlenmeli ve toplantının doğru şekilde gerçekleştirilmesini sağlamalıdır.

 
Bu toplantıyı daha etkin yapabilmenizi sağlayacak bazı yöntemler bulunmaktadır. Bunların bazılarını kendi Agile yolculuğum sırasında deneme yanılma yöntemi ile bulduğumu belirtmeliyim:
  • Toplantıda ilk kimin konuşacağını veya hangi sırayla konuşulacağını belirlemek bazen problem olmaktadır. Bu problemin aşılması için, konuşma sırasını belirleme görevini toplantının düzenleyicisi üstlenmelidir. Toplantı düzenleyicisi, "Son Gelen İlk Konuşur" veya "Takım Maskotu Kimde ise O Konuşur" kuralları ile toplantının etkin işletilmesini sağlayabilir.
  • Toplantının, takımın çalıştığı yerde yapılmasının enerji seviyesini yükselttiği söylenir. Ancak kendi denediğim, toplantının rahatsız ortamlarda (Yangın merdiveni, asansör boşluğu vb.) yapılması da, ekip içerisinde bir aciliyet duygusu oluşturmakta ve toplantının etkin yapılmasını sağlamaktadır.
  • Toplantının belirtilen zaman sınırı içerisinde tamamlanması da zaman zaman problem olmaktadır. Bu problemi aşmanız için, toplantının yapıldığı yerde eğer projeksiyon cihazı var ise, online bir zamanlayıcı kullanarak, toplantıyı tamamlamak için ne kadar süreniz kaldığını takım üyelerinin görmesini sağlayabilirsiniz. Böylece takım, zamanla bu süreye uymayı alışkanlık haline getirecektir.
  • Yukarıda belirttiğim gibi bu toplantının en temel problemi durum raporu verilmesi şeklinde yapılmasıdır. Burada Scrum Master olarak, konuşan kişi ile göz kontağını kesmenizi öneriyorum. Ben genellikle, o an konuşan kişiye odaklanmak yerine; çevreye, duvarlara veya tavana bakmayı tercih ediyorum. Bu sayede takımın birbiri arasında konuşmasını sağlayabilirsiniz.
Bu pratikleri siz de uygulayıp, sonuçlarını burada paylaşabilirsiniz.