Kanban ile Scrum

Muhammet Ayal
Devops Türkiye☁️ 🐧 🐳 ☸️
4 min readNov 10, 2019

Bu yazıda Agile’ın sahipliğindeki Kanban ve Scrum’ı inceleyip, bariz farklılıkları üzerinden aynı amaca nasıl hizmet ettiğini göstermek istiyorum.

Agile, Proje Yönetimi ve Ürün Geliştirme süreçlerini günümüzün çok değişkenli ve dinamik yapısına uyarlayabilmek için geliştirmeci ekiplere sunulmuş prensipler bütünü. Bu dinamizm içerisinde yoldan sapmamak için önceden çizilmiş bir harita, aralarda da durup düşünmek için harita üzerinde işaretlenmiş kervansaraylar var.

Kanban, esasında olabildiğince işlerimizin görünürlüğüne önem veren, work in progress (WIP) limitini azaltmak ve verimliliği maximize etmek için kullanılan bir framework . Bunun için Kanban board kullanılır ve çalışma prensipleri sürekli iyileştirmeye ve geliştirmeye açıktır.

Scrum ekipleri, müşterilere çalışan bir paketi sprint adı verilen belirli aralıklarla göndermeyi taahhüt ederler. Aynı zamanda Agile prensipleri uygulayan diğer framework’ün adıdır.

Genel farkları resmeden güzel bir görsel

Beğendiğim bir Scrum / Kanban tablosu: reference

Bu maddeleri tek tek inceleyelim.

Scrum için;

Cadence: 2 — 4 hafta uzunluğunda katî bir başlangıç ve bitiş tarihi olan sprintler var. Kısa zaman diliminde komplike görevleri küçük küçük story’lere bölerek iş yapabilme önemlidir. Buradaki kritik soru ekip bu user story’ler için yazılan kodu deliver edebilecek mi?

Release Methodology: Ad-hoc release’lerin yayınlanması Scrum için mühimdir. Ancak her bir sprint’in sonunda bir release çıkması best practice olarak daha iyidir. Sprint hedefinin, sprint review toplantısında gerçekleştirip gerçekleştirilemeyeceği belli olur.

Roles: Product Owner, müşteri merkezlidir, product backlog’u yönetir ve geliştirme ekibi tarafından yapılan işin önceliklendirilmesine yardımcı olur. Scrum master, scrum prensiplerine göre çalışmaları düzenler, takımı organize eder. Development team, işleri yapan ekiptir. Scrum ekibinin odağı müşterilere sağlıklı bir ürün teslim etmektir.

Velocity: Scrum ekiplerinin en mühim metriğidir. (Sprint içinde tamamlanan story point sayısı). Scrum ekiplerinin ne kadar iş yaptığını ve gelecek için ne kadar yapabileceğini gösterir.

Change Philosophy: Takımlar bir sprint sırasında kapsam değişikliği yapmak istemezler. Scrum ekipleri bazen feedback alır ve üzerinde çalıştıkları şeyin müşteri için düşündükleri kadar değerli olmadığını öğrenebilir. Bu gibi durumlarda, sprint kapsamı, her şeyden önce müşterinin faydasına göre değişmelidir.

Kanban için;

Cadence: Ekipleri değişen önceliklere adapte etmeye hazır tutan sürekli bir iş akışı yapısına dayanıyor. Kartlarla gösterilen iş öğeleri, iş akışının (sütun) bir aşamasından diğerine geçtikleri bir kanban tahtasında düzenlenir. Kanban board’u özelleştirmek ve takımın yapısına göre düzenlemek en iyisi.

Release Methodology: Kesinleşmiş ve düzenli bir release tarihi yoktur. Teorik olarak, kanban bir görevi yerine getirmek için belirli bir zaman vermez. Görev daha erken (veya daha sonra) tamamlanırsa, sprint incelemesi gibi bir aşamayı beklemek zorunda kalmadan gerektiğinde release edilebilir.

Kanban roles: Tüm takımın kanban panosu vardır. Bazı takımlar çevik bir koçu çalıştırırlar, ama scrumun aksine, her şeyin sorunsuz çalışmasını sağlayan tek bir “kanban master” yoktur. Yönetim kurulu üzerinde ortaklaşa çalışmak ve işleri yerine getirmek tüm ekibin ortak sorumluluğudur.

Key Metrics: Lead Time (teslim süresi) ve Cycle Time (döngü süresi), kanban ekipleri için önemli ölçümlerdir. WIP’i Daha fazla metrik için

Change philosophy: Bir kanban iş akışı herhangi bir zamanda değişebilir. Yeni iş öğeleri backlog’a eklenebilir ve mevcut kartlar öncelik sırasına göre birlikte engellenebilir veya kaldırılabilir. Ayrıca, takımın kapasitesi değişirse, WIP sınırı yeniden ayarlanabilir ve iş öğeleri buna göre ayarlanabilir. Esnek olmak, olmaya çalışmak daha mühim.

Hangisini seçmeli?

Scrum veya Kanban seçildiğinde kimse kimseye darılmaz. Yanlış yaptın demez. Bu iki metodu mix olarak kullanan şirketler de çokça yaygın. Birini seçip tecrübe ettikten sonra diğerini de deneyebilirsiniz.

Tool Seçimi

Developer’a ihtiyaç duymadan şirket içi tüm süreçlerinizi tasarlayabileceğiniz ve benim de en çok sevdiğim tool’larda biri olan Jira’nın Jira software modülü bu işler için biçilmiş kaftandır.

Jira Board: Planlama ve İzleme
Release ve Report

Kaynak:

  • Atlassian
  • MAX REHKOPF makale çevirisi referans alınarak bu yazı hazırlanmıştır.

--

--

Muhammet Ayal
Devops Türkiye☁️ 🐧 🐳 ☸️

Matematik Mühendisi | Süreç ve Dijital Dönüşüm Danışmanı | Atlassian Jira Mütehassıs’ı | Rebabi