"Enter"a basıp içeriğe geçin

Scrum Nedir ? Geniş Anlatım

Not:Bu yazı güncel tutulmaya çalışılacak. Son güncelleme: 27 Mayıs 2015
Not: Hızlı okumak istiyorsanız sadece kalın kısımları okursanız özetlemiş olursunuz.

Scrum’ı anlatmadan önce “Agile” nedir bunu bilmemiz gerekir. Agile bir proje yönetim biçimdir. Agile metodolojisi daha çok yazılımcılara yöneliktir. Genel olarak ihityacın muallak olduğu durumlarda kullanılır. 17 dev adamın imzaladığı bir Agile manisfestosu;

Bizler daha iyi yazılım geliştirme yollarını uygulayarak ve başkalarının da uygulamasına yardım ederek ortaya çıkartıyoruz. Bu çalışmaların sonucunda:

Süreçler ve araçlardan ziyade bireyler ve etkileşimlere
Kapsamlı dökümantasyondan ziyade çalışan yazılıma
Sözleşme pazarlıklarından ziyade müşteri ile işbirliğine
Bir plana bağlı kalmaktan ziyade değişime karşılık vermeye
değer vermeye kanaat getirdik.

Özetle, sol taraftaki maddelerin değerini kabul etmekle birlikte,
sağ taraftaki maddeleri daha değerli bulmaktayız.

Neden Agile?

  1. Değişen önceliklerin yönetimi
  2. Daha hızlı canlıya çıkma
  3. Yazılım kalitesinde artma
  4. Basitleştirilmiş yazılım geliştirme süreci
  5. Takım moralinin yükselmesi

Agile framework’ünü taban almış farklı çalışma metodolojileri vardır. Bunlar:
Scrum
Extreme programming
Waterfall
Incremental

Şeklinde uzar gider. Extreme Programming ile Scrum benzer yapıya sahiptir ama Scrum kullanım oranı XP’ye göre fazla ve giderek artmaktadır. Genelde Scrum seminerlerinde anlatıcıların ilk yapacağı şey Waterfall’a b*k atmaktır ki haksız da sayılmazlar 🙂 .  Waterfall’da yada geleneksel yöntemde yapılan başlıca hatalardan biri Analiz-> Dizayn -> Kod -> Test -> Yayınlama süreçlerini önceden tahmin edip bunları sırasıyla yapmaya çalışmaktı. Çünkü bir proje en azından 6 aya yakın zaman aldığı için proje bitmeye yakın ihtiyaçlar değişebildiği gibi asıl istenen projeden farklı bir proje ortaya çıkabiliyordu. Yani 6 ayımızın çöpe gitmesi demek oluyordu.  Ama Scrum öyle mi 🙂  Scrum’da Sprint denilen 2 ile 4 hafta arası olan çalışmalar vardır. Her Sprint sonunda çalışan bir ürün çıkartılır  böylece çıkartılan ürünle istenen ürün arasındaki sapma sürekli görülür ve hedefe doğru projede düzeltmeler yapılır.

Gelelim Scrum’a:
3 temel başlık vardır.

1- Roller (Roles)

  • 1.1 Ürün Sahibi (Product Owner)
  • 1.2 Scrum Yöneticisi (Scrum Master)
  • 1.3 Geliştirme Takımı (Development Team)

2- Scrum Etkinlikleri (Scrum Events)

  • 2.1 Sprint (Koşu)
  • 2.2 Günlük Scrum (Daily Scrum)
  • 2.3 Sprint Planlama (Sprint Planning)
  • 2.4 Backlog arındırma (Backlog Refinement)
  • 2.5 Sprint Değerlendirme (Sprint Review)
  • 2.6 Sprint Retrospektifi (Sprint Retrospective)

3- Kavramlar / Araçlar (Artifacts)

  • 3.1 Ürün Gereksinim Dokümanı (Product Backlog)
  • 3.2 Sprint İş Listesi (Sprint Backlog)
  • 3.3 Bitti Tanımı (Definition of Done)
  • 3.4 Sprint Kalan Zaman Grafiği (Burndown Chart)

 

1- Roller (Roles)

1.1 Ürün Sahibi (Product Owner)

Ütopik PO görevleri bunlardır.

  • Ürün vizyonunu geliştirmek ve adapte etmek
  • Product backlogu oluşturmak, iyileştirmek ve önceliklerini belirlemek.
  • Takımla birlikte user storyleri belirlemek. Bunun için takımın analisti ile çalışılması en uygun olanıdır.(%90 geliştirme takımı kendi içinde yapar)
  • Bir sprint içinde yapılamayan işleri uygun bir şekilde bölerek takımın geliştirmesini sağlamak.(Bunu yapan PO’ya can feda)
  • Kabul kriterlerini belirlemek.(DoD’lardan bahsediyoruz. SM’ye itelenebilir)
  • Pazarı gözlemleyerek, Pazar hakkında gelişmeleri takip etmek, analiz etmek (Para kazanmak istiyorsa yapacak:) )
  • Ürünün veya projenin paydaşları ile etkileşimde olmak.
  • İş ile ilgili her tür rakam, ölçümleme ve anket sonucunu geliştirme takım ile paylaşarak ürün ile takım arasında bir bağ kurulmasını sağlamalıdır.
  • Sprint planning, backlog refinement, review toplantılarına katılmak. Daily scrumlara gerektiğinde katılarak bilgi vermelidir.
  • Takıma süreçlerin iyileşmesi için yardımcı olmak.
  • Scrum konusunda kendini geliştirmeye devam etmelidir. Kurumdaki diğer product ownerla fikir alışverişinde bulunmalıdır.
  • Ürünün veya projenin ilerlemesini ölçümleyebilmelidir.
  • Ürünün son kullanıcılarını düzenli olarak ziyaret ederek geribildirimlerini almalıdır.(Geliştirici için geribildirimin çölde vaha gibidir)
  • Fikirleri ürüne çevirmelidir. Mümkünse fikirleri MVP(Minimum Viable Product) haline getirerek ürünün yapılmasını sağlamalıdır.

Bu görevleri hakkıyla yapan PO’yu öpün de başınıza koyun. Tecrübe edilmiş PO hataları:

  • Yapılabilecek bir numaralı hata yarı zamanlı (part time) PO olmaktır.
  • PO takıma yakın değilse, takım boşlukları varsayımlarla doldurur. Bu da sorunlara yol açar.
  • Proje yöneticisi ve PO ayrı rollerdir. PO, proje yöneticileri ile görüşüp Product Backlog oluşturur.
  • PO eğer projenin herşeyini biliyorsa takıma işini öğretmeye başlar. “Inspect & adapt” ölür.
  • Takım kaliteyi arttırmayı, PO ise daha fazla iş isteyerek (mecazi olarak) düşürmeyi amaçlar.
  • Geçmişi gözden geçirme toplantılarına (retrospective meetings) PO katılabilir katılmayabilir.
  • PO’lar hem içe (takıma) dönük, hem de dışa (müşteriye) dönük olması gerekir.
1.2 Scrum Yöneticisi (Scrum Master)

ScrumMaster

  • Scrum sürecinin agile usullerine uygun olarak ilerlemesini sağlamak.
  • Takımı scrum konusunda eğitimini sağlamak ve her daim agile prensiblerine uygun bir şekilde devam etmesini  sağlamak.
  • Takımdaki her bir üye için geçerli olmak üzere Scrum’dan vazgeçmesini engellemek ve motivasyonu yüksek tutmak.
  • Takımın yaptığı işler için DONE kavramını belirlemek ve yapılan işlerin DONE kavramına uyup uymadığını kontrol etmek.
  • Takımın iş yapmasını engelleyen unsurları  ortadan kaldırmak.
  • Product owner’ı Scrum konusunda eğitmek ve yönlendirmek. Scrum Master’lar genellikle iş yapan taraftan birisi olduğundan Product Owner’a mentorluk görevini de üstlenebilmektedir.
  • Takım bireylerinin yaptıkları işe odaklanmalarını sağlamak ve Sprint hedefinden saptırıcı her türlü dış etmenden takımı korumak.
  • Takıma karılmasını veya takımın sorumluluğu dışında iş yaptırmak isteyenleri engellemek.
  • Scrum Master lider, takım arkadaşı ve gözetmen rollerini üstlenir. Öncelikle lider olarak takımın önünde gider, takımla beraber çalışarak takımın içinde olur, belli bir süre sonra takım belli bir olgunluğa geldikten sonra da takımın arkasında yüyür ve onları gözlemler. Takımın hizmetkar lideridir de denenebilir.
  • Kaizen(gelişime açık) ruhunun korunmasını sağlayarak takımın kendini geliştirmesini sağlar.
  • Takımın kendi kendini yönetebilir duruma getirerek yüksek performanslı bir takım haline gelmelerini sağlar.
  • Sprintlerdeki riskleri belirler, öncesinde ortada kaldırmaya ya da minimize etmeye çalışır.
  • Başarısız olunan durumlarda takımın eski motivasyonunun sağlanmasından sorumludur.

Scrum Master’ın da yukarı da bahsettiğimiz görevlerini sağlıklı olarak yapabilmesi içinde takım üyelerinin çok fazla olmaması gerekir. Ne kadar fazla kişi olursa o derece kontrol edilmesi zor bir takım haline gelecektir. Bunun için ideal olanın 5-9 kişilik takımların oluşmasıdır. Kişi sayısının fazla olması durumunda takım içinde kopukluklar gruplanmalar olmaktadır ki Agile için en önemli olan takım olgusuna zarar verecektir. Scrum Master takım içindeki uyumunda maximum olmasını sağlamalıdır. Takım içinde uyumu bozan ve düzelmeyen kişilerin de takımdan uzaklaştırılmasını sağlamalıdır.

Tabii ki takım kurulur kurulmaz uyum yakalaması birbirlerine güvenmeleri mümkün değildir. Bu da zamanla oluşan bir duygu olacaktır. Bir scrum takımının ideal duruma gelmesi 6 ayı bulabilmektedir.

Tüm bunların sonucunda ideal durum ise scrum takımının  tamamiyle kendi kendine organize olabilmesi, Scrum’da ustalaşması ve Scrum Master’lık rolüne ihtiyaçlarının kalmayarak bu rolün ortadan kalkması beklenmektedir. Takımın bu hale gelmesi de uzun bir zaman almaktadır.

 

1.3 Geliştirme Takımı (Development Team)

Development Team, 3 – 9 kişiden oluşan küçük takımlardır. Ürünün geliştirilmesinden sorumludurlar. Ürün geliştirme esnasında gereken bütün yeteneklere sahip kişilerden oluşturulmalıdır. Bir başka şekilde anlatmak gerekirse, ihtiyaç olması durumunda grafik tasarımcı, yazılım mühendisi, veritabanı yöneticisi gibi yeteneklere sahip kişiler, Development Team’i oluşturmalıdır.

Development Team genellikle aynı ofiste çalışıyor olmalıdır. Ancak farklı ofislerde, hatta farklı lokasyonlardaki ofislerde çalışan kişilerden oluşan Development Team örnekleri de mevcuttur. Development Team’lerde bulunan kişilerin bazı roller hariç olmak üzere (ÖR: Veritabanı Yöneticisi) tam zamanlı çalışıyor olması önem arz etmektedir.

Bu takımların en büyük özelliği kendi kendilerine organize olmalarıdır. Takımda hiçbir şekilde hiyerarşik bir yapı belirlenemez. Scrum takımındaki kimse, hangi işi kimin yapacağını söyleyemez. Takım üyeleri yapmak istedikleri görevleri kendileri belirler.

Development Team’in görevlerini şu şekilde özetleyebiliriz:

  • Sprint içerisinde yapılması gereken görevleri belirler.
  • Bu görevlere ne kadar efor harcanması gerektirdiği konusunda tahminleme yapar.( Bu tahminlere PO ve SM kesinlikle karışmaması gerekir)
  • Ürün geliştirme sorumluluğunu üstlenir.
  • Ürünün kalitesinden sorumludur.

Scrum’ın bu farklı rol tanımlama stratejisinin arkasında takım bireylerinin yaratıcılığını ve üretkenliğini arttırmak yatmaktadır.

2- Scrum Etkinlikleri (Scrum Events)
Scrum MeetingsScrum Meetings Flow

2.1 Sprint (Koşu)

Bir ay veya daha az zaman sınırı olan, içerisinde “Bitti”(Definition of Done) olan, kullanılabilir ve potansiyel olarak yayınlanabilir bir Ürün Parçasının oluşturulduğu Sprint, Scrumın kalbidir. Baştan sona bir geliştirme çalışması boyunca Sprintlerin süresi sabittir. Önceki Sprint biter bitmez yeni Sprint başlar. Sprintler, Sprint Planlama, Günlük Scrumlar, geliştirme işi, Sprint Değerlendirme ve Sprint Retrospektifinden oluşur.

Sprint boyunca:

  • Sprint Hedefini tehlikeye sokacak hiçbir değişiklik yapılmaz
  • Kalite hedefleri düşmez
  • Daha fazlası öğrenildikçe Ürün Sahibi ve Geliştirme Takımı arasında kapsam netleştirilebilir ve tekrar müzakere edilebilir.

Her bir Sprint bir aydan uzun bir ömrü olmayan bir proje olarak düşünülebilir. Projeler gibi Sprintler de bir şeyi başarmak için kullanılır. Her bir Sprintin, neyin üretileceğine ilişkin bir tanımı, bir tasarımı ve üretime rehberlik edecek esnek bir planı, işin kendisi ve sonuçta ortaya çıkacak olan ürünü vardır.

Sprintler bir takvim ayıyla sınırlıdır. Sprintin süresi çok uzun olursa üretilecek şeyin tanımı değişebilir, karmaşıklık ve risk artabilir. Sprintler, en az bir takvim ayında bir, Sprint Hedefine doğru ilerleyişi gözlemeyi ve adapte etmeyi sağlayarak öngörülebilirliği mümkün kılar. Ayrıca Sprintler riski bir takvim ayının maliyetiyle sınırlar.

2.2 Günlük Scrum (Daily Scrum)

Günlük Scrum, Geliştirme Takımının faaliyetleri hakkında takım üyelerinin birbirlerine bilgi verdiği ve önündeki 24 saat için bir plan oluşturacağı, 15 dakikayla sınırlı bir etkinliktir. Bu toplantıda bir önceki Günlük Scrumdan beri yapılan iş gözlemlenir ve sonrakitoplantıya kadar yapılabilecek iş planlanır. Günlük Scrum karmaşıklığı azaltmak için her gün aynı yer ve zamanda düzenlenir. Toplantıda Geliştirme Takımı üyeleri şunları anlatır:

  •  Geliştirme Takımının Sprint Hedefine ulaşması için dün ne yaptım?
  •  Geliştirme Takımının Sprint Hedefine ulaşması için bugün ne yapacağım?
  •  Beni veya Geliştirme Takımını Sprint Hedefine ulaşmaktan alıkoyacak bir engel görüyor muyum?

Geliştirme Takımı, Sprint Hedefine doğru ilerlemeyi ve Sprint Backlog’undaki işlerin tamamlanma durumlarının nasıl bir eğilim çizdiğini görmek için Günlük Scrumı kullanır. Günlük Scrum, Geliştirme Takımının Sprint Hedefini gerçekleştirme ihtimalini güçlendirir. Geliştirme Takımı her gün Sprint Hedefine ulaşmak ve beklenen Ürün Parçasını Sprint sonuna kadar üretmek için birlikte kendini yöneten bir ekip olarak nasıl çalışması gerektiğini anlamalıdır. Geliştirme Takımı veya takım üyeleri Günlük Scrumın hemen ardından ayrıntılı olarak tartışmak, Sprintin kalan işini yeniden planlamak veya adapte etmek için sıklıkla bir araya gelirler.

Scrum Master Geliştirme Takımının toplantıyı yapmasını temin eder fakat Günlük Scrumı yürütmek Geliştirme Takımının sorumluluğudur.Scrum Master Geliştirme Takımına Günlük Scrumı 15 dakikayla sınırlı tutmasını öğretir.

Scrum Master Günlük Scruma sadece Geliştirme Takımının katılması kuralını ısrarla benimsetir.

Günlük Scrumlar iletişimi iyileştirir, diğer toplantıları ortadan kaldırır, geliştirmenin önündeki engellerin tespit edilmesini sağlar, hızlı karar almayı teşvik eder ve Geliştirme Takımının bilgi seviyesini arttırır. Bu etkinlik kilit bir gözlem ve adaptasyon toplantısıdır.

2.3 Sprint Planlama (Sprint Planning)

Sprintte yapılacak iş Sprint Planlamada planlanır. Tüm Scrum Takımı birlikte çalışarak planı oluşturur.

Sprint Planlama, bir aylık Sprint için 8 saatle sınırlıdır. Daha kısa Sprintler için, etkinlik genellikle daha kısadır. Scrum Master, etkinliğin yapılmasını ve katılımcıların amacını anlamasını temin eder. Scrum Master, Scrum Takımına bu etkinliğin zaman sınırını aşmamasını öğretir.

Sprint Planlama şunlara cevap verir:

  •  Bu Sprintte Ürün Parçası olarak ne teslim edilebilir?
  •  Ürün Parçasını teslim etmek için gerekli olan iş nasıl başarılacak?
Birinci Konu: Bu Sprintte ne yapılabilir?

Geliştirme Takımı, Sprint boyunca geliştirilecek işlevselliği öngörmek için çalışır. Ürün Sahibi, Sprintin başarması gereken amacı ve (Sprintte tamamlanırsa) Sprint Hedefini gerçekleştirecek Product Backlog kalemlerini tartışır. Tüm Scrum Takımı Sprintin işini anlamak için birlikte çalışır.

Sprint Planlama toplantısının girdileri Product Backlog, en son çıkan Ürün Parçası, Geliştirme Takımının Sprintte harcayacağı kapasite tahmini ve Geliştirme Takımının geçmiş performansıdır. Product Backlog’tan kaç tane kalemi alacağına Geliştirme Takımı karar verir. Sadece Geliştirme Takımı önündeki Sprintte ne kadar işi yapabileceğini tartabilir.

Geliştirme Takımı Sprintte teslim edeceği Product Backlog kalemlerini öngördükten sonra Scrum Takımı Sprint Hedefini oluşturur. Sprint Hedefi, Product Backlog’unun Sprint boyunca uygulanmasıyla ulaşılacak amaçtır ve Geliştirme Takımına Ürün Parçasını neden geliştirdiğiyle ilgili rehberlik eder.

İkinci Konu: Seçilen iş nasıl yapılacak?

Sprint Hedefini belirleyen ve Sprinte alınacak Product Backlog kalemlerini seçen Geliştirme Takımı bu işlevselliği Sprint boyunca nasıl “Bitti” olan bir Ürün Parçasına dönüştüreceğine karar verir. Sprint için seçilen Product Backlog kalemleri ve bunları teslim etmek için hazırlanan plana birlikte Sprint Backlog adı verilir.

Geliştirme Takımı, genellikle Product Backlog’unu, çalışan bir Ürün Parçasına dönüştürmek için gerekli olan işi ve sistemi tasarlamakla başlar. İşler farklı büyüklükte veya tahmin edilen eforlarda olabilir. Ancak Geliştirme Takımı Sprint Planlamada önündeki Sprintte yapabileceğine inandığı kadar işi öngörerek üzerine alır. Toplantının sonunda Sprintin ilk günleri için planlanan iş kırılır; bu birimler çoğunlukla bir gün veya altında sürelerdedir. Geliştirme Takımı, hem Sprint Planlamada hem gerektiği ölçüde Sprint boyunca, Sprint Backlog’undan iş almak için kendi kendine organize olur.

Ürün Sahibi, seçilen Product Backlog kaleminin anlaşılmasına ve doğru seçimin yapılmasına yardım edebilir. Eğer Geliştirme Takımı çok az veya çok fazla işi olduğunu düşünürse, seçili Product Backlog kalemlerini Ürün Sahibiyle tekrar müzakere edebilir. Geliştirme Takımı toplantıya teknik veya uzmanlık tavsiyesi vermek üzere başka kişileri toplantıya davet edebilir.

Sprint Hedefi (Sprint Goal)

Sprint Hedefi, bir Sprint için belirlenen ve Product Backlog’nun gerçekleşmesiyle ulaşılabilecek amaçtır. Geliştirme Takımına neden ilgili Ürün Parçasını geliştireceğiyle ilgili rehberlik eder. Sprint Planlama toplantısında oluşturulur. Sprint Hedefi Geliştirme Takımına Sprintte geliştirilen işlevsellikle ilgili biraz esneklik sunar. Seçili Product Backlog kalemleri birbiriyle ilişkilendirilen bir bütünsel işlev sunar; o da Sprint Hedefidir. Sprint Hedefi, Geliştirme Takımını farklı girişimlerde bulunmak yerine birlikte çalışmaya sevk edecek, parçalarının aynı bütüne hizmet ettiği herhangi bir şey olabilir.

Geliştirme Takımı çalıştıkça, Sprint Hedefini aklından çıkarmaz. Sprint Hedefine ulaşmak için işlevselliği ve teknolojiyi geliştirir. Eğer Sprint boyunca iş, Geliştirme Takımının beklediğinden farklılaşmaya başlarsa, Takım Ürün Sahibiyle Sprint Backlog’unun kapsamı konusunda müzakere eder.

2.4 Backlog arındırma (Backlog Refinement)

Backlog’taki özellikler scrum ekibi tarafından değerlendirilir. Burdaki işler hamdır. Bu ekip bu ham özellikleri birllikte yorumlayarak kırpma, bölme, birleştirme gibi işlemler yaparak Ham Backlog’ları olgunlaştırır. Bu işleme Backlog Grooming denir. Gelecek sprint toplantısı için kaynak niteleğindedir. Yönetim tarafından bu toplantı zaman kaybı olarak görülür fakat ileriye dönük işleri hızlandırır.

2.5 Sprint Değerlendirme (Sprint Review)

Sprint Değerlendirme, her bir Sprintin sonunda Ürün Parçasını görüp kontrol etmek ve gerekiyorsa Product Backlog’unu adapte etmek için düzenlenir. Sprint Değerlendirme boyunca, Scrum Takımı ve paydaşlar Sprintte yapılan işle ilgili görüşürler. Bu görüşmeye ve Sprint boyunca Product Backlog’unda yapılan değişikliklere dayanarak, katılımcılar değeri en üst seviyeye çıkarmak için yapılabilecek yeni şeyleri konuşurlar. Bu gayrı resmî bir toplantıdır, bir durum tespiti toplantısı değildir. Ürün Parçasını sunmanın amacı geribildirim almak ve işbirliğini güçlendirmektir.

Bir aylık Sprint için bu toplantının zaman sınırı 4 saattir. Daha kısa Sprintler için, bu süre genellikle daha kısadır. Scrum Master, etkinliğin gerçekleşmesini ve katılımcıların bunun amacını anlamasını temin eder. Scrum Master herkese zaman sınırı içerisinde kalmasını öğretir.

Sprint Değerlendirme şu unsurları içerir:

  •  Katılımcılar Ürün Sahibi tarafından davet edilen kilit paydaşlar ve Scrum Takımıdır
  •  Ürün Sahibi, Product Backlog kalemlerinden hangilerinin “Bitti” olup olmadığını açıklar
  •  Geliştirme Takımı Sprint boyunda neyin iyi gittiğini, hangi sorunlarla karşılaştığını ve bu sorunları nasıl çözdüğünü tartışır  Geliştirme Takımı “Bitti” dediği işi gösterir ve Ürün Parçasıyla ilgili soruları yanıtlar
  •  Ürün Sahibi, Product Backlog’unu tartışır. O güne kadar olan ilerlemeye dayanarak yaklaşık tamamlama sürelerini öngörür (eğer gerekliyse)
  •  Pazarın veya ürünün potansiyel kullanımının, sıradaki en değerli işin seçimini değiştirip değiştirmediğinin değerlendirilmesi
  •  Ürünün sıradaki yayını için zaman planının, bütçenin, potansiyel yeteneklerin ve pazarın değerlendirilmesi.
2.6 Sprint Retrospektifi (Sprint Retrospective)

Sprint Retrospektifi, Scrum Takımının kendini gözlemesi ve sıradaki Sprintte yapacağı iyileştirmelere ilişkin bir plan oluşturması için bir fırsattır.

Sprint Retrospektifi, Sprint Değerlendirmeden sonra ve Sprint Planlamadan önce yapılır. Bir aylık Sprint için 3 saatle sınırlıdır. Daha kısa Sprintler için etkinlik süresi genellikle daha kısadır. Scrum Master etkinliğin gerçekleşmesini ve katılımcıların etkinliğin amacını anlamasını temin eder. Scrum Master herkese toplantıyı zaman sınırı içerisinde tutmasını öğretir. Scrum Master, Scrum sürecini yönetme sorumluluğu sebebiyle herhangi bir takım üyesi gibi toplantıya katılır.

Sprint Retrospektifinin amaçları şunlardır:

  •  Son Sprintin insanlar, ilişkiler, süreç ve araçlar bakımından nasıl geçtiğini gözlemek
  •  İyi giden noktaları ve muhtemel iyileştirme alanlarını tespit edip sıralamak
  •  Scrum Takımının iş yapış tarzını iyileştirecek bir plan oluşturmak.

Scrum Master, sıradaki Sprinti daha etkili ve keyifli kılmak için geliştirme sürecini ve pratiklerini iyileştirme yönünde Scrum Takımını cesaretlendirir. Her Sprint Retrospektifi esnasında, Scrum Takımı “Bitti” tanımını uygun şekilde adapte ederek ürün kalitesini artıracak yolları planlar.

Sprint Retrospektifinin sonunda, Scrum Takımı sıradaki Sprintte uygulayacağı iyileştirme alanlarını tespit etmiş olur. Bu alanları iyileştirmek Scrum Takımının kendini gözleyerek adapte olmasıdır. İyileştirmeler herhangi bir anda yapılabilse de, Sprint Retrospektifi gözlem ve adaptasyona odaklanmak için bir resmî fırsattır.

 

3- Kavramlar / Araçlar (Artifacts)

3.1 Ürün Gereksinim Dokümanı (Product Backlog)

Product Backlog üründe ihtiyaç duyulan her şeyin sıralandığı bir listedir ve üründe yapılacak herhangi bir değişiklik için yegâne gereksinimler kaynağıdır. Ürün Sahibi, içeriği, erişilebilirliği ve sıralamasıyla Product Backlog’undan sorumludur.

Bir Product Backlog asla tam değildir. Başlarda ilk bilinen ve en iyi anlaşılan gereksinimleri gösterir. Ürün ve içinde kullanılacağı ortam değiştikçe Product Backlog de değişir. Product Backlog dinamiktir; ürünün kullanışlı, rekabetçi ve faydalı olabilmesi için neye ihtiyaç duyduğunu belirlemek amacıyla sürekli değişir. Bir ürün var oldukça, Product Backlog de var olur.

Product Backlog, ürüne gelecek yayınlarda yapılacak değişikliklerin kaynağı olan tüm özellikleri, işlevleri, gereksinimleri, iyileştirmeleri ve düzeltmeleri sıralar. Product Backlog kalemlerinin tanımı, sırası, tahmini ve değeri vardır.

Bir ürün kullanıldıkça, değer kazandıkça ve pazar geribildirim verdikçe, Product Backlog daha geniş ve ayrıntılı bir listeye dönüşür. Product Backlog canlı bir eser olduğu için gereksinimler sürekli değişir. İş gereksinimlerindeki, pazar koşullarındaki veya teknolojideki değişmeler Product Backlog’unda de değişikliklere neden olabilir.

Aynı ürün üzerinde çoğunlukla birden fazla Scrum Takımı çalışır. Ürünle ilgili yapılacak işleri tarif etmek için tek bir Product Backlog kullanılır. Böyle bir durumda Product Backlog kalemleri gruplandırılabilir.

Product Backlog’unu arındırma (refinement), Product Backlog’undaki kalemlere ayrıntı, tahmin ve sıra özellikleri ekleme eylemidir. Ürün Sahibi ve Geliştirme Takımının Product Backlog kalemlerinin ayrıntıları üzerinde çalıştığı bitmeyen bir süreçtir. Product Backlog arındırma çalışması esnasında kalemler gözden geçirilir ve güncellenir. Scrum Takımı arındırmanın ne zaman ve nasıl yapılacağına karar verir. Arındırma işlemi genellikle Geliştirme Takımının kapasitesinin %10’undan fazlasını almaz. Ancak Product Backlog kalemleri Ürün Sahibi tarafından veya onun takdiriyle her an güncellenebilir.

Üst sırada olan Product Backlog kalemleri genelde daha açıktır ve alt sıradakilerden daha ayrıntılıdır. Açıklık ve ayrıntı arttıkça daha isabetli tahminler yapılabilir. Sıranın altına doğru indikçe ayrıntı azalır. Product Backlog kalemlerinin Sprint süresi içerisinde “Bitti” olabilmesi için Geliştirme Takımının sıradaki Sprintte meşgul olacağı kalemler arındırılır. Geliştirme Takımının bir Sprintte “Bitti” durumuna getirebileceği Product Backlog kalemleri Sprint Planlamada seçim için “Hazır” kabul edilir. Product Backlog kalemleri genellikle yukarıda tarif edilen arındırma faaliyetleriyle böyle bir şeffaflık derecesine ulaşır.

Geliştirme Takımı tüm tahminlerden sorumludur. Ürün Sahibi Geliştirme Takımını ilgili kalemleri anlaması ve uygun tercihler yapması için etkileyebilir. Ancak son söz, işi yapan Geliştirme Takımınındır.

Bir Hedefe Doğru İlerlemeyi İzlemek

Hedefe ulaşmak için geriye kalan iş her an hesaplanabilir. Ürün Sahibi en azından her Sprint Değerlendirme toplantısında geriye kalan toplam işi izler. Ürün Sahibi projelendirilen toplam işin istenen zamanda tamamlanıp tamamlanamayacağını anlamak için önceki Sprint Değerlendirme toplantısında kalan işle bu rakamı kıyaslar. Bu bilgi tüm paydaşlar nezdinde şeffaflaştırılır.

İlerlemeyi öngörmek için aşağı-tüketim (burn-down), yukarı-tüketim (burn-up) veya kümülatif akış (cumulative flow) gibi eğilimi ortaya koyan çeşitli planlama araçları  kullanılmaktadır. Bu araçların faydası kanıtlanmıştır. Ancak bunlar deneyciliğin önemini gölgeleyemezler. Karmaşık ortamlarda, ne olacağı bilinemez. İleriye dönük kararlar almada sadece geçmişte ne olduğu bilgisinden faydalanabilirsiniz.

3.2 Sprint İş Listesi (Sprint Backlog)

Sprint Backlog, Ürün Parçasını teslim etme ve Sprint Hedefine ulaşma planını ve Sprint için seçilen Ürün Kapsamı kalemlerini içerir.Sprint Backlog, Geliştirme Takımının Ürün Parçasında hangi işlevselliğin olacağının ve bu işlevselliği “Bitti” olan bir Ürün Parçasına dönüştürmek için gerekli olan işin öngörüsüdür.

Sprint Backlog, Geliştirme Takımının Sprint Hedefine ulaşmak için gerekli gördüğü tüm işleri görünür kılar.

Sprint Backlog, Günlük Scrumda ilerlemenin anlaşılabilmesi için yeterli ayrıntıyı içeren bir plandır. Geliştirme Takımı, Sprint boyunca Sprint Backlog’unu değiştirir; Geliştirme Takımı Sprint içerisinde plana uygun çalıştıkça ve Sprint Hedefine ulaşmak için gerekli olan işi daha fazla anladıkça Sprint Backlog belirginlik kazanır.

Yeni bir iş gerektikçe, Geliştirme takımı bunu Sprint Backlog’una ekler. İş yapıldıkça, kalan iş miktarı tahmini güncellenir. Gereksiz görülen her unsur plandan çıkarılır. Sadece Geliştirme Takımı, Sprint boyunca Sprint Backlog’unu değiştirebilir. Sprint Backlog, Geliştirme Takımının Sprint boyunca başarmayı planladığı işin son derece görünür ve gerçek-zamanlı bir resmidir ve sadece Geliştirme Takımına aittir.

Sprintin İlerlemesini İzlemek Sprint Backlog’undaki toplam kalan iş Sprintin herhangi bir anında hesaplanabilir. Geliştirme Takımı, Sprint Hedefini gerçekleştirmeye ne derece yakın olduğunu görebilmesi için en azından her Günlük Scrumda toplam kalan işi izler. Geliştirme Takımı, Sprint boyunca kalan işi izleyerek ilerlemesini yönetebilir.

 

3.3 Bitti Tanımı (Definition of Done)

Bir Product Backlog kalemi veya bir Ürün Parçası için “Bitti” deniyorsa, herkes “Bitti”nin ne olduğunu anlamalıdır. Scrum Takımından Scrum Takımına farklılık göstermekle birlikte, takımdakiler şeffaflığı sağlamak için, işin hangi durumda bitmiş sayılacağına dair aynı bilgiye sahip olmalıdır. İşte bu Scrum Takımının “Bitti” tanımıdır ve Ürün Parçası üzerindeki çalışmanın değerlendirilmesi için referanstır.

Aynı tanım, Geliştirme Takımına, Sprint Planlamada kaç Ürün Kapsamı kalemini seçeceğinde rehberlik eder. Her Sprintin amacı, Scrum Takımının “Bitti” tanımına uyacak şekilde potansiyel olarak yayınlanabilir işlevselliğe sahip Ürün Parçaları teslim etmektir.

Geliştirme Takımları her Sprintte işlevselliğe sahip bir Ürün Parçası teslim eder. Ürün Parçası, Ürün Sahibinin onu hemen yayınlama kararı verebilmesi için kullanılabilir haldedir. Eğer bir Ürün Parçasının “Bitti” tanımı, geliştirmeyi yapan organizasyonun kılavuzları, standartları ve genel iş yapış şeklinin bir parçasıysa, Scrum Takımları bunlara asgari standart olarak uymalıdır. Eğer “Bitti” tanımı organizasyonun iş yapışının bir parçası değilse, Geliştirme Takımı ürün için uygun olan bir “Bitti” tanımı yapmalıdır. Eğer sistem veya ürün yayını üzerinde çalışan birden fazla Scrum Takımı varsa, tüm Scrum Takımlarındaki Geliştirme Takımları ortak bir “Bitti” tanımı getirmelidir.

Her bir Ürün Parçası, tüm önceki ürün Parçalarının üzerine gelir ve bunların birlikte çalışmalarını temin edecek şekilde test edilir.

Scrum Takımları olgunlaştıkça, “Bitti” tanımlarının yüksek kalite için daha katı kriterler içerecek şekilde genişlemeleri beklenir. Her bir ürünün veya sistemin üzerinde yapılacak herhangi bir işlem için standart haline gelen bir “Bitti” tanımı olmalıdır.

 

3.4 Sprint Kalan Zaman Grafiği (Burndown Chart)
  • İlgili Sprint için tanımlanan görevlerin gözlemlenmesine yarayan görsel bir araç
  • Günlük bazda güncellenmelidir
  •  Bu sayede Sprint sonuna kadar tamamlanması gereken görev miktarı herkes tarafından izlenebilir
  •  Her gün sonunda üzerinde çalışılan görevle ilgili güncelleme yapılır ve böylece Burndown Chart güncel tutulur
  •  İstenen isteklerin iterasyon süresi içerisinde gerçekleşip gerçekleşemeyeceği bu şema yardımıyla izlenebilmektedir

Burndown Chart

 

Kaynaklar:
http://scrumtrainingseries.com (En kral kaynak)
http://www.ceng.metu.edu.tr/~temizer/Scrum/Scrum%20Guide%20-%20TR.pdf (Çıktısını alın)
http://www.scrumturkey.com/ (Çeşitli sayfalarda güzel bilgiler var)
http://www.yilmazcihan.com/
http://btisleri.com/scrum-nedir/
http://caglarkaya.piquestion.com/2014/07/01/244/
http://tr.wikipedia.org/wiki/Scrum
http://emsteknoloji.com/Scrum_Nedir

Not: Bu yazı yukardaki kaynaklardan derlenmiştir. Yer yer yorumlar serpiştirilmiştir.

İlk Yorumu Siz Yapın

Bir Cevap Yazın

E-posta hesabınız yayımlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir