Her fasilitatorün elinin altında hazır olması gereken retrospective teknikleri. 💯

Sprint Retrospective etkinlerinizde kullanabileceğiniz farklı retrospective teknikleri ile ilgili yazı dizisini aşağıdaki linklerden bulabilirsiniz. Her biri ayrı bir amaca hizmet eden, eğlenceli aktiviteler. Kaizen’e yeterki katkı olsun. 😎

Bazıları benim hazırladığım, bazıları ise artık bi klasik haline gelmiş teknikler. Keyifli okumalar, keyifli etkinlikler.

Renkli Sorular

Renkli Sorular: Bir Icebreaker / Retrospective Aktivitesi

Çarklı ve Renkli Sorular

Ice Breaker : Çarklı ve Renkli Sorular | İlkim Dilara Kadakaloğlu

2 İyi 1 Geliştir

Retrospective Tekniği: 2 İyi 1 Geliştir | İlkim Dilara Kadakaloğlu

Improve your DOD

Retrospective Tekniği : Improve Your Definition Of Done (DOD)

Dot Voting

Dot Voting - Facilitation Techniques | İlkim Dilara KADAKALOĞLU

Starfish Retrospective

Retrospective Tekniği : Starfish Retrospective | İlkim Dilara Kadakaloğlu

Sailboat | Wind & Anchors

Retrospective: Sailboat | Wind & Anchors | İlkim Dilara Kadakaloğlu

Mad Sad Glad

Mad Sad Glad - Retrospective Tekniği | İlkim Dilara KADAKALOĞLU

Start Stop Continue

Start Stop Continue - Retrospective Tekniği | İlkim Dilara KADAKALOĞLU

Devamı geliyor…

Retrospective Teknikleri was originally published in dtcop on Medium, where people are continuing the conversation by highlighting and responding to this story.

Scrum Nedir? | Video: 1Er Cümle ile Scrum

Scrum Nedir ? Bu sefer uzun uzun değil de Scrum’ı ve beraberinde bize getirdiği yeni terimlerini birer cümle ile açıklıyorum. 🎈

Scrum Nedir ? Bu sefer uzun uzun yazmayacağım.

Scrum’ı ve beraberinde bize getirdiği yeni terimlerini birer cümle ile açıklıyorum. Kim bilir belki bu tarz (Birer Cümle) bir yazı dizisi şablonu olur.

Scrum Nedir ?

Kompleks ve karmaşık problemleri, değişen şartlara adapte olarak, yüksek değerli ürün haline dönüştürmek için bir çerçevedir.

Scrum Team

Product Owner, Scrum Master ve Development Team’den oluşan, ürünü geliştirmek için yeterli kapasiteye sahip olan, kendileri için en doğru kararı verebilen takımdır.

Product Owner

Ürüne, sektöre ve markete hakim olan ve o ürünü en yüksek değere ulaştırmak için stratejik kararları alan/alabilen kişidir.

Scrum Master

Scrum’ın doğru uygulanmasından sorumlu, ekibi ve/ya organizasyonu Scrum konusunda destekleyen, hizmetkar liderdir.

Development Team

Her Sprint sonunda bir ürün parçası üreten, dışa bağımlı olmadan gerekli tüm yetkinliklere sahip olan, kendi kendini yönetebilen, çapraz fonksiyonlu profesyonellerden oluşan takımdır.

Sprint

Kullanılabilir bir ürün parçası üretmek için, aralıksız birbirini takip eden, 1 ay veya daha kısa süreli zaman parçasıdır.

Sprint Planning

Sprint sonuda teslim edilebilecek ürün parçasının belirlendiği ve o ürün parçasını geliştirmek için hangi işlerin yapılacağının planlandığı bir etkinliktir.

Sprint Goal

Sprint sonunda oluşacak ürün parçasına yön veren hedeftir.

Daily Scrum

Geliştirici ekibin önündeki 24 saatte yapacağı işleri konuştuğu, 15 dakika ile sınırlı, ayakta yapılan günlük bir planlamadır.

Sprint Review

Scrum takımının bir Sprint’te ürettiği ürün parçasını, paydaşlarına sunduğu ve geri bildirim aldığı bir etkinliktir.

Sprint Retrospective

Scrum takımının geçtiği sprinti ve birbirini değerlendirdiği, gelişimini gözlemlediği ve iyileşme kararları aldığı bir etkinliktir.

Product Backlog

Ürünün belirlenmiş özelliklerinin sıralandığı, önceliklendirilmiş ve sürekli gelişen / değişen bir listedir.

Sprint Backlog

Geliştirici ekibin, Sprint sonunda çıkaracağı ürün parçasını oluşturmak için yapacağı işlerin listesidir.

Increment

Sprint’in çıktısı olan ve son kullanıcının kullanabileceği bir ürün parçası.

Originally published at http://www.ilkimdilara.com on April 15, 2020.

1Er Cümle ile Scrum Nedir? | İlkim Dilara Kadakaloğlu

Video | Scrum Nedir? was originally published in dtcop on Medium, where people are continuing the conversation by highlighting and responding to this story.

Remote Scrum Master | Online Facilitation | İlkim Dilara Kadakaloğlu

Malum virüs (COVID-19) herkesi eve kapattı. Dolayısı ile bu evden çalışma şekli bir çok çalışma alışkanlığımızı da etkiledi. En çok da yanyana çalışan ve buna fazlasıyla alışmış ekipler etkilendi diyebilriz. Artık online’ız. — Remote Scrum Master — Show Must Go On ✌

Remote Scrum Master Olarak

Peki biz Remote Scrum Master lar, bu konuda ekiplere nasıl destek verebiliriz, uygun ortamı nasıl sağlayabiliriz?

Ta taamm! Önerilerle geliyorum.

Öncelikle uzakta olduğumuz için birbirimizi göremiyoruz. Takım olmanın ruhunu kaybetmemek için birbirimizi görmemize ihtiyacımız olacaktır. O yüzden aşağıda örnek verdiğim iletişim toollarını mümkün olduğunca kamera açık yapmakta fayda var. Yüzyüze iletişimin önemli olduğunu daha önce birçok kez vurgulamıştım.

Bireysel olarak sosyal aktivitelerimizin neredeyse sıfırlandığı günler yaşıyoruz. Remote Scrum Master lar olarak takıma biraz eğlenceli aktiviteler yaptırmak keyifli olabilir. Önerdiğim toollar size bu konuda yardımcı olacaktır.

Microsoft Teams

Yanyana çalışmayan ekipler için ideal araçlardan biri olduğunu düşünüyorum. Yok yok kısıtlamayayım, tüm ekipler için oldukça yararlı. Birçok farklı ihtiyaca hizmet ediyor.

Bir takım oluşturup, ekipteki herkesin ortak kullanabileceği servislerden yararlanabilirsiniz Microsoft Teams ile;

Ortak dosyaları saklayabilir 📃

Chat özelliği ile takım üyeleri ile yazılı iletişim kurabilir 💬💭

Video konferans özelliği ile tüm eventlerinizi yapabilir 🎥

Video konferans sırasında ekran paylaşımı yapabilirsiniz. 💻

Bir diğer güzel özelliği de mobil desteğininde olması. Yani mobil cihazınızla da tüm bu servisleri kullanabilirsiniz.🤳

Zoom

Son zamanların en popüler video konferans aracı. 💯 Özellikle bu evden çalışma durumu Zoom’un bu popülerliğine popülerlik kattı. Ücretli ve ücretsiz paketleri mevcut. Ücretsiz paket özelliklerinden bahsedecek olursam;

100 katılımcıya kadar destek 👨‍🦰👩‍🦱🧒👨‍🦱👱‍♀️👨

Max 40 dakikalık oturum (40 dakikadan sonra yeni sessiondan devam edilebilir. Katılımcıları tekrar çağırmak gerekiyor)⏳

Video konferans sırasında chat özelliği 💬💭

Video konferans sırasında ekran paylaşımı 💻

ScrumPoker.Online

Yeni keşfim scrumpoker.online. Üstelik ücretsiz.✌

Online bir oda oluşturup, katılımcıları QR kod veya oda numarası ile davet edebileceğiniz güzel bir estimation aracı. İster fiboanacci ister t-shirt sizing kullanın. Bu araç bizlere bir çok estimation seçeneği sunuyor. Ayrıca oturum esnasında, tüm katılımcılar oy vermeden puanları da göstermiyor. Bu da katılımcıların birbirinden etkilenmemesini sağlıyor. Herşeyi düşünmüşler. Arayüzü çok aşırı güzel olmasa da bence ihtiyacı fazlasıyla karşılıyor. Güle güle kullanın.

Menti / Mentimeter

Benim neredeyse tüm fasilite ettiğim etkinliklerde kullandığım, en çok sevdiğim tool. ❤ Menti ile katılmcılarla anonim olarak etkileşime girilebiliyor. Bizlere farklı soru tipi seçenekleri sunuyor ve mutlaka ihtiyacımı karşılayan bir soru tipi bulabiliyorum. Bir çok tool gibi ücretsiz sürümü var ama fonksiyonları belli adetlerde kullanmamıza izin veriyor.

Üye olduğunuzda 2 fonksiyon, bir arkadaşınızı davet ettiğinizde 3 fonksiyon kullanmaya hakkınız oluyor.

Menti’nin çalışması iki farklı link ile oluyor. Admin panel olarak mentimeter.com, katılımcı arayüzü olarak menti.com kullanılıyor.

Katılımcılara sorabileceğiniz soru tipleri:

• Çoktan seçmeli: Sorunun cevabını belirleyeceğiniz şıklardan seçtirebilirsiniz.
• Açık uçlu soru: Bir soru sorup cevabını text olarak alabilirsiniz.
• Scales: verdiğiniz seçeneklerin her birine puan vermelerini isteyebilirsiniz
• Ranking: verdiğiniz seçenekleri sıraya sokmalarını isteyebilirsiniz
• Word Cloud: katılımcılardan aldığıınz feedbacklerle bir word cloud oluşturabilirsiniz
• Q&A: Katılımcıların size sormasını isteyebilir ve sorulmuş sorulara oy vermelerini sağlayabilirsiniz. Böylece en çok oy olan sorudan başlayabilirsiniz.

Bir güzel özelliği de katılımcılara Quiz yapabiliyorsunuz.Hatta yaptığınız quiz ile bir lider tablosu da oluşturabiliyorsunuz.

Katılımcılar cevaplarını verdikçe siz de ekranınızda eş zamanlı olarak sonuçları görebiliyorsunuz. Görsel olarak izlemesi eğlenceli oluyor.

Ben burada scrum poker aktivitesi bile yapabiliyorum.(scrumpoker.online a alternatif olarak)

Mural.co

Remote Scrum Master , online olarak fasilitasyon yapabilen scrum master’dır. Mural da bize bu konuda için mükemmel bir yardımcı diyebilirim. Yüzyüze yaptığımız etkinliklerde kullandığımız tahta bu tool ile online hale geliyor.

Eğer takımınızla tahta (board) ve postit alışkanlığınız varsa, Mural tam size göre. Katılımcıları ister login olarak ister anonim olarak board’a alabiliyorsunuz. Tüm katılımcılar board üzerinde aynı zamanda çalışabiliyor ve herkes yapılan hareketleri eş zamanlı görebiliyor.

Mural bize hazır şablonlar sunuyor. Hatta aklınıza gelen gelmeyen ne kadar farklı kcanvas varsa burada bulabilirsiniz. Çeşit oldukça bol. Brainstorming, icebreaker, scrum etkinlikleri ne yapmak istiyorsanız, liste içinden ihtiyacınıza uygun şablonu seçebilir ve hemen kullanmaya başlayabilirsiniz. Hatta isterseniz kendi şablonunuzu da oluşturabilirsiniz.

FunRetro.io

FunRetro malesef ücretli ama ücretsiz deneme sürümü var. Belki süresi dolana kadar bizim karantina biter. 🙏

Funretro bize defaultta 3–4 farklı retro tekniği sunuyor. (Start Stop Continue, Mad Sad Glad, Star Fish vb) Aslında bu sunduğu teknikler bir şablon gibi. İstersek bunları değiştirip, kendi ihtiyacımız haline getirebiliyoruz. Bu araç ile katılımcılardan geri bildirim alabilir hatta bunları oylamaya sunabiliyoruz. Biraz kurcalamak lazım sadece.

Wheel of Names

Etkinlikleri biraz eğlenceli yapmak için keşfettiğim ve vazgeçemediğim bir web sitesi oldu Wheel of Names. Ramdom olarak katılımcılara belirlediğim soruları sormak için bir tool ararken karşıma çıktı. 😎🎉 Gerçek bir çarktan tek farkı online olması hatta daha iyisi. Çünkü istediğiniz kadar item ekleyebiliyorsunuz.

Hem görsel olarak hem de fonksiyon olarak göze ve ihtiyaca yönelik yardımcı bir tool olarak görüyorum. Animasyonu ve ekstra sunduğu fonksiyonlar oldukça başarılı. Çarkın renklerini, çarkı döndüğünde ve döndükten sonra nasıl davranmasını gerektiğini özelleştirebilmek fasilite ettiğiniz etkinliği daha da kolaylaştırıyor.

Bu toolu kullanarak uyguladığım bir ice breaker’ı da paylamak istiyorum. Ekibinzle de oynayabileceğiniz eğlenceli bir oyun aynı zamanda.

Ice Breaker : Çarklı ve Renkli Sorular | İlkim Dilara Kadakaloğlu

Survey Monkey

Anketlerin olmazsa olmazı Survey Monkey. Sormak istediklerinizi bir anket şeklinde sormak istiyorsanız tercih etmenizi tavsiye ediyorum. Her güzel araçta olduğu gibi SurveyMonkey de ücretli bir hizmet. Ama ufak kısıtlamalarla ücretsiz seçeneği de mevcut. (Anket başına soru sayısı kısıtı gibi)

Anket cevaplarını anonimleştirmek, sonuçları görselleştirmek, verileri Excel’e export edebilmek gibi bir çok alt servisi de mevcut. Türkçe dil desteği de cabası. E daha ne olsun.

Beden Sağlığı

Evden çalışmak, ofiste çalışmaktan daha rahat olduğu kesin. İster koltukta, ister masa başında olalım, pijamalarla rahaat rahaat geçiriyoruz bu karantina günlerini. Fakat bu çalışma zamanını koltuk rahat diye uzun süreli tutmamak lazım. Arada kalkıp ev içinde ufak bir tura çıkmak bacak kol, sırt, bel, boyun, göz kısaca her türlü organı, uzvu biraz rahatlatacaktır. Hatta kısa süreli ufak egzersiz hareketleri çok da güzel olur. 🤸‍♀️ Nasılsa evdeyiz. Evde olmanın avantajlarını kullanalım.

Benim gibi boynunda fıtık ve düzleşme sahibi arkadaşlar için aşağıya minik bir egzersiz hareket serisi bırakıyorum.

Kamu Spotu

Bir Remote Scrum Master olarak arada takım arkadaşlarıma “KAMU SPOTU” geçtiğim doğrudur. ✌ Çalışmaya aşırı odaklandığımızda bu karantina günlerinde yapmamız gereken bazı şeyleri unutabiliriz. Ben de ekip üyelerine bunları hatırlamak istedim. Geçtiğim bazı kamu spotları:

• Camları açmayı, odayı havalandırmayı unutma! 🌍
• Hadi kalk bir ellerini yıka. 🖐
• Boğazınız kurumuştur. En az 2 litre su iç. 🥤🥛☕
• Maske, kolonya vs ihtiyacınız var mı? 😷
• Kendinize dikkat edin. XoXo.

Originally published at http://www.ilkimdilara.com on March 19, 2020.

Remote Scrum Master | Online Facilitation | İlkim Dilara Kadakaloğlu

İlkim Dilara KADAKALOĞLU
d.

Remote Scrum Master was originally published in dtcop on Medium, where people are continuing the conversation by highlighting and responding to this story.

Scrum aksaklıklarına odaklanan Stephan Wolpers’ın “Scrum Anti-Patterns Guide”ı çok sevilince devam edip, rehberdeki diğer Scrum etkinliklerini de tamamlamaya ve yine Scrum Master arkadaşlarımla birlikte bir workshop ile ele almaya karar verdim. Sıra uzun ve meşakkatli bir başlığa, Sprint planlamaya geldi.

Her sprintin başında, sprintin uzunluğuna bağlı olarak maksimum 8 saat sürmesi gereken Sprint planlama, takımın o sprintteki hedefini belirlediği ve bu yönde organize olduğu oldukça önemli bir çalışmadır. Zor soruların sorulması, önceliklerin tartışılması, neyin nasıl yapılacağının konuşulması itibariyle, Product Owner’ı paydaşlara karşı zayıf duran ya da refinement yapma alışkanlığı olmayan takımları çok zorlar. Takımın Product Owner’dan boş zaman talep ettiği, teknik borç ödemesi gerektiğini hatırlattığı ve belki bekleyen bugları da önüne aldığını düşünürsek, gergin bir etkinliğe dönüşmesi ihtimaller dahilindedir.

Sprint planlama 2 ana bölümden oluşur, “What-Ne Yapacağız” ve “How-Nasıl Yapacağız” kısımları. İlk kısımda Product Owner’ın da talep ettiği işlerden hangilerinin Sprint’e alınacağına karar verilir, ikinci kısımda bu işlerin detayına bakılır ve nasıl yapılacağı planlanır. Herkes tarafından bu oyun planının anlaşılması çok önemlidir.

Şimdi “Scrum Anti-Patterns Guide”da hangi sorunlar ele alınmış, workshop kısmına geçmeden önce kısaca bir inceleyelim:

· Kimler tatilde? Takım Sprint Planlama’nın başında izin ve müsaitlik durumlarını toparlayıp, ne kadar iş alabileceğine dair bir fikri olmadan planlamaya başlar. (Herkes ne zaman ne kadar birlikte olacak konuşmadan, işbirliği gerektiren hiçbir şeye girişmeyin.)

· Kapasite aşımı Development takımı kapasitesini yanlış öngörür ve tamamlayabileceğinden daha fazla iş alır. (Burada aslında bile isteye, takımın kendisini zorlamak için fazla iş almasından ayrı olarak, tahminleme hatası anlamında kullanılmış. Diğerine birazdan değineceğiz.)

· Teknik borcu es geçme Development takımı teknik borçla uğraşmak için yeterince zaman talep etmez. (Stephan Wolpers, ideal olarak sprint süresinin %25'inin bug ve teknik borç kapatıcı refaktör işlerine ayrılmasını önermiş. Ancak workshop’umuzda, hali hazırda uzun süredir yaşatılan bir ürünle ilgili çalışıyorsak veya sıklıkla operasyonel iş yapmak zorunda kalıyorsak, genelde bu süreleri ayırmayı ve %15 bug için zamanı sabit tutup, teknik borcu da ayrıca konuşmayı tercih ediyoruz diye yorumlar geldi.)

· Boş zaman bırakmama Development takımının %20 zamanı Product Owner’dan boş zaman olarak talep etmemesi veya etse de alamaması durumu. (Burada Wolpers çok güzel bir noktaya değinmiş, boş zamanı olmayan bireyler kendi işlerine fazlasıyla odaklanır ve takım çabasını, ruhunu es geçerler diyor. Bunun da bir Scrum takımında çok gerekli olan yardımlaşma ve pair programlama konularından uzaklaşmasına, ufak işlere hızlıca yanıt verememesine, dönem dönem bazı bireylerin tıkanıklık nedeni olmasına varan yokuş aşağı bir gidişe neden olduğunu eklemiş. Yürekten katılıyorum.)

· Aşırı detaycılık Sprint planlamanın “How-Nasıl Yapacağız” kısmında, Development takımının her bir alt taskı yazmaya kendini zorlayıp, aşırı detaylı planlamaya çalışması. (İşi çok granülleştirmek yerine, toplamda 2/3 alt taskın şekillenmiş olması bile fazlasıyla yeterli. Daha fazlasını planlamaya çalışmak israf üretmekle sonuçlanabilir.)

· Fazla detaylı süre tahmini Development takımı alt taskların da sürelerini tek tek tahminlemeye çalışır. (Bu biraz planlamış olmak için zorlamaya giriyor. Bir başka fazla granülleştirme eylemi.)

· Yetersiz planlama Sprint planlamanın ilk kısmı olan “Ne Yapacağız”ın tamamlanıp, “Nasıl Yapacağız” kısmının tamamen atlanması.

· Takımın self-organize olmaması Takımın kendi kendine neyi kimin yapacağına karar vermesi yerine, bir “takım lideri” takım üyelerine taskları atar. (Pek çok nedeni olabilir, araştırma gerektirir.)

· Ne için savaşıyoruz? Product Owner bir sprint goal’ü ortaya koyamaz veya koyduğu hatalıdır. (Başarılı bir sprint goal cümlesi “Ne için savaşıyoruz?” sorusunu yanıtlayacaktır. Product Owner ve Development takımı arasındaki el sıkışmayı ifade eder. Odaklı ve ölçülebilirdir.)

· Kanban’a Scrum muamelesi Sprint Backlog rasgele tasklar silsilesi gibidir ve Sprint Goal tanımlanamamıştır. (Eğer bu davranış, Sprint Planlamanızın ilk kısmı olan “Ne Yapıyoruz” un sürekli sonucu haline gelmişse, ürününüzün olgunluğuna da bakarak Scrum çatısının dışına çıktığınıza karar verebilirsiniz ve Kanban takımınız için daha uygun olabilir.)

· Önceki sprintten taşanlar Hiç tartışmadan önceki sprintten gelen tamamlanmamış işleri yeni sprinte almak ve bunu standart bir davranış haline getirmek. (Bu konuyu biz de kendi aramızda uzun uzun konuştuk. Aslında sprint goal’üne çok da etkisi yoksa iş kalabilmesi doğal görünüyor. Bir takımın sürekli %100 iş tamamlaması demek, takım sanki güvenli bölgede kalmış ve hiç fazla iş almaya cesaret edememiş demek olabilir. Bizde de kalan işi sprinte alırken farklı pratikler olduğu, kimi takımın resizing yaptığı bazılarının ise buna zaman harcamadan direkt aldığı workshopta ortaya çıktı.)

· Son dakikacılık “Definition of Ready”e uymayan işleri Product Owner’ın son dakika sprinte sokuşturmaya çalışması. (Prensip olarak, Product Owner’ın takımın her zaman en değerli işi yaptığından emin olması gerektiği için, bu tip değişiklikler kabul edilebilir. Ancak Scrum takımı, düzenli refinement aktivitesi yapıyorsa, bu son dakika değişikliklerinin nadiren olması gerekir. Sık sık yaşanıyorsa, Product Owner’ın önceliklendirme veya takıma bunu aksettirme konusunda desteğe ihtiyacı olabilir. Veya müşterilere hayır demekte zorlanıyor olabilir.)

· Dış mihraklar Product owner takımı gerçekçi bir şekilde alabileceği maddelerden daha fazlasını alması için zorlar. (Nedeni adreslenmelidir ancak muhtemelen Product Owner’ın takımın dışından bir duruma odaklanması nedeniyle bu sorun yaşanmaktadır.)

· Düzensiz sprint uzunluğu Scrum takımının değişken sprint uzunlukları vardır. Örneğin; işler sprint uzunluğuna göre değil sprint uzunluğu işlerin büyüklüğüne göre ayarlanır. (Tatil dönemleri vs gibi durumlardan değil, yılın geri kalanı için bu pratiğin uygulanmasından bahsediliyor. Takımın işleri doğru şekilde bölmek için biraz daha fazla zaman ayırması, bu sorunu ortadan kaldıracaktır.)

· DoR surlarını aşamamak “Definition of Ready”, backlog maddelerinin artık sprint’e alınabilecek kadar anlaşılır hale gelmiş, parçalanmış ve ne yapılacağının kestirilebilir olması amacıyla kullanılır. Takımın bunu dogmatik bir şekilde kullanması ve onay sürecine döndürmesi planlamaları zorlaştırmaya başlıyor. (İlginç bir konu ve biz de kendi aramızda uzun uzun konuştuk. Bir işe ne zaman hazır demeliyiz? Farklı durumlar yaşandığında, örneğin UX tasarımı 2 gün içerisinde hazır olacağı durumda user story’i sprint’e almamalı mıyız? Wolpers’a bu konuda katılıyorum ve takımın kararının esas olması gerektiğini düşünüyorum.)

· DoR yoksaymak Takım işlerin olgunlaşıp olgunlaşmadığına bakmadan sprinte alır. (Bir önceki maddenin tersi bir durumdur. “Definition of Ready” takımın sprint içerisinde hızlı hareket etmesini sağladığı için önemli bir planlama bileşenidir.)

· Planlamaya katılmama Development takımı kolektif olarak sprint planlamaya katılamıyor, takımı temsil eden birkaç kişi bulunuyordur. (Sprint planlama bir takım aktivitesidir ve herkesin sesi duyulmadan konsensus -veya ona en yakın durum — sağlanamayacaktır.)

Yazının başında söz ettiğim ve Scrum Master arkadaşlarla bu maddeleri çalışacağımız workshop kısmı için, değişik bir fasilitasyon tekniği uygulamaya karar verdim, a.k.a. deneysellik :) Elimizde “Scrum Anti-Patterns Guide”ın Sprint Planlama bölümü var, ne yapabiliriz? Tüm workshopu bir takımın Sprint planlaması gibi uygulamak ilginç olabilir gibi duruyor. Sonunda mevzu bir nev’i Planningception’a dönüştü.

Önce yukarıdaki anti-pattern listesi sanki biz bir takımmışız ve bizim backlog’umuzmuş gibi, hızlıca okuyup üzerinde konuştuk. Sonra Product Owner’lık edip takımı yönlendirmek istemediğimden (eh ürün çıkarmıyoruz), istenen konulara odaklanılması için dot-voting ile 4 maddeyi Sprint’imize almaya karar verdik ve “What-Ne Yapacağız?” kısmını böylece tamamladık. Seçilen maddeler, “Yetersiz planlama”, “Son dakikacılık”, “Önceki sprintten taşanlar” ve “Teknik borcu es geçme” oldu.

Ardından bu 4 aksaklığa, user-story muamelesi edip, nasıl çözebileceğimizi post-it’lere yazmaya başladık. Bu sırada da farklı takımlarda neler yaşanıyor, biz benzerini yaşadık mı, yaşadıysak çözebildik mi onları konuştuk. Tüm etkinliğin sonunda, “Madem planlama gibi davrandık, var mı gerçekten burada çıkan aksiyonlara taahhüt eden” dediğimizde 4 faydalı aksiyonda karar kılındı: “Definition of Ready tanımını çalışmak”, “Teknik borç paydaşlara nasıl daha görünür kılınır, araştırmak”, “Kanban bilgimizi artırmak” ve “Slicing çalışmak” ekip olarak Sprint Planlamaları daha iyi yapabilmek için güçlenmek istediğimiz alanlar olarak ortaya çıktı. Hatta bu hafta “Definition of Ready tanımını çalışmak” aksiyonuna taahhüt eden arkadaşım bir etkinlik koşturarak “Definition of Ready” tanımı hakkında uzun uzadıya düşünmemizi sağladı bile :)

Umarım bu rehber aracılığı ile siz de kendi Sprint planlamalarınızı iyileştirebilir ve bu yorucu aktivitedeki sorunları daha etkin şekilde çözebilirsiniz.

Not: Bazen planlamaya atıştırmalık getirmek bile ortamı daha neşeli hale getirebiliyor. Test edildi, onaylandı :)

Stefan Wolpers’ın “Scrum Anti-Patterns Guide”ı için https://age-of-product.com/scrum-anti-patterns/

Sprint Nasıl Planlanmaz? was originally published in dtcop on Medium, where people are continuing the conversation by highlighting and responding to this story.

Retrospective Tekniği : Improve Your Definition Of Done (DOD)

Scrum’ın amacı, potansiyel olarak üretime alınabilecek çıktılar (Increment) üretmektir. Bir incrementin üretim ortamına potansiyel olabilmesi için bitmiş (Done) olması gerekir. Bu yüzden takımlar kendi bitti tanımlarını (Definition Of Done — DOD) oluştururlar. Scrum rituellerinden Sprint Retrospective etkinliği ise takımların bu bitti tanımlarını gözden geçirmesi ve geliştirmesinde en uygun ortamı sağlar. Bu yazıda DOD’nin geliştirilmesine yardımcı olabilecek bir Retrospective Tekniği anlatacağım.

Hazırlık

Bir tahtaya veya flipchart’a iç içe 3 adet dikdörtgen çizin. Dikdörtgenler birbirine yakın olmasın. Aralara postit gelecek.

En içteki dikdörtgene “Mevcut — Now”, ortadakine “Bir Sonraki — Next”, en dıştakine ise “Gelecek — Future” yazın.

Takımdaki herkese yetecek kadar postit ve kalemi hazırlayın.

Nasıl Uygulanır?

Part 1

Ekipteki herkese postit dağıtın.

Ekipten, herşeyi yapabilecekleri bir ortamda olduklarını varsaymasını ve bu ortamda DOD’nin sahip olmasını istedikleri parçaları/maddeleri düşünmesini isteyin. Bu bir beyin fırtınası (Brain Storming) aktivitesidir.

Ekipten, düşündükleri her bir DOD (Definition of Done) parçasını ayrı ayrı popsitlere yazmalarını isteyin.

Bu part için son olarak, postitleri bir duvarda (hazırlamış olduğun dikdötgenlerin yanında da olabilir) toplayın.

Part 2

Ekipten tüm DOD (Definition of Done) parçalarını topladıktan sonra, sıra bu parçaları hazırladığımız dikdörtgen kutucuklara yerleştirmeye geliyor.

3 tane kutumuz vardı.

• Mevcut (Now)
• Bir Sonraki (Next )
• Gelecek (Future)

***Dikdörtgenleri de bu sırada doldurmak gerekir.

Mevcut (Now)

Bu alan ekibin mevcuttaki DOD tanımındaki parçalarla doldurulur. Bu alandaki DOD parçaları, ekibin mevcutta veya bir sonraki Sprintte uygulayacağı DOD parçalarından oluşmalıdır. Bir ekip olarak, bu alandaki DOD parçalarının yapılacağı taahhüt edilmelidir. Ekibin bir sonraki Sprint’te bu tanımdan sorumlu tutulacağını vurgulamak önemlidir.

Bu alan ekibin mevcut uygulamalarını yansıtacağı için örnek olarak şunlar verilebilir: Unit Test, Code Review, UAT vs..

Bir Sonraki — Next

Ekipçe, beyin fırtınasında ortaya çıkan DOD parçalarından, ekibin kısa vadede DOD tanımına alabileceği parçaları bu alana taşıyın.

Ekibin parçaları bu alana taşıması ne zaman yapılacağını planlamak değil, daha çok bir niyet göstergesidir.

Ekibin bu alana taşıdıkları parçaları “Mevcut (Now)” alanına taşıyamamasının bir nedeni vardır. Gerçekleştirebilmek için biraz çalışma, çaba ya da satın alma gerektiriyor olabilir. bu aktivite ile daha görünür bir hale gelecek ve aksiyon almayı da hızlandıracaktır.

Gelecek — Future

Ekibin bu alandaki parçaları DOD (Definition of Done) içerisinde alabilmeleri için önemli miktarda zaman, enerji veya malzeme/çalışan yatırımı gerektirir. “Bir Sonraki (Next)” alanına kıyasla gerçekleştirmenin daha zor olduğu parçalardır. Yine de takımın bunların farkında olması ve görselleştirmesi aksiyon almayı veya durum tespiti yapmayı daha kolay hale getirecektir.

Definition of Done Aksiyon Planı

Definition of Done — DOD kaliteyi arttıran önemli öğelerden biridir. Doğru orantı kuracak olursak; kaliteyi arttırmak için DOD yi geliştirmek doğru bir yol olacaktır. Bu aktivite ile de mevcuttakini görmek ve ileri hedefleri koymak adına bir atmış olursunuz.

Peki aksiyon olarak neler yapılabilir?

💎 Ekip, “Bir Sonraki” ve “Gelecek” alanlarına koyduğu parçaları önceliklendirebilir,

💯 Önceliklendirilen DOD parçaları daha da detaylandırılabilir, daha fazla netlik kazanabilir.

📜 Gerçekleştirmek üzere bir Backlog’ta takip edebilir,

Bunlar gibi birçok aksiyon alınabilir. En iyi ve doğru olanı yine ekip bilecek ve kendisi karar verecektir.

Bu aktiviteyi uygulayıp geri dönüşlerinizi yorum olarak yazabilirsiniz. Farklı tavsiyeleri olanlar da tabii.

Biz Denedik

Originally published at http://www.ilkimdilara.com on February 18, 2020.

Retrospective Tekniği : Improve Your Definition Of Done (DOD)

İlkim Dilara KADAKALOĞLU
d.

Retrospective Tekniği : Improve Your Definition Of Done (DOD) was originally published in dtcop on Medium, where people are continuing the conversation by highlighting and responding to this story.

Etkili kullanıcı hikayesi yazma kılavuzu yazı dizisinin ikinci tekniği DEEP.

Etkili Kullanıcı Hikayesi Yazma Kılavuzu : DEEP Model

DEEP

Bir ürünü geliştirirken elimizde Ürün İş Listesi (Product Backlog) tutarız. Bu liste, ürünün geliştirilmesi gereken tüm özellikleri, işlevleri, gereksinimleri ve düzenlemeleri içerir. Bu listeyi oluşturan her bir öğe INVEST modelde anlattığımız Kullanıcı Hikayeleriyle (User Stories) veya farklı bir şekilde açıklaması yapılmalı, büyüklüğü tahminlenmiş/ölçümlenmiş olmalı, önceliği verilmiş ve değişen şartlara uyum sağlamak amacıyla sürekli güncellenmeli.

Roman Pichler yazdığı “Agile Product Management with Scrum” kitabında, bir ürün iş listesinin kaliteli bir şekilde yazılabilmesini 4 ana başlık altında topluyor. Her bir başlığın baş harfiyle oluşan DEEP modelden bahsediyor.

Detailed Appropriately — Yeteri kadar detaylandırılmış

Bir ürün iş listesinde üstte olan kullanıcı hikayeleri ilk geliştirilecek hikayelerdir. Bu yüzden bu hikayeler, ekibin anlayabilmesi ve büyüklüğünü ölçümleyebilmesi için yeteri kadar detaylandırılmalıdır. Yeteri kadar dememin bir sebebi var. Her şeyin en ince detayına kadar açıklanması değil de geliştirici ekibin ölçümleyebilmesi ve planlayabilmesine imkan sağlayacak kadar detaylandırılmış olması yeterlidir.

Estimeted — Büyüklüğü tahminlenmiş

Ürün iş listesi öğelerinin büyüklükleri (büyüklük, karmaşıklık, risk vs hepsini içerir) geliştirici ekipçe tahmin edilir. Detaylandırılmış maddeler doğruya daha yakın, backlog’un aşağılarına doğru indikçe belirsizlik de artacağı için üste göre daha high level tahminler yapılır. Bu gayet doğal ve olması gerekendir. Ekip daha fazla bilgi edindikçe yeniden tahminleme yapmalıdır.

Tahminleme demişken Story Point ve Planning Poker’den de bahsetmek istiyorum. Kullanıcı hikayelerine verilen en bilindik puanlama birimi Story Point’tir. Adını, User Story’lere tahminleme yapılıp puan verilmesinden almıştır. Planning Poker ise yine en bilindik, ekibin bu puanı verme tekniğidir. Ekipteki herkes aynı anda bir hikayeyi puanlar ve bunu oyunlaştırarak puan kartlarıyla yaparlar. Puanlamalarda genellikle Fibonacci Sayıları tercih edilir. Bunun nedenini farklı bir yazıda bir ara açıklarım. 😊

Emergent — Değişime adapte olabilen

Ürün iş listesi statik değildir. Aksine sürekli değişir, değişmelidir. Proje ilerledikçe, gittikçe daha fazla tecrübe ve bilgi edinilir. Ayrıca çevre şartları, pazar durumu, ekonomi de değişkenlik gösterebilir. Hatta çok uç ve beklenmedik durumlarla bile karşılaşılabilir. (Doların 10₺ olması gibi 😒) Böyle bir dünyada, şartlarda ürün iş listesini sabit tutmak asla doğru bir olmayacaktır. Geleneksel metodlarda (Waterfall Proje Geliştirme) yaşanan ve bir dönüşüme ihtiyaç duyulan en büyük konulardan biridir de bu aynı zamanda. Dolayısıyla ürün iş listesi şartlara uygun olacak şekilde sürekli yenilenmeli, güncellenmeli, düzenlenmelidir.

Prioritized — Önceliklendirilmiş

Ürün iş listesi sürekli güncel tutulmalı dedik. Bunu destekleyen bir diğer şey ise, listedeki maddelerin önceliklerinin verilmiş olmasıdır. Bu yüzden listenin üstündekiler yüksek öncelikli, aşağıdakiler daha düşük öncelikli diyoruz. Ekipler, geliştirilmekte olan ürünün veya sistemin değerinin en üst düzeye çıkarıldığından emin olmak için her zaman yüksek öncelikli maddelere odaklanır ve tamamlar.

Peki öncelik neye göre belirlenmeli?

Cevap basit. Değere (Value) göre.

Buradaki kasıt, hikayede bahsedilen işin geliştirilmesi durumunda son kullanıcıya kattığı yarar, değerdir. Tabii ki beraberinde riskleri ve yapılan yatırımın ne kadarda ve nasıl karşılık bulacağı gibi parametreleri göz önünde bulundurmak da gerekir.

Cost — önceden yapılmazsa, sonradan daha pahalıya mal olabilecek maddeler daha öncelikli olabilir.

Risk — riskli görülen maddeler daha öncelikli olabilir.

ROI (Return of Invest) — geri getirisi yüksek olan maddeler hep önceliklidir.

Originally published at http://www.ilkimdilara.com on January 14, 2020.

Serinin diğer yazıları:

• Etkili Kullanıcı Hikayesi Yazma Kılavuzu | İlkim Dilara Kadakaloğlu
• Etkili Kullanıcı Hikayesi Yazma Kılavuzu : INVEST
• Etkili Kullanıcı Hikayesi Yazma Kılavuzu : DEEP Model
• Etkili Kullanıcı Hikayesi Yazma Kılavuzu : SMART Model
• Etkili Kullanıcı Hikayesi Yazma Kılavuzu : 3C - İlkim Dilara Kadakaloğlu

Etkili Kullanıcı Hikayesi Yazma Kılavuzu : DEEP was originally published in dtcop on Medium, where people are continuing the conversation by highlighting and responding to this story.

Etkili kullanıcı hikayesi yazma kılavuzu yazı dizisinin ilk tekniği INVEST.

Etkili Kullanıcı Hikayesi Yazma Kılavuzu : INVEST

Çevik yazılım projeleri için INVEST model, Bill Wake tarafından kaliteli bir ürün iş listesinin (Product Backlog) olması gereken özelliklerinin bir hatırlatıcısı olarak oluşturulmuştur. INVEST model için ürün listesi maddelerini kullanıcı hikayeleri şeklinde yazmak iyi bir pratiktir ama INVEST için olması zorunlu bir durum değildir. INVEST ile hazırlanmış bu kullanıcı hikayeleri bir Scrum veya Kanban ürün iş listesinde hatta XP projelerinde de kullanılabilir.

INVEST model 6 önemli özelliğe dikkat çeker. INVEST adını da bu özelliklerin baş harflerinden almıştır. INVEST bize etkili bir kullanıcı hikayesinin sahip olması gereken 6 özelliği hatırlatır.

Peki nedir bunlar?

Independent — Bağımsız:

Kullanıcı hikayeleriyle çalışmanın kolay yollarından biri, o hikayenin bağımsız olmasıdır. Hikayeler arasındaki bağımlılıklar önceliklendirme ve planlama problemlerine yol açar. Örneğin müşterinin yüksek öncelik verdiği bir hikaye düşük öncelik verilmiş bir hikayeye bağımlı olursa, hangisini önce yapılacağına karar verilmesi oldukça güç olacaktır.

Bağımlı kullanıcı hikayelerini bağımsız hale getirmenin birkaç yolu var. Bunlardan biri bağımlı olan hikayeleri birleştirmek. Ama bu birleşimden oluşan yeni hikaye çok büyük olmayacaksa tabii. 😊

Eğer bağımlı hikayeleri birleştirmek istemiyorsanız da bu sefer farklı bakış açılarıyla yeni hikayeler yazmak gerekir.

Negotiable veya Negotiated — Tartışılabilir

Kullanıcı hikayeleri, detayları ve kabul kriterleri müşteri ve geliştirme ekipleri arasındaki bir görüşmede tartışılacak ve karar verilecek olan kısa tanımlardır. Bu yüzden bir kullanıcı hikayesi üzerinde tartışılabilir olmalıdır. Hikayeler yazılı sözleşmeler gibi kati ve değişmez değildir.

Kullanıcı hikayeleri, tamamen ayrıntılı olmasında ziyade, üzerinde tartışmak için hatırlatıcı olduklarından tüm detayı içermemelidir. Ancak hikaye yazıldığı zaman önemli detaylar biliniyorsa bu bilgiler hikayeye ek açıklama olarak yazılabilir.

Özetle, kullanıcı hikayeleri geliştirilecek ürün parçası için bize yol gösteren kısa bir bilgilerdir. Üzerinde tartıştıkça (hatta belki geliştirme sırasında) detaylandırılabilir. Değişmez olmamalı, aksine değişme adapte olmalıdır.

Valuable — Değerli

“Kullanıcı hikayeleri değer üretmeli” demek tek başına yeterli olmuyor maalesef. Çünkü değer dediğimiz şey ürünü geliştiren ile ürünü kullanan kişi arasında farklılık gösterebiliyor. Teknik olarak değerli görünen bir şey, son kullanıcı için hiçbir değer üretmiyor olabilir. Bu yüzden kullanıcı hikayeleri bir değer üretmeli derken, o ürünü kullanacak son kullanıcılar için bir değer üretmeli olarak algılamak daha doğru olacaktır.

Bir kullanıcı hikayesinin müşteri ve kullanıcılar için değerli olmasını sağlamanın en iyi yolu ise hikayeyi onların yazmasını sağlamaktır.

Ufak bir uyarı
Hikayeleri son kullanıcıların yazması başta zor olacaktır. Hatta en çok karşılaşılan durum; kullanıcıdan gelen hikayeyi geliştirici ekibin değişmez görmesidir. “Gelen hikaye kapsamında bunlar yoktu …” gibi söylemlerle karşılaşılabilir. Burada bir kullanıcı hikayesinin “Negotiable” olduğu unutulmamalı, geliştirici ekip ve son kullanıcılar iş birliği ile o hikayeyi detaylandırmalı, varsa değişiklikler değerlendirilmelidir.

Estimable — Tahminlenebilir

Geliştirme ekibinin bir hikayenin büyüklüğünü veya geliştirmek için harcanacak süreyi tahmin edebilmeleri oldukça önemlidir. Bu bilgiye göre planlamalar yapılmaktadır. Bu yüzden de bir kullanıcı hikayesinin olması gereken özelliklerden biri tahmin edilebilir olmasıdır.

Bir hikayenin tahmin edilemez olmasının 3 genel nedeni vardır:

• Geliştiricilerin domain bilgisine sahip olmaması
• Geliştiricilerin teknik olarak yetersiz olması
• Hikayenin çok büyük olması

Eğer ki geliştirici ekip, hikayeyi anlamıyor veya yeterli domain bilgisine sahip değilse, hikayeyi yazan müşteri/kullanıcı ile detaylandırabilmek için üzerinde konuşmalı ve tartışmalıdır. Tahmin edilebilir olması için geliştirici ekibin hikayeyi genel olarak anlaması gerekir. ( En ince detaylarına girmeğe gerek yoktur)

Geliştiriciler hikayeyi geliştirmek için gerekli teknik bilgiye sahip değilse “Spike” dediğimiz öncü çalışma aktivitesini yapmak gerekir. Bu teknik yetersizliği ortadan kaldıracak çalışmalar, eğitimler vs ayrı bir hikaye olarak değerlendirilebilir. Böylece geliştirici ekip, asıl hikayeyi tahmin edebilecek kadar teknik yeterliliği arttırmış olur.

Spike
Kapsam belirleme, analiz, araştırma, gereksinimler, toplantı, gelişim süreci gibi aktiviteler için kullanılır. Spike olarak işaretlenmiş işlerin size’ları çoğu zaman düşün hatta bazen 0 (Sıfır) bile olabilir. Çünkü bir iterasyonda zaten yapılması gereken işler olduğu için bunlar değerli bir çıktı sağlayacak çalışmalar değildir. Sadece o çıktıya giden yolda bizi geliştirecek işlerdir.

Eğer ki hikaye tahminlemek için çok büyükse, bu sefer yapılacak iş daha basit. 😊Hikayeyi daha küçük öykülere ayırmak çoğu zaman doğru bir yöntemdir.

Small — Küçük

Bir kullanıcı hikayesinin büyüklüğü, planlama ve tahminleme yapabilmek için önemli bir parametredir. Bu yüzden bir kullanıcı hikayesi, bir iterasyon içinde tamamlanabilecek kadar küçük olmalıdır.

Ürün iş listesinde büyük hikayelere “Epic” denir. Planlama ve tahminlemelerin Epic’ler üzerinden yapmak doğru sonuçlar vermeyebilir. Bu yüzden Epic’leri kullanıcı hikayelerine bölmek gerekir. Sonrasında bu küçük hikayeler üzerinden tahminleme ve planlama yapmak daha doğru olacaktır.

Testable — Test edilebilir

Bir kullanıcı hikayesi test edilebilir şekilde yazılmalıdır. Bunu birçok sebebi var tabii ki. İlk akla gelen nedenlerden biri geliştiricinin neyi geliştireceğine ve hangi kurallara göre geliştirmesine yol göstermesidir. Ayrıca, testlerin başarılı geçmesi, hikayenin başarıyla geliştirildiğinin kanıtıdır aynı zamanda.

Bir hikayenin test edilebilir özelliğine en büyük katkıyı o hikayenin Kabul Kriterleri (Acceptance Criteria) sağlar. Kabul kriterleri, bir hikayenin geliştirilmesi sonucu olması istenenler ve beklenenler listesidir. Bir geliştirme eğer kabul kriterlerini sağlamıyorsa testlerden de geçmediğini ve dolayısı ile kullanıcı hikayesinin başarılı yazılmadığını gösterir. Kısaca kullanıcı hikayelerinde kabul kriterleri, test aktivitelerinde doğrudan etkilidir.

Herkes bir hikayenin tamamlanmasının nasıl doğrulanacağını anlamalı ve kabul etmelidir. Bunu yapmanın bir diğer yolu da Bitti Tanımı (Definition of DONE) oluşturmaktır. Bu tanım bir hikayenin hangi aşamalardan geçmesi gerektiğini belirtir. Test aktivitesi de bu tanım içinde olmazsa olmazdan tabii. 😊

Önemli olarak gördüğüm bir diğer konu ise testlerin mümkün olduğunca otomatikleştirilmesi. Projenin başlarında test aktiviteleri kolay olabilir. Proje adım adım geliştikçe kontrol edilmesi gerekenler de bir o kadar artacaktır. Dün çalışan kodun bugün çalışmaması durumuyla karşı karşıya kalabiliriz. Sorunu mümkün olan en kısa sürede bulabilecek otomatik testler, daha kaliteli ürünler çıkarmaya ve daha kısa sürede teslim etmeye katkı sağlayacaktır. 👏

İlkim Dilara KADAKALOĞLU
d.

Originally published at http://www.ilkimdilara.com on December 27, 2019.

Serinin diğer yazıları:

• Etkili Kullanıcı Hikayesi Yazma Kılavuzu : INVEST
• Etkili Kullanıcı Hikayesi Yazma Kılavuzu | İlkim Dilara Kadakaloğlu
• Etkili Kullanıcı Hikayesi Yazma Kılavuzu : DEEP Model
• Etkili Kullanıcı Hikayesi Yazma Kılavuzu : SMART Model
• Etkili Kullanıcı Hikayesi Yazma Kılavuzu : 3C - İlkim Dilara Kadakaloğlu

Efektif Kullanıcı Hikayesi Yazma Kılavuzu : INVEST was originally published in dtcop on Medium, where people are continuing the conversation by highlighting and responding to this story.

Etkili Kullanıcı Hikayesi Yazma Kılavuzu

Etkili Kullanıcı Hikayesi Yazma Kılavuzu | İlkim Dilara Kadakaloğlu

Kullanıcı Hikayesi (User Story), çevik ekiplerde kullanılan en iyi pratiklerdendir. Genellikle son kullanıcı veya bir sistem kullanıcısı bakış açısıyla yazılır. Başka bir deyişle, bir kullanıcı hikayesi kullanıcının türünü, ne istediğini ve nedenini açıklar. Bir gereksinimin basitleştirilmiş bir tanımını oluşturmaya yardımcı olur. Projeye bağlı olarak, kullanıcı hikayeleri müşteriler, kullanıcılar, yöneticiler veya geliştirme ekibi üyeleri dahil olmak üzere çeşitli paydaşlar tarafından yazılabilir.

Bu yazı serisinde etkili bir kullanıcı hikayesi yazmak için bize yol gösterecek, yardım edecek tekniklerden bahsedeceğim. Eğer bir kılavuza ihtiyaç duyuyorsanız doğru yerdesiniz. 🎉

Ama öncesinde biraz kullanıcı hikayesi nedir kısmına girelim. 👇

Kullanıcı Hikayesi Şablonu: Rol — Aksiyon — Yarar

Kullanıcı hikayeleri için bir gereksinimin temel unsurları olan rol, aksiyon ve yarar çerçevesinde yazılan basit bir şablonu vardır.

Rol:

Kullanıcı hikayelerinde rol, sistem ile etkileşime giren gerçek bir insan olmalı ve mümkün olduğunca spesifik tanımlanmalıdır. Fakat Geliştirme Ekibi (Development Team) bir kullanıcı değildir.

Aksiyon:

Kullanıcı hikayelerinde aksiyon, sistemin davranışı olmalıdır. Hikaye yazılırken “sistem” kelimesi yazılmamalı, hikayede aksiyon zaten sistemin davranışı olduğu bilinmelidir. Aksiyonlar olumsuz değil olumlu kelimeler seçilerek belirtilmelidir.
“…. olarak, haber verebilmeliyim. ” ✔
“… olarak, haber verememeliyim.” ❌

Fayda:

Kullanıcı hikayelerinde fayda, aksiyon sonucu sağlanmış olan avantajlardır. Birçok hikaye aynı faydadan yararlanabilir. Hikayedeki fayda sadece hikayede geçen rol için değil, diğer kullanıcılar veya müşteriler için de olabilir.

Önemli Notlar: Kullanıcı hikayeleri günlük bir dilde ve herkesin aynı şeyi anlayacağı şekilde yazılmalıdır. Belirli bir amacı (What — Action — Ne ) bireyin (Who — Role — Rol) perspektifinden, istediği nedeni (Why — Benefit — Fayda) ile birlikte tanımlanmalıdır.

Kullanıcı hikayesi şablonu bize, onu nasıl yazacağımız ile ilgili bir yol çiziyor kuşkusuz. Ama etkili bir şekilde hikaye yazabilmek için farklı yardımcılara ihtiyacımız olduğu aşikar. Herkesin o kullanıcı hikayesinden aynı şeyi anlaması, geliştirici ekibin doğru tahminleme (Estimation — Sizing) ve planlama yapabilmeleri için bir hikayenin olmazsa olması olan kabul kriterlerini doğru ve anlaşılır bir şekilde yazılmış olması gerekir.
Tam bu noktada bize yardımcı olan birkaç teknik var. Sizlere bunlardan bahsediyor olacağım. Bunlar;
• INVEST
• DEEP
• SMART
• 3C

O zaman bize kılavuz olacak bu yazı dizini başlatıyorum…

Yeyyy 🎉🎉🎉

İlkim Dilara KADAKALOĞLU
d.

Originally published at http://www.ilkimdilara.com on December 27, 2019.

Etkili Kullanıcı Hikayesi Yazma Kılavuzu | İlkim Dilara Kadakaloğlu

Efektif Kullanıcı Hikayesi Yazma Kılavuzu was originally published in dtcop on Medium, where people are continuing the conversation by highlighting and responding to this story.

Scrum Framework’ünün can damarlarından biri Daily Scrum etkinliğidir. Takımın her gün aynı yer ve saatte yaptığı bu 15 dakikalık buluşma, işbirliğini artırma, sorunları çözme ve hızlı karar verme amacıyla kullanılır ve Sprint Goal’üne giden yolda olup olmadığımızı anlamamızı sağlar.

Peki bu değerli ve kısa etkinliğin neden hakkını veremiyoruz? Hakkını veremedikçe neden kaçamak yapmaya başlıyoruz? Bu sorunla ilgili pek çok farklı gerekçe bulabilir, kendimizce çözümler geliştirip takımlarımızla paylaşabiliriz. Peki bunu elimizdeki araçlarla nasıl yaparız?

İlk Scrum tecrübemden beri, kısa sürse de çok farklı dinamikleri olan ve takımın enerjisini tartmak için müthiş bir olanak sağlayan Daily Scrum hep en ilginç bulduğum aktivite olmuştur :) Verimli kullanıldığı zaman takımı hedefe muhteşem oryante ederken, kötü geçtiğinde takım üyelerinin birbirine bıçak çekmesine yol açacak bir enerji barındırır içerisinde. Her sprintte defalarca tekrarlanacak bir etkinlik olduğunu da düşünürsek, fayda sağlanmadığı durumda takımın ilk sıkıldığı ve düşürmeye çalıştığı etkinliğe dönüşür. Bu nedenle bir süredir Scrum Master arkadaşlarımla bu farkındalığı yaratmak amacıyla bir çalışma yapmak istiyordum.

Stephan Wolpers’ın “Scrum Anti-Patterns Guide” keyifle okuduğum ve oldukça faydalandığım bir kaynak. Scrum’daki rol, etkinlik ve kurallara dair anti-patternleri çok güzel bir araya getirmiş. İçerisindeki bir bölüm de“Daily Scrum Anti-Patterns” ve Daily Scrum’da en sık rastlanan 20 kanayan yara ele alınıyor.

Bunları detayına çok girmeden aşağıda sıralamak istedim; açıklamaları rehber içerisinde mevcut:

1. Rutinsizlik: Her gün aynı yer ve saatte olması gerekirken, bir türlü oturmayan Daily Scrum. Her gün yapılan bir toplantı için sürekli değişkenliğin getireceği karmaşayı tahmin edersiniz.
2. Statü toplantısı: Scrum Master, Product Owner hatta Stakeholder’a statü raporlayıp kaçma.
3. Gerekli detaya girmeme: Kimseye bir değer katmayan, anlamsız durum bilgilendirmeleri. “Dün X-123 hakkında çalıştım, bugün X-129'a bakacağım.” gibi…
4. Probleme dalma: Park edip Daily Scrum sonunda konuşmak yerine, problemleri çözmeye başlama.
5. Planlama toplantısı: Yeni talepleri konuşma, user story’leri kırma ile başlayıp sprint planlamaya giden bir yelpaze.
6. Oryantasyon kaybı: Asıl amacı Sprint Goal’üne giden yolda mıyız? olan bu toplantının amacını yitirmesi.
7. Work-item ömrünü umursamama: Bir sorunda takılan Dev Team üyesinin bu durumunu görmezden gelme, yardım teklif etmeme.
8. Sazı eline alma: Takımdan birisinin tek başına uzun uzun konuşarak Daily Scrum’ı sabote etmesi.
9. Statler ve Waldorf: Muppet Show’da balkondaki 2 yaşlı amca oluyorlar. Neden bu listede olduklarını tahmin ettiniz sanırım :) Her konuda yorumu olan takım üyeleri için kullanılmış.
10. Konuşana saygısızlık: Yazmaya gerek var mıydı...
11. Atama yapma: Product Owner ya da Scrum Master’ın atama yapmaya başlaması.
12. Hiçbir fikri olmayanlar: Daily Scrum’a hazır gelmeyen takım üyeleri.
13. Hadi güne başlayalım!: Güne başlamak için Daily Scrum’ı beklemek.
14. Gecikenler ya da gelmeyenler: Bir başka saygı eksikliği olarak Daily Scrum’dan kaçış.
15. Aşırı geri-bildirim: Yeri olmadığı halde Daily Scrum’da eleştiriye girmek.
16. Metrobüs: Kalabalık takımları tanımlamak için çeviriye biraz aroma kattım :) Böyle takımların Daily Scrum’dan fayda alamadıklarına çok şahit oluyoruz.
17. Konuşkan “tavuklar”: Rehberde Daily Scrum’da konuşmaması gereken kişilerin konuşup katılım göstermesi olarak anlatılmış, örn Stakeholderlar.
18. Yönetimin komuta kontrolü: Yöneticilerin Daily Scrum’a katılıp takım üyelerinin performanslarını gözlemlemesi.
19. “Bi gelebilir misin?”: Yöneticilerin Daily Scrum biter bitmez, bazı takım üyelerinden rapor istemesi.
20. Ek iş: Daily Scrum’da Sprint Goal’üne hizmet etmeyen ek iş taleplerinin Sprint’e alınmaya çalışılması.

Bu maddeleri şirketimizdeki Scrum Master arkadaşlarımla paylaşmak ve mümkünse bir tartışma ortamı yaratmak için, haftalık CoP etkinliğimiz uygun bir ortam sağlayacaktı. İşi bir metin dağıtıp “hadi herkes okusun”dan çıkarmak için de, oyunlaştırmayı tercih ettim. Bunları nasıl inceleyebilir, gruplayabiliriz diye düşünürken; bir takımı takım yapan elementler yani Scrum değerleri aklıma geldi.

Her takım sorununun kök nedenine bakarsak aslında bir veya birkaç Scrum değeri ihlalini görebiliriz. Bu farkındalığa sahip bir Scrum Master, çalışmayan değere odaklanırsa; yolunu çok daha net görebilir. Bu nedenle workshop başlarken, 20 anti-pattern listesini Scrum Master arkadaşlarıma dağıttım. Ardından her birini tek tek okuyup, tahtada gördükleri Scrum değerlerinin hangisinde problem yaşandığını düşündüklerini sordum. Herkesin bir oy hakkı olduğu için, en büyük problem gördüklerine odaklanmaları gerekecekti. 2 veya 3.maddeden sonra herkes ısınınca, iknalar ve tartışmalar başladı, ki hedeflediğim kısmı da buydu. Yaklaşık 1,5 saat boyunca kopmadan, dağılmadan herkes sorunlara kafa yorup, nedenlerini düşündü ve tartıştı.

Bir sorunu belli bir çatıya oturtmaya çalıştığınızda işiniz oldukça kolaylaşıyor. Kucağınıza düşen bir probleme nereden yaklaşacağınızı anlamak sizi çözüme çok yaklaştırıyor. Bu çalışmanın Scrum Master arkadaşlarıma Scrum değerlerinin güzel bir enstruman olduğunu hatırlatmanın yanında, bize 20 anti-pattern’i tartışırken içselleştirdiğini ve görür görmez yakalayabilecek duruma getirdiğini de düşünüyorum. Scrum Master’ların sorunlara farklı yaklaşımlarını, bazen rutine binen dertleşme formatından çıkarıp konuşabilmek de günün bir başka artısı oldu.

Stefan Wolpers’ın “Scrum Anti-Patterns Guide”ı için https://age-of-product.com/scrum-anti-patterns/

Daily Scrum Nasıl Yapılmaz? was originally published in dtcop on Medium, where people are continuing the conversation by highlighting and responding to this story.

Liberating Structures Nedir? - İlkim Dilara Kadakaloğlu

Liberating Structures, toplantıları ve konuşmaları kolaylaştırmak için Henri Lipmanowicz ve Keith McCandless tarafından önerilen bir uygulama listesidir. İnsanların birlikte nasıl çalışabildiklerini bulmaları ve tasarlamaları için sunulan 33 farklı alternatifili bir listedir. Bu alternatifli yaklaşım hem pratik hem de uygulanması kolaydır. Her seviye çalışan için (Executive seviyesi de dahil) kullanılabilir. Uzun eğitimler veya özel yetenekler gerekmez. Ustalık sadece uygulamaktan geçer. 💪

Liberating Structures, herkesin fasilite edebileceği bir yapıdadır. Bu yüzden de dedike bir fasilitor gerektirmez. Liberating Structures nasıl uygulanacağına dair talimatların tamamı sitesinde ve kitabında yazmaktadır. Web sitesinde, LS menu altında tüm aktiviteler listelenmiş ve açıklanmıştır.

Peki Liberating Structures’i öne çıkaran değer nedir?

Organizasyonlarda ve/ya gruplarda varsayılan olarak kabul edilmiş 5 geleneksel mikro yapı vardır:

• Sunumlar (Presentations)
• Durum Raporu (Status Report)
• Açık Tartışmalar (Open Discussions)
• Yönetilen/Kontrol altına alınan tartışmalar (Managed Discussions)
• Beyin Fırtınaları (Brainstorms)

Bunlardan bazıları ya çok kısıtlayıcı (sunumlar, yönetilen tartışmalar, durum raporları) ya da ucu çok açık (açık tartışmalar ve beyin fırtınası) yapıdadır. Kısıtlayıcı olması, fikirlerin açığa çıkmamasına; ucu açık olması da odağı kaybetmeye yol açar.

Liberating Structures ise, dağılmış bir kontrolü benimseyip, sonraki adımları şekillendirmek için daha adil ve daha fazla sayıda insanı içerecek şekilde tasarlanmıştır. Sağladığı faydaları ise; daha yenilikçi bir yaklaşım (Innovation), yüksek katılım, şeffaf bir ortam, bir amaç için odaklanmak, eğlenmek vb. sıralayabiliriz. Tabii ki deneyimledikçe daha da net anlaşılacaktır.

Liberating Structures Menü

Aşağıdaki menü, LS’in 2.2 versiyonunu göstermektedir. Eğer LS konusuda yeniyseniz, basit olanlardan başlamak tavsiye ediliyor. — Her konuda olduğu gibi. 😎

Bu tablo şeklindeki LS menü, sol sütten başlayıp sağ alta doğru daha karmaşık olacak şekilde sıralanmıştır. Dolayısı ile yeni başlayanlar için önerilenler, 1–2–4-All ve/ya Impromptu Networking olur genelde. Daha karmaşık yöntemler de çoğunluklar bu basit yapıdaki yöntemleri yapı taşı olarak kabul eder ve onlar üstüne kuruludur.

Tüm Liberating Structures uygulamaları aynı formatta tanımlanmıştır.

• Bir simge ve isim ile temel özelliklerini ifade eden kısa bir etiket.
• Neyin mümkün olduğu — Bu LS uygulanarak neyi başarabileceğinizi açıklayan bir paragraf
• Neden ve amaç — Bu LS’i kullanmaya teşvik edebilecek amaçlar
• İpuçları — Bu LS uygulandığında daha fazla değer alma şansını arttıracak tavsiyeler ve yapılmaması gerekenler
• Alternatifler ve çeşitlendirmeler — başka LS’leri denemek veya hayal etmek için alternatifler ve eklemeler
• Örnekler — gerçek uygulama örnekleri
• Yardımcı materyaller — LS’i uygulamak için gerekli olan ve/ya ek destek sağlayabilecek görseller, slaytlar, videolar vb.

Tüm bu maddeler her LS için tanımlanmıştır. Resmi web sitesinden LS Menu altında tüm LS uygulamalarının detaylarını görebilir ve her bir LS için tüm maddelerin içeriğini inceleyebilirsiniz.

Hangi LS Uygulamasını Kullanmalıyım?

Liberating Structure resmi internet sayfası oldukça kullanışlı bir şekilde tasarlanmış. LS menü sayesinde tüm uygulamalarına kolayca ulaşabiliyorsunuz. Her uygulamanın kendine ait bir sayfası ve oldukça detaylı açıklamaları olduğu için anlamayı da kolaylaştırıyor. Bir de hayatı mobilde yaşayanlar için mobil uygulaması da mevcut. Hem iOS hem Androidişletim sistemi mağazalarından bu uygulamayı indirebilirsiniz.

LS uygulamalarını öğrenmenin en kolay yolu onu deneyimlemekten geçer. Pratik yapmak, hem daha iyi anlamamızı hem sağladığı faydaları farketmemizi hem de üzeride kendi yorumumuzu ekleyerek geliştirmemizi sağlar.

LS uygulamalarına nereden başlayacağımız, ihtiyacımızın ne olduğu ile ilgilidir. İhtiyacımıza ve/ya yapmak istediğimiz amaca hizmet edecek olan LS uygulamasını seçebilmek için 2 farklı yöntem izleyebiliriz.

1. LS Selection Matchmaker
2. Matching Matrix

LS Selection Matchmaker

LS Selection Matchmaker, klasik bir eşleştirme tekniğidir. LS menüdeki uygulamalar ile o uygulamaların çözdüğü problemler eşleştirilmiştir. Doğru uygulamayaı seçmek için doğru bir problem/ihtiyaç analizi yapmak yeterli olacaktır. Problemi veya ihtiyaç duyulan şeyi bulduğumuzda, kullanmamız gereken doğru LS uygulamasını da bu yöntem ile bulmuş olacağız.

Nasıl mı?

• Öncelikle yaşadığınız zorluk, ortaya çıkarmak istediğiniz problem ve/ya çözüm üretmek istediğiniz durum hakkında düşünün ve bununla birkaç cümle yazın.
• LS Selection Matchmaker’ın bize sunduğu PDF (LS Selection Matchmaker v9) üzerindeki kutucuklardaki yazıları, sizin yazdığınız cümleler ile karşılaştırın. Ulaşmak istediğiniz her hedefin yanına bir işaret koyun (yuvarlak içine de alabilirsiniz)
• İşaretlediğiniz hedefleri kendi içlerinde mantıksal bir dizi oluşturacak şekilde gruplayın. Bu sıralamayı başlangıç, orta, son uygulama olacak şekilde tasarlayın.
• Kritik olmayan hedefleri daha sonra yapılmak üzere listenizden kaldırın.
• Elinizde 3 ila 7 hedef arasında bir dizi varsa, tebrikler ilk LS uygulama serisini elde ettiniz. 👏🎉
• Çeşitliliği arttırmak için daha kısa, uzun seriler oluşturabilirsiniz.
• Oluşturduğunuz serileri başkalarıyla paylaşın karşılaştırın, değiştirin, sizin için en mantıklı olanı bulana kadar devam edebilirsiniz. 💪
• Seçtiğiniz hedef kutucuklarını, hangi uygulamalar ile eşleştiğini bulun. Bundan sonra artık planlamaya başlayabilirsiniz. (İlgili LS uygulamasının zaman planlaması ve hazırlık çalışmaları)

Matching Matrix

Hangi LS uygulamasını seçmemiz konusunda bize yardımcı olabilecek bir diğer yöntem ise Matching Matrix’dir. Bu yöntem de bir eşleştirme yöntemidir. Bu matris ile, uygulamayı kullanacak grupların hedef ve amaçları göz önünde bulundurularak, her bir LS uygulamasının güçlü yönleri ortaya çıkarılmıştır. Karar verme sürecinde de bu güçlü yönler etkili olacaktır.

LS uygulamaları 5 ana grupta incelenmiştir. Bunlar;

• Discovering everyday solutions — problem çözme, koordinasyon, düzenli etkileşimler/toplantılar
• Noticing patterns together — değişiklikleri anlamak/açıklamak, değişiklikleri anlamak için yollar aramak
• Unleashing local action — her bir bireyin aksiyon alması
• Drawing out prototypes — hızlıca küçük parçalar geliştirmek, daha sonra birleştirilebilecek parçalar üretmek
• Spreading innovation — fikirlerin, hizmetlerin, servislerin yayılması ve daha üst seviyelere çıkarılması

LS uygulamalarını alt alta yazıp, yanlarına bu 5 ana grubu kolon haline getirdiğimizde Matching Matrix’i oluşturmuş oluyoruz. Aşağıdaki matriste de hangi LS uygulamasının hangi ana grupta iyi olduğu ✔(tick) ile belirtilmiştir.

Siz de bu güçlü yanlara göre ihtiyacınıza hangisi hizmet ediyorsa o LS uygulamasını deneyebilirsiniz.

İlkim Dilara KADAKALOĞLU
d.

Originally published at http://www.ilkimdilara.com on October 10, 2019.

Liberating Structures Nedir? - İlkim Dilara Kadakaloğlu

Liberating Structures Nedir? was originally published in dtcop on Medium, where people are continuing the conversation by highlighting and responding to this story.