Bimar Arkas Blog Sayfaları: SCRUM WORKSHOP ÇALIŞMA NOTLARIM

Manifesto for Agile Software Development

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

Pozitif Kaygılarımız

 Backlog'um değerli mi? (Maddelerim net ve önceliklendirilmiş, iş sahipleri için değer taşıyor)

 Backlog'umu tüketebiliyor muyum? (maddelerim bitiyor mu?)

 Ekip mutlu mu?

Scrum Framepwork Guide PDF

http://www.scrumguides.org/download.html

Product Owner (PO)

O ürünün değerinden sorumludur.

Müşteriye karşı sorumludur.

"Delivery Date" den sorumludur.

Developer %10 zamanını PO ya ayırır.

Bu sürede "backlog grooming" yani PBI ların içlerinin zenginleştirilmesi, son haline getirilmesi aktivitesi gerçekleştirilir.

Product Backlog unu yeni sprintler için hazır tutar.

Teknik borç azaltmaya yönelik altyapı - kaliteye yönelik maddeler iş değeri açısından PO ya iyi anlatılmalı ve bir PBI olarak sprint içine alınmalıdır.

SCRUM Master (SM)

SM = Agile Coach olarak da ifade edilebilir.

SCRUM konusunda ustadır. Yarım zamanlı bir iştir.

Ekip zamanla scrum'a alıştıkça ve ustalaştıkça SM ye ihtiyaç duymayacak bir konuma gelebilir.

Ekip üyelerinin mevcut işlerinde kesintiye uğramadan çalışmasını sağlamalıdır.

Takımın motivasyonunu devamlı yüksek tutmalıdır.

Takımın sprinti koşmasında, hedefe varmasını engelleyecek her türlü sorunun ortadan kaldırılmasından sorumludur.

Takımın refahını sağlar.

➡ Süreçler üzerinde yeni şeyler deneyelim. En fazla 1 veya 2 sprint kaybederiz.

Waterfallà İnşaat ve Askeriye de geçerli olabilir. Vasıfsız isçiler eliyle yapılan işler içerir.
Scrumà Inovasyon ve sanat içeren yazılım sektörü için uygundur.
Proje ekibi: Eğitimli, sosyal beklentisi olan, başarılı olmaya odaklı, potansiyelinin engellenmemesi gereken bir topluluktur.

 Değişiklikleri ne kadar çabuk kabul eder ve benimsersek o kadar çabuk değer üretiriz.

 PLANLAR TAŞA YAZILMAZ.
 PLANA TAPILMAZ.

⚠ Hata yapıldığında utanç duyulan bir sistem yaratmamak gerekir.

USER STORY
àDEFINITION OF READY
Madde yazıldı. Analizi, iş değeri belirlendi. Talebe başlamak için beklenen bir şey yok. Ekip arkadaşıma ve PO ya sorup devam edebileceğim derinlik yeterlidir.
à DEFINITON OF DONE
Build, Test, Reviev, Otomatik Testler, Sonar, Güvenlik à DONE

BU TANIMLAR MUTLAKA YAPILMALI. TÜM PAYDAŞLAR BU TANIMDA EL SIKIŞMALI VE BU TANIM GÜNCEL TUTULMALIDIR.

Theory of Constraints 3 Bottle Demo to Improve Flow
https://www.youtube.com/watch?v=PMiTVUDiNQ4

SCRUM SERENOMİLERİ

SABAH TOPLANTILARI: àFOCUS ON SPRINT GOAL
Toplantıdan önce ekip üyelerinin maddelerinin son halini TFS de güncellenmesi güzel bir pratiktir. Kalan iş BURNDOWN chart'ın güncel olmasını sağlar.
Hedefe koşarken önümüzdeki engeller nelerdir. Nasıl kaldırırız? Bunlar konuşulmalıdır.
Scrum Master (SM'ye) bu konuda en az 1 madde çıkması lazım.
Sen bu işle uğraşırsan sprint yetişmez. Buna bakalım.
Önemli olan sprintin yetişmesi önündeki engellerin kaldırılmasıdır. Sprint'e koşan faaliyetler konuşulur.
"Sprint için ne yaptım, ne yapacağım, kime bu yolda destek oldum" konuşulur.
Uzayan konu daha sonra ilgililerin kendi arasında halletmesi için kesilir. Sonra onlar devam edebilir.
Sabah toplantıları 15 dakikayı kesinlikle geçmemelidir.

Bir nedenden dolayı beklemeye geçen kişiler, kendi gündeminden veya düşük öncelikli bir işle değil, MEVCUT SPRINT PLANINA dahil bir iş ile uğraşmalıdır. Aksi halde sprint hedefi tutmaz.

SPRINT PLANLAMA TOPLANTISI
Hafta başına 2 saat planlama faaliyeti olmalıdır. Backlog'dan sıradan başlanarak o sprinte alınacak maddeler seçilir.

RETROSPECTIVE TOPLANTISI
PO bulunmaz.
SM ye bir KAIZEN çıkarmalıdır. Bu KAIZEN sonucu yapılacak değişiklik bir sonraki sprinte PBI olarak yansıtılabilir. SM bunu en tepeye koyabilir.
Daha sonra işe yaradı mı yaramadı mı değerlendirilir.
Devreye alımdan sonra değişikliklerin etkisi ne oldu? Hata üretiyor muyuz? Bir sonraki sprinte neleri daha iyi yapabiliriz.
Bu toplantıları stressiz bir ortamda belki yemek söyleyerek, iyileştirme amaçlı yapmak lazım. Ekip kendi içinde rahatça öz eleştiri yapabilmelidir.

SPRINT PERFORMANSI?
Velocity (ekibin planladığı sprintte çıkacak maddelerin iş değeri toplamı) değerinin artırılması performans hedefi olarak verilirse kalite düşebilir. Bununla birlikte ekip tahminleme çalışmasında otomatik olarak maddelere yüksek velocity değerleri verme eğilimine girebilir. Sonuçta çıkan iş aynı olacaktır ama velocity istatistiği bozulmuş olacak. Yani bu işe yaramaz. Önemli olan verimliği düşüren tüm engellerin kaldırılmasıdır.
Önceki sprintte tüm çalışmaya rağmen tamamlanamayan bir USER STORY varsa, ekip planladığı kadarını bir nedenden yapamadıysa, yeni sprintte yapabileceğimiz kadar alalım. Başarılı spirintten sonra bir sonrakinde yapabileceğimiz kadar tekrar planlarız. Yapamayacağımızı bile bile fazla madde planlamanın hiçbir anlamı yoktur. Önemli olan ortadan engelleri kaldırarak, daha verimli bir şekilde sprint amacına yönelik çalışmaktır.

Her takımın kendi hızı vardır. Takımlar arası VELOCITY REKABETİ / karşılaştırması yanlıştır. BUG lar veya diğer olumsuz durumlar işler için kişisel sorumlu aramak ve performans sistemine yansıtmaya çalışmak takım ruhuna zarar verecektir. Cadı avına çıkılmamalıdır.

⚠ BİR SPRINT NASIL "BAŞARISIZ" OLUR?
Given that each Sprint is an experiment and Scrum is an empirical process:
An unsuccessful Sprint is one where at the end we have not learned anything. We did not Inspect and Adapt the results for customizing the Product and Processes.
https://www.scrum.org/resources/blog/what-failed-sprint

BUG CAP
Takımın backlog undaki / havuzundaki açık hata sayısı bir üst sınır koyuyoruz. 30 diyelim. BUG sayısı 30'a ulaştığında ekip kayıt kalemi bırakıp (sprintteki "feature" geliştirimini bırakıp) hata kayıtlarını azaltıyor. Bu isteyemeyen bir durum olduğu için ekip hata sayılarını bu sınırın altımda tutma eğilimine giriyor. Hata adetlerimiz her zaman mümkün olduğunda az olmalıdır.

⚠ TASK/CONTEXT SWITCHING
Kaçınmamız gereken bir durumdur. Bitirebileceğimiz kadar is alalım. Birden fazla isin yarım yarım ilerlemesindense teker teker yapılıp bitirilmesi daha hızlı sürüyor.

--> Bir günden fazla suren TASK olmamalıdır
--> TASK ları hep back log un tepesinden alalım. En değerli iş en önce yapılmalıdır.

 GÜÇLÜ PIPELINE, AGILE PROJE
Kod silebilmek yazmaktan daha zordur. Kolayca kod silebilecek güçlü bir pipeline kurmak önemlidir.
Bundan kasıt şudur: unit testler, integration ve ui testlerin olmalı ki kod üzerinde değişiklik yapmaktan veya silmekten çekinmeyelim.

Root Cause Analysis From Juran
https://www.youtube.com/watch?v=IETtnK7gzlE

Fibonacci Sequence in Nature
https://www.youtube.com/watch?v=nt2OlMAJj6o

Scaled Agiled Framework (Enterprise için uyarlanmış bir framework)
http://www.scaledagileframework.com/

Acil / Araya Giren Maddeler
Bunların etiketlenmesi, daha sonra ekip ve SM tarafından etki analizinin yapılması gerekir. Süreç neden araya giren talep üretiyor. Mutlaka bir yerdeki sıkıntıya işaret edecektir. Acil işler kesinti yaratır. Bunların da iyi yönetilmesi gerekir. Bu maddeler için nöbetçi atanabilir.

Acil Talepler için BUFFER
Sprint planında bu gibi maddeler için BUFFER zaman koymak yaygın bir yaklaşımdır. BUFFER dan kullanılmaz ise (mevcut sprintte her şey yolunda ise) yerine bir sonraki sprintten madde çekilebilir. Motivasyon yükselten bir şeydir.
Acil istekler veya BUG lar için nöbetçi de tanımlanabilir. Ekibin toplama TASK SWITCHING kaybını azaltmış oluruz.

⚠ EMAIL HUNTING
Kim ne demişti kendimize kanıt aramak yerine arayıp konuşalım sorunu halledelim. Analiz ve test uzmanları ekibin bir parçası olabilirler. İletişimin artması beklemeleri azaltacaktır.

⚠ BROOKS LAW
Geciken projeye adam almak işleri kötüleştirir.

CHANGE MANAGEMENT
https://www.prosci.com/adkar/adkar-model
Awareness of the business reasons for change. Awareness is the goal/outcome of early communications related to an organizational change
Desire to engage and participate in the change. Desire is the goal/outcome of sponsorship and resistance management
Knowledge about how to change. Knowledge is the goal/outcome of training and coaching
Ability to realize or implement the change at the required performance level. Ability is the goal/outcome of additional coaching, practice and time
Reinforcement to ensure change sticks. Reinforcement is the goal/outcome of adoption measurement, corrective action and recognition of successful change

Value Stream Mapping (VSM)
Süreç iyileştirme yöntemidir.
Ürünün kodlanmasından müşteriye çıkmasına kadar olan süreç sondan başa doğru şemaya aktarılır. Bir işin toplamda beklemeler ile kadar sürdüğü, aslında asıl işin ne kadar sürdüğü karşılaştırılır. Manuel yapılan işler ve beklemelerin tespitine yarar.