Sprint Sonunda Retrospective Nasıl Yapılabilir?

Agile yazılım geliştirme yaklaşımının öne çıkan özelliklerinden ikisi, değişime cevap verebilme ve değişen şartlara adaptasyondur. Bunu sağlayabilmek için yapılması gerekenlerden birisi de sürekli olarak nerede olunduğunun, nereye gidilmeye çalışıldığının değerlendirilmesi ve alınması gereken aksiyonların alınmasıdır.

Agile manifesto'da bununla ilgili olan prensip; "Takım, düzenli aralıklarla nasıl daha etkili ve verimli olabileceğinin üzerinde düşünür ve davranışlarını buna göre ayarlar ve düzenler."

"Her zaman iyileştirilebilecek bir şeyler vardır.", "Hiç bir şey mükemmel değildir ama her şey mükemmelleştirilebilir.", "Agile bir hedef değil yolculuktur." gibi yaklaşımlar bu değerlendirme/iyileştirme toplantılarının sürekli olarak yapılmasını gerekli kılar.

Bu prensip farklı isimlerle anılabilir; Inspect&Adapt, Continuous Improvement, Kaizen, Retrospective gibi. Scrum kapsamında bu prensip retrospective toplantısı adı altında bir pratiğe dönüştürülmüş. Retrospective toplantıları her sprint'in sonunda ekibin yaptığı, scrum master, product owner, takım gibi roller dışında yönetici gibi diğer rollerin de katılabileceği bir toplantıdır. 2haftalık sprintler icin 1-1.5saat civarı olması tavsiye ediliyor.

Retrospective toplantılarının yapılmamasının nedenleri genelde şunlar oluyor;

• İnsanlar iş yapış şekilleri, projeler, süreçler vs. üzerine yeterince kafa yormadığı için iyileştirecek bir şey ortaya koyamıyorlar, diğer bir deyişle umursamıyorlar.
• Retrospective toplantılarında çıkan aksiyonlar takip edilmiyor, yani iyileştirilmesi gereken yerler iyileştirilmiyor, dolayısı ile her toplantıda aynı sorunlar tekrar tekrar konuşuluyor, bu durum bir süre sonra toplantının gereksiz olduğu düşüncesi ile sonuçlanıyor.
• Toplantıda konuşulan konular bireyselleştiriliyor ve çatışmalar çıkıyor. Bir ekip bilinci/ruhu yok ise bu çatışmalar çok kolay tetiklenebiliyor, özellikle test/development çatışmaları.

Yukarıdaki gibi sorunlar yüzünden retrospective toplantıları yapamıyorsanız ama yapmanız gerektiğini, bir şeyleri iyileştirmeniz gerektiğini düşünüyorsanız, ki her zaman iyileştirecek bir şeyler vardır, bu sorunları çözmek birinci derecede scrum master rolünü üstlenen kişiye kalıyor.

Retrospective toplantılarını ferah, insanların rahat edebileceği, beyaz tahtası olan bir toplantı odasında yapmak sağlıklı sonuçlar almanıza yardımcı olacaktır.

Retrospective toplantılarında insanları konuşturabilmek onlardan geri bildirim alabilmek için kullanılan farklı yöntemler var. Biz şu pratikleri kullanıyoruz;

• Sprint puanı
• Mutluluk Indexi
• Yapmaya Başlayalım/Yapmayalım/Yapmaya Devam Edelim Çalışması
• Nokta Puanlama
• Tartışma

Retrospective toplantısına liderlik eden bir kişi oluyor, bizde genellikle bu kişi scrum master oluyor ama bu zorunlu değil, hatta ekib dışından birisinin retrospective toplantısına liderlik etmesi de tavsiye edilen bir pratik.

Toplantının başında toplantının nasıl ilerleyeceği her bölüme ne kadar süre ayrıldığı ile ilgili ekibe bilgilendirme yapılıyor ve sonrasında pratiklere geçiliyor.

İlk iki pratik için ekibe küçük(5x5cm) kağıtlar dağıtıyorum. Bu kağıdın bir tarafı ilk pratik için diğer tarafı da ikinci pratik için kullanılacak.

Sprint puanı ilgili sprint hakkında ekibin genel hissiyatını öğrenmek için kullanılan bir pratik. Bu pratik geçen sprint ile ilgili ne hissediyorsun sorusuna kişinin aklına gelen ilk cevabı aslında, bu cevabı farklı formatlarda alabiliyorsunuz biz puan formatında alıyoruz. Herkes aldığı kağıdın bir yüzüne sprint'e 10 üzerinden kaç puan verdiğini genel hissiyatına göre yazıyor, sonra herkesin verdiği puanlar toplanıp ortalama puan bilgisi bulunup ekip ile paylaşılıyor. Bu puan size üst seviyede, geçirdiğiniz sprint'i diğer sprintleriniz ile de karşılaştırma imkanı veriyor.

Mutluluk Indexi, ilk başta biraz garip geliyor isim olarak, bireysel bir geri bildirim alıyorsunuz ekip arkadaşlarınızdan. Bu pratik her ekip üyesinin özel olarak 3 farklı soruya verdiği cevaptan oluşuyor;

• Genel olarak burada çalışmaktan ne kadar mutlusun? (5 üzerinden puan)
• İleriye dönük olarak mutlu olacağına/kalacağına inanıyor musun? (5 üzerinden puan)
• Seni mutlu edeceğine inandığın 3-5 kelime yazar mısın?

 Herkes verilen kağıdın bir yüzünü 3'e bölerek bu 3 soruya cevabını bölmelere yazıyor. Bu pratik için kimin ne yazdığının scrum master tarafından bilinmesi gerekiyor, dolayısı ile bu kağıtlara ekip üyeleri isimlerini de yazıyor.

Scrum master, veya ekip lideri, bu kağıtları toplayıp daha sonra, mümkünse diğer sprint'in retrospective toplantısına kadar, her bir ekip arkadaşıyla kağıda yazdığı bağlamda konuşuyor. Çözülmesi gereken problemleri çözüyor veya çözülmesi için girişimlerde bulunuyor. 

Bu pratik size her bir ekip arkadaşınızın ne kadar mutlu olduğu, ne kadar umutlu olduğu, neleri istediği veya istemediği ile ilgili bilgi veriyor. Ekip arkadaşlarınızın hangi seviyede olduğu hakkında bilginiz oluyor, mesela birisinin iş yerinde maaş/kariyer gibi problemleri var ise o kişiden kendini geliştirmesini, ekip ile teknik anlamda bir şeyler paylaşmasını beklemek çok gerçekçi olmayabiliyor. Normalde çok iyi iş çıkaran bir ekip arkadaşınızın performansındaki düşüşün nedenini anlayabiliyorsunuz. Bu tür konuları bu şekilde formal bir girdi alarak yapmak bu işin tek yolu değil elbet, ekip arkadaşları ile düzenli olarak konuşan bir lider bu şekilde bir girdi almadan bu süreci iyi bir şekilde yönetebilir. Yazılı iletişim ile bir ön çalışma sonra onun üzerine sözlü iletişim ile yazılanları açma olan bu yöntem bana daha kolay ve etkin geliyor.

Yapmaya Başlayalım/Yapmayalım/Yapmaya Devam Edelim çalışması için renkli post-it'ler kullanıyoruz. Her kategorinin bir rengi oluyor, bunları tahtaya kategori isimlerinin altına yapıştırıyorum. Daha sonra 5dakika boyunca her ekip üyesi bu kategoriler ile ilgili olarak geçen sprint için düşüncelerini post-it'lere yazıyor. Kategorilerin anlamları şu şekilde;

• Yapmaya Başlayalım; Yapmıyoruz ancak yaparsak şu şekilde faydalar olacağını düşünüyorum, bir sonraki sprint'de bunun yapılmasını istiyorum.
• Yapmayalım; Bunu yapıyoruz ancak bu bize şu şekilde zarar veriyor o yüzden artık bunu önümüzdeki sprint'den itibaren yapmayalım istiyorum.
• Yapmaya Devam Edelim; Bunu yapıyoruz, şu şekilde faydalarını görüyoruz, o yüzden bunu yapmaya devam edelim. Sprint kapsamında bir çok şey yapıyor ve hepsinin devam etmesini istiyor olabilirsiniz, buraya yapmaya yeni başladığınız veya kritik gördüğünüz şeyleri yazabilirsiniz.

5 dakikanın sonunda, ekip üyeleri sıra ile tahtaya çıkıp post-it'ler üzerine yazdığı notları tahtada ilgili kategoriye yapıştırıyor ve yazdığı şeyi okuyor, belki 2-3 cümle ile de bir açıklama yapıyor, ama tartışılmıyor. Her ekip üyesi bunu yaptıktan sonra biz, eğer tahtada çok fazla konuşulması/tartışılması/aksiyon alınması gereken post-it var ise nokta puanlama yöntemi ile öncelikleri belirlemek için oylama yapıyoruz. Eğer post-it sayısı az ise hepsini konuşabileceksek bu oylamayı yapmıyoruz.

Nokta puanlamada her ekip üyesinin her kategoride 3 nokta'dan ibaret olan bir puanlama hakkı oluyor. Toplamda 3 kategori var, yani her ekip üyesinin elinde 9 adet noktası oluyor. Ekip üyeleri tahtaya çıkıp her kategoride kendine göre öncelikli olan post-it'lere puan veriyor, isterse tüm puanını(3nokta) tek bir post-it'e de verebilir veya dağıtadabilir. Burada amaç öncelikli olan, en çok puan alan, konuları belirleyip onlara öncelikli olarak odaklanmak.

Son olarak tahtadaki post-it'ler, toplantıya liderlik eden kişi öncülüğünde ekip ile tartışılıyor ve yeterince net değilse, farklı görüşler varsa bunlar ortaya çıkarılmaya çalışılıyor. Burada herkesin eşit süre alarak fikir beyan etmesine imkan verilmesi, faydasız çatışmaların önüne geçilmesi, konuların bireyselleştirilmesine izin verilmemesi gibi konulara dikkat etmek gerekiyor. Burada eğer alınması gereken aksiyonlar çıkar ise onları da not etmek gerekiyor.

Elbette bir ekipde bireysel sorunlar da olabilir, ekibi rahatsız eden, ekip motivasyonunu düşüren çalışanlar olabilir. Bu tip sorunların retrospective toplantılarında konuşulması çok doğru bir yaklaşım değil, çatışma çıkma veya bireysel olarak bir ekip üyesinin rencide edilme ihtimali çok yüksek olduğu için. Scrum master veya ekip liderinin bu tip sorunların farkında olması ve bu tip ekip üyeleri ile bire bir konuşması, bir birleri arasında sorun yaşayan insanların bire bir konuşmasını sağlaması gerekiyor. Bireysel sorunları ve sonuclarını net olarak ortaya koyması, çözüm üretmesi veya çözüm beklemesi gerekiyor.

Bu son pratik ile birlikte retrospective toplantısı sonlandırılıyor.

Toplantı sonrasında biz retrospective toplantısının çıktılarını(sprint puan, mutluluk indexi, Yapmaya Başlayalım/Yapmayalım/Yapmaya Devam Edelim notları, aksiyonlar) yazılı olarak online bir ortamda(JIRA) tutuyoruz. Takip edilmesi gereken aksiyonları bir kanban board üzerinden online herkesin görebileceği şekilde takip ediyoruz.

Retrospective toplantısı sonucunda çıkan aksiyonların takip edilmesi, delegasyonu, yapılması scrum master veya ekip liderinin sorumlulugunda oluyor. Mutluluk Index'lerinde çıkan konuların ekip üyeleri ile bire bir görüşülmesi de yine aynı kapsamda.

İlk başta söylediğimizi tekrar edelim; unutmayalım her zaman iyileştirecek bir şeyler vardır.

Retrospective pratikleri ile ilgili faydalandığımız bir kitap;

• Agile Retrospectives: Making Good Teams Great, by Esther Derby, Diana Larsen

Cucumber ile Behaviour Driven Development

Behaviour Driven Development kavramı son zamanlarda dikkatimi çeken bir konu. İlk önce Dan North tarafından ortaya atılmış. Dan North, TDD(Test Driven Development) ile ilgili bazı tecrübelerinden yola çıkarak gördüğü aşağıdaki gibi bazı eksikliklerden dolayı bu kavramı ortaya atmış;

• Testler nerede başlar nerede biter belli olmuyor,
• Testlere verilen isimleri sadece developer'lar anlıyor,
• Ortak bir dil(ubiquitous language) kullanılamıyor,
• Test, Analist, Development arasında ortak bir anlayış sürece dahil edilemiyor.

BDD ile aynı amacı güden pratikler farklı isimlerle anılabiliyor, bunlardan bazıları; Specification by Example, Acceptance Test Driven Development, Extenden Test Driven Development.

BDD ile ilgili Liz Keogh'un şu şekilde küçük ve kapsayıcı bir tanımı var; "Using examples in conversation to illustrate behaviour."

BDD, TDD'nin bir alternatifi değil, daha çok Eric Evans'ın Domain Driven Design kitabında bahsettiği kavramlar ile TDD'nin birleşimi gibi. TDD yapmanız BDD yapmanızı gereksiz kılmıyor, tersi de geçerli, BDD yapıyor olmanız TDD yapmanızı gereksiz kılmıyor.

Hem BDD hem de TDD test pratiğinden ziyade tasarım pratiği olarak görülüyor. Çünkü her iki pratiğin de asıl odak noktası test veya test otomasyonu değil, ama bu pratik uygulandığında test otomasyonu sürecin doğal bir çıktısı oluyor. BDD ve TDD'nin ayrıldıkları ana nokta ikisinin odaklandıkları konular; TDD tarafında daha çok koda odaklanılıyor, "iyi tasarlanmış temiz kod" amacı öne çıkıyor. "Test, Code, Refactor" döngüsü ile bu sağlanmaya çalışılıyor. BDD tarafında ise birinci sıraya iş birliği ve ortak anlayış konuluyor, bunu sağlamak için de davranışların çalıştırılabilir(executable) tanımları(spesifikasyonlar) three amigos denilen test, analist ve developer üçlüsü tarafından yazılıyor. Yani BDD ise test'den öte çalıştırılabilir spesifikasyonlar sunuyor.

Her iki pratikte de önce test kodları yazılsın sonra bu kodları gececek gercek kodlar yazılsın mantığı var, BDD tarafında buna "outside-in" development diyorlar. BDD tarafında aslında test kodlarından önce bir de three amigos tarafından davranışın tanımlanması adımı var. Yani ilk önce davranış tanımı, sonra bu davranışları test edecek test kodları, sonra da bu davranışı gerçekleştirecek gerçek kodlar yazılıyor, dışarıdan içeriye doğru gelme bu şekilde oluyor.

Pratiğin gerçekleştirilmesi anlamında bana BDD'ye daha çabuk uyum sağlanacakmış gibi geliyor, çünkü BDD tarafı TDD'ye göre biraz daha üst seviyede kalıyor. TDD tarafında biraz daha birim(methdod, sınıf) seviyesinde önce test kodu sonra gerçek kod yazılması, developer'ın kod yazmaya bakış açısında daha ciddi bir değişiklik gerektiriyormuş gibi geliyor. Bu değişikliğe uyum da kişiden kişiye değişmekle birlikte muhtemel 5-6 aydan önce oturmuyor.

Neden BDD yapalım? Diye sorunca; sistemin/projenin gereksinimleri/davranışları anlamında; analist(veya müşteri), testci ve developer arasında güçlü bir iletişime ve ortak bir anlayışa olan ihtiyaç karşımıza çıkıyor. BDD'nin temel amacı yazılım geliştirmedeki bu temel rollerin(analist, test, developer) güçlü bir işbirliği ile çalışmaları. Bu temel amaca erişmek için yapılan pratiğin bize iki önemli çıktısı oluyor, birincisi; sistemin temel davranışlarının test edilmesinin otomatize edilmesi, ikincisi; sistemin davranışlarının güncel bir dökümantasyonunun sağlanması.

Cucumber BDD yapmak için kullanılan bir araç. BDD kavramını kullanabilmeniz için farklı programlama dilleri, farklı ortamlar için sağlanmış başka araçlar da var. Cucumber three amigos tarafından yazılan çalıştırılabilir spesifikasyonların çalıştırılmasını ve sonuclarının raporlanmasını sağlıyor. GitHub üzerinde açık kaynak kodlu bir proje ve arkasında Aslak Hellesoy, Matt Wynne gibi isimler var. İlk önce Ruby için yazılmış sonra Java, Groovy, .NET, JavaScript vs. 14 farklı dili destekliyor ve Spring, Selenium, PicoContainer vs. 5 farklı framework ile entegrasyonu var.

Cucumber çalıştırılabilir spesifikasyonlar yazmak için Gherkin isimli bir dili kullanıyor. Basit bir kaç tane keyword'ü ve formatı olan bir dil bu. Size DSL(Domain Specific Language) ile doğal dil kullanarak spesifikasyonlarınızı(davranışlarınızı) yazma imkanı veriyor. Gherkin'de en son 56 farklı dilde spesifikasyonlarınızı yazabiliyorsunuz.

Cucumber üst seviyede şu bileşenlerden oluşuyor; Business Facing(Features, Scenarios, Steps), Technology Facing(Step Definitions, Support Code, Automation Library, Your System). Burada three amigos'un beraber çalıştığı kısım sadece "Business Facing" olan taraf, "Techology Facing" kısmı sadece developer'lara kalıyor. Bu bileşenlere kısaca bakacağız.

Sisteminizdeki/projenizdeki her bir özellik(feature) için bir tane ".feature" uzantılı Gherkin dosyanız oluyor. Bu feature dosyasında sistemin ilgili özelliğinin tanımı ve bu özelliğe göre farklı durumlardaki davranışı senaryo adı altında yazılıyor. Senaryoları kabul kriteri olarak düşenebiliriz, bu senaryolar Given/When/Then formatında, "steps" denilen adımlarla, yazılıyor. Given ile bir ön koşulu, When ile olayı, Then ile de sonucu tanımlıyorsunuz. Örnek bir Gherkin feature file aşağıdaki gibi;

@foo
Feature: Basic Arithmetic

Background: A Calculator
Given a calculator I just turned on

Scenario: Addition
  # Try to change one of the values below to provoke a failure
When I add 4 and 5
Then the result is 9

Cucumber bu step'leri çalıştırabilmek için bunlara karşılık bir kod parcacığının olmasını bekliyor ve bunlara "step definitions" diyor, Java'da bunlar method'lar oluyor. Cucumber aradaki eşleştirmeyi regular expression'lar ile yapıyor. Step tanımlarındaki textleri methodlar üzerine Java annotation'ları ile yazılan ifadeler ile eşleştirmeye çalışıyor ve eşleştirdiği method'u çalıştırıyor. Sisteminizdeki feature dosyalarında yazdığınız her bir step'in tüm sisteminiz boyunca tek bir anlamının olması gerekiyor. Bir step icin Cucumber birden fazla step definiton bulursa bunu hata olarak size yansıtıyor. Yukarıdaki örnek step'ler için step definition'lar aşağıdaki gibi oluyor;

@Given("^a calculator I just turned on$")
        public void a_calculator_I_just_turned_on() {
        calc = new RpnCalculator();
}

@When("^I add (\\d+) and (\\d+)$")
       public void adding(int arg1, int arg2) {
       calc.push(arg1);
       calc.push(arg2);
       calc.push("+");
}

@Then("^the result is (\\d+)$")
      public void the_result_is(double expected) {
      assertEquals(expected, calc.value());
}

Bu step denifiniton'lar içinde siz gerçek sisteminizde beklenen davranışı test etmeye çalışıyorsunuz. Feature dosyasından methodlarınıza parametre geçirmek için regular expression'ın capture group('()' icindeki kısımlar) mantığı kullanılıyor.

Cucumber'ın feature/senaryo/step'leri çalıştırma mantığı aşağıdaki gibi;

Bir senaryonun başarılı olması altındaki tüm step'lerin başarılı olmasıdır, bir step'in başarılı olması da ilgili step definition'dan exception(PendingException dışında) fırlatılmaması demektir.

Cucumber senaryo bazında bağımsız çalışıyor, JUnit'deki her bir test methodunun kendi icinde bagımsız calışması gibi. Senaryoların da buna göre tasarlanmasını bekliyor. Yani senaryonun başındaki sistemin state'i ile sonundakinin aynı olmasını bekliyor.

Senaryolara "hooks" denilen yöntemler ile öncesinde/sonrasında çalışacak kodlar ekleyebiliyorsunuz. TDD'deki setup/teardown veya @Before/@After olarak işaretlenmiş methodlar gibi. Örneğin bir senaryo çalıştırılmadan önce veritabanı bağlantısı alınıp, çalıştırıldıktan sonra bu bağlantının kapatılmasını istiyorsunuz, bunu bu hook methodlar ile yapabiliyorsunuz.

Cucumber test otomasyonu anlamında size browser'ı veya swing ekranlarınızı kontrol etme gibi yetenekler sağlamıyor, bu tarz ihtiyaçlar için selenium web driver gibi araçları kullanmak gerekiyor.

Feature ve senaryolarınızı tagleyebiliyorsunuz, örneğin yukarıda verilen örnekte @foo tag'i kullanılmış. Tagler size istediğiniz feature veya senaryo grubunu çalıştırma imkanı veriyor. Ek olarak hook methodları tagler ile ayarlıyorsunuz hangi senaryodalar calışacağını belirtmek için. Örneğin çok yavaş çalışan senaryolarınız var bunları her build'de çalıştırmak istemiyorsunuz, sadece gece yapılan build'de çalıştırmak istiyorsunuz, bu tarz ihtiyacları tag'ler yardımı ile gerçekleştirebiliyorsunuz.

Cucumber ile BDD yapılırken insanlar çok çeşitli sorunlar ile karşılaşabiliyorlar, hatta öyle bir noktaya geliniyorki artık Cucumber ile çalışmak faydadan ziyade zarar vermeye, ayak bağı olmaya başlıyor. En çok yaşanılan sorunlar;

• Rastgele başarısız olan testler(bir çalışıyor bir çalışmıyor),
• Kendisi ile ilgisi olmayan değişikliklerden etkilenip başarısız olan testler(kırılganlık),
• Testlerin çok yavaş çalışması,
• Paydaşlarla iş birliğinin olmaması(sadece dev, sadece test feature'ları yazıyor gibi)

Bu tarz durumlardan kacınmak icin öncelikle test icin yazılan kodların da gercek kodlar gibi tasarım, temizlik, ilgi, bakım gerektirdiğini unutmamak gerekiyor. Dikkat edilmesi gereken bazı konular;

• Feature dosyalarını önemsiz detaylar ile doldurmayın, ilgili feature'un temel olarak neyi kontrol etmeyi gerektirdiğine odaklanın,
• Feature dosyalarında sistemi komut komut yönlendirmek yerine biraz daha üst seviyede düşünün, bu tarz gereksinimleri step definition tarafına bırakın,
• Duplication'lardan kaçının, aynı işi yapan ancak isimleri farklı olan step definition'lar burada krtik oluyor,
• Ortak dil kavramına önem verin,
• Yazılan feature'ları otomatik olarak bir dökümantasyona dönüştürüp, müşteri gibi paydaşlardan geri bildirim alın. Bu işlemi yapan online araçlar da var, relish gibi.

Sonuç olarak; BDD'nin temel amaçı olarak işbirliği ve iletişim ön plana çıkıyor. Bu işe başlayacaksanız detaylarda boğulmamak önemli bir kriter, örneğin UI testleri bu detaylarda boğulmayı çok daha hızlandırabiliyor, o yüzden ilk defa başlayacaksanız UI testlerinden ziyade, backend servislerinizin testleri ile başlamak daha anlamlı olabilir. Test otomasyonu BDD'nin bir çıktısı olarak size çok büyük faydalar sağlayacaktır, her bir geliştirme sonrasında günlerce, gecelerce regresyon testi koşma derdiniz olmayacaktır, sisteminizin sağlığını her an kontrol edebilir olacaksınız. Yaşayan bir dökümantasyona sahip olabilirsiniz, ancak yaşayan dökümantasyon bu işe başlarken aklınızda olursa feature'larınızı da ona uygun olarak yazabilirsiniz. Bu feature'lardan RTM(Requirement Tracebility Matrix), TDD(Test Durum Dökümanı) gibi dökümanları çıkarmak hiç zor olmayacaktır. Zaten var olan bir projeye tüm sistemin otomasyonu yapılacak amacıyla feature'larınızı yazmak size gercek faydayı vermeyebilir, bu şekilde bir ihtiyacınız varsa da bunu zamana yaymak, önce yeni gelen işlerle başlamak daha anlamlı olabilir.

Referans olarak benim okuduğum aşağıdaki iki kitap var;

• Specification by Example: How Successful Teams Deliver the Right Software, by Gojko Adzic
• The Cucumber for Java Book: Behaviour-Driven Development for Testers and Developers, by Seb Rose, Matt Wynne, Aslak Hellesoy

Gojko Adzic'in kitabı daha cok kavram üzerine, spesifik bir BDD aracı üzerine değil. Bir çok yaşanmış örnekten yola çıkarak size bu yolda neler ile karşılaşacağınızı ve bunlara karşı neler yapmanız gerektiğini anlatıyor.

Uç Noktalarda Yapılan Sporlar

Uç noktalarda yapılan sporlar(extreme sports) aslında bazıları spor mu değil mi kafa karışıklığı oluşturmuyor değil ama adrenalin için yapıldığı muhakkak.

Ben de bunlardan, downhill, wingsuit gibi bazıları ara sıra izlemeyi seviyorum, özellikle wingsuit çok uçuk bir şeymiş gibi geliyor ama insanlar ciddi ciddi adrenalin için bu işi yapıyorlar. Özel dikilmiş bir çeşit kanat şeklinde parçaları olan bir kıyafet var üzerinizde ve boşluğa atlıyorsunuz. Tabi iş atlamakla bitmiyor, ciddi bir teknik gerektirdiği muhakkak, göründüğü kadar basit değildir diye düşünüyorum.

Extra adrenalinli spor deyince ilk akla gelen sponsor, redbull...değişik bir yaklaşımları var...işte biz bu kadar enerji veriyoruz demeye mi getiriyorlar bilmiyorum.

Denemek isterdim diye aklımdan geçiyor ama cesaret edebileceğimi sanmıyorum, bir de bu derece hayatını riske atmak ne kadar doğru bilmiyorum.

Diğeri wingsuit'e göre biraz daha masum, tepeden aşağıya bisikletle kendinizi bırakıyorsunuz, ama yol yok, patikalardan, ağaçların arasından, tümseklerden zıplaya zıplaya, taklalar ata ata(tabi bisikletle beraber) tepeden aşağıya iniyorsunuz.

Downhill tarzında bisiklete binen Türkiyede çok fazla kişi yoktur diye düşünüyordum ancak geçenlerde Bursada Mustafa Kemal Paşa ilçesinde bir downhill festivali düzenlenmiş, youtube'da görüntüleri var, demekki topluluklar var ve organize olabiliyorlar. Tabi biraz amatörler, redbull sponsporlu aktivetelerdeki kadar heyecan vermiyorlar. İzleyince kolay gelen bu aktivetenin de aslında ne kadar ciddi bir teknik gerektirdiğini anlamış oluyorsunuz amatörleri izleyince.

Agile Maliyetlendirme

Yapılacak olan işlerin önceden maliyetlendirilmesi yazılım geliştirme sektöründeki kritik işlerden birisidir ve bu konuda function point, uzman görüşü(expert judgement), story point kullanımı vb. çeşitli yöntemler günümüzde kullanılmaktadır. Her yöntemin olumlu olumsuz yönleri olduğu için tek bir standart model yok(yazılım dünyasının en büyük derdi standartlar yoktur çok fazla).

Agile dünyada maliyet hesabı için kullanılan yöntemlerden birisi de story point kavramı ile maliyetlendirmedir. Burada kritik kavramlar ekip, büyüklük, hız, süre ve takvimdir. Kısaca story pointler kullanılarak maliyetlendirmenin nasıl yapılacağından bahsetmeye çalışacağım.

Agile yöntemlerde maliyetlendirme ile ilgili önemli kurallardan birisi, “İşi kim yapacak ise en iyi maliyeti o verir” mantığıdır. Yazılım geliştiriyorsak da geliştirme ekibi ya da scrum takımı(developer, testci, DBA, mimar vs. takımda kim var ise hepsi dahildir) maliyeti verir.

İşlere örnek olarak şu gözle bakılır;

İş: Ankara’dan İstanbula otomobil ile Ankara-İstanbul otobanı kullanılarak gidilecek

Büyüklük: 400km

Hız: 100km/h(ortalama)

Süre: 4Saat

Takvim: 08:00–12:00

Bu kavramların özellikleri ve aralarındaki ilişkiler; büyüklük herkese göre aynıdır, değişen bir bilgi degildir, hız aractan araca veya kişiden kişiye değişir, süre hıza bağlıdır, takvim de süreye bağlıdır. Dolayısı ile bu kavramlardan büyüklük ve hız asıl belirleyici olanlardır.

Bu kavramlar kullanılarak maliyetlendirme yapılacak ise büyüklük hesabı yapılacak olan işin anlamlı bir büyüklükte olması gerekir. Anlamlı bir büyüklükten kasıt ekibin o işi anlayıp, o işi gerçekleştirmek için yapılması gerekenleri kafasında kabaca canlandırabilmesi gerekir. Çok fazla belirsizlik içermemesine dikkat edilir.

Scrum’da işlerin belirlenmesinden sorumlu kişi product owner rolünü üstlenen kişidir, bu kişi müşteridir veya müşteriyi temsil eden kişidir, yapılacak olan işin/projenin user story olarak maddelere bölünmüş halinden oluşan product backlog olarak adlandırılan gereksinim listesini yönetir. Scrum takımı product backlog’daki user story’lere büyüklük maliyeti verir. Örnek bir user story “Kullanıcı olarak kullanıcı adı ve şifremle sisteme login olmak istiyorum” şeklindedir. User story’ler maliyet vermek için çok büyük ise(epic, theme) çeşitli yöntemlerle maliyet verilebilecek daha küçük parçalara bölünürler veya maliyet vermek için küçük user story’ler var ise bunlardan bazıları birleştirilebilir.

Product backlog hazır ve büyüklük maliyeti verilmesi gerekiyor, product owner ve scrum takımının olduğu bir toplantı düzenlenir. Bu toplantıda poker planning denilen bir yöntemle scrum takımı product backlog maddelerine(user story) maliyet verirler. Açık olmayan noktalar hakkında product owner’dan bilgi alırlar, user story’ler parçalanıp, birleştirilebilir.

Büyüklük maliyeti verilirken birim olarak story points denilen bir birim kullanılır ve işler göreceli büyüklüklerine göre puanlanır. Bunu büyüklüklerine göre t-shirt’lerin S, M, L, XL gibi işaretlenmesi olarak da düşünebilirsiniz. Story point olarak genellikle fibonacci serisine benzer 0, 1, 2, 3, 5, 8, 13, 20, 40, 100 gibi rakamlar kullanılır, aradaki sayılar kullanılmaz. Bunun iki önemli nedeni var birincisi aradaki sayılar olursa çok fazla karmaşa olur, 5 mi yoksa 6 mı şeklinde, bunun yerine 5 mi 8 mi ayırımı daha kolay karar verilebilir bir durumdur. Diğer bir neden işlerin büyüklükleri ile o işteki belirsizlik veya belirsizlik çıkma olasılığı da doğrusal olarak artar o yüzden sayılar arasındaki farklar da giderek artıyor, mesela 40 ile 100 arasında ciddi bir fark var. Bu büyüklükteki sayılar genelde belirsizlik içeren ve bölünemeyen user story’ler için kullanılır.

Göreceli büyüklük kavramı için referans noktası veya noktaları olması gerekir, ilk defa poker planning yapmıyorsanız zaten daha önceden verdiğiniz büyüklük maliyetleri sizin için referanstır ancak ilk defa yapıyorsanız kendinize referans orta seviye bir iş seçip ona orta seviye bir puan vermelisiniz(3,5 gibi), sonraki işlerinizin maliyetlerini hep o referans işle karşılaştırarak vermelisiniz. Örneğin referans işe 5puan dedik, sonraki iş bu referans işten çok az daha büyük bir iş o zaman bu işe de 8puan diyorsunuz, ya da sonraki iş referans işten küçük bir iş o zaman bu işe 3puan yada 2puan diyorsunuz şeklinde ilerleniyor.

Poker planning şu şekilde yapılır; user story puanları (0,1,2,3,5,8 vb) poker kartlarına bastırılmış şekilde her scrum takımı üyesinin elinde bir deste puan kartı olur. Product backlog’daki maliyet verilecek iş her ekip üyesi maliyet verebilecek hale gelinceye kadar kabaca irdelenir. Sonra her ekip üyesi ilgili iş için belirlediği puan kartını ters bir şekilde masaya kapatır, herkes kartını koyduktan sonra kartlar açılır. Yani maliyet verirken ekip üyeleri bir birinden etkilenmesin diye ilk önce kimse kimsenin verdiği maliyeti görmez. Kartlar açıldıktan sonra çok farklı puanlar var ise en küçük puan veren ekip üyesi ile en büyük puanı veren ekip üyelerine neden bu puanı verdikleri sorulur. Bu noktada diğer ekip üyelerinin gözünden kaçan bir nokta var mı yok mu bu anlaşılmaya çalışılır. Gerekli tartışmalar yapıldıktan sonra ekip benzer bir puan üzerinde anlaşıncaya kadar bu seans devam eder. Ekip ortak bir puan üzerinde anlaştığında o işin büyüklük maliyeti verilmiş olur. Takım bu şekilde product backlog’daki tüm maddeleri puanlar.

Elimizde büyüklükleri puan olarak belirlenmiş bir product backlog var, bu product backlog’daki işlerin ilgili ekip tarafından ne kadar sürede yapılabileceğini bulmamız gerekiyor ki süre ve takvim olarak müşterimiz ile anlaşalım. Süre için bize hız bilgisi gerekli. Buradaki hız scrum takımının birim zamanda ne kadar puanlık iş yapabildiğidir. Örneğin product backlog’daki işler 1000puan çıktı bizim scrum takımımız 15günde 50puanlık iş yapabiliyor, o zaman product backlog’daki işlerin bu scrum takımı tarafından tamamlanması  ((1000/50)*15)= 300gün sürer, şeklinde bir hesap yapılır. Buradaki kritik nokta bu hız bilgisinin nasıl elde edildiği eğer ilk defa story point’lerle maliyet verip iş yapmıyorsanız hız bilgisi için ekibin tarihsel verileri kullanılabilir, geçmişte kac puanlık işler ekip tarafından ne kadar sürede yapıldı şeklinde ortalama bir hesap yapılıp hız bilgisi elde edilebilir. Ancak geçmiş verileriniz yok ise hız bulmak veya tahmin etmek için farklı yöntemler kullanmanız gerekiyor, bunlardan birisi müşteriniz ile anlaşabiliyorsanız bir iterasyon yapıldıktan sonra hız bilgisi elde edilip müşteriye bu hız bilgisi üzerinden maliyet dönülür. Müşteri ile bu konuda anlaşamıyorsanız tahmini bir hız seçmeniz gerekir başlangıç için.

Agile yöntemlerde gereksinimler, süreler, maliyetler vs. bir defada alınan ya da başlangıcta kesin rakamlarla belirlenen şeyler olarak kabul edilmez. Aslında tüm yöntemlerde bu böyle olmalıdır, çünkü belirsizliklerin en fazla olduğu projenin başlangıç aşamasında verilen süre, maliyet gibi bilgiler çok büyük oranda projenin ortasında, sonunda sapar, projenin başlangıcında gereksinimleri sabit olarak almak, süreleri, maliyeti sabit olarak vermek çoğu zaman gerçekçi bir yaklaşım olmamakla birlikte firmalar kendilerini garanti altına almak için bu sabit kapsam, sabit fiyat, sabit süre yöntemini tercih ediyorlar.

Agile yöntemlerde süre, maliyet gibi sayılarla ifade edilen kavramlar için aralık kullanılması da tercih edilen bir yöntem. Aynı şey scrum takımının hız bilgisi için de geçerlidir. Hız ile verimlilik bir birine paralel kavramlar değildirler, bir takım ne kadar hızlıysa o kadar verimlidir diyemeyiz. Hızları düşük diye eleştirdiğiniz bir takımın hiç bir extra efor sarfetmeden hızını arttırması gayet kolay, story point’leri daha fazla verirler. O yüzden bu kavramlara doğru yaklaşmak çok önemlidir. Hızın artması değil sağlıklı bir aralıkta olması önemlidir. Bazen artar, bazen azalır.

Burada yazılım maliyetlendirmesinde çok kullanılan adam gün, adam ay vb. içinde zaman bilgisi barındıran kavramlardan hiç bahsetmedik. Bir ekip bir projeye maliyet verirken ekipden zaman bazlı maliyet almak sizin o işin gerçek büyüklüğünü bilmemenize neden olur. Aynı işi bir ekip elamanı 1günde yapar, başka bir ekip elemanı 3günde yapar ancak sonucta yaptıkları iş aynıdır. Peki bu 1günlük bir iş midir, 3günlük bir iş midir? Neye göre, kime göre? Bu yüzden kişiden kişiye çok fazla değişiklik göstermeyen büyüklük kavramı ile maliyetlendirmek daha sağlıklı bir yaklaşımdır.

Agile maliyetlendirme ile ilgili Mike Cohn’un Agile Estimating and Planning kitabı okunabilecek güzel bir kaynak.

Holding Space

Türkçe karşılığını bulamadığım holding space kavramı basitce insanın kendisi veya bir başkasının bir şeyleri yapması için ona müdahalelerden, ön yargılardan uzak bir ortamı sağlaması, onun ilerlemesi bir şeyler ortaya çıkarabilmesi için desteklenmesi yani ona kendini bir şekilde ifade edebilmesi için alan açılması anlamına geliyor.

Bu kavram farklı alanlarda uygulanmakla birlikte daha çok yoga vs. gibi meditasyon teknikleri alanında karşınıza çıkıyor. Ben bu kavram ile ilk defa Lyssa Adkins’in Coaching Agile Teams kitabında karşılaştım.  Yazar kitabın master yourself bölümünde her gün güne başlarken yaptığı, bir dizi kişisel farkındalık(mindfulness) kitabının birinden rastgele bir bölümü açıp orayı okuyup, o bölümden aldığı ilgili mesajı o günkü aktivitelerine yansıtmaya çalışmak gibi bir pratikten bahsediyor. Yazarın kütüphanesindeki kitaplardan bir tanesi de holding space kavramı ile ilgili küçük küçük bölümler içeren Chris Corrigan’ın The Tao of Holding Space kitabı.

Agile dünyaya bu kavramın agile lider açısından yansıması ise ekiplerinize alan açın, onları baskılamayın, onları komutlarla kontrol etmeyin, onların yaptığı, yapacağı, yapması gereken işlere karışmayın, kendi iclerinde organize olabilen, hareket edebilen, üretebilen, problem çözebilen, öğrenebilen bir takım olmalarına izin verin. Onların yapmaları gereken, takım olarak yapmaları gerekeni onların yerine siz yapmayın, onlara güvenin ve bir şeyler yapmalarına izin verin.

Mevcut çalışma koşullarımıza, genel olarak Türkiyedeki yazılım geliştirme kültürüne baktığımızda yukarıdaki paragrafta yazanlar çok uçuk şeylermiş gibi geliyor. Bu sektörde, biraz da deneyimli olan, bir çok kişinin bu yaklaşıma nasıl tepkiler vereceği az çok tahmin edilebilir, “Yapmazlar ki!”, “Yapamazlar ki!”, “İnsanlara bu kadar güvenmek büyük risk!” vs.

Türkiyedeki yazılım geliştirme sektöründe bugüne kadar gördüğüm, deneyimli deneyimsiz insanların, genel olarak kültürlerine baktığımda da bu tepkilerin bir kısmı yersiz değil gibi. Ama bu noktaya ulaşamayız biz olduğumuz gibi devam edelim şeklinde de bir mantık doğru değil.

Bir takım kendi kendine hareket edebilen, sağlıklı bir verimlilik aralığında(verimlilik nedir çok tartışmalı bir konu bu arada) çalışan, yüksek performanslı bir ekip olabilir. Ancak elbette doğru insanlar ve doğru teşhis ve tedaviyle.

Bir ekibi hadi böyle olun, ekip liderine çok ihtiyac duymadan kendi kendinize sağlıklı bir şekilde çalışın şeklinde birden bire koyvermek, ekibin de koyvermesiyle sonuclanıyor, tecrübeyle sabittir J.

Onlar Sanıyorlar ki

Onlar sanıyorlar ki, biz sussak mesele kalmayacak.
halbuki,
biz sussak, tarih susmayacak...
Tarih sussa, hakikat susmayacak...

Onlar sanıyorlar ki,
bizden kurtulsalar mesele kalmayacak.
halbuki,
bizden kurtulsalar, vicdan azabından kurtulamayacaklar,
vicdan azabından kurtulsalar,
tarihin azabından kurtulamayacaklar...
Tarihin azabından kurtulsalar, Tanrı'nın gazabından kurtulamayacaklar.

Sezai KARAKOÇ

Uyumayan Tavşan ve Bildiğiniz Kaplumbağa

Organizasyonel anlamda çalışanlarınız arasında faydalı bir rekabet oluşturulması hem organizasyonun hem de çalışanların faydasınadır. Hem organizasyonel olarak hem de bireysel olarak sürekli bir iyileşmenin ateşleyici etkenlerinden biridir. Bunu yapmayıp iyiyi vasatı aynı şekilde değerlendirip aynı geri bildirimleri onlara verirseniz bunun hem organizasyon için hem iyi hem de vasat bireyler için olumsuz sonuçları olur.

Kaplumbağa ve tavşanı yarıştırıyorsunuz, tavşan uyumuyor ancak sürekli kaplumbağa ile yarışı beraber bitiriyorlar ne olduğunu hiç anlamıyor. Tavşan ne kadar çabalasa da bir şey değişmiyor, kaplumbağa aynı kaplumbağa ama her yarışın sonunda kamlumbağayı birisi alıp tavşanın yanına koyup, “Aferin aynı zamanda bitirdiniz!” diyor. Neden? Önemli olan yarışmak mı, ama yarışmıyor da, o zaman önemli olan kaplumbağanın orda olması, ne yarışmasının önemi var ne de yarışmayı kazanmak icin çaba sarfetmesinin. Neden çaba sarfetsin ki zaten yarışı her zaman beraber bitiriyorlar. Birileri kaplumbağanın kaplumbağa olduğunu ısrarla anlamak istemiyor ve ondan tavşandan ne beklerse onu bekliyor, ama farketmiyor ki, kaplumbağa istenileni veremese farketmiyor...

Örneğin bir pozisyonun gerekliliği alan uzmanlığı ve teknik yeterlilik ise sadece alan uzmanı olan ancak teknik olarak yeterli olmayan insanları da bu pozisyonda tutmanız gerektiğinde benzer bir duruma düsüyorsunuz. Tam tersi bir durum genelde geçerli olmuyor yani alan uzmanı olmayan ancak teknik olarak yeterli olan insanları ekip lideri yapamıyorsunuz. Bu insanlar yıllardır aynı ezberde iş yaptıkları icin bu ezberin dışına çıkmaları çok mümkün olmuyor ki zaten o ezberin dışı hakkında da hic bir fikirleri yok. Daha önce yapılmayan bir işi yapmalarını istediğinizde bocalıyorlar. Yani bildiği iş alanı bilgisini çıkarın geriye pek bir şey kalmıyor.

Bu arkadaşları  başka çalışanların başına lider olarak koyarsanız, beraber çalıştığı kendi ekibindeki insanlar açısından iş alanı bilgisi almaktan başka bir işe yaramıyor. Teknik meselelere gelince ne bir yönlendirme var, ne de bir çözüm üretiyorlar ve çoğu iş hayatına yeni başlamış ekip arkadaşları bir bataklığın içinde debelendikçe daha da dibe batıyorlar.

Yeterli yetersiz herkesten aynı rolü oynaması isteniyor ancak bazıları rolün hakkını veremeyince onun altında kalıyorlar. Buna rağmen yine herkesin aynı olarak değerlendirilmeye devam edilmesi ise bireysel ve organizasyonel olarak ilerlemeyi durduruyor. Çünkü bu şekilde davranarak rolün hakkını verenlerin de motivasyonunu kırıyorsunuz. Bir rekabet ortamı yok, çünkü rekabet edilecek kimse yok, ki rekabet etseniz de bir anlam ifade etmiyor, sonuc olarak aynısınız. Bu hem iyiler hem de vasatlar icin aynı derecede önemli, iyiler yapmaya çalıştıklarının karşılığını alamıyorlar, vasatlar bir şey yapsada yapmasada farketmiyor, iyilerle arasında da zaten bir fark yok neden çaba sarfetsin ki? Veya çaba sarfetmesi gerektiğinin bile farkında değil dünyayı bildiğinden ibaret sanıyor. Sürekli iyileştirme, daha iyi daha düzgün iş yapma diye bir bakış açısı yok.

Bir organizasyonda roller ve sorumluluklar net olarak ayrıştırılmalıdır. Rolünün hakkını verenler ile vermeyenler de net olarak ayrıştırılmalıdır. “Ne şiş yansın ne kebab” mantığının bence organizasyonel anlamda uzun vadede bir faydası yok. Elinizdeki iyilerin gözü sürekli dışarda olur, bazıları gider, siz de vasatlarla beraber kalırsınız. Hedefleriniz vizyonunuz uzun vadeli ise bence bakış acısı bu olmalıdır, yok yarın ne olacağı belli degil biz günü kurtaralım yeter diyorsanız o zaman zaten bir şey yapmaya gerek yok. Ancak organizasyonunuza yeni elemanlar, birazcık da olsa iyi elemanlar almak icin göbeğiniz çatlıyorsa bu politikanızı ciddi anlamda gözden gecirmeniz gerekir.

Organizasyonel olarak bu şekildeki mevcut politikanızdan bugüne kadar bir zarar görmemiş olmanız politikanızın doğruluğundan değil biraz insanların kültürü ile alakalı. Yapılan haksızlığa sesini çıkarmaktan aciz, var olanı kabullenen, bana dokunmayan yılan bin yaşasın mantığıyla hareket eden çalışanlarınızdan dolayıdır. Ancak bir gün birileri uyanırsa ve en önemli kaynağınız insansa çok kötü çuvallarsınız.

İnsanlara verilen değer çalıştığı yıl ile değil ürettiği değer ile doğru orantılı olmalıdır. Bugüne kadar ne üretti, ortaya ne koydu, neleri iyileştirdi bize ne kattı şeklinde değerlendirmeler yapıldığında ortaya ne çıkıyorsa kişiye verilen değer de o kadar olmalıdır. O zaman tecrübelileri elimizde tutamayız, onları küstürürüz derseniz o zaman siz de değer üreten tecrübelileri elinizde tutun değer üretmeyenleri tutmanızın zaten anlamı yok, belki bazılarının gerçekten küsmesi gerekiyordur. Değer üretmeyen 3 tane elamanınız olacağına değer üreten 1 tane elemanınız olsun.

Kaplumbağalar tavşan değildir gözünüzü açın, alın kaplumbağaları kaplumbağaların içine koyun, kaplumbağalar da mutlu olsun tavşanlar da.