Kabul Kriterleri: Gherkin Formatı

Merhaba Arkadaşlar,

Bildiğiniz üzere user story'lerin temelde 3 bölümü vardır. Hikayenin tanımı - kabul kriterleri - bitimin tanımlanması. Şimdi Kabul Kriterleri kısmına bir alternatif oluşturan dil/model/format üzerinde duracağız: Gherkin Format/Language.

Malumunuz olduğu üzere, Kabul kriterleri müşterinin perspektifinden yapılır. Bunu en etkili kullanabileceğiniz formatlardan birisi de Gherkin yöntemidir. Kimilerine göre 3 kimilerine göre 5e ayrılır.

• Given
• When
• Then

Temelde bu 3leme üstüne kuruludur. Her bir adımda AND ile çoklayabilirsiniz. Bir de senaryoyu sayarsak, toplamda 5 yapar. Hatta daha da geliştirip daha fazla keyword kullanan da var. Evet, anlamsız gelen arkadaşlarım için adımları açıklayalım. :)

Given: description of the state of the system. Yani başlangıç durumudur. Senaryo için başlangıç noktası. 

When: customer or system action. Yani bir aksiyon alınması

Then: result of the action. When adımında alınan aksiyonun sonucu, çıktısı.

Hemen bir örnekle açıklayalım.

Örneğin ödeme sayfasında müşterilerin sorunsuzca ödeme yapabilmesi isteniyor olsun.

Given: Ödeme sayfasına girilmesi; müşterinin ödeme syafasında beklemesi

When: Müşteri ekrana, atıyorum, Krdi Kartı bilgilerini girmesi

Then: Sistemin müşteriye one-time-password(OTP) ile onay sms'i göndermesi.

Gördüğünüz gibi başarılı bir ödeme işleminde bir adımı, gayet düzenli ve anlaşılır bir şekilde kabul kriteri haline dönüştürebildik.

Görüşmek üzere.

Spotify Agile Organization - Spotify Çevik Organizasyonu

Merhaba Arkadaşlar,

Üzerinde mutabık olunamayan ama bazı firmalarca taklit edilen bir diğer Agile organizasyonu ise : Spotify Yapılanması. 

Önce kitabi kısmından bahsedelim, sonra neden itilaf oluşuyor kısaca ona değinelim.
Bir klasik haline gelen internetten resim alıntılama faslıyla başlayalım. :)

Spotify yapılanmasında da agile'daki gibi squad'lar ve bunların birer PO'su var. Tam olarak agile ritüellerini uygulamazlar. Scrum ya da kanban master'ları yoktur. Bir agile coach'a bağlıdırlar ve onunla çalışırlar.

Tribe denilen yapı, birbiriyle ilişkili olan birçok squad'ın bir araya gelmesiyle oluşan bir yapıdır. Yukarıdaki resimden de göreceğiniz üzere, bir tribe altında birçok squad ve her squad'ın da kendi Product Owner'ı vardır. Her tribe'ın da bir tribe leader'ı olmaktadır. Bir önceki yazımda bahsettiğim hiyerarşik bir yapı yok, Product Owner'lar arasında. Chief yok yani. PO'lar kendi aralarında işbirliği yaparlar. High-level bir roadmap üzerinde çalışırlar. Tribe'ın tüm PO'ları birlikte çalışır.

Chapter denen yapı ise, tribe altında, farklı squadlardan, benzer uzmanlığı bulunan kişilerin bilgi paylaşımı ve çözümler için oluşturdukları yapılardır. 

Guild'ler ise farklı tribe'lardan da katılanılan, daha genel, workshop veya atölye tarzında, isteyenin katılabidiği daha genel bir bilgi paylaşımıdır. Chapter'da örneğin arayüz geliştiricileri toplanmıştır. Guild ise tüm geliştiriciler gibi düşünebilirsiniz.

Gelelim bu yapıya yapılan itirazlara. :) Kurumların bu yapıya geçerek, sadece squad ya da direktörlük isimlerini değiştirerek, bu modeli uyguladığını sanmaları en büyük yanlışlardan birisi. Yani bu model size isimlerinizi değişitirip yola devam edin demiyor. 

Bir diğer sıkıntı da, bu model ya da yapılanma, Spotify firmasına göre yıllar içinde tecrübe edilen, denenen bir yapı. Bir modeli alayım, aynısını kullanayım çok başarılı bir yol olmaz. Bunu baz alıp firmalar kendilerine uyarlamadığı sürece, çok da başarılı olmayabilir. Örneğin, scrum master kullanıp da bu yapıyı deneyenler var. :)

Ve bu modelin arkasında Spotify'ın kendi organizasyonel ve kurum kültürü de var. Çalışanlara düşünmeleri eğlenmeleri için verilen zamanlar; hataların pişkince yüze vurulmasından ziyade, denemenin göstergesi olduğu inancı vs vs. Tüm bunları alt alta koyduktan sonra bu model daha anlamlı olacaktır.

Sonra görüşürüz.

Chief Product Owner

Merhaba Arkadaşlar,

Chief Product Owner nedir, ne değildir'i kısaca sizinle de paylaşmak istiyorum. Önce bir adım geri gidelim. Agile mantalitesinde, biliyorsunuz, bir product owner-scrum master-development team yer alır. 

Normalde product owner'lar, kitabi terimle anlatmak gerekirse, ürünün değerini arttıran ve bunu da dev team ile çalışarak yapan kişidir. 

Buraya kadar sorun yok. Soru tam olarak şu: " Tek bir Product Owner'ın başa çıkabileceğinden daha büyük bir ürün varsa ne olacak? ( what happens when the product ise too large for a single product owner?)

Bir diğer soru da şu: Tek bir ürün üzerinde çalışan birçok takım varsa ne olacak? ( what happens when you have dozens of teams working on a single project?)

Tam da böyle durumlara karşı, agile organizasyonel yapılanmasında bir kavram karşımıza çıkıyor: Chief Product Owner. 

Chief Product Owner, daha üst seviyeden kararlar alabilen, takım product ownerlarının kendisine bağlı olduğu ve bu takım product owner'larına yön veren kişidir.

Bu yapılanmadaki anahtar kelime HİYERARŞİ'dir (hierarchical organization). Burada ast-üst olayı var yani.  İnternetten yine hazır bir resme kondum; kendim çizmedim, onu paylaşayım sizlerle.

Yani daha üst seviye olaylara bakan, stratejik kararları veren, ürünün nereye gideceğini belirleyen ve hatta bunun için karar verici paydaşlarla görüşen kişidir. Takım PO'su gibi detaylarla ilgilenmez.

Sonra görüşürüz.