Biz insanlar olarak hepimiz şunu kabul ediyoruz ki: Endüstri 4.0, 4. Sanayi Devrimi, IoT(Nesnelerin İnterneti) gibi gelişmelerin ardından dünya üzerindeki çoğu şirket rekabet ortamına ayak uydurmak için dijital dönüşüm kervanına katılmışlardır. Bu dönüşümü en iyi şekilde uygulayabilen şirketler doğal seçilim yoluyla günümüze kadar gelebilmiş, servetlerine servet, ülke ekonomilerine değer katmışlardır. Bu yazımızda scrum framework kavramının temel felsefesi olan Agile yaklaşımından ve Scrum metodolojisinden bahsedeceğiz.

İlginizi çekebilir: Nesnelerin İnterneti (IoT) Nedir?

Bu dönüşümle birlikte yazılım mühendisleri ve bilgisayar mühendisleri her şirkette bulunması gereken vazgeçilmez bir meslek haline gelmiştir. Mühendisler bu süreç içerisinde proje geliştirilirken uyulması gereken kuralları içeren çeşitli algoritmalar veya metodlar oluşturmuşlardır. Waterfall ve Agile yaklaşımı bu metodlardan birkaçıdır.

Agile Metodlarının Kullanım Alanları Nelerdir?

Günümüzde pek çok şirket herhangi bir şey yaparken Agile metodlarını kullanmaktadır. Agile metodları, bir diğer adıyla da çevik metodlar genellikle teknoloji alanında kullanılmasıyla bilinse de hemen hemen her işte kullanılabilen metodlardır.

Agile metodları, üretkenlik, verimlilik ve kalite gibi parametreler göz önüne alındığında kuruluşlara, ekiplere ve ürünlere yardımcı olma konusunda hızla güçlü bir itibar kazanmaktadır. Öyleyse, Agile yaklaşımı tam olarak nedir ve işletmeniz için ne gibi faydaları vardır?

Agile Yaklaşımı Nedir?

Agile yaklaşımı, artımlı, yinelemeli bir yönetim yaklaşımını benimser. Agile yaklaşımının ana amacı, hızlı katma değer elde etmek istendiğinde, ekiplerin gelişen bir ortamda üretken olmalarına yardımcı olmaktır. Agile proje yönetiminde kullanılan başlıca yöntemler Kanban, Scrum ve XP metodolojileridir. Bunların tümü, esneklik, sürekli iyileştirme, ekip girdisi ve yüksek kaliteli çıktı edinimine dayanan Agile Manifesto’yu takip eder.

Agile manifesto bir grup yazılımcı tarafından yayımlanan toplumsal bir bildiridir. Bu manifesto 12 prensip ve 4 değeri kendine esas edinir.

Detayla Agile Metodolojisi Nedir? yazımızda!

Geleneksel Yaklaşım ve Agile Yaklaşımı Arasındaki Farklar Nelerdir?

Geleneksel yaklaşım olarak bilinen Waterfall yaklaşımı yinelemeli olmadığından Agile yaklaşımından farklıdır. Waterfall yaklaşımı daha çok kademeli bir akış üzerinde odaklanır. Bu yaklaşım analizle başlar, dizayn, uygulama, test ve bakım şeklinde bir şelale gibi aşağı doğru iner. Agile yaklaşımı müşterinin isteklerini müşteriyi zincire dehil ederek saptar ve bu istekler değişse bile yinelemeci bir yapıya sahip olduğundan  değişikliklere çok rahat adapte olabilir. Bu noktada Agile yaklaşımı Waterfall yaklaşımından farklıdır.

Scrum Framework Nedir?

Scrum Framework, Agile ile aynı olarak zannedilse de aslında Agile daha çok bir felsefe, Scrum framework ise bu felsefenin uygulanma alanıdır.

Scrum’un basit bir yapısı vardır. Waterfall metolojisinin aksine katı kuralları yoktur ve karmaşık değildir. Scrum bir metodoloji değildir. Scrum, bilimsel deneycilik yöntemini uygular. Scrum karmaşık ve öngörülemez problemleri çözmek için birbirine saygı duyan insanların örgütlenmesiyle, algoritmik bir yaklaşımı sezgisel yaklaşımla değiştirir.

Aşağıdaki grafik, Scrum Framework’ün kurucusu olan Ken Schwaber ve Jeff Sutherland‘ın 30 Günde Yazılım adlı kitaplarında açıkladığı gibi, bizi planlamadan yazılım teslimine kadar götüren Scrum in Action‘ı temsil ediyor.

Nasıl Bir Ekiple Scrum Yapılır?

Scrum çalışmasını yapmak için Scrum yapanlar arasında olması gereken bazı ortak değerler vardır.

    • Commitement(Adanmışlık): Scrum ekibinin hedeflerine ulaşmak için istekli olması ve birbirini desteklemesi
  • Focus(Odaklanmak): Ekibin dikkatinin Sprint hedefleri doğrultusunda en iyi şekilde ilerlemek için işin üstünde olması
  • Openness(Açıklık): Ekibin ve hissedarların birlikte çalışmaya açık olması
  • Respect(Saygı): Scrum ekip üyelerinin birbirlerini yeterli ve bağımsız bireyler olarak görmeleri
  • Courage(Cesaret): Scrum ekip üyelerinin zorlu problemler karşısında doğru şeyi yapmaya cesaretinin olamsı

Scrum Yapılacak Ortamda Bulunması Gereken Özellikler Nelerdir?

    • Transparency (Şeffaflık): Ortaya çıkan süreç ve iş hem işi yapanlara hem de işi devralanlar için görünür olmalıdır.  Şeffaflık kontrolü doğurur, şeffaflık olmadan kontrol yanıltıcı ve zararlıdır.
  • Inspection(Kontrol, Denetleme): Scrum eserleri ve belirlenmiş hedefler doğrultusundaki ilerleme, olası istenmeyen değişkenleri ve problemleri saptamak için sıklıkla ve özenle kontrol edilmelidir. Kontrol adaptasyonu etkin kılar. Uyum olmadan düşünülen kontrol anlamsızdır. Scrum olayları değişimi uyandırmak için tasarlanmıştır.
  • Adaptation(Adaptasyon): Bir sürecin herhangi bir yönü kabul edilebilir sınırların dışına çıkarsa veya ortaya çıkan ürün kabul edilemezse, yapılan işlem veya üretilen malzemeler tekrardan düzeltilmelidir. Daha fazla sapmayı en aza indirmek için ayarlama mümkün olan en kısa sürede yapılmalıdır. Adaptasyon, ilgili kişilerin bir şey yapma özgürlüğü olmadığında veya ilgili kişiler kendilerini yönetemediğinde daha zor hale gelir. Scrum ekibi denetleme adına yeni bir şey öğrendiğinde onu uygulaması beklenir.

Scrum Takımı Nedir? Scrum Takımı Kimlerden Oluşur?

Scrum Takımı NedirScrumun ana birimi küçük bir insan topluluğu olan Scrum takımıdır. Scrum takımı bir Scrum Master, bir Ürün sahibi ve geliştiricilerden oluşur. Scrum takımında ne hiyerarşi ne de altgruplar vardır. Scrum takımı, her seferinde tek bir hedefe yani ürün hedefine (Product Goal) odaklanan profesyonellerden oluşan kapsayıcı ve uyumlu bir birimdir.

Scrum takımı üyeleri çok fonksiyonludur, yani üyeler her Sprintte(koşu) değer yaratmak için gerekli tüm becerilere sahiptir. Aynı zamanda kendi kendini yönetirler, yani kimin neyi, ne zaman ve nasıl yapacağına kendileri karar verirler.

Scrum Takımı çevik kalabilecek kadar küçük ve bir Sprint içinde önemli bir işi tamamlayacak kadar büyüktür, tipik olarak 10 veya daha az kişidir. Genel olarak, daha küçük ekipler daha iyi iletişim kurar ve daha üretkendir. Scrum takım nüfusu sayıca çok olurlarsa, her biri aynı ürüne odaklanan çoklu takımlar halinde yeniden örgütlenmeyi gözden geçirmelidirler. Bunun sonucunda, aynı Ürün Hedefini, Ürün İş Listesini ve Ürün Sahibini paylaşmaları gerekir.

Scrum Ekibi, ürünle ilgili olabilecek her şeyden, paydaş işbirliği, doğrulama, bakım, işletim, deney, araştırma ve geliştirme ve gerekli olabilecek diğer her şeyden sorumludur. Scrum ekibi, örgüt tarafından kendi işlerini yönetmeleri için bir araya getirilmiş ve yetkilendirilmişlerdir. Sürdürülebilir bir hızda Sprintler halinde çalışmak, Scrum Takımının odaklanmasını ve tutarlılığını geliştirir.

Scrum Takımının tamamı, her Sprintte kaydadeğer ve kullanışlı bir Arttırım (Increment) yaratmaktan sorumludur. Scrum metodu, Scrum Takımı içinde üç spesifik sorumluluk tanımlar: Geliştiriciler, Ürün Sahibi ve Scrum Master.

Geliştiriciler(Developers): Scrum takımındaki geliştiriciler,  kendini her Sprintte kullanışlı bir Arttırım yaratmaya adamış kişilerdir. Geliştiricilerin ihtiyaç duyduğu belirli beceriler genellikle geniştir ve çalışma alanına göre değişiklik gösterir. Bununla birlikte, Geliştiriciler her zaman aşağıdakilerden sorumludur:

  • Sprint için İş listesi olarak da bilinen(Sprint Backlog) bir plan oluşturmak
  • DoD(Definition of Done) ilkesine bağlı kalarak kaliteyi aşılamak
  • Planlarını Sprint Hedefine göre her gün uyarlamak; ve,
  • Profesyoneller olarak birbirlerini sorumlu tutmak.

Ürün Sahibi(Product Owner): Ürün Sahibi, Scrum Takımının çalışmasının sonucu olan ürünün, değerini maksimize etmekten sorumludur. Bunun nasıl yapılacağı kuruluşlar, Scrum Takımları ve bireyler arasında büyük ölçüde değişebilir.

Ürün Sahibi ayrıca aşağıdakileri içeren etkili Ürün İş Listesi (Product Backlog) yönetiminden sorumludur:

  • Ürün Hedefini geliştirmek ve açıkça iletmek;
  • Ürün İş Listesi(Product Backlog) öğelerini oluşturmak ve açık bir şekilde iletmek;
  • Ürün İş Listesi(Product Backlog) ögelerinin sipariş edilmesi; ve,
  • Ürün İş Listesinin(Product Backlog) şeffaf, görünür olmasını sağlamak ve anlaşıldığını garanti etmek

Ürün Sahibi yukarıdaki işi yapabilir veya sorumluluğu başkalarına devredebilir. Ne olursa olsun, Ürün Sahibi sorumlu tutulur.

Ürün Sahiplerinin başarılı olması için tüm organizasyonun kararlarına saygı göstermesi gerekir. Bu kararlar, Ürün İş Listesinin içeriğinde ve Arttırım(Increment) aracılığıyla Sprint İncelemesi’de(Sprint Review) gözlemlenebilir.

Ürün Sahibi bir komite değil, tek kişidir. Ürün Sahibi bir çok paydaşın ihtiyaçlarını Ürün İstek Listesi’nde temsil edebilir. Ürün İstek Listesini değiştirmek isteyenler bunu Ürün Sahibini ikna etmeye çalışarak yapabilirler.

Scrum Master: Scrum Master, Scrum Kılavuzunda tanımlandığı gibi Scrum’ı kurmaktan sorumludur. Bunu, hem Scrum Takımı hem de organizasyon içinde herkesin Scrum teorisini ve uygulamasını anlamasına yardımcı olarak yapar. Scrum Master, Scrum Takımının etkinliklerinden sorumludur. Bunu, Scrum Takımının Scrum çerçevesi içinde uygulamalarını iyileştirmesini sağlayarak yaparlar.

Scrum Masters, Scrum Takımına ve daha büyük olan organizasyona hizmet eden gerçek liderlerdir.

Scrum Master, Scrum Takımına aşağıdakiler dahil çeşitli şekillerde hizmet eder:

  • Ekip üyelerine özyönetim ve çok fonksiyonluluk konularında koçluk yapmak;
  • Scrum Takımının DoD(Definition of Done) tanımına uyan yüksek değerli Arttırımlar oluşturmaya odaklanmasına yardımcı olmak;

  • Scrum Takımının ilerlemesinin önündeki engellerin kaldırılmasını sağlamak; ve,

  • Tüm Scrum etkinliklerinin gerçekleşmesini ve bu etkinliklerin bu zaman çerçevesi içinde pozitif ve üretken geçmesini garanti altına almak.

Scrum Master, Ürün Sahibine aşağıdakiler dahil çeşitli şekillerde hizmet verir:

  • Ürün Hedefinin etkili tanımı ve Ürün İş Listesinin etkili yönetimi için teknikler bulunmasına yardımcı olmak;
  • Scrum Takımının net bir şekilde ve kısa sürede Ürün İş Listesi ögelerine olan ihtiyacı anlamasına yardımcı olmak;

  • Karmaşık bir ortam için deneysel ürün planlaması oluşturmaya yardımcı olmak; ve,

  • İstenildiğinde veya gerektiğinde paydaş işbirliğini kolaylaştırmak

Scrum Master, organizasyona aşağıdakiler dahil çeşitli şekillerde hizmet sunar:

  • Scrum’ın benimsenmesinde organizasyona liderlik etmek, organizasyonu eğitmek ve  organizasyona koçluk yapmak;

  • Organizasyon içerisinde Scrum uygulamaları planlamak ve tavsiye etme;

  • Çalışanların ve paydaşların karmaşık işler için deneysel bir yaklaşımı anlamasına ve uygulamaya koymasına yardımcı olmak; ve,

  • Paydaşlar ve Scrum Takımları arasındaki engelleri kaldırmak.

Scrum Etkinlikleri Nelerdir?

Sprint

Sprint, sprint dışındaki tüm diğer etkinlikler için bir kapsayıcıdır. Scrum’daki her etkinlik, Scrum eserlerini incelemek ve uyarlamak için resmen bir fırsattır. Bu etkinlikler, gereken şeffaflığı sağlamak için özel olarak tasarlanmıştır. Herhangi bir olayın öngörülen şekilde gerçekleştirilmemesi, inceleme ve uyum sağlama fırsatlarının kaybedilmesine neden olur. Scrum etkinlikleri, Scrum’da düzen oluşturmak ve Scrum içerisinde tanımlanmamış toplantıları minimize etmek için kullanılmıştır.

Optimal olarak, karmaşıklığı azaltmak için tüm etkinlikler aynı zamanda ve aynı yerde yapılır.

Sprint: Sprintler, fikirlerin değere dönüştürüldüğü Scrum’ın kalbidir. Tutarlılık sağlamak için bir ay veya daha kısa süreli sabit uzunluktaki etkinliklerdir. Yeni bir Sprint, önceki Sprint’in bitiminden hemen sonra başlar.

Sprint Planlama, Günlük Scrumlar, Sprint İnceleme ve Sprint Retrospektifi dahil Ürün Hedefine ulaşmak için gerekli tüm çalışmalar Sprintlerin içinde gerçekleşir.

Sprint sırasında:

  • Sprint Hedefini tehlikeye atacak hiçbir değişiklik yapılmaz;
  • Kalite düşmez;
  • Ürün İş Listesi(Product Backlog) gerektiği gibi iyileştirilir; ve,
  • Sprint kapsamı, daha fazla bilgi edindikçe Ürün Sahibi ile açıklığa kavuşturulabilir ve yeniden müzakere edilebilir.

Sprint’ler, her ay bir Ürün Hedefine yönelik ilerlemenin denetlenmesini ve Ürün Hedefine yönelik adapyasyon ile birlikte öngörülebilirliği sağlar. Bir Sprint’in zaman periyodu çok uzun olduğunda, Sprint Hedefi geçersiz hale gelebilir, karmaşıklık artabilir ve risk artabilir. Daha fazla öğrenme döngüsü oluşturmak, maliyet ve çaba riskini daha küçük bir zaman dilimiyle sınırlamak için daha kısa Sprintler kullanılabilir. Her Sprint kısa bir proje olarak kabul edilebilir.

Sprint Hedefi geçersiz hale gelirse bir Sprint iptal edilebilir. Yalnızca Ürün Sahibi Sprint’i iptal etme yetkisine sahiptir.

Sprint Planlama(Sprint Planning)

Sprint Planlama, Sprint için yapılacak işi düzenleyerek Sprint’i başlatır. Ortaya çıkan bu plan, tüm Scrum Takımının ortak çalışmasıyla oluşturulur.

Ürün Sahibi, katılımcıların en önemli Ürün İş Listesi(Product Backlog) öğelerini ve Ürün Hedefine nasıl ulaşılcağını tartışmaya hazırlıklı olmalarını sağlar. Scrum Takımı, tavsiye vermeleri için diğer kişileri de Sprint Planlama’ya davet edebilir.

Sprint Planlama aşağıdaki konuları ele alır:

  • Birinci Konu: Bu Sprint neden değerli?
    Ürün Sahibi, ürünün mevcut Sprint’te değerini ve kullanışlılığının nasıl artırabileceğini önerir. Tüm Scrum Takımı daha sonra Sprint’in paydaşlar için neden değerli olduğunu açıklayan bir Sprint Hedefi tanımlamak için işbirliği yapar. Sprint Hedefi, Sprint Planlama sona ermeden önce kesinleştirilmelidir.
  • İkinci Konu: Bu Sprint Ne Yapılabilir?
    Geliştiriciler, Ürün Sahibi ile görüşerek, Ürün İş Listesinden mevcut Sprint’e dahil edilecek öğeleri seçerler. Scrum Takımı, bu süreç sırasında bu öğeleri iyileştirebilir, bu da anlayış ve güveni artırır. Bir Sprint içinde ne kadarlık kısmın tamamlanabileceğini seçmek zor olabilir. Bununla birlikte, Geliştiriciler geçmiş performansları, gelecek kapasiteleri ve DoD(Definition of Done) hakkında ne kadar çok şey bilirlerse, Sprint tahminlerinde o kadar emin olurlar.
  • Üçüncü Konu: Seçilen iş nasıl yapılacak?
    Seçilen her Ürün İş Listesi öğesi için Geliştiriciler, DoD tanımını karşılayan bir arttırım oluşturmak için gerekli işi planlar. Bu genellikle Ürün İstek Listesi maddelerinin bir günlük veya daha kısa süreli daha küçük iş ögelerine ayrıştırılmasıyla yapılır. Bunun nasıl yapılacağı tamamen Geliştiricilerin takdirine bağlıdır. Kimse onlara Ürün İş Listesi maddelerini nasıl değer arttırımlarına dönüştüreceklerini söylemez.

Sprint Hedefi, Sprint için seçilen Ürün İş Listesi öğeleri ve bunları sunma planı birlikte Sprint İş Listesi olarak adlandırılır.

Sprint Planlama, bir aylık bir Sprint için maksimum sekiz saat olmalıdır. Daha kısa Sprintler için Sprint planlama genellikle daha kısadır.

Günlük Scrum(Daily Scrum)

Günlük Scrum’ın amacı, Sprint Hedefi doğrultusundaki ilerlemeyi incelemek ve Sprint İş Listesini gerektiği şekilde uyarlayarak, işin geleceğini planlamaktır.

Günlük Scrum, Scrum Takımının Geliştiricileri için 15 dakikalık bir etkinliktir. Karmaşıklığı azaltmak için,  Sprint’in her günü aynı saatte ve aynı yerde yapılır. Ürün Sahibi veya Scrum Master, Sprint İş Listesindeki öğeler üzerinde aktif olarak çalışıyorsa, Geliştiriciler olarak katılırlar.

Geliştiriciler, Günlük Scrumları Sprint Hedefine doğru ilerlemeye odaklandığı ve sonraki iş günü için eyleme geçirilebilir bir plan ürettiği sürece, istedikleri yapı ve teknikleri seçebilirler. Bu odaklanma yaratır ve kendi kendini yönetmeyi geliştirir.

Günlük Scrumlar iletişimi geliştirir, engelleri belirler, hızlı karar almayı teşvik eder ve sonuç olarak diğer toplantılara olan ihtiyacı ortadan kaldırır.

Günlük Scrum, Geliştiricilerin planlarını ayarlamalarına izin verilen tek zaman değildir. Sprint’in geri kalan çalışmasının uyarlanması veya yeniden planlanması hakkında daha ayrıntılı tartışmalar için genellikle gün boyunca bir araya gelirler.

Sprint İncelemesi(Sprint Review)

Sprint İncelemesinin amacı, Sprint’in sonucunu incelemek ve gelecekteki uyarlamaları belirlemektir. Scrum Takımı, çalışmalarının sonuçlarını kilit paydaşlara sunar ve Ürün Hedefine yönelik ilerleme tartışılır.

Etkinlik sırasında, Scrum Ekibi ve paydaşlar Sprint’te nelerin başarıldığını ve çevrelerinde nelerin değiştiğini gözden geçirirler. Bu bilgilere dayanarak, katılımcılar bir sonraki adımda ne yapacakları konusunda işbirliği yaparlar. Ürün İş Listesi, yeni fırsatları değerlendirmek için de düzenlenebilir. Sprint İncelemesi bir çalışma oturumudur ve Scrum Takımı bunu bir sunumla sınırlamaktan kaçınmalıdır.

Sprint İncelemesi, Sprint’in sondan ikincisidir ve bir aylık bir Sprint için maksimum dört saat ile sınırlıdır. Daha kısa Sprintler için inceleme genellikle daha kısadır.

Sprint Retrospektifi(Sprint Retrospective)

Sprint Retrospektifinin amacı, kaliteyi ve verimi artırmanın yollarını planlamaktır.

Scrum Takımı, son Sprint’in bireyler, etkileşimler, süreçler, araçlar ve DoD bakımından nasıl gittiğini tartışır. İncelenen unsurlar genellikle çalışma alanına göre değişir. Bunları Sprint hedefinden saptıran varsayımlar belirlenir ve sebepleri araştırılır. Scrum Takımı, Sprint sırasında neyin iyi gittiğini, Sprint’in hangi problemlerle karşılaştığını ve bu problemlerin nasıl çözüldüğünü (veya çözülemediğini) tartışır.

Scrum Takımı, verimi artırmak için en yararlı değişiklikleri belirler. En etkili iyileştirmeler mümkün olan en kısa sürede ele alınır. Bir sonraki Sprint için Sprint İş Listesine bile eklenebilirler.

Sprint Retrospektifi, Sprint’i sonlandırır. Bir aylık bir Sprint için maksimum üç saat ile sınırlıdır. Daha kısa Sprintler için Retrospektif genellikle daha kısadır.

Scrum Eserleri Nelerdir?

Scrum’ın eserleri, işi veya değeri temsil eder. Anahtar bilgilerin görünürlüğünü (transparency)en üst düzeye çıkarmak için tasarlanmıştır. Bu nedenle, onları inceleyen herkes aynı adaptasyon temeline sahiptir.

Her bir eser, ilerlemeyi ölçtüğünden, şeffaflığı ve odaklanmayı artırdığından emin olmak için birer taahhüt içerir (Bir nevi kendi içinde kontrol mekanizması):

  • Ürün İş Listesi için, Ürün Hedefidir.
  • Sprint İş Listesi için, Sprint Hedefidir.
  • Arttırım için, DoD( Definition of Done)

Bu taahhütler, deneyciliği desteklemek ve Scrum Takımı ve paydaşları için Scrum değerlerini pekiştirmek için mevcuttur.

Ürün İş Listesi(Product Backlog)

Ürün İş Listesi, ürünü daha iyi hale getirmek için nelere ihtiyaç duyulduğu sorusunun cevabını barındıran, doğurgan ve sıralı bir listesidir. Scrum Takımı tarafından üstlenilen tek iş kaynağıdır.

Scrum Takımı tarafından bir Sprint içinde tamamlanabilecek Ürün İş Listesi öğeleri, Sprint Planlama etkinliğinde seçilmeye hazır olarak addedilir. Genellikle, Faaliyetleri netleştirdikten sonra bu derecede şeffaflık elde ederler. Ürün İstek Listesi iyileştirmesi, Ürün İstek Listesi öğelerini daha küçük, daha hassas öğelere ayırma ve bu ögeleri daha iyi tanımlama eylemidir. Bu, tanım, sipariş ve boyut gibi ayrıntıları eklemek için süregiden bir faaliyettir. Nitelikler genellikle çalışma alanına göre değişir.

İşi yapacak olan Geliştiriciler boyutlandırmadan sorumludur. Ürün Sahibi, uyumsuzlukların farkına varmalarına ve seçim yapmalarına yardımcı olarak Geliştiricileri etkileyebilir.

Taahhüt: Ürün Hedefi
Ürün Hedefi, Scrum Takımının hedef olarak doğrultusunda plan yapacağı ürünün gelecekteki durumunu tanımlar. Ürün Hedefi, Ürün İş Listesindedir. Ürün İş Listesinin geri kalanı, Ürün Hedefini “neyin” tamamlayacağının tanımıdır.

Ürün, değer sunan bir araçtır. Net bir sınırı, bilinen paydaşları, iyi tanımlanmış kullanıcıları veya müşterileri vardır. Bir ürün bir hizmet, fiziksel bir ürün veya daha soyut bir şey olabilir.

Ürün Hedefi, Scrum Takımı için uzun vadeli hedeftir. Bir sonraki hedefe ulaşmadan önce bir hedefi yerine getirmeleri (veya terk etmeleri) gerekir.

Sprint İş Listesi(Sprint Backlog)

Sprint İş Listesi(Sprint Backlog), Sprint Hedefi, Sprint için seçilen Ürün İş Listesi(Product Backlog) öğeleri ve Arttırımı(Increment) teslim etmek için eyleme geçirilebilir bir plandan oluşur.

Sprint İş Listesi(Sprint Backlog), Geliştiriciler tarafından yine Geliştiriciler için planlanmış bir plandır. Bu plan, Geliştiricilerin Sprint Hedefine ulaşmak için Sprint sırasında başarmayı planladıkları işin oldukça görünür, gerçek zamanlı bir resmidir. Sonuç olarak, Sprint İş Listesi, daha fazla şey öğrenildikçe Sprint boyunca güncellenir. Sprint İş Listesi, Günlük Scrum’da ilerlemelerini inceleyebilecekleri kadar ayrıntıya sahip olmalıdır.

Taahhüt: Sprint Hedefi
Sprint Hedefi, Sprint için tek hedeftir. Sprint Hedefi, Geliştiricilerin bir taahhüdü olmasına rağmen, bunu başarmak için gereken iş açısından esneklik sağlar. Sprint Hedefi aynı zamanda uyum ve odaklanma yaratarak Scrum Takımını ayrı girişimler yerine birlikte çalışmaya teşvik eder.

Sprint Hedefi, Sprint Planlama etkinliği sırasında oluşturulur ve ardından Sprint İş Listesine eklenir. Geliştiriciler Sprint sırasında çalışırken, Sprint Hedefini akıllarında tutarlar. Çalışma beklenenden farklı çıkarsa, Sprint Hedefini etkilemeden Sprint içindeki Sprint İş Listesinin kapsamını müzakere etmek için Ürün Sahibi ile işbirliği yaparlar.

Arttırım(Increment)

Arttırım, Ürün Hedefine doğru atılan somut bir basamaktır. Her Ürün Parçası, önceki Ürün Parçalarının tümüne bir eklemedir ve tüm Ürün Parçalarının birlikte çalıştığını ispat ederek doğrulanır. Değer sağlamak için Arttırım kullanılabilir olmalıdır.

Bir Sprint içinde birden fazla Arttırım oluşturulabilir. Artışlarının toplamı Sprint Review’de sunulur ve böylece deneyciliği destekler. Ancak Bir Arttırım paydaşlara Sprint sona ermeden de teslim edilebilir. Sprint Gözden Geçirme asla bir değer açığa çıkarma kapısı olarak görülmemelidir.

İş, DoD’a(Definition of Done) uymadığı sürece Arttırımın parçası olarak kabul edilemez.

Taahhüt: DoD(Definition of Done)
DoD, Ürün için gerekli kalite gereksinimleri karşıladığında Arttırımın resmi bir açıklamasıdır.

Bir Ürün İş Listesi(Product Backlog) öğesi DoD’u karşıladığı anda Arttırım doğar.

DoD, Arttırım kavramının bir parçası olarak hangi çalışmanın tamamlandığına dair herkese ortak bir anlayış sağlayarak şeffaflık(açıklık, netlik) yaratır. Bir Ürün İş Listesi öğesi DoD’a uymuyorsa, yayınlanamaz ve hatta Sprint İncelemesinde(Script Review) sunulamaz. Bunun yerine, gelecekte değerlendirilmek üzere Ürün İstek Listesine (Product Backlog) geri döner.

Bir artım için DoD organizasyonun standartlarının bir parçasıysa, tüm Scrum Takımları asgari olarak buna uymalıdır. Organizasyonel bir standart değilse, Scrum Takımı ürüne uygun bir DoD oluşturmalıdır.

Geliştiricilerin DoD’a uyması gerekir. Bir ürün üzerinde birlikte çalışan birden fazla Scrum Takımı varsa, bunlar karşılıklı olarak aynı DoD’u tanımlamalı ve buna uymalıdır.

Bu yazımızda Scrum Framework kavramını detaylıca ele aldık. Son olarak yazımı Scrum Framework kılavuzu ile bitirmek isterim.

 

 

 

Author

1 Comment

  1. Mekselina Ilgın Salkım Reply

    Bilgilendirici, çok güzel bir yazı olmuş eline sağlık 🙂

Bir Cevap Yazın

Yeni içeriklerden haberdar olmak ister misiniz?

Mail adresinizi bırakın ve yeni blog yazılarından haberdar olun!
ABONE OL
KVKK kanununa göre e-posta adresimden iletişime geçilmesine izin verilmiş sayılacaktır
close-link
Blog yazımızı beğendiniz mi?
%d blogcu bunu beğendi: