Scrum

Yazılım geliştirme süreci ⓘ

Etkinlikler ve adımlar

Gereksinimler | Mimari | Tasarım | Yaşama geçirme | Sınama | Konuşlanma

Modeller

Agile | Cleanroom | Iterative | RAD | RUP | Spiral | Waterfall | XP | Scrum

Supporting disciplines

Configuration management | Documentation | Software quality assurance (SQA) | Project management | User experience design

Scrum Süreci ⓘ

Scrum (engl. "itişip kakışma“), yazılım geliştirme ve yazılım Mühendisliği'nde bir uygulama geliştirme çerçevesidir. Atik yazılım geliştirme yöntemi olarak çevik yönetim ve proje yönetimi'nde karmaşık bir ortamda ürünleri geliştirmek, sunmak ve sürdürmek için bir çerçevedir. Bu geliştirme çerçevesinin temel özelliği gözlemci, geliştirmeci ve tekrara dayalı olmasıdır. Birçok modern yazılım projesinin oldukça karmaşık olduğu ve en baştan tümünü planlamanın zor olacağı şeklindeki bir varsayımdan hareket eder. Bu karmaşıklığı üç ilke ile azaltmaya çalışır. ⓘ

1. Şeffaflık: Projedeki ilerlemeler ve sorunlar günlük olarak tutulur ve herkes tarafından izlenebilir olması sağlanır.
2. Gözlem : Ürünün parçaları ya da fonksiyonları düzenli aralıklarla teslim edilir ve değerlendirilir.
3. Uyumlanma: Ürün için gereksinimler en baştan bir defalığına belirlenmez, bilakis her teslimat tekrar değerlendirilir ve duruma göre uyarlamalar yapılır. ⓘ

Amaç başlangıçta hayal edilen ve tasarlanana uyan bir ürünün, hızlı, ucuz ve kaliteli şekilde üretilmesidir. Tasarlanan ürünün gerçekleştirilmesi, müşteri/kullanıcı tarafından mümkün olduğunca detaylı şekilde hazırlanmış bir talepler listesinin aşama aşama gerçekleştirilmesi biçiminde yapılmaz. Bunun yerine müşteri/kullanıcı tarafından istenilen ve tanımlanan işlevler, iki ya da dört haftalık "Sprint" adı verilen dönemler içerisinde geliştirilir ve yeniden gözden geçirilir. Bu kullanıcı bazlı gereksinim tanımı Kullanıcı Hikayesi olarak nitelenir ve özellikler defterinde yer alır. Her Sprint sonunda yazılımın fonksiyonel bir parçası bitmiş ve müşteriye teslim edilebilir bir durumda olur. Scrum Çevik yazılım geliştirme prensiplerini hayata geçiren bir yöntemdir. ⓘ

Scrum karmaşık projelerin yönetimi için bir çatıdır (Çatı anlayışı bitmiş bir program değil, yazılımın bir çerçevesidir). ⓘ

Scrum veya SCRUM, araştırma, satış, pazarlama ve ileri teknolojiler de dahil olmak üzere diğer alanlarda kullanılmasına rağmen, başlangıçta yazılım geliştirmeye vurgu yapan bir proje yönetimi çerçevesidir. On veya daha az üyeden oluşan ekipler için tasarlanmıştır ve bu ekipler çalışmalarını sprint adı verilen, bir aydan uzun olmayan ve genellikle iki hafta süren zaman kutulu yinelemeler içinde tamamlanabilecek hedeflere bölerler. Scrum ekibi, günlük scrum (bir çeşit stand-up toplantısı) adı verilen 15 dakika veya daha kısa süreli günlük toplantılarda ilerlemeyi değerlendirir. Sprintin sonunda ekip iki toplantı daha düzenler: geri bildirim almak için paydaşlara yapılan işi gösteren sprint incelemesi ve ekibin düşünmesini ve gelişmesini sağlayan sprint retrospektifi. ⓘ

Scrum Agile etkinlikleri, 2020 Scrum Kılavuzu'na dayanmaktadır ⓘ

İsim

Scrum terimi rugby'den ödünç alınmıştır ve burada oyunculardan oluşan bir oluşum söz konusudur. Scrum terimi, ekip çalışmasını vurguladığı için makalenin yazarları tarafından seçilmiştir. Yazılım geliştirme terimi scrum ilk olarak 1986 yılında Hirotaka Takeuchi ve Ikujiro Nonaka tarafından kaleme alınan "Yeni Ürün Geliştirme Oyunu" başlıklı makalede kullanılmıştır. Makale Harvard Business Review dergisinin Ocak 1986 sayısında yayımlanmıştır. ⓘ

Scrum zaman zaman SCRUM olarak büyük harflerle yazılmaktadır. Kelimenin kendisi bir kısaltma olmamakla birlikte, büyük harfle yazılması muhtemelen Ken Schwaber'in başlığında SCRUM'u büyük harfle yazan ilk makalesinden gelmektedir. ⓘ

Scrum teriminin ticari markasının sona ermesine izin verilmiş olsa da, artık bir bireyden ziyade daha geniş bir topluluğun sahip olduğu genel bir ticari marka olarak kabul edilmektedir. ⓘ

Anahtar fikirler

Scrum, karmaşık ürünlerin geliştirilmesi, teslim edilmesi ve sürdürülmesi için hafif, yinelemeli ve artımlı bir çerçevedir. Bu çerçeve, ürün geliştirmeye yönelik geleneksel, sıralı yaklaşımın varsayımlarına meydan okumakta ve tüm ekip üyelerinin fiziksel olarak bir arada bulunmasını veya yakın çevrimiçi işbirliğini ve ayrıca ilgili tüm ekip üyeleri ve disiplinler arasında günlük yüz yüze iletişimi teşvik ederek ekiplerin kendi kendilerini organize etmelerini sağlamaktadır. ⓘ

Scrum'ın temel ilkelerinden biri, müşterilerin istenenlerin kapsamını değiştireceğinin (genellikle gereksinimlerin değişkenliği olarak adlandırılır) ve öngörülebilir veya planlı bir yaklaşımın uygun olmadığı öngörülemeyen zorlukların olacağının kabul edilmesidir. Bu değişiklikler çeşitli kaynaklardan gelir, ancak scrum'a göre, nedenini anlamak önemsizdir ve değişim basitçe kabul edilmeli, benimsenmeli ve faydalar için analiz edilmelidir. ⓘ

Tarihçe

Hirotaka Takeuchi ve Ikujiro Nonaka, scrum terimini ürün geliştirme bağlamında 1986 tarihli Harvard Business Review makaleleri 'The New New Product Development Game' ile tanıtmışlardır. Takeuchi ve Nonaka daha sonra The Knowledge Creating Company (Bilgi Yaratan Şirket) adlı makalelerinde scrum'ın "örgütsel bilgi yaratma, [...] özellikle sürekli, aşamalı ve spiral olarak yenilik getirme konusunda iyi" bir yöntem olduğunu savunmuşlardır. ⓘ

Yazarlar, otomotiv, fotokopi ve yazıcı endüstrilerindeki imalat firmalarından alınan örnek olay incelemelerine dayanarak, ticari ürün geliştirmede hız ve esnekliği artıracak yeni bir yaklaşım tanımlamışlardır. Bu yaklaşıma bütünsel ya da rugby yaklaşımı adını vermişlerdir; çünkü tüm süreç, birbiriyle örtüşen çok sayıda aşama boyunca tek bir çapraz işlevli ekip tarafından yürütülmekte ve ekip "topu ileri geri paslayarak bir birim olarak mesafeyi kat etmeye çalışmaktadır". (Rugby futbolunda, her takımın forvetleri başları aşağıda birbirine kenetlenip topa sahip olmaya çalışırken oyunu yeniden başlatmak için bir scrum kullanılır). ⓘ

Scrum çerçevesi Schwaber'in DuPont Araştırma İstasyonu ve Delaware Üniversitesi'nde Babatunde Ogunnaike ile yaptığı araştırmaya dayanmaktadır. Ogunnaike, deneyselliğe dayanmayan yazılım gibi karmaşık ürünler geliştirme girişimlerinin, başlangıç koşulları ve varsayımlar değiştikçe daha yüksek risklere ve başarısızlık oranlarına mahkum olduğunu belirtmiştir. Esneklik ve şeffaflık ile sık denetim ve uyarlama kullanan ampirizm en uygun yaklaşımdır. ⓘ

1990'ların başında Ken Schwaber, şirketi Advanced Development Methods'da Scrum'a dönüşecek olan yaklaşımı kullanmış; Jeff Sutherland, John Scumniotales ve Jeff McKenna ise Easel Corporation'da benzer bir yaklaşım geliştirerek Scrum kelimesini kullanmışlardır. ⓘ

Sutherland ve Schwaber, fikirlerini tek bir çerçeve olan scrum'a entegre etmek için birlikte çalıştılar. Scrum'ı test ettiler ve sürekli olarak geliştirdiler. 1995'teki makaleleri, 2001'de Çevik Yazılım Geliştirme Manifestosu'na katkıları ve 2002'den bu yana scrum'ın dünya çapında yayılması ve kullanılmasına yol açtı. ⓘ

1995 yılında Sutherland ve Schwaber, Austin, Teksas'ta Nesne Yönelimli Programlama, Sistemler, Diller ve Uygulamalar '95 (OOPSLA '95) kapsamında düzenlenen İş Nesnesi Tasarımı ve Uygulaması Çalıştayı'nda scrum çerçevesini açıklayan bir bildiriyi birlikte sundular. Sonraki yıllarda Schwaber ve Sutherland bu materyali kendi deneyimleri ve gelişen iyi uygulamalarla birleştirerek scrum olarak bilinen yöntemi geliştirmek için işbirliği yaptılar. ⓘ

Schwaber 2001 yılında Mike Beedle ile birlikte çalışarak Scrum ile Çevik Yazılım Geliştirme adlı kitapta bu yöntemi tanımladı. Scrum'ın ürün geliştirmeyi planlama ve yönetme yaklaşımı, karar verme yetkisini operasyon özellikleri ve kesinlikleri seviyesine getirmeyi içerir. ⓘ

Schwaber 2002 yılında diğerleriyle birlikte Scrum Alliance'ı kurdu ve Sertifikalı Scrum akreditasyon serisini oluşturdu. Schwaber 2009'un sonlarında Scrum Alliance'tan ayrıldı ve paralel Professional Scrum akreditasyon serisini denetleyen Scrum.org'u kurdu. ⓘ

2009'dan bu yana Schwaber ve Sutherland tarafından Scrum Kılavuzu adlı kamuya açık bir belge yayınlanmış ve güncellenmiştir. Mevcut versiyonu Kasım 2020 olmak üzere 6 kez revize edilmiştir. ⓘ

Scrum Ken Schwaber ve Jeff Sutherland tarafından 1990'ların başında geliştirildi ve temel fikirleri Schwaber (Schwaber 2004) tarafından ortaya konmuştur. Scrum proje rolleri :

• Product Owner (Ürün Sahibi)
• Team (Takım)
• ScrumMaster (Scrum Ustası)

ve özellikle "geleneksel" "proje yöneticisi" rolü bulunmaz. Proje rollerinin görevlerine ek olarak Scrum proje akışını Sprint (en fazla dört hafta süren) anlayışıyla düzenler. ⓘ

Ken Schwaber, Jeff Sutherland ve diğerleri tarafından formüle edilen Çevik manifesto (Agile 2001) çevik yazılım geliştirme değerleri Scrumda vücut bulur: Çevik Yazılım Geliştirme Manifestosu'na göre; ⓘ

1) Süreçler ve araçlardan ziyade, bireyler ve etkileşimler, ⓘ

2) Kapsamlı dokümantasyondan ziyade, çalışan yazılım, ⓘ

3) Sözleşme pazarlıklarından ziyade, müşteri ile işbirliği, ⓘ

4) Bir plana bağlı kalmaktan ziyade, değişime cevap vermek, ⓘ

daha değerlidir... ⓘ

Scrum ekibi

Scrum'ın temel birimi, bir ürün sahibi, bir scrum ustası ve geliştiricilerden oluşan küçük bir ekiptir. Ekip kendi kendini yönetir, çapraz işlevseldir ve her seferinde tek bir hedefe odaklanır: ürün hedefi. ⓘ

Ürün sahibi

Ürünün paydaşlarını ve müşterinin sesini temsil eden (veya bir komitenin isteklerini temsil edebilir) ürün sahibi, iyi iş sonuçları sağlamaktan sorumludur. Dolayısıyla ürün sahibi, ürün birikiminden ve ekibin sunduğu değeri en üst düzeye çıkarmaktan sorumludur. Ürün sahibi, ürünü müşteri merkezli sonuçlar (tipik olarak - ancak bunlarla sınırlı olmamak üzere - kullanıcı hikayeleri) açısından tanımlar, bunları ürün birikimine ekler ve önem ve bağımlılıklara göre önceliklendirir. Bir scrum ekibinin yalnızca bir ürün sahibi olmalıdır (bir ürün sahibi birden fazla ekibi destekleyebilse de) ve bu rolün scrum master rolü ile birleştirilmemesi şiddetle tavsiye edilir. Ürün sahibi, ürün geliştirmenin iş tarafına odaklanmalı ve zamanının çoğunu paydaşlar ve ekiple irtibat kurarak geçirmelidir. Ürün sahibi, ekibin teknik bir çözüme nasıl ulaşacağını dikte etmez, ancak ekip üyeleri arasında fikir birliği arar. Bu rol çok önemlidir ve her iki tarafın da derinlemesine anlaşılmasını gerektirir: iş dünyası ve scrum ekibindeki mühendisler (geliştiriciler). Bu nedenle, iyi bir ürün sahibi, işletmenin neye ihtiyacı olduğunu iletebilmeli, neden buna ihtiyaç duyduklarını sorabilmeli (çünkü bunu başarmanın daha iyi yolları olabilir) ve gerektiğinde teknik bir dil kullanarak geliştiriciler de dahil olmak üzere tüm paydaşlara mesajı iletebilmelidir. Ürün sahibi, riski kontrol ederken ve değer elde ederken son derece karmaşık işleri yönetmek için scrum'ın ampirik araçlarını kullanır. ⓘ

İletişim, ürün sahibinin temel sorumluluklarından biridir. Öncelikleri aktarma ve ekip üyeleri ve paydaşlarla empati kurma becerisi, ürün geliştirmeyi doğru yönde yönlendirmek için hayati önem taşır. Ürün sahibi rolü, ekip ile paydaşları arasındaki iletişim boşluğunu doldurur, paydaşların ekibe karşı vekili ve genel paydaş topluluğuna karşı ekibin temsilcisi olarak hizmet eder. ⓘ

Ekibin paydaşlara karşı yüzü olarak ürün sahibinin paydaşlarla iletişim görevlerinden bazıları şunlardır

• Sürümleri tanımlamak ve duyurmak.
• Teslimat ve ürün durumunu iletmek.
• Yönetişim toplantıları sırasında ilerlemeyi paylaşmak.
• Önemli RIDA'ları (riskler, engeller, bağımlılıklar ve varsayımlar) paydaşlarla paylaşın.
• Öncelikleri, kapsamı, finansmanı ve takvimi müzakere edin.
• Ürün birikiminin görünür, şeffaf ve net olmasını sağlayın. ⓘ

İlişki kurma becerisi, bir ürün sahibinin sahip olması gereken önemli bir özelliktir - kendini başkasının yerine koyabilme becerisi. Bir ürün sahibi çeşitli geçmişleri, iş rolleri ve hedefleri olan farklı paydaşlarla konuşur ve bu farklı bakış açılarını takdir edebilmelidir. Etkili olmak için, ürün sahibinin hedef kitlenin ihtiyaç duyduğu ayrıntı düzeyini bilmesi akıllıca olacaktır. Geliştiriciler, beklentilere uygun bir ürün oluşturabilmek için kapsamlı geri bildirimlere ve spesifikasyonlara ihtiyaç duyarken, bir yönetici sponsor sadece ilerleme özetine ihtiyaç duyabilir. Gereğinden fazla bilgi vermek paydaşların ilgisini kaybedebilir ve zaman kaybına neden olabilir. Doğrudan iletişim, deneyimli ürün sahipleri tarafından tercih edilir. ⓘ

Bir ürün sahibinin etkili iletişim kurma becerisi, paydaş ihtiyaçlarını belirleme, paydaş çıkarları arasındaki öncelikleri müzakere etme ve gereksinimlerin etkili bir şekilde uygulanmasını sağlamak için geliştiricilerle işbirliği yapma tekniklerinde yetenekli olmasıyla da artar. ⓘ

Geliştiriciler

Geliştiriciler, her sprintte değer artışları oluşturmak için gereken tüm çalışmaları yürütür. ⓘ

Geliştiriciler terimi, sistemin veya ürünün geliştirilmesinde ve desteklenmesinde rol oynayan herkesi ifade eder ve diğerlerinin yanı sıra araştırmacıları, mimarları, tasarımcıları, veri uzmanlarını, istatistikçileri, analistleri, mühendisleri, programcıları ve test uzmanlarını içerebilir. Ancak, bazı kişiler 'geliştirici' teriminin kendileri için geçerli olmadığını düşündüklerinde ortaya çıkabilecek karışıklık nedeniyle, genellikle sadece ekip üyeleri olarak adlandırılırlar. ⓘ

Ekip kendi kendini organize eder. Ekibe ürün sahibi dışında hiçbir iş gelmemelidir ve scrum yöneticisinin ekibi dikkat dağıtıcı unsurlardan koruması beklenirken, ekip maksimum anlayış ve anında geri bildirim elde etmek için müşteriler ve/veya paydaşlarla doğrudan etkileşime girmeye teşvik edilir. ⓘ

Scrum ustası

Scrum, ekibin ürün hedeflerini ve çıktılarını teslim etme becerisinin önündeki engelleri kaldırmaktan sorumlu olan bir scrum ustası tarafından kolaylaştırılır. Scrum ustası geleneksel bir ekip lideri veya proje yöneticisi değildir, ancak ekip ile dikkat dağıtıcı etkiler arasında bir bariyer görevi görür. Scrum ustası, Scrum teorisi ve kavramları konusunda ekibe koçluk yaparak, genellikle kilit oturumları kolaylaştırarak Scrum çerçevesinin takip edilmesini sağlar ve ekibi büyümeye ve gelişmeye teşvik eder. Bu rol, bu ikili perspektifi güçlendirmek için ekip kolaylaştırıcısı veya hizmetkar-lider olarak da adlandırılmaktadır. ⓘ

Bir scrum ustasının temel sorumlulukları şunları içerir (ancak bunlarla sınırlı değildir):

• Ürün sahibinin, ekibin sürekli olarak ilerleme kaydedebilmesi için ihtiyaç duyulan işin iyi anlaşılmasını sağlayacak şekilde ürün birikimini sürdürmesine yardımcı olmak
• Kilit paydaşlardan gelen girdilerle birlikte ürün için yapılan tanımın belirlenmesinde ekibe yardımcı olmak
• Ürün için yüksek kaliteli özellikler sunmak amacıyla scrum ilkeleri çerçevesinde ekibe koçluk yapmak
• Kilit paydaşları ve organizasyonun geri kalanını scrum (ve muhtemelen çevik) ilkeleri konusunda eğitmek
• Scrum ekibinin ilerlemesinin önündeki engellerden kaçınmasına veya bu engelleri ortadan kaldırmasına yardımcı olmak
• Ekip içinde öz-örgütlenmeyi ve çapraz işlevselliği teşvik etmek
• Düzenli ilerleme sağlamak için ekip etkinliklerini kolaylaştırmak ⓘ

Scrum ustası, insanların ve kuruluşların kesinlik ve öngörülebilirlik umutlarını geride bırakarak deneysel ve yalın düşünceyi benimsemelerine yardımcı olur. ⓘ

Scrum ustası rolünün bir proje yöneticisinden farklılaştığı noktalardan biri, proje yöneticisinin insan yönetimi sorumluluklarının olması, scrum ustasının ise olmamasıdır. Scrum ustası, ekibin yetkilendirilmesi ve kendi kendini organize etmesi beklendiğinden sınırlı miktarda yönlendirme sağlar. Geleneksel komuta ve kontrol eğilimleri zorluklara neden olacağından Scrum, proje yöneticisinin rolünü resmi olarak tanımaz. ⓘ

Yönetici de kullanıcı ve müşteri gibi Scrum ekibine az oranda tabiidir. Ama scrumun yapısal çerçevesini yönetici belirler. Ek olarak da kaynaklar (Ressourcen) oluşturur(yer, alet vs.). Scrum ustasına destek olur ve mesleki personel organizesi sağlar ve Scrum ekibini dış taleplerden korumak gibi bir sorumluluğu vardır. ⓘ

Görevi: Projenin çerçevesi ile ilgilenir ve Scrum ustasının proje alanı içerisindeki belirlediği problemlerin çözümü ile ilgilenir. ⓘ

İş akışı

Sprint

Scrum çerçevesi

Scrum süreci

Sprint (iterasyon veya zaman kutusu olarak da bilinir) scrum'da geliştirmenin temel birimidir. Sprint zaman kutulu bir çalışmadır; yani her sprint için uzunluk önceden kararlaştırılır ve sabitlenir ve normalde bir hafta ile bir ay arasındadır, en yaygın olanı iki haftadır. ⓘ

Her sprint, sprint hedefinin tanımlandığı bir sprint planlama etkinliği ile başlar. Yaklaşan sprint için öncelikler birikmiş işler arasından seçilir. Her sprint iki etkinlikle sona erer:

• sprint gözden geçirme (geri bildirimlerini almak için ilerlemenin paydaşlara gösterilmesi)
• sprint retrospektifi (bir sonraki sprintler için derslerin ve iyileştirmelerin belirlenmesi). ⓘ

Scrum, yeni tamamlanan sprintin sonunda değerli, eyleme geçirilebilir çıktıları vurgular. Yazılım söz konusu olduğunda, bu muhtemelen ürünlerin tamamen entegre edilmiş, test edilmiş ve belgelenmiş ve potansiyel olarak piyasaya sürülebilir olmasını içerir. ⓘ

Sprint planlama

Bir sprintin başında, scrum ekibi bir sprint planlama etkinliği düzenler:

• Ürün sahibi tarafından belirlenen önceliklere dayanarak sprint sonuna kadar teslim etmeyi öngördükleri şeyin kısa bir açıklaması olan sprint hedefi üzerinde anlaşmaya varmak
• Bu hedefe katkıda bulunan ürün biriktirme öğelerini seçin
• O sprint sırasında hangi öğelerin yapılmasının amaçlandığını karşılıklı olarak tartışarak ve üzerinde anlaşarak bir sprint birikimi oluşturun

Sprint planlamasının maksimum süresi dört haftalık bir sprint için sekiz saattir. Ayrıntılı çalışma detaylandırıldıkça, ekip bu çalışmayı tek bir sprintte tamamlayamayacağına inanıyorsa, bazı ürün biriktirme listesi öğeleri bölünebilir veya ürün biriktirme listesine geri döndürülebilir. ⓘ

Günlük scrum

Bilgisayar odasında günlük scrum. Bu merkezi konum, ekibin zamanında başlamasına yardımcı olur. ⓘ

Bir sprint sırasında her gün, geliştiriciler belirli yönergelerle günlük bir scrum (bazen ayakta yapılır) düzenler: Tüm geliştiriciler hazırlıklı gelir. Günlük scrum:

• sprint hedefine yönelik ilerlemenin denetlenmesine odaklanır
• her gün aynı saatte ve yerde gerçekleşmelidir
• on beş dakika ile sınırlıdır (zaman kısıtlaması)
• ekip nasıl karar verirse öyle yürütülür
• başkalarını da içerebilir, ancak sadece geliştiriciler konuşmalıdır.
• scrum yöneticisi tarafından kolaylaştırılabilir
• ilerlemenin önündeki engelleri belirleyebilir (örneğin, engel, risk, sorun, gecikmiş bağımlılık, temelsiz olduğu kanıtlanan varsayım)
• tartışmalara yer vermiyor
• ilerleme çizelgelerini güncellemek için bir araç değildir

Günlük scrum sırasında ayrıntılı tartışmalar yapılmamalıdır. Bir kez bittiğinde, bireysel üyeler sorunları ayrıntılı olarak tartışabilir, bu genellikle 'ara oturum' veya 'after party' olarak bilinir. Belirlenen sorunlar veya hatalar, bir çözüme ulaşmak için çalışmak amacıyla günlük scrum dışında toplu olarak tartışılmalıdır. ⓘ

Ekibin bu etkinliğe değer vermediği durumlarda, bunun nedenini belirlemek ve ekibi ve paydaşları Scrum ilkeleri konusunda eğitmek veya ekibi sprint ilerlemesi hakkında tam olarak bilgilendirmek için kendi yöntemlerini tasarlamaya teşvik etmek scrum yöneticisinin sorumluluğundadır. ⓘ

Sprint gözden geçirme

Bir sprintin sonunda ekip tarafından gerçekleştirilir:

• Tamamlanan çalışmayı paydaşlara sunar (diğer adıyla demo)
• gibi konularda paydaşlarla işbirliği yapar:
  • tamamlanan ürün artışı hakkında geri bildirim davet etmek
  • tamamlanmamış işin (planlanmış veya başka türlü) etkisinin tartışılması
  • Gelecek çalışmalar için öneriler almak (bir sonraki aşamada ne üzerinde çalışılacağına dair rehberlik)

Ürün Sahipleri bu etkinliği, ürün birikimini paydaşlarla birlikte gözden geçirmek ve iyileştirmek için değerli bir fırsat olarak görmelidir. ⓘ

Sprint gözden geçirmeleri için yönergeler:

• Tamamlanmamış işler gösterilmemelidir; paydaşlara alacakları ürün artışları sunulmalıdır, ancak gerekirse devam eden işleri de görmeyi talep edebilirler. Ancak ekip sadece yapılanları göstermeye hazır olmalıdır.
• Önerilen süre iki haftalık bir sprint için iki saattir (diğer sprint süreleri için orantılıdır). ⓘ

Sprint retrospektifi

Sprint retrospektifinde ekip

• geçmiş sprint(ler) üzerine düşünür
• Son Sprint'in nasıl gittiğini inceler (bireyler, etkileşimler, süreçler, araçlar, Bitti tanımı)
• sürekli süreç iyileştirme eylemlerini belirler ve kabul eder ⓘ

Sprint retrospektifleri için yönergeler:

• Sprint retrospektiflerinde dikkate alınması önerilen üç alan şunlardır:
  • Sprint sırasında neler iyi gitti?
  • Ne iyi gitmedi?
  • Bir sonraki sprintte neleri farklı yapabiliriz?
• Süre, dört haftalık bir sprint için maksimum üç saattir, diğer sprint süreleri için orantılıdır (örneğin, iki haftalık bir sprint için bir buçuk saat).

Scrum ustası bu etkinliği kolaylaştırabilir, ancak ekibin bir parçası olarak da hazır bulunabilir. ⓘ

Backlog iyileştirme

Başlangıçta temel bir scrum uygulaması olmamasına rağmen, backlog arıtma (eski adıyla tımarlama) Scrum Kılavuzuna eklenmiş ve bir sprint'e giren ürün biriktirme öğelerinin kalitesini yönetmenin bir yolu olarak benimsenmiştir. Bu, yeni bilgiler ışığında ürün biriktirme listesi öğelerinin gözden geçirilmesi ve değiştirilmesi/güncellenmesi/yeniden sıralanması için devam eden bir süreçtir. ⓘ

İş listesini ve içindeki öğeleri değiştirme nedenleri şunları içerebilir:

• Daha büyük öğeler birden fazla küçük öğeye bölünebilir
• Kabul kriterleri netleştirilebilir
• Bağımlılıklar belirlenebilir ve araştırılabilir
• Bir öğe daha fazla keşif ve analiz gerektirebilir
• Öncelikler değişmiş olabilir; beklenen getiriler artık farklı olacaktır ⓘ

İyileştirme, öğelerin sprint planlaması için geliştiriciler tarafından anlaşılır ve yürütülebilir hale getirilecek şekilde uygun şekilde hazırlanması ve sıralanması anlamına gelir. ⓘ

İş listesi teknik borcu da içerebilir (tasarım borcu veya kod borcu olarak da bilinir). Bu, yazılım geliştirmede, daha uzun sürecek daha iyi bir yaklaşım kullanmak yerine şimdi kolay bir çözüm seçmenin neden olduğu ek yeniden çalışmanın zımni maliyetini yansıtan bir kavramdır. ⓘ

Bir ekibin sprint kapasitesinin yüzde 10'una kadarının backlog iyileştirmesine yatırılması tavsiye edilir. Daha olgun ekipler bunu planlanmış tanımlı bir etkinlik olarak değil, doğal iş akışının bir parçasını oluşturan, gerektiğinde ürün birikimini iyileştiren ve ayarlayan geçici bir faaliyet olarak görecektir. ⓘ

Bir sprinti iptal etme

Ürün sahibi gerekirse bir sprinti iptal edebilir ve bunu diğerlerinden (geliştiriciler, scrum master veya yönetim) gelen girdilerle yapabilir. Örneğin, son dış koşullar sprint hedefinin değerini ortadan kaldırabilir, bu nedenle devam etmek anlamsızdır. ⓘ

Bir sprint anormal bir şekilde sonlandırıldığında, bir sonraki adım, sonlandırmanın nedeninin gözden geçirildiği yeni bir sprint planlaması yapmaktır. ⓘ

Eserler

Artifaktlar, projedeki işleri yönetmek için kullanılan dokümantasyonu ifade eder. ⓘ

Ürün biriktirme listesi

Ürün birikimi, yapılacak işlerin bir dökümüdür ve ekibin bir ürün için koruduğu ürün gereksinimlerinin sıralı bir listesini içerir. İş listesi öğeleri için yaygın formatlar arasında kullanıcı hikayeleri ve kullanım senaryoları bulunur. Bu gereksinimler özellikleri, hata düzeltmelerini, işlevsel olmayan gereksinimleri vb. tanımlar - uygulanabilir bir ürün sağlayan her şey. Ürün sahibi, risk, iş değeri, bağımlılıklar, boyut ve ihtiyaç duyulan tarih gibi hususlara göre ürün biriktirme listesi öğelerine (PBI'ler) öncelik verir. ⓘ

Ürün biriktirme listesi "neye ihtiyaç duyulduğu, ne zaman ihtiyaç duyulduğuna göre sıralanır" ve herkes tarafından görülebilir ancak yalnızca ürün biriktirme listesi öğelerini yönetmek ve sürdürmekten sorumlu olan ürün sahibinin onayıyla değiştirilebilir. ⓘ

Ürün biriktirme listesi, ürün sahibinin iş değerine ilişkin değerlendirmesini içerir ve ekibin çaba veya karmaşıklığa ilişkin değerlendirmesini de içerebilir; bu değerlendirme genellikle, ancak her zaman değil, yuvarlatılmış Fibonacci ölçeği kullanılarak hikaye noktaları cinsinden ifade edilir. Bu tahminler, ürün sahibinin zaman çizelgesini ölçmesine yardımcı olur ve ürün biriktirme listesi öğelerinin sıralamasını etkileyebilir; örneğin, aynı iş değerine sahip iki özellik için ürün sahibi, daha düşük geliştirme çabasına sahip (çünkü yatırım getirisi daha yüksektir) veya daha yüksek geliştirme çabasına sahip (çünkü daha karmaşık veya daha risklidir ve bu riski daha erken ortadan kaldırmak isterler) işin daha erken teslim edilmesini planlayabilir. ⓘ

Ürün biriktirme listesi ve her bir ürün biriktirme listesi öğesinin iş değeri ürün sahibinin sorumluluğundadır. Her bir öğeyi teslim etmek için harcanacak çaba hikaye puanı veya zaman olarak tahmin edilebilir. Ekip, hikaye puanı cinsinden tahmin yaparak bireysel geliştiricilerin bağımlılığını azaltır; bu özellikle geliştiricilerin sprint tesliminden sonra sıklıkla başka işlere atandığı dinamik ekipler için yararlıdır. Örneğin, bir kullanıcı hikayesi (Fibonacci dizisi kullanılarak) 5 olarak tahmin edilirse, üzerinde kaç geliştiricinin çalıştığına bakılmaksızın 5 olarak kalır ⓘ

Hikaye noktaları bir zaman kutusundaki çabayı tanımlar, bu nedenle zamanla değişmezler. Örneğin, bir kişi bir saat içinde yürüyebilir, koşabilir veya tırmanabilir, ancak harcanan çaba açıkça farklıdır. Fibonacci dizisindeki terimler arasındaki boşluk ilerlemesi, ekibi dikkatlice düşünülmüş tahminler sunmaya teşvik eder. 1, 2 veya 3'lük tahminler benzer çabalar anlamına gelir (1 önemsizdir), ancak ekip 8 veya 13 (veya daha yüksek) tahmin ederse, hem teslimat hem de bütçe üzerindeki etki önemli olabilir. Hikaye puanlarını kullanmanın değeri, ekibin önceki sprintlerdeki benzer çalışmaları karşılaştırarak bunları yeniden kullanabilmesidir, ancak tahminlerin o ekibe göre göreceli olduğu kabul edilmelidir. Örneğin, bir ekip için 5 olan tahmin, daha deneyimli ve daha yüksek kapasiteye sahip geliştiricilerden oluşan bir başka ekip için 2 olabilir. ⓘ

Her ekibin bir ürün sahibi olmalıdır, ancak birçok durumda bir ürün sahibi birden fazla ekiple çalışabilir. Ürün sahibi, ürünün değerini en üst düzeye çıkarmaktan sorumludur. Ürün sahibi girdi toplar ve birçok kişiden geri bildirim alır ve birçok kişi tarafından lobi faaliyetlerine maruz kalır, ancak nihayetinde neyin inşa edileceği konusunda son kararı verir. ⓘ

Ürün biriktirme listesi:

• Yeni özellikler, eski özelliklerin değiştirilmesi, özelliklerin kaldırılması ve sorunların giderilmesi dahil olmak üzere bir ürünü değiştirme taleplerini kaydeder
• Geliştiricilerin ürünün iş faydasını en üst düzeye çıkaran çalışmalar yapmasını sağlar ⓘ

Tipik olarak, ürün ve müşteriler hakkında yeni bilgiler ortaya çıktıkça gelişen ürün birikimini iyileştirmek için tüm ekip birlikte çalışır ve bu nedenle daha sonraki sprintler yeni çalışmaları ele alabilir. ⓘ

Yönetim

Ürün biriktirme listesi, en basit haliyle, üzerinde çalışılacak öğelerin bir listesidir. İşlerin nasıl ekleneceği, çıkarılacağı ve sıralanacağı konusunda iyi belirlenmiş kurallara sahip olmak, tüm ekibin ürünü nasıl değiştireceği konusunda daha iyi kararlar almasına yardımcı olur. ⓘ

Ürün sahibi, ürün biriktirme listesi öğelerini en kısa sürede ihtiyaç duyulanlara göre önceliklendirir. Geliştiriciler, sprint hedefinden etkilenerek gelecek sprint için öğeleri seçer ve bu öğeleri ürün birikiminden sprint birikimine, yani oluşturacakları öğelerin listesine taşır. Kavramsal olarak, sprint hedefi listenin en üstündeki yüksek öncelikli öğelerden etkilenir, ancak sprint içinde daha fazla iş yapmak için zaman kalmışsa, geliştiricilerin bazı düşük öncelikli öğeleri aldığını görmek alışılmadık bir durum değildir. ⓘ

Yüksek öncelikli öğeler (biriktirme listesinin en üstünde yer alan), geliştiricilerin üzerinde çalışmasına uygun olacak şekilde daha fazla ayrıntıya bölünmelidir. İş listesi ne kadar aşağıya inerse, öğeler o kadar az ayrıntılı olacaktır. Schwaber ve Beedle'ın belirttiği gibi "Öncelik ne kadar düşükse, biriktirme listesi öğesini zar zor seçene kadar o kadar az ayrıntı." ⓘ

Ekip birikmiş işler üzerinde çalışırken, değişimin kendi çevrelerinin dışında gerçekleştiği varsayılmalıdır - ekip, yararlanılması gereken yeni pazar fırsatları, ortaya çıkan rakip tehditleri ve müşterilerden gelen ve ürünün çalışma şeklini değiştirebilecek geri bildirimler hakkında bilgi edinebilir. Tüm bu yeni fikirler, ekibin birikimi yeni bilgileri içerecek şekilde uyarlamasını tetikleme eğilimindedir. Bu, çevik bir ekibin temel zihniyetinin bir parçasıdır. Dünya değişir, iş listesi asla bitmez. ⓘ

Sprint backlog

Sprint biriktirme listesi, geliştiricilerin bir sonraki sprintte ele almaları amaçlanan ürün biriktirme listesindeki öğelerin alt kümesidir. Geliştiriciler, bir sonraki sprint için kapasitelerini değerlendirmek üzere geçmiş performanslarını kullanarak ve bunu ne kadar 'çaba' harcayarak tamamlayabileceklerine dair bir kılavuz olarak kullanarak sprinti doldurmaya yetecek kadar iş yaptıklarını hissedene kadar bu birikimi doldururlar. ⓘ

Sprint biriktirme listesindeki işler asla geliştiricilere atanmaz (veya itilmez); ekip üyeleri biriktirme listesi önceliğine ve kendi beceri ve kapasitelerine göre işi gerektiği gibi çekerler. Bu, geliştiricilerin kendi kendini organize etmesini teşvik eder. ⓘ

Sprint backlog'u geliştiricilerin malıdır ve dahil edilen tüm tahminler geliştiriciler tarafından sağlanır. Scrum'ın bir parçası olmasa da, bazı ekipler mevcut sprintteki işin durumunu görselleştirmek için eşlik eden bir pano kullanır: Yapılacaklar, Yapılıyor, Bitti. ⓘ

Artış

Artış, sprint hedefini karşılayan sprintin potansiyel olarak yayınlanabilir çıktısıdır. Tamamlanan tüm sprint birikim öğelerinden oluşur ve önceki tüm sprintlerin çalışmalarıyla entegre edilir. Artım, scrum ekibinin Bitti Tanımına (DoD) göre tamamlanmış, tamamen işlevsel ve ürün sahibinin gerçekten dağıtmaya ve kullanmaya karar verip vermediğine bakılmaksızın kullanılabilir durumda olmalıdır. ⓘ

Uzantılar

İnsanların scrum kullanmasına yardımcı olmak için aşağıdaki eserler ve teknikler kullanılabilir. ⓘ

Burndown çizelgesi

Tamamlanmış bir sprint için her günün sonunda kalan çabayı gösteren örnek bir döküm tablosu. ⓘ

Genellikle scrum'da kullanılan (ancak scrum'ın bir parçası olmayan) bir burndown grafiği, kalan işi gösteren herkese açık bir grafiktir. Her gün güncellenir ve referans için hızlı görselleştirmeler sağlar. Burndown grafiğinin yatay ekseni kalan günleri gösterirken, dikey eksen her gün kalan iş miktarını gösterir. ⓘ

Sprint planlaması sırasında, ideal yakma tablosu çizilir. Ardından, sprint sırasında geliştiriciler kalan işlerle grafiği günceller, böylece grafik her gün güncellenir ve gerçek ile tahmin edilen arasındaki karşılaştırmayı gösterir. ⓘ

Kazanılan değer tablosu ile karıştırılmamalıdır. ⓘ

Sürüm yakma grafiği

Bir sürüm için her sprintte tamamlanan kapsamı gösteren örnek bir yakma tablosu (MVP = Minimum Uygulanabilir Ürün) ⓘ

Sürüm yakma grafiği, ekibin görünürlük sağlaması ve bir sürüme doğru ilerlemeyi takip etmesi için bir yoldur. Her sprintin sonunda güncellenen bu grafik, tahmini bir kapsamın sunulmasına yönelik ilerlemeyi gösterir. Sürüm yakma grafiğinin yatay ekseni bir sürümdeki sprintleri gösterirken, dikey eksen her sprintin sonunda tamamlanan iş miktarını gösterir (genellikle tamamlanan işin kümülatif hikaye noktalarını temsil eder). İlerleme, tahmini kapsamı temsil eden yatay bir çizgiyle buluşmak üzere büyüyen bir çizgi olarak çizilir; genellikle bugüne kadarki ilerlemeye dayalı olarak, belirli bir yayın tarihine kadar ne kadar kapsamın tamamlanabileceğini veya belirli bir kapsamı tamamlamak için kaç sprint gerekeceğini gösteren bir tahminle birlikte gösterilir. ⓘ

Sürüm yakma grafiği ne kadar işin tamamlandığını, ne kadar işin eklendiğini veya çıkarıldığını (yatay kapsam çizgisi hareket ederse) ve yapılacak ne kadar iş kaldığını görmeyi kolaylaştırır. ⓘ

Hazır tanımı (DoR)

Spesifikasyonların ve girdilerin iş kalemini başlatmak için yeterince açık bir şekilde belirlenip belirlenmediğini belirlemek için başlangıç kriterleri. ⓘ

Bitti Tanımı (DoD)

Sprint backlog öğesi üzerindeki çalışmanın tamamlanıp tamamlanmadığını belirlemek için çıkış kriterleri, örneğin: DoD tüm regresyon testlerinin başarılı olmasını gerektirir. Tamamlandı tanımı bir ekipten diğerine değişebilir ancak bir ekip içinde tutarlı olmalıdır. ⓘ

Hız

Bir ekibin tek bir sprint için toplam kapasite çabası, son sprintte tamamlanan iş değerlendirilerek elde edilir. Geçmiş hız verilerinin toplanması, ekibin kapasitesini, yani ne kadar işi rahatça başarabileceğini anlamasına yardımcı olmak için bir kılavuzdur. ⓘ

Bu metrik scrum topluluğunda tartışmalara neden olmuştur:

• Tüketilen hikaye puanları teslim edilen değere eşit değildir: ekip yapılan işi görebilir ve paydaşlara teslim edilebilir faydaları göz ardı edebilir
• dikkat dağıtıcı uygulamaların devreye girmesi: tahminlere karşı gerçekleşmeler, varyans incelemesi ve yeniden tahmin politikası ortaya çıkmaya başlar
• Yönetim, hızı bir performans ölçütü olarak görür ve bu nedenle hızı artırmaya çalışır:
  • kalite düşer - ekip eklenen iş yükünü karşılamak için "köşeleri kesmeye" başlar
  • moral bozulur - ekip rahat ve sürdürülebilir bir hızda çalışamaz ve artan baskı tükenmişliğe neden olur
  • tahminler zarar görür - geliştiriciler tampon oluşturmak için tahminleri şişirir ve aynı çabayı farklı bir ölçekte ölçerek "ölçütlerle oynar"
  • değer zarar görür - nihai etki, odağın iş değeri sunumundan uzaklaşması sonucunda paydaş memnuniyetsizliğine neden olan müdahaledir ⓘ

Bir ekibin teslimat kapasitesini anlamanın değeri olsa da hız, ayarlanabilen bir kadran değil, ekip için bir gösterge olarak düşünülmelidir. ⓘ

Spike

Bir konsepti araştırmak veya basit bir prototip oluşturmak için kullanılan zaman kısıtlı bir süre. Spike'lar sprintler arasında gerçekleşecek şekilde planlanabilir ya da daha büyük ekipler için bir spike birçok sprint teslim hedefinden biri olarak kabul edilebilir. Spike'lar genellikle bütçeyi güvence altına almak, bilgi birikimini artırmak veya bir kavram kanıtı üretmek amacıyla büyük veya karmaşık ürün birikimi öğelerinin tesliminden önce uygulanır. Bir spike'ın süresi ve hedef(ler)i başlamadan önce ekip tarafından kararlaştırılır. Sprint taahhütlerinden farklı olarak, spike'lar somut, sevk edilebilir, değerli işlevler sunabilir veya sunmayabilir. Örneğin, bir spike'ın amacı bir eylem planı üzerinde başarılı bir şekilde karara varmak olabilir. Süre dolduğunda spike sona erer, hedefe ulaşılmış olması gerekmez. ⓘ

İzleyici mermi

Drone spike olarak da adlandırılan izleyici mermi, mevcut mimariye, mevcut teknoloji setine, üretim kalitesinde kodla sonuçlanan mevcut en iyi uygulamalar setine sahip bir spike'tır. İşlevselliğin çok dar bir uygulaması olabilir, ancak atılacak bir kod değildir. Üretim kalitesindedir ve geri kalan iterasyonlar bu kod üzerine inşa edilebilir. Bu ismin askeri kökeni, merminin izlediği yolu görünür kılarak düzeltmelere olanak tanıyan mühimmattır. Genellikle bu uygulamalar, katmanların beklendiği gibi bağlandığını kanıtlamak için tek bir formun giriş alanını arka uca bağlamak gibi bir uygulamanın tüm katmanları boyunca 'hızlı bir atış' niteliğindedir. ⓘ

Sınırlamalar

Scrum'ın faydalarını elde etmek daha zor olabilir:

• Üyeleri coğrafi olarak dağınık veya yarı zamanlı olan ekipler: Scrum'da geliştiriciler yakın ve sürekli bir etkileşim içinde olmalı, ideal olarak çoğu zaman aynı alanda birlikte çalışmalıdır. Teknolojideki son gelişmeler bu engellerin etkisini azaltmış olsa da (örneğin, dijital bir beyaz tahta üzerinde işbirliği yapabilmek), Çevik manifesto en iyi iletişimin yüz yüze olduğunu ileri sürer.
• Üyeleri çok özel becerilere sahip olan ekipler: Scrum'da geliştiriciler, uzmanlık alanlarının dışındaki görevler üzerinde çalışmalarına izin veren T şeklinde becerilere sahip olmalıdır. Bu, iyi bir Scrum liderliği tarafından teşvik edilebilir. Çok özel becerilere sahip ekip üyeleri iyi katkı sağlayabilir ve sağlarken, diğer disiplinler hakkında daha fazla bilgi edinmeye ve onlarla işbirliği yapmaya teşvik edilmelidirler.
• Çok sayıda dış bağımlılığı olan ürünler: Scrum'da ürün geliştirmeyi kısa sprintlere bölmek dikkatli bir planlama gerektirir; kullanıcı kabul testi veya diğer ekiplerle koordinasyon gibi dış bağımlılıklar gecikmelere ve bireysel sprintlerin başarısız olmasına yol açabilir.
• Olgun veya eski ya da kalite kontrolü düzenlenmiş ürünler: Scrum'da, ürün artışları tek bir sprintte tamamen geliştirilmeli ve test edilmelidir; her sürüm için büyük miktarda regresyon testi veya güvenlik testi (örneğin, tıbbi cihazlar veya araç kontrolü) gerektiren ürünler, daha uzun şelale sürümlerine kıyasla kısa sprintlere daha az uygundur. ⓘ

Mevcut araçlar

Diğer çevik yaklaşımlar gibi, scrum'ın etkili bir şekilde benimsenmesi de mevcut çok çeşitli araçlarla desteklenebilir (ancak bunlara bağlı değildir). ⓘ

Birçok şirket, sprint backlog oluşturmak ve sürdürmek için elektronik tablolar gibi evrensel araçlar kullanır. Ürün geliştirme için scrum terminolojisini kullanan veya scrum dahil birden fazla ürün geliştirme yaklaşımını destekleyen açık kaynaklı ve tescilli yazılım paketleri de vardır. ⓘ

Diğer kuruluşlar scrum'ı yazılım araçları olmadan uygulamakta ve eserlerini kağıt, beyaz tahta ve yapışkan notlar gibi basılı formlarda muhafaza etmektedir. ⓘ

Scrum değerleri

Scrum, tüm ampirik süreç kontrollerinde olduğu gibi şeffaflık, denetim ve adaptasyondan oluşan üç sütun tarafından desteklenen geri bildirim odaklı ampirik bir yaklaşımdır. Scrum çerçevesindeki tüm çalışmalar sonuçtan sorumlu olanlar tarafından görülebilir olmalıdır: süreç, iş akışı, ilerleme, vb. Bunları görünür kılmak için scrum ekiplerinin geliştirilmekte olan ürünü ve ekibin ne kadar iyi çalıştığını sık sık denetlemesi gerekir. Sık denetim sayesinde ekip, çalışmalarının kabul edilebilir sınırların dışına çıktığını tespit edebilir ve süreçlerini ya da geliştirilmekte olan ürünü uyarlayabilir. ⓘ

Bu üç sütun, ekipte güven ve açıklık gerektirir ve scrum'ın aşağıdaki beş değeri bunu sağlar:

1. Bağlılık: Ekip üyeleri, her bir sprintte ekip hedeflerine ulaşmayı bireysel olarak taahhüt eder.
2. Cesaret: Ekip üyeleri, doğru olanı yapabilmek için çatışma ve zorluklarla birlikte çalışma cesaretine sahip olduklarını bilirler.
3. Odaklanma: Ekip üyeleri yalnızca ekip hedeflerine ve sprint birikimine odaklanır; birikim dışında hiçbir iş yapılmamalıdır.
4. Açıklık: Ekip üyeleri ve paydaşları çalışmaları ve karşılaştıkları zorluklar konusunda şeffaf olmayı kabul ederler.
5. Saygı: Ekip üyeleri Ekip üyeleri birbirlerinin teknik açıdan yetenekli olmalarına ve iyi niyetle çalışmalarına saygı duyar. ⓘ

Uyarlamalar

Scrum, birçok farklı amaca ulaşmak için çeşitli bağlamlarda kullanılır. Bu farklı amaçlara ulaşmak için Scrum sıklıkla uyarlanır veya adapte edilir. Scrum'ı uyarlamaya yönelik yaygın bir yaklaşım, Scrum'ın tüm ürün geliştirme yaşam döngüsünü kapsamaması nedeniyle Scrum'ın diğer yazılım geliştirme metodolojileriyle melezleştirilmesidir; bu nedenle, kuruluşlar daha kapsamlı bir uygulama oluşturmak için ek süreçler ekleme ihtiyacı duyarlar. Örneğin, ürün geliştirmenin başlangıcında, kuruluşlar genellikle iş vakası, gereksinim toplama ve önceliklendirme, ilk üst düzey tasarım ve bütçe ve program tahmini konularında süreç rehberliği ekler. ⓘ

Çeşitli yazarlar ve scrum kullanan insan toplulukları, scrum'ın belirli sorunlara veya kuruluşlara nasıl uygulanacağı veya uyarlanacağı konusunda daha ayrıntılı teknikler de önermiştir. Birçoğu bu metodolojik teknikleri, mimari ve yazılımdaki tasarım kalıplarına benzeterek 'kalıplar' olarak adlandırmaktadır. ⓘ

Scrumban

Scrumban, scrum ve kanban temelli bir yazılım üretim modelidir. Scrumban özellikle üretim hataları veya programlama hataları gibi sık ve beklenmedik iş öğeleri içeren ürün bakımı için uygundur. Bu gibi durumlarda scrum çerçevesinin zaman sınırlı sprintleri daha az faydalı olarak algılanabilir, ancak ekibe ve eldeki duruma bağlı olarak scrum'ın günlük etkinlikleri ve diğer uygulamaları hala uygulanabilir. İş aşamalarının görselleştirilmesi ve eş zamanlı bitmemiş işler ve kusurlar için sınırlamalar Kanban modelinden aşinadır. Bu yöntemler kullanılarak ekibin iş akışı, her bir iş öğesi veya programlama hatası için minimum tamamlanma süresine izin verecek ve diğer yandan her bir ekip üyesinin sürekli olarak çalışmasını sağlayacak şekilde yönlendirilir. ⓘ

İşin her aşamasını göstermek için, aynı alanda çalışan ekipler genellikle post-it notları veya büyük bir beyaz tahta kullanır. Merkezi olmayan ekipler söz konusu olduğunda Assembla, Jira veya Agilo gibi aşama gösterim yazılımları kullanılabilir. ⓘ

Scrum ve kanban arasındaki en büyük fark, scrum'da işin sabit bir süreyi kapsayan sprintlere bölünmesi, kanban'da ise iş akışının sürekli olmasıdır. Bu, scrum'da her sprintten sonra boşaltılan iş aşaması tablolarında görülebilirken, Kanban'da tüm görevler aynı tabloda işaretlenir. Scrum çok yönlü bilgi birikimine sahip ekiplere odaklanırken, Kanban uzmanlaşmış, işlevsel ekipleri mümkün kılar. ⓘ

Scrum'ların Scrum'ı

Scrum'ların scrum'ı, aynı ürün üzerinde çalışan birden fazla ekip için scrum'ı geniş ölçekte çalıştırmak için kullanılan bir tekniktir ve özellikle örtüşme ve entegrasyon alanlarında yazılım tesliminin nasıl koordine edileceğine odaklanarak karşılıklı bağımlılıklarındaki ilerlemeyi tartışmalarına olanak tanır. Scrum'ların scrum'ının temposuna (zamanlamasına) bağlı olarak, her scrum ekibi için ilgili günlük scrum, diğer ekiplerden elçilerle scrum'ların scrum'ına katılmak üzere bir üyenin elçi olarak atanmasıyla sona erer. Bağlama bağlı olarak, elçiler teknik katkıda bulunanlar veya her takımın scrum ustası olabilir. ⓘ

Scrum'ların scrumu sadece bir ilerleme güncellemesinden ziyade, ekiplerin belirlenen riskleri, engelleri, bağımlılıkları ve varsayımları (RIDA'lar) çözmek, hafifletmek veya kabul etmek için toplu olarak nasıl çalıştıklarına odaklanmalıdır. Scrum'ların scrum'ı bu RIDA'ları risk panosu (bazen çözüldü, sahiplenildi, kabul edildi ve hafifletildi kelimelerinin baş harflerinden sonra ROAM panosu olarak da bilinir) gibi kendine ait bir birikim aracılığıyla izler ve bu da genellikle ekipler arasında daha fazla koordinasyon ve işbirliğine yol açar. ⓘ

Bu, her büyükelçinin aşağıdaki dört soruyu yanıtladığı günlük bir scrum'a benzer şekilde yürütülmelidir:

• Son görüşmemizden bu yana ekibiniz hangi riskleri, engelleri, bağımlılıkları veya varsayımları çözdü?
• Tekrar bir araya gelmeden önce ekibiniz hangi riskleri, engelleri, bağımlılıkları veya varsayımları çözüme kavuşturacak?
• Ekibinizi yavaşlatan veya yollarına çıkan yeni riskler, engeller, bağımlılıklar veya varsayımlar var mı?
• Başka bir ekibin yoluna çıkacak yeni bir risk, engel, bağımlılık ya da varsayım ortaya koymak üzere misiniz? ⓘ

Jeff Sutherland'ın yorumladığı gibi, ⓘ

Scrum of Scrums'ı ilk olarak ben tanımladığım için (Ken Schwaber IDX'te benimle birlikte çalışıyordu), Scrum of Scrums'ın bir 'meta Scrum' olmadığını kesin olarak söyleyebilirim. Benim kullandığım şekliyle Scrum'ın Scrum'ı, tüm ekiplerin çalışan yazılımlarını sprint sonunda Bitti Tanımına veya sprint sırasında sürümlere teslim etmekten sorumludur. PatientKeeper Sprint başına dört kez üretime teslim edildi. Ancestry.com iki haftalık Sprint başına 220 kez üretime geçmiştir. Hubspot günde 100-300 kez canlı yazılım sunar. Scrum of Scrums Master, bu işi yapmaktan sorumlu tutulmaktadır. Yani Scrum of Scrums operasyonel bir teslimat mekanizmasıdır. ⓘ

Büyük ölçekli scrum

Büyük ölçekli scrum (LeSS), scrum'ın orijinal amaçlarını kaybetmeden ölçeklendirme kuralları ve yönergeleri ile scrum'ı genişleten bir ürün geliştirme çerçevesidir. ⓘ

Çerçevenin iki seviyesi vardır: ilk LeSS seviyesi sekiz ekibe kadar tasarlanmıştır; 'LeSS Huge' olarak bilinen ikinci seviye, yüzlerce geliştiriciye kadar geliştirme için ek ölçeklendirme unsurları sunar. "Scrum'ı ölçeklendirmek, standart gerçek tek takımlı Scrum'ı anlamak ve benimseyebilmekle başlar. Büyük ölçekli Scrum, tek ekipli Scrum unsurlarının amacını incelemeyi ve standart Scrum kurallarının kısıtlamaları içinde kalarak aynı amaca nasıl ulaşılacağını bulmayı gerektirir." ⓘ

Bas Vodde ve Craig Larman, LeSS çerçevesini özellikle telekom ve finans sektörlerinde büyük ölçekli ürün geliştirmeyle ilgili deneyimlerinden yola çıkarak geliştirdiler. Scrum'ı ele alarak ve neyin işe yaradığını keşfetmek için birçok farklı deney deneyerek gelişti. Bu deneyler 2013 yılında LeSS çerçeve kurallarına dönüştürülmüştür. LeSS'in amacı, gereksiz karmaşık organizasyonel çözümleri çözerek ve bunları daha basit yollarla çözerek organizasyon karmaşıklığını 'azaltmaktır'. Daha az rol, daha az yönetim, daha az organizasyonel yapı. ⓘ

Eleştiri

Scrum etkinliklerinin üretkenliğe zarar verdiği ve gerçek üretken görevlere daha iyi harcanabilecek zamanı boşa harcadığı, genellikle etkinliğin amacının ve hedefinin yanlış anlaşılmasından kaynaklandığı, bu nedenle kısa süreli bir tartışmadan ziyade aşırı uzun ve kapsamlı bir toplantı olarak gerçekleştirildiği bildirilmiştir. Scrum uygulamaları, Çevik Manifesto'nun ruhuna uygun olarak doğru bir şekilde takip edilmediğinde, bir tür mikro yönetime dönüşme ve uygulamaların ortadan kaldırmaya çalıştığı aynı işlevsizliği yeniden ortaya çıkarma eğilimindedir. Scrum ayrıca işin tamamlanması için gereken çabanın doğru bir şekilde tahmin edilebileceğini varsayar, ancak çoğu zaman bu oldukça öngörülemez olabilir. Scrum, deneysel analiz ve deneme özgürlüğünü teşvik etmek için kuralcı uygulamaları kasıtlı olarak ihmal eder. Scrum, projeleri yönetmek için alternatif bir yaklaşımdan ziyade bir biçim olarak algılanmaktadır. Scrum'a ilk giriş, hemen yüksek kaliteli sonuçlar üretmeyecektir; sabırsızlık Scrum'ın yerleşme ve büyüme şansını elinden alır. Scrum'a yönelik yaygın işlevsiz yaklaşımlar artık Karanlık Scrum ve Çığlık gibi antipaternler olarak kabul edilmektedir. ⓘ

Roller

Scrum Süreç-Modeli net olarak üç çeşit rolü tanır: Ürün Sahibi, Takım ve Scrum Master ⓘ

Etkileşim

Scrum Ustası : Takımı korumak ve yardımcı olmak. Ürün sahibine yardımcı olmak. ⓘ

Ürün Sahibi : Kullanıcı hikâyelerinin ayrıntılarını takım ile konuşmak. Dış rollerdekiler ile "Kullanıcı Hikâyeleri"ni belirlemek. ⓘ

Geliştiriciler : Gereksinimlerin nasıl yapılacağını belirlemek ve standart kalite çerçevesinde (Bitti Tanımı) geliştirmek. ⓘ

Geliştirme Takımı

Yazılım ekibinin görevi ürün sahibinin taleplerine ve sıralamasına uygun ürünün işlevselliğini sağlamak ve belirlenen kalite standartlarına uymak koşuluyla ürünü teslim etmektir. Ne kadar ve hangi işlevlerin sprinte dahil olacağına kendileri karar verirler. ⓘ

Scrumda geliştirme takımı bir ekip olarak algılanır ve iyi ya da kötü sonuçlar takım elemanlarına çıkartılmaz bilakis takımı bir birim olarak algılar. Bir takım 5-9 kişiden oluşur. ⓘ

Ek olarak yazılım takımı kullanıcı hikâyelerinin çerçevesini tahmin edebilir ama kural olarak da bir günü geçmemelidir. ⓘ

Scrum takım içinde rol dağılımıyla ilgilenmez. Belirtildiği gibi Scrum bir yönetim metodudur. Tabii ki bütün roller ya da daha doğrusu yetenekler başarılı bir proje gelişimi için hazır olmak zorundadır. Bir takımda olması gereken özellikleri iki başlık altında ifade edebiliriz: 1) Kendi kendine organize ve küçük 2) Multidisipliner ve özerk ⓘ

Kullanıcı (User)

Kullanıcı ilerideki yazılımın/ürünün kullanıcısıdır. Ürünün nasıl bir perspektif ile kullanılacağı konusunda fikir verir ve gerçek hedef kitlesidir. Kullanıcı Sprint başlangıcı ve sonucunda ürünü test etme amaçlı yer alır ve geri bilgi akışı (Feedback) sağlar. ⓘ

• ) Kullanılabilirlik (Usability) konusunda takıma değerli ipuçları verir
• ) Takım ve ürün sahibi kullanıcı bilgileri doğrultusunda Sprint-planını uyarlar ve son durum tekrar kullanıcı tarafından test edilir. ⓘ

Takım ve Etkileşim

Rol dağılımında takım kendi kendini organize eder. Ne Scrum ustası ne de ürün sahibinin takım içinde kimin neyi ne zaman kiminle yapacaklarına dair bir yaptırımı olmaz. Scrum ustasının vazifesi yalnızca takımın farklı etkenlerlerle rahatsız edilmemesine dikkat etmektir. ⓘ

Rollerin istismar riski

Scrum'da klasik "Proje Yöneticisi'nin olmayışı, özellikle deneyimsiz bir Scrum ekibinde, Scrum ustası ya da ürün sahibinin (Product Owner) bu rolü üstlenmesi tehlike yaratır ve takımın Özerklik statüsüne zarar vererek, Scrumda sapmalara yol açar.Bu tehlikeyi azaltmanın yolu Scrum-ustası ve ürün sahibinin bir Scrum-Expert'inden yardım almasıyla sağlanabilir. ⓘ

Toplantılar

Sprint Planlama Toplantısı 1

Bu toplantıda ürün sahibi kendi yazılım takımına ürün içeriğinde(Product Backlog) kararlaştırılan kullanıcı hikayelerini (User Stories) öncelik sırasına göre belirtir ve gereksinimler takım tarafından netleştirilip yazılı olarak kaydedilir. Kullanıcı da işlevsellik konusunda önemli bilgiler verebilir. Bunun dışında ürün sahibi ve takım sprint içinde olması gereken işlevler ve kriterler üzerinde anlaşırlar (bkz. Definition of Done). ⓘ

Amaç kullanılabilir yazılım elde etmektir: test edilmiş, entegre olmuş ve kullanıcıya açılmış olmalıdır. ⓘ

Sprint'in kabul şartları kabul kriterleri(test, işlev, performans) ile etkileşimlidir. Bu tarz kararlar sprint sonucunda net şekilde belirlenir ve belirtilen fonksiyonların gerçekten içerdiklerine bakılır ve incelenir. ⓘ

Açıklamalar yapıldıktan sonra Scrum ustası takımına gelecek sprint de kaç adet kullanıcı hikayesi olacağını sorar ve tek tek değerlendirilip dış baskı olmadan erişilebilirliğine bakılır. [26] ⓘ

Süre: 60 dakika Sprint(haftalık) ⓘ

Sprint Planlama Toplantısı 2

Sprint-plan 1 de "NE?" ön planda iken, burada "NASIL?" sorusu ön plana çıkar. Yazılım takımı hangi kullanıcı hikâyelerinin Sprint'e dahil olduğunu bilir ve uygulamanin(teorik) teknik boyutu açıklanır. Toplantı Takım'ın kendi sorumluluğunda organize edilir. Genellikle küçük gruplar oluşturulup yapı, test, açık gibi konulara açıklık verilir. Burada beklenen sonuç görevlerin bir günlük süreyi aşmayacak şekilde bitirilmesini kapsar. ⓘ

Görevler belirlenen kullanıcı hikâyelerinden hareketle duvara ya da beyaz tahtaya (Taskboard) asılır bu sayede hangisinin işlemde ya da sırada olduğu bilinir. ⓘ

Süre : 60 dakika her Sprint(haftalık)de ⓘ

Sprint-plan 1 ve 2 aynı gün içerisinde yapılmalıdır. ⓘ

Günlük Scrum (Daily Scrum)

Günlük Scrum ⓘ

Her iş günü başlamadan evvel 15 dakikalık bilgi paylaşımı için günlük Scrum toplantısı yapılır. Bu görüşmede herhangi bir problem değerlendirilmez, yalnızca 3 tema işlenir: dün ne yaptım, bugün ne yapacağım, beni ne engelliyor. Eger belirtilen görev bir günde bitmesi mümkün değil ise, görev parçalanıp takıma dağıtılır. ⓘ

Eger 15 dakıka içinde bazı sorular cevap bulamadığı durumlarda Scrum ustası not alıp bir sonraki toplantıya taşır ya da kendisi çözüm üretir. ⓘ

Sprint Değerlendirmesi (Sprint Review)

Değerlendirme Sprint'in sonunda takım tarafından yapılır ve başlangıçta belirlenen hedeflerin kapsamında olup olmadığı Ürün sahibi tarafından değerlendirilir. Eğer teslim edilen işlevde eksiklik(test olmamış ise) var ise o kullanıcı hikâyesi tekrar dan, ürün sahibi tarafından ürün içeriğine(Product Backlog) gönderilir ve öncelik sırası verilir. ⓘ

Değerlendirmeye kullanıcının(User) katılımı da işlevin testi, ürün tasarımı ve kullanıcı bakışı açısından çok önemlidir. Kullanıcı Hıkayelerin de bir eksiklik var ise Scrum ustası tarafından not alınıp, ürün sahibi tarafından ürün içeriğine aktarılır. Süre olarak 1 ayda biten Sprint in değerlendirmesi en fazla 4 saat sürmeli, az süren sprintlerde süre uyarlanır. ⓘ

Sprint Retrospektif (Geçmişe Bakış)

Geçmişe bakış toplantıları, Sprint Değerlendirme toplantılarından sonra ve Sprint Planlama toplantılarından önce yapılırlar ve geçmiş sprint'teki tecrübeler masaya yatırılarak iyileştirmeler belirlenir. Scrum yönteminin en önemli özelliklerinden birisi bu süreçte suçlu/suçsuz eleştirilerinin yapılmamasıdır. ⓘ

Yapı Taşları

Scrum Task ⓘ

Sprint İçeriği

Sprint içeriği halledilmesi gereken görevleri gösterir. Bu amaç için dört sütunlu bir görev tahtası kullanılır: 1. sütun'da Sprint'de bulunan İş Parçacıkları ("Stories") ⓘ

2. sütun'da görevler ("ToDo") ⓘ

3. sütun'da çalışma ("In Progress") ve 4.sütun'da teslime hazır ("Done") olan iş parçacıkları bulunur. ⓘ

Yazılım takımı elemanları günlük Scrum'da önceki gün hangi görev üzerinde çalıştığını ve bitip bitmediği hakkında bilgi verir. Bir günde bitmeyen görevler ise kırmızı bir nokta ile işaretlenir. Böylelikle engeller kolayca tespit edilir. ⓘ

Bitti Tanımı (Definition of Done)

Bitti tanımı, bır kullanıcı hikâyesinin uygulanmasına ait ve yazılıma nüfus eden etkinliklerin kontrol listesidir. Ek belgeler olarak: yorum yazmak, birim testleri ve tasarım belgeleri. Bitti tanımı proje başlangıcında katılımcılar tarafından kararlaştırılır, ayrıca geliştirme sürecindede uyarlanabilir. Sprint'in başlangıcında görevlerin sayısı ve kapsamı hakkında yardımcı olur ve tüm hikâyelerde uygulanmak zorunda değildir. Bitti tanımı Sprint'in sonunda belirli bir hikâyenin ayrıntılı taleplerini belirttiğinden, Sprint'in kabul edilmesine de hizmet eder. ⓘ

Scrum'ın sınırları

Öğrenilen dersler ve değerlendirme

Scrum kullanımında, kişi özgün tahminlerini (alt/üst) kalıcı ve süreklileştirir. Scrum ilk günden itibaren ürün geliştirmesinde olması gerekendeki sapmaları gösterir: hızlı, iyi, uygun fiyatlı ya da yüksek kalitede olması takımın kazandığı deneyimlere bağlıdır. ⓘ

Takım bileşimini engelleyen faktörler

Scrum'ın uygulanmasını çeşitli faktörler engelleyebilir. Geliştirme takımı hiyerarşik yapılanmanın tersine, kendi kendini yönetme ilkesiyle şekillenir. ⓘ

Geliştirme takımı içindeki önceki konumlarından vazgeçmek istemeyen üyelerin olması çelişkilere yol açabileceğinden hareketle iç disiplinin bilince çıkarılması, görevlerin dış destek olmadan yapılması için önemlidir. Scrum'da proje ekibi sprint'deki tüm görevler üzerinde birlikte çalışırlar, böylelikle testci, yazılımcı, tasarımcı uyumu takıma yansır. Ancak deneyimli bir takım dezavantajları telafi edebilir. ⓘ

Scrum Nerelerde Uygulanır

Yeni ya da var olan bir Projede

Scrum yeni bir Projede ya da klasik yöntemlerle başlamış bir projeyi kurtarmaya uygundur. ⓘ

Scrum uyglanmadan önce yeteri kadar ürün içeriği(Product Backlog) mevcut olmalı ve hangi teknolojik bir çatının kullanılacağıda kararlaştırılmalı ve uygulanmalıdır. Müşteriye verilen birinci fonksiyonalite olayın ciddiyetini ifade edeceğinden önemlidir. ⓘ

Klasik projelerde, çalışan uygulama nın çok zaman alması ya da hiç çalışır bir duruma gelmemesi Müşteri ile takım arasındaki güveni zedeler bu yüzden birinci Sprint (ö. 30 günde) önemlidir ve takım da çalışır durumda uygulama sunarak kendini kanıtlamış olur ⓘ

Büyük ya da birbirine bağımlı Projelerde

Scrum takımı 5-8 kişiden oluşturulduğundan büyük projelerde aynı zamanda birden fazla Scrum takımı (katman) uluşturulur ve Sprint aynı anda başlar ve sonuçlar Sprint değerlendirme toplantısında sunulur. ⓘ

Takım kordinasyonunu sağlamak için, her takım haftada 1/2 toplantı yapar(Scrum of Scrums), Scrum kurucularında Jeff Sutherland bir Scrum projesinde 800 kişinin çalışabileceğini belirtir. ⓘ

Scrum ve XP

Scrum temelde yazılım geliştirme yönetim olarak görülür ancak diğer metodlarla da basit kombine yapılabilir, bu XP (Extreme Programming) metodu ile denendi ve birbirlerine iyi uyum gösterdiği görüldü. XP@Scrum ı Ken Schwaber ve Martin Fowler Trans Canada Pipeline Ltd. başarıyla uygulamıştır. ⓘ

Özet

Scrum hafif ağırlıkta bir yönetim sürecidir, çeşitli boyutlardaki projelerde uygulanabilir. Scrum'ın temel özellikleri:

• Küçük takımları iletişim ve bilgi değişimine teşvik eder.
• Teknolojik değişimleri ve kullanıcı gereksinimleri için uyarlanabilirlik sağlar.
• Sık yaratılan ürün sürümlerinde, teftiş edilmiş, uyarlamış ve test edilmişler dokümante edilebilir.
• Yapılacak iş'in küçük parçalara dağılımı ve mümkün oldukça birbirinden bağımsız alt görevleri.
• Her zaman bitmiş olarak bir proje bildirim mümkünatı, olası o süre nedeniyle mali, teknik rekabet ya da diğer. ⓘ

Araçlar

Scrum'ın uygulanması ve sürecin kolaylaştırılması için araçlar: Agilo, Pangoscrum, AgileZen, Tinypm, ThoughtWorks Studios, Greenhopper, VersionOne, ScrumWorks Pro, Banana Scrum ve ScrumTable. ⓘ

Dipnotlar

• 0. Scrum Guide : https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Turkish-2.0.pdf 14 Ağustos 2021 tarihinde Wayback Machine sitesinde arşivlendi.
• 1 Kitap: Scrum mit User Stories, Ralf Wirdemann, ISBN 978-3-446-42660
• 2 Kitap: Agile Prozesse: Von XP über Scrum bis MAP, Eckhart Hanser, Yayıncı: Springer, ISBN 978-3-642-12312-2
• 3 Script : https://web.archive.org/web/20120609232045/http://jeffsutherland.com/scrumhandbook.pdf
• 4 Scrip : Seminar Software Engineering : (Universität Zürich - Prof. Dr. Martin Glinz)
• 5 Link: https://files.ifi.uzh.ch/rerg/amadeus/teaching/seminars/seminar_ws0304/07_Schweitzer_Scrum_Ausarbeitung.pdf2 Ekim 2013 tarihinde Wayback Machine sitesinde arşivlendi. ⓘ