Scrum (yazılım geliştirme) - Scrum (software development)

Yazılım geliştirme
Çekirdek aktiviteleri
Paradigmalar ve modeller
Metodolojiler ve çerçeveler
Destekleyici disiplinler
Uygulamalar
Aletler
Standartlar ve Bilgi Organları
sözlükler
Anahatlar

Scrum , araştırma, satış, pazarlama ve ileri teknolojiler dahil olmak üzere diğer alanlarda kullanılmış olmasına rağmen, başlangıçta yazılım geliştirmeye vurgu yaparak karmaşık bir ortamda ürünleri geliştirmek, sunmak ve sürdürmek için bir çerçevedir . Çalışmalarını , bir aydan uzun olmayan ve genellikle iki haftadan uzun olmayan , sprint adı verilen zaman sınırlı yinelemeler içinde tamamlanabilecek hedeflere bölen on veya daha az üyeden oluşan ekipler için tasarlanmıştır . Scrum Takımı, günlük scrum olarak adlandırılan 15 dakika veya daha kısa süreli günlük toplantılardaki ilerlemeyi değerlendirir. Sprintin sonunda ekip iki toplantı daha yapar: geri bildirim almak için paydaşlara yapılan çalışmaları gösteren sprint incelemesi ve ekibin yansıtmasını ve geliştirmesini sağlayan sprint retrospektifi.

İsim

Yazılım geliştirme terimi scrum ilk kez 1986 yılında Hirotaka Takeuchi ve Ikujiro Nonaka tarafından "Yeni Yeni Ürün Geliştirme Oyunu" başlıklı bir makalede kullanılmıştır . Makale Harvard Business Review'un Ocak 1986 sayısında yayınlandı . Terimi ödünç rugby bir, saldırı oyuncuların oluşumdur. Scrum terimi , ekip çalışmasını vurguladığı için makalenin yazarları tarafından seçilmiştir.

Scrum bazen tamamı büyük harflerle SCRUM olarak yazılır . Kelimenin kendisi bir kısaltma olmasa da , büyük harfle yazılmış stili muhtemelen Ken Schwaber'in başlığında SCRUM'u büyük harfle yazan ilk makalesinden geliyor .

İken marka terimi üzerinde Scrum kendisi sukut izin verilmiş olan daha geniş topluluklara ziyade bir birey tarafından sahip olunan olarak, bu sayılır.

Scrum'da kullanılan terimlerin çoğu tipik olarak baştaki büyük harflerle yazılır (örneğin, Scrum Master , Daily Scrum ). Bununla birlikte, ansiklopedik bir ton sağlamak için, bu makale bu terimler için normal cümle durumunu kullanır (örneğin, scrum master , günlük scrum ) – tanınmış markalar olmadıkça ( Certified Scrum Master ve Professional Scrum Master gibi ).

Anahtar fikirler

Scrum, karmaşık ürünleri geliştirmek, sunmak ve sürdürmek için hafif, yinelemeli ve artımlı bir çerçevedir. Çerçeve, ürün geliştirmeye yönelik geleneksel, sıralı yaklaşımın varsayımlarına meydan okuyor ve tüm ekip üyelerinin fiziksel olarak ortak yerleşimini veya yakın çevrimiçi işbirliğini ve ayrıca tüm ekip üyeleri arasında günlük yüz yüze iletişimi teşvik ederek ekiplerin kendi kendini organize etmelerini sağlıyor. ve ilgili disiplinler.

Scrum'ın temel ilkelerinden biri, müşterilerin istenenin kapsamını değiştireceği (genellikle gereksinim değişkenliği olarak adlandırılır ) ve öngörülemeyen veya planlı bir yaklaşımın uygun olmadığı öngörülemeyen zorlukların olacağı konusundaki ikili tanımadır . Bu değişiklikler çeşitli kaynaklardan gelir, ancak neden alakasız olduğunu anlamak: değişim basitçe kabul edilmeli, benimsenmeli ve faydalar için analiz edilmelidir.

Bu nedenle, Scrum kanıta dayalı ampirik bir yaklaşım benimser – sorunun tam olarak anlaşılamayacağını veya önceden tanımlanamayacağını kabul eder ve bunun yerine ekibin hızlı bir şekilde teslim etme, ortaya çıkan gereksinimlere yanıt verme ve gelişen gereksinimlere uyum sağlama yeteneğini nasıl en üst düzeye çıkaracağına odaklanır. teknolojiler ve piyasa koşullarındaki değişiklikler.

Tarih

Hirotaka Takeuchi ve Ikujiro Nonaka , 1986 Harvard Business Review makalesinde, 'Yeni Yeni Ürün Geliştirme Oyunu'nda ürün geliştirme bağlamında scrum terimini tanıttılar . Takeuchi ve Nonaka daha sonra The Knowledge Creator Company'de bunun bir "örgütsel bilgi yaratma, [...] özellikle sürekli, kademeli ve spiral bir şekilde yenilik getirmede iyi" olduğunu savundu .

Yazarlar, otomotiv, fotokopi ve yazıcı endüstrilerindeki imalat firmalarından alınan örnek olay incelemelerine dayanarak, ticari ürün geliştirmeye yönelik hızı ve esnekliği artıracak yeni bir yaklaşım tanımladılar . Buna bütünsel veya ragbi yaklaşımı adını verdiler , çünkü tüm süreç, takımın "birim olarak mesafeyi kat etmeye, topu ileri geri pas vermeye çalıştığı" birden fazla örtüşen aşamada çapraz fonksiyonlu bir ekip tarafından gerçekleştiriliyor . (In ragbi futbol , bir saldırı aşağı başlarını ile her takım birbirini kilitleyen forward gibi, yeniden başlatma oyun için kullanılan ve topa sahip kazanmak için girişim olduğunu.)

Scrum çerçevesi, Schwaber'in DuPont Araştırma İstasyonu ve Delaware Üniversitesi'nde Babatunde Ogunnaike ile yaptığı araştırmaya dayanıyordu. Ogunnaike, yazılım gibi ampirizme dayanmayan 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 tavsiye etti. Esneklik ve şeffaflıkla sık denetim ve uyarlama kullanan ampirizm en uygun yaklaşımdır.

1990'ların başında Ken Schwaber , şirketinde Advanced Development Methods; ederken Jeff Sutherland John Scumniotales ve Jeff McKenna tek kelime scrum kullanarak ona atıfta bulunarak, Şövale Corporation benzer bir yaklaşım geliştirdi.

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 makalelerine, 2001'de Çevik Manifesto'ya katkılarına ve 2002'den beri Scrum'ın dünya çapında yayılmasına ve kullanılmasına yol açtılar.

1995'te Sutherland ve Schwaber , Austin, Teksas'ta Nesne Yönelimli Programlama, Sistemler, Diller ve Uygulamalar '95'in (OOPSLA '95) bir parçası olarak düzenlenen İş Nesnesi Tasarımı ve Uygulama Çalıştayı'nda Scrum çerçevesini açıklayan bir makaleyi birlikte sundular . Takip eden yıllarda, Schwaber ve Sutherland, bu materyali deneyimleri ve gelişen iyi uygulamalarıyla birleştirerek Scrum olarak bilinen şeyi geliştirmek için işbirliği yaptılar.

2001'de Schwaber , Scrum ile Çevik Yazılım Geliştirme adlı kitapta yöntemi açıklamak için Mike Beedle ile birlikte çalıştı . Scrum'ın ürün geliştirmeyi planlama ve yönetme yaklaşımı, karar verme yetkisini operasyon özellikleri ve kesinlik düzeyine getirmeyi içerir .

2002'de Schwaber diğerleriyle birlikte Scrum Alliance'ı kurdu ve Certified Scrum akreditasyon serisini kurdu . Schwaber, 2009 sonlarında Scrum Alliance'dan ayrıldı ve paralel Profesyonel Scrum akreditasyon serisini denetleyen Scrum.org'u kurdu .

2009'dan beri, Schwaber ve Sutherland tarafından The Scrum Guide adlı bir kamu dokümanı yayınlanmış ve güncellenmiştir. Mevcut sürüm Kasım 2020 olmak üzere 6 kez revize edilmiştir.

Scrum takımı

Scrum'ın temel birimi, bir ürün sahibi, bir Scrum Master ve geliştiricilerden oluşan küçük bir ekiptir. Ekip kendi kendini yönetir, çapraz işlevlidir ve her seferinde tek bir amaca 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 eden) ürün sahibi, iyi iş sonuçları elde etmekten sorumludur. Bu nedenle, ü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 odaklı sonuçlar (tipik olarak - ancak bunlarla sınırlı olmamak üzere - kullanıcı hikayeleri ) açısından tanımlar, bunları ürün biriktirme listesine ekler ve önem ve bağımlılıklara göre öncelik sırasına koyar . Bir scrum ekibinin yalnızca bir ürün sahibi olmalıdır (bir ürün sahibi birden fazla ekibi destekleyebilmesine rağmen) ve bu rolün scrum master rolüyle birleştirilmemesi şiddetle tavsiye edilir. Ürün sahibi, ürün geliştirmenin iş tarafına odaklanmalı ve zamanın çoğunu paydaşlar ve ekiple bağlantı 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: Scrum ekibindeki işletme ve mühendisler (geliştiriciler). Bu nedenle, iyi bir ürün sahibi, işletmenin neye ihtiyacı olduğunu iletebilmeli, buna neden ihtiyaç duyduğunu sorabilmeli (çünkü bunu başarmanın daha iyi yolları olabilir) ve mesajı gerektiği gibi teknik dil kullanarak geliştiriciler dahil tüm paydaşlara iletebilmelidir. Ürün sahibi, riski kontrol ederken ve değer elde ederken oldukça karmaşık işleri yönetmek için Scrum'ın ampirik araçlarını kullanır.

İletişim, ürün sahibinin temel sorumluluğudur. Öncelikleri aktarma ve ekip üyeleri ve paydaşlarla empati kurma yeteneği, ürün geliştirmeyi doğru yönde yönlendirmek için hayati önem taşır. Ürün sahibi rolü, ekip ve paydaşları arasındaki iletişim boşluğunu doldurur, paydaşlar için ekibe bir vekil ve genel paydaş topluluğu için bir ekip temsilcisi olarak hizmet eder.

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

  • Sürümleri tanımlayın ve duyurun.
  • Teslimat ve ürün durumunu iletin.
  • Yönetim toplantıları sırasında ilerlemeyi paylaşın.
  • Önemli RIDA'ları (riskler, engeller, bağımlılıklar ve varsayımlar) paydaşlarla paylaşın.
  • Öncelikleri, kapsamı, finansmanı ve programı müzakere edin.
  • Ürün biriktirme listesinin görünür, şeffaf ve net olduğundan emin olun.

Empati, bir ürün sahibinin sahip olması gereken önemli bir özelliktir - kendini bir başkasının yerine koyma yeteneği. Bir ürün sahibi, çeşitli geçmişlere, iş rollerine ve hedeflere sahip farklı paydaşlarla sohbet eder ve bu farklı bakış açılarını değerlendirebilmelidir. Etkili olmak için, bir ürün sahibinin hedef kitlenin ihtiyaç duyduğu ayrıntı düzeyini bilmesi akıllıca olacaktır. Geliştiricilerin beklentilere uygun bir ürün oluşturabilmeleri için kapsamlı geri bildirime ve spesifikasyonlara ihtiyacı varken, bir yönetici sponsorun yalnızca ilerleme özetlerine ihtiyacı olabilir. Gerekenden daha fazla bilgi sağlanması, paydaşların ilgisini kaybedebilir ve zaman kaybına neden olabilir. Deneyimli ürün sahipleri tarafından doğrudan bir iletişim aracı tercih edilir.

Bir ürün sahibinin etkili bir şekilde iletişim kurma yeteneği, paydaş ihtiyaçlarını belirleyen, paydaş çıkarları arasında öncelikleri müzakere eden ve gereksinimlerin etkin bir şekilde uygulanmasını sağlamak için geliştiricilerle işbirliği yapan tekniklerde beceri sahibi olmasıyla da geliştirilir.

geliştiriciler

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

Vadeli geliştiriciler sistemin veya ürünün geliştirilmesi ve destek veren bir rol oynar ve diğerleri arasında araştırmacılar, mimarların, tasarımcıların, veri uzmanları, istatistikçiler, analistler, mühendisler, programcılar ve test içerebilir herkese gelir. Ancak, bazı insanlar 'geliştirici' teriminin kendileri için geçerli olmadığını düşündüklerinde ortaya çıkabilecek karışıklık nedeniyle, genellikle sadece ekip üyesi olarak anılırlar .

Takım kendi kendini organize ediyor. Ürün sahibi aracılığıyla ekibe hiçbir iş gelmemeli ve scrum master'ın ekibi dikkat dağıtıcı şeylerden koruması beklenirken, ekip, maksimum anlayış ve geri bildirimin anında elde edilmesi için müşteriler ve/veya paydaşlarla doğrudan etkileşime girmeye teşvik edilir.

Saldırı ustası

Scrum, ekibin ürün hedeflerini ve çıktılarını sunma becerisinin önündeki engelleri kaldırmaktan sorumlu olan bir scrum yöneticisi tarafından kolaylaştırılır. Scrum master, geleneksel bir ekip lideri veya proje yöneticisi değildir, ancak ekip ile herhangi bir dikkat dağıtıcı etki arasında bir bariyer görevi görür. Scrum master, ekibe scrum teorisi ve kavramları konusunda koçluk yaparak, genellikle önemli oturumları kolaylaştırarak scrum çerçevesinin takip edilmesini sağlar ve ekibi büyümeye ve gelişmeye teşvik eder. Rol aynı zamanda bu ikili bakış açılarını güçlendirmek için bir ekip kolaylaştırıcısı veya hizmetkar-lider olarak anılmıştır .

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

  • Ürün sahibinin ürün birikimini, gerekli çalışmanın iyi anlaşılmasını sağlayacak şekilde sürdürmesine yardımcı olmak, böylece ekibin sürekli olarak ilerleme kaydedebilmesi
  • Kilit paydaşlardan gelen girdilerle ekibin ürün için bitmiş tanımını belirlemesine yardımcı olmak
  • Ürünü için yüksek kaliteli özellikler sunmak için Scrum ilkeleri dahilinde ekibe koçluk yapmak
  • Kilit paydaşları ve organizasyonun geri kalanını Scrum (ve muhtemelen Çevik) ilkeleri konusunda eğitmek
  • Scrum takımının, takımın içinde veya dışında, ilerlemesinin önündeki engellerden kaçınmasına veya bunları kaldırmasına yardımcı olmak
  • Takım içinde kendi kendine organizasyonu ve çapraz işlevselliği teşvik etmek
  • Düzenli ilerleme sağlamak için ekip etkinliklerini kolaylaştırmak

Scrum master, insanların ve kuruluşların ampirik ve yalın düşünceyi benimsemelerine yardımcı olarak kesinlik ve öngörülebilirlik umutlarını geride bırakır.

Scrum yöneticisi rolünün bir proje yöneticisinden farklılık gösterme yollarından biri, ikincisinin insan yönetimi sorumluluklarına sahip olabilmesi ve scrum yöneticisinin olmamasıdır. Bir scrum master, ekibin yetkilendirilmesi ve kendi kendini organize etmesi beklendiğinden sınırlı miktarda yön sağlar. Geleneksel komuta ve kontrol eğilimleri zorluklara neden olacağından , Scrum proje yöneticisinin rolünü resmi olarak tanımaz .

iş akışı

sürat koşusu

Scrum çerçevesi
Hackathon § Code sprintleri ile karıştırılmamalıdır .
Scrum süreci

Bir sprint ( yineleme veya zaman kutusu olarak da bilinir ), Scrum'daki temel geliştirme birimidir. Sprint, zaman sınırlamalı bir çabadır; yani, uzunluk her sprint için önceden kararlaştırılır ve sabitlenir ve normalde bir hafta ile bir ay arasındadır ve en yaygın olanı iki haftadır.

Her sprint, bir sprint hedefinin oluşturulduğu ve bir sonraki sprint için amaçlanan çalışmayı içeren bir sprint biriktirme listesinin ortaya çıktığı bir sprint planlama olayı ile başlar . Her sprint iki olayla sona erer:

  • bir sprint incelemesi (paydaşlara geri bildirimlerini almak için gösterilen ilerleme)
  • bir sprint retrospektifi (bir sonraki sprintler için dersleri ve iyileştirmeleri tanımlayın).

Scrum, gerçekten yapılan sprintin sonundaki değerli, faydalı çıktıyı vurgular. Yazılım söz konusu olduğunda, bu muhtemelen ürünlerin tamamen entegre olduğunu, test edildiğini ve belgelendiğini ve potansiyel olarak serbest bırakılabilir olduğunu içerir.

Sprint planlaması

Bir sprintin başlangıcında, scrum ekibi aşağıdakiler için bir sprint planlama etkinliği düzenler:

  • Ürün sahibi tarafından belirlenen önceliklere dayalı olarak, sprint sonunda teslim etmeyi tahmin ettikleri şeyin kısa bir açıklaması olan sprint hedefi üzerinde anlaşmaya varın
  • Bu hedefe katkıda bulunan ürün biriktirme listesi öğelerini seçin
  • Bu sprint sırasında hangi öğelerin yapılmasının amaçlandığı konusunda karşılıklı olarak tartışarak ve anlaşarak bir sprint biriktirme listesi 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ığından, takım o işi tek bir sprintte tamamlayamayacaklarına inanırsa, bazı ürün biriktirme listesi öğeleri bölünebilir veya ürün biriktirme listesine iade edilebilir.

Günlük saldırı

Bilgisayar odasında günlük bir telaş. 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 saldırı düzenler (bazen ayakta gerçekleştirilir ):

Tüm geliştiriciler hazırlıklı gelir. Günlük koşuşturma:

  • sprint hedefine doğru ilerlemeyi denetlemeye odaklanır
  • her gün aynı saatte ve yerde olmalı
  • on beş dakika ile sınırlıdır (zaman kısıtlamalı )
  • ancak ekip karar verirse yürütülür
  • başkalarını içerebilir, ancak yalnızca geliştiriciler konuşmalıdır.
  • Scrum Master tarafından kolaylaştırılabilir
  • ilerlemenin önündeki engelleri belirleyebilir (örneğin, engel, risk, sorun, gecikmeli bağımlılık, varsayımın asılsız olduğu kanıtlanmıştır)
  • tartışmalara yer vermiyor
  • ilerleme çizelgelerini güncellemenin bir yolu değildir

Günlük saldırı sırasında ayrıntılı tartışmalar yapılmamalıdır. Bir kez bittiğinde, bireysel üyeler, genellikle "ara oturumu" veya "parti sonrası" olarak bilinen sorunları ayrıntılı olarak tartışabilirler. Belirlenen engelleyiciler, bir çözüme yönelik çalışmak amacıyla günlük telaşın dışında toplu olarak tartışılmalıdır.

Takımın bu etkinlikteki değeri görmediği durumlarda, nedenini belirlemek ve takımı ve paydaşları Scrum ilkeleri hakkında eğitmek veya takımı sprint hakkında tam olarak bilgilendirmek için kendi yöntemini tasarlamaya teşvik etmek scrum master'ın sorumluluğundadır. ilerlemek.

Sprint incelemesi

Bir sprint sonunda yürütülen ekip:

  • tamamlanan işi paydaşlara sunar (diğer adıyla demo )
  • aşağıdakiler gibi konularda paydaşlarla işbirliği yapar:
    • tamamlanan ürün artışı hakkında geri bildirim davet etmek
    • tamamlanmamış çalışmanın etkisini tartışmak (planlanmış veya başka türlü)
    • Yaklaşan çalışma için öneriler alma (bir sonraki çalışma için rehberlik)

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

Sprint incelemeleri için yönergeler:

  • Eksik çalışma gösterilmemelidir; Paydaşlara alacakları ürün artışları sunulsa da, gerekirse devam eden çalışmaları görmeyi de talep edebilir. Ancak, ekip sadece ne yapıldığını göstermeye hazır olmalıdır.
  • Önerilen süre, iki haftalık bir sprint için iki saattir (diğer sprint süreleriyle orantılı).

Sprint retrospektif

Sprint retrospektifinde takım:

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 neyi farklı yapabilirdik?
  • Önerilen süre, iki haftalık bir sprint için bir buçuk saattir (diğer sprint süreleriyle orantılıdır).

Scrum ustası bu olayı kolaylaştırabilir, ancak onların varlığı zorunlu olarak kabul edilmez.

İş listesi iyileştirme

Başlangıçta temel bir Scrum uygulaması olmasa da, biriktirme listesi iyileştirme (önceden bakım olarak adlandırılır ) Scrum Kılavuzuna eklendi ve bir sprint'e giren ürün biriktirme listesi öğelerinin kalitesini yönetmenin bir yolu olarak kabul edildi. Ürün biriktirme listesi kalemlerini yeni bilgiler ışığında gözden geçirme ve değiştirme/güncelleme/yeniden sipariş verme sürecidir.

Birikmiş iş 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 tanımlanabilir ve araştırılabilir
  • Bir öğe daha fazla keşif ve analiz gerektirebilir
  • Öncelikler değişmiş olabilir; beklenen getiriler şimdi farklı olacak

İyileştirme, öğelerin uygun şekilde hazırlanması ve sprint planlaması için geliştiriciler için açık ve yürütülebilir olmasını sağlayacak şekilde sıralanması anlamına gelir.

Biriktirme listesi ayrıca teknik borç (tasarım borcu veya kod borcu olarak da bilinir) içerebilir . 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.

Birikmiş iş listesi iyileştirme üzerine bir takımın sprint kapasitesinin yüzde 10'una kadar yatırım yapılması önerilir. Daha olgun ekipler bunu planlanmış tanımlanmış bir olay olarak değil, doğal iş akışının bir parçasını oluşturan, gerektiğinde ürün biriktirme listesini rafine eden ve ayarlayan geçici bir etkinlik olarak görecektir.

Bir sprinti iptal etme

Ürün sahibi gerekirse bir sprint'i 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 olumsuzlayabilir, bu nedenle devam etmenin anlamı yoktur.

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

eserler

Ürün birikimi

Ürün biriktirme listesi, yapılacak işlerin bir dökümüdür ve ekibin bir ürün için sürdürdüğü sıralı ürün gereksinimleri listesini içerir . Biriktirme listesi öğeleri için yaygın biçimler, kullanıcı hikayelerini ve kullanım senaryolarını içerir . Bu gereksinimler, özellikleri , hata düzeltmelerini , işlevsel olmayan gereksinimleri vb. - uygulanabilir bir ürün sağlayan her şeyi tanımlar . Ürün sahibi, risk, iş değeri, bağımlılıklar, boyut ve ihtiyaç duyulan tarih gibi hususlara dayalı olarak ürün biriktirme listesi kalemlerine (PBI'lar) öncelik verir.

Ürün biriktirme listesi "ihtiyaç duyulana göre sıralanır" ve herkes tarafından görülebilir, ancak yalnızca ürün biriktirme listesi kalemlerinin yönetiminden ve bakımından sorumlu olan ürün sahibinin onayı ile değiştirilebilir.

Ürün biriktirme listesi, ürün sahibinin iş değeri değerlendirmesini içerir ve ekibin çaba veya karmaşıklık değerlendirmesini içerebilir, her zaman olmasa da genellikle hikaye noktalarında yuvarlatılmış Fibonacci ölçeği kullanılarak belirtilir . Bu tahminler, ürün sahibinin zaman çizelgesini ölçmesine yardımcı olur ve ürün biriktirme listesi kalemlerinin sırasını etkileyebilir; örneğin, aynı iş değerine sahip iki özellik için, ürün sahibi, daha düşük geliştirme çabasıyla (çünkü yatırım getirisi daha yüksek olduğundan) veya daha yüksek geliştirme çabasıyla (çünkü daha karmaşık veya daha riskli olduğundan) işin daha erken teslimini planlayabilir. ve bu riski daha erken emekli etmek istiyorlar).

Ürün biriktirme listesi ve her bir ürün biriktirme listesi kaleminin iş değeri, ürün sahibinin sorumluluğundadır. Her bir öğeyi teslim etme çabası, hikaye noktaları veya zaman olarak tahmin edilebilir. Ekip, hikaye puanlarını tahmin ederek, bireysel geliştiricilerin bağımlılığını azaltır; bu, özellikle geliştiricilerin genellikle sprint tesliminden sonra başka işlere atandığı dinamik ekipler için kullanışlıdır. Örneğin, bir kullanıcı hikayesi eforda 5 olarak tahmin edilirse (Fibonacci dizisi kullanılarak), üzerinde kaç geliştiricinin çalıştığına bakılmaksızın 5 olarak kalır.

Öykü noktaları, bir zaman kutusundaki çabayı tanımlar, böylece 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 tahminleri benzer çabalara işaret eder (1 önemsizdir), ancak ekip 8 veya 13 (veya daha yüksek) tahmin ederse, hem dağıtım hem de bütçe üzerindeki etkisi ö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 takıma göre olduğu kabul edilmelidir. Örneğin, bir ekip için 5 tahmini, daha yüksek yeteneğe sahip daha deneyimli geliştiricilerden oluşan başka bir ekip için 2 olabilir.

Çoğu durumda bir ürün sahibi birden fazla ekiple çalışabilmesine rağmen, her ekibin bir ürün sahibi olmalıdır. Ürün sahibi, ürünün değerini maksimize etmekten sorumludur. Ürün sahibi girdi toplar ve onlardan geri bildirim alır ve birçok insan tarafından lobi yapılır, ancak nihayetinde neyin inşa edileceğine dair nihai karara sahiptir.

Ürün birikimi:

  • Yeni özellikler, eski özelliklerin değiştirilmesi, özelliklerin kaldırılması ve sorunların düzeltilmesi dahil olmak üzere bir ürünü değiştirme isteklerini yakalar
  • Geliştiricilerin, ürünün ticari faydasını en üst düzeye çıkaran çalışmaları olmasını sağlar

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

Yönetmek

Bir ürün biriktirme listesi, en basit haliyle, üzerinde çalışılacak öğelerin bir listesidir. İşin nasıl eklendiği, kaldırıldığı ve sıralandığıyla ilgili yerleşik kurallara sahip olmak, tüm ekibin ürünün nasıl değiştirileceği konusunda daha iyi kararlar almasına yardımcı olur.

Ürün sahibi, en kısa sürede ihtiyaç duyulan ürün biriktirme listesi öğelerine öncelik verir. Sprint hedefinden etkilenen geliştiriciler, gelecek sprint için öğeleri seçer ve bu öğeleri ürün iş listesinden oluşturacakları öğelerin listesi olan sprint iş listesine taşır. Kavramsal olarak, sprint hedefi, listenin başındaki yüksek öncelikli öğelerden etkilenir, ancak sprint içinde daha fazla çalışmaya uyum sağlamak için zaman kalmışsa, geliştiricilerin bazı düşük öncelikli öğeleri aldığını görmek olağandışı değildir.

Yüksek öncelikli öğeler (birikim listesinin en üstünde), geliştiricilerin üzerinde çalışması için uygun olan daha ayrıntılı parçalara ayrılmalıdır. Birikme listesi ne kadar aşağıdaysa, öğeler o kadar az ayrıntılı olacaktır. Schwaber ve Beedle'ın belirttiği gibi, "Öncelik ne kadar düşükse, birikmiş öğeyi zar zor çözene kadar o kadar az ayrıntı."

Ekip birikmiş iş yığını üzerinde çalışırken, değişimin çevrelerinin dışında gerçekleştiği varsayılmalıdır - ekip, yararlanmak için yeni pazar fırsatları, ortaya çıkan rakip tehditleri ve müşterilerden gelen geri bildirimler hakkında ürünün amaçlanma şeklini değiştirebilecek geri bildirimler hakkında bilgi edinebilir. çalışmak. Tüm bu yeni fikirler, ekibi yeni bilgileri birleştirmek için biriktirme listesini uyarlamaya teşvik etme eğilimindedir. Bu, çevik bir ekibin temel zihniyetinin bir parçasıdır. Dünya değişir, birikim asla bitmez.

Sprint biriktirme listesi

Sprint iş listesi, geliştiricilerin gelecek sprintte ele alması amaçlanan ürün iş listesindeki öğelerin alt kümesidir. Geliştiriciler, bir sonraki sprint için kapasiteyi değerlendirmek için geçmiş performansı kullanarak ve bunu ne kadar 'çaba' tamamlayabilecekleri konusunda bir kılavuz olarak kullanarak, sprint'i doldurmak için yeterli işleri olduğunu hissedene kadar bu birikimi dolduracaktır.

Sprint biriktirme listesi üzerindeki çalışma hiçbir zaman geliştiricilere atanmaz (ya da iletilmez); ekip üyeleri, birikmiş iş yükü önceliğine ve kendi beceri ve kapasitelerine göre işi gerektiği gibi çeker. Bu, geliştiricilerin kendi kendine organizasyonunu teşvik eder.

Sprint biriktirme listesi geliştiricilerin mülkiyetindedir ve dahil edilen tüm tahminler geliştiriciler tarafından sağlanır. Scrum'ın bir parçası olmamasına rağmen, bazı takımlar mevcut sprintteki işin durumunu görselleştirmek için eşlik eden bir pano kullanır: Yapılacaklar, Yapılıyor, Bitti.

artış

Arttırma sürat amaçlara uygundur sürat potansiyel serbest bırakılabilir çıkışıdır. Önceki tüm sprintlerin çalışmalarıyla bütünleştirilmiş, tamamlanmış tüm sprint biriktirme listesi öğelerinden oluşur. Artış, scrum ekibinin tamamlandı (DoD) tanımına göre eksiksiz olmalı , tam olarak çalışmalı ve ürün sahibinin onu 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.

Açılış tablosu

Her günün sonunda kalan eforu gösteren, tamamlanmış bir sprint için örnek bir iş bitim çizelgesi.
Ana madde: Yanık grafiği

Genellikle Scrum'da kullanılır (ancak Scrum'ın bir parçası değildir), bir iş bitim çizelgesi, kalan işi gösteren, herkese açık olarak görüntülenen bir çizelgedir. Her gün güncellenir, referans için hızlı görselleştirmeler sağlar. İş bitim 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 iş bitim grafiği çizilir. Ardından, sprint sırasında geliştiriciler grafiği kalan çalışma ile günceller, böylece grafik gerçek ve tahmin edilen arasında bir karşılaştırma göstererek gün gün güncellenir.

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

Yanma grafiğini serbest bırakın

Her sprint'in tamamlanan kapsamını gösteren bir sürüm için örnek bir tükenmişlik grafiği (MVP = Minimum Uygulanabilir Ürün)

Sürüm tükenme çizelgesi, ekibin bir sürüme yönelik görünürlük sağlaması ve ilerlemeyi izlemesi için bir yoldur. Her sprintin sonunda güncellenir ve bir tahmin kapsamının sağlanmasına yönelik ilerlemeyi gösterir. Yayın yakma grafiğinin yatay ekseni bir yayındaki sprintleri gösterirken dikey eksen, her bir sprint sonunda tamamlanan iş miktarını gösterir (tipik olarak tamamlanan işin kümülatif hikaye noktalarını temsil eder). İlerleme, tahmin kapsamını temsil eden yatay bir çizgiyi karşılamak üzere büyüyen bir çizgi olarak çizilir; genellikle, belirli bir yayın tarihine kadar ne kadar kapsamın tamamlanabileceğini veya verilen kapsamı tamamlamak için kaç sprint gerektiğini gösteren, bugüne kadarki ilerlemeye dayalı bir tahminle gösterilir.

Serbest bırakma çizelgesi, ne kadar işin tamamlandığını, ne kadar iş eklendiğini veya kaldırıldığını (yatay kapsam çizgisi hareket ederse) ve ne kadar iş kaldığını görmeyi kolaylaştırır.

Hazır tanımı (DoR)

Spesifikasyonların ve girdilerin iş öğesini başlatmak için yeterince ayarlanıp ayarlanmadığını belirlemek için başlangıç ​​kriterleri .

done tanımı (DoD)

Exit-kriterler Savunma Bakanlığı bütün gerektirir: sürat birikim öğe üzerinde çalışma, örneğin tam olup olmadığını belirlemek için regresyon testleri başarılı olmak. Bitti tanımı bir ekipten diğerine değişebilir ancak bir ekip içinde tutarlı olmalıdır.

Hız

Bir takımın, son sprintte tamamlanan işi değerlendirerek elde edilen, tek bir sprint için toplam yetenek çabası. Geçmiş hız verilerinin toplanması, ekibin kapasitelerini, yani ne kadar işi rahatça başarabileceklerini anlamalarına yardımcı olmak için bir kılavuzdur.

Bu metrik, Scrum topluluğunda tartışmalara neden oldu:

  • tüketilen hikaye puanları , teslim edilen değere eşit değil : ekip yapılan işi görebilir ve paydaşlara sağlanabilecek faydaları görmezden gelebilir
  • dikkat dağıtıcı uygulamaların tanıtılması: gerçeklere karşı tahmin, varyans araştırması ve yeniden tahmin politikası ortaya çıkmaya başlar
  • yönetim, hızı bir performans ölçüsü olarak görür, bu nedenle onu artırmaya çalışır, yani:
    • kalite zarar görür - ekip, eklenen iş yükünü dahil etmek 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
    • tahmin zarar görür - geliştiriciler, aynı çabayı farklı bir ölçekte ölçerek, arabelleklerde oluşturmak ve "metrikleri oynamak" için tahminleri şişirir
    • değer zarar görür - nihai etki, odağın iş değeri sunumundan uzaklaştırılmasının bir sonucu olarak 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.

başak

Bir kavramı araştırmak veya basit bir prototip oluşturmak için kullanılan zaman sınırlamalı bir dönem. Ani yükselişler, sprintler arasında gerçekleşecek şekilde planlanabilir veya daha büyük takımlar için, birçok sprint teslimat hedefinden biri olarak bir artış kabul edilebilir. Ani artışlar genellikle bütçeyi güvence altına almak, bilgiyi genişletmek veya bir kavram kanıtı üretmek için büyük veya karmaşık ürün biriktirme listesi kalemlerinin tesliminden önce tanıtılır. Bir ani yükselişin süresi ve amacı/hedefleri, başlamadan önce ekip tarafından kararlaştırılır. Sprint taahhütlerinin aksine, ani artışlar somut, taşınabilir, değerli işlevler sunabilir veya sunmayabilir. Örneğin, bir ani yükselişin amacı, bir eylem planına başarılı bir şekilde karar vermek olabilir. Ani yükseliş, zaman dolduğunda sona erer, mutlaka hedef yerine getirildiğinde değil.

izli mermi

Drone spike olarak da adlandırılan izleyici mermi, mevcut mimariye, mevcut teknoloji setine, üretim kalite koduyla sonuçlanan mevcut en iyi uygulamalar setine sahip bir ani artıştır. İşlevselliğin çok dar bir uygulaması olabilir, ancak kullanılıp atılan kod değildir. Üretim kalitesindedir ve geri kalan yinelemeler bu kod üzerine inşa edilebilir. Adın, merminin yolunu görünür kılan ve düzeltmelere izin veren mühimmat olarak askeri kökenleri vardı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 çekim'dir.

sınırlamalar

Aşağıdaki durumlarda Scrum'ın faydalarına ulaşmak daha zor olabilir:

  • Üyeleri coğrafi olarak dağınık veya yarı zamanlı olan ekipler : Scrum'da geliştiriciler, ideal olarak çoğu zaman aynı alanda birlikte çalışarak yakın ve sürekli etkileşime sahip olmalı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 iddia ediyor.
  • Üyeleri çok özel becerilere sahip takımlar : Scrum'da geliştiriciler , uzmanlıklarının dışındaki görevlerde çalışmalarına izin veren T şeklinde becerilere sahip olmalıdır . Bu, iyi Scrum liderliği tarafından teşvik edilebilir. Çok özel becerilere sahip ekip üyeleri iyi katkıda bulunabilir ve katkıda bulunurken, diğer disiplinler hakkında daha fazla bilgi edinmeye ve onlarla işbirliği yapmaya teşvik edilmelidirler.
  • Birçok 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 neden olabilir.
  • Olan ürünler olgun veya miras veya regüle ile kalite kontrol : In Scrum, ürün artışlarla tam olarak gelişmiş ve tek sprint test edilmelidir; Her sürüm için büyük miktarlarda regresyon testi veya güvenlik testi (örneğin, tıbbi cihazlar veya araç kontrolü) gerektiren ürünler, kısa sprintler için daha uzun şelale sürümlerinden daha az uygundur .

Mevcut araçlar

Ana madde: Scrum yazılımının karşılaştırılması

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

Birçok şirket, bir sprint biriktirme listesi oluşturmak ve sürdürmek için elektronik tablolar gibi evrensel araçlar kullanır. Ayrıca, ürün geliştirme için Scrum terminolojisini kullanan veya Scrum dahil olmak üzere çoklu ürün geliştirme yaklaşımları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 uygular ve eserlerini kağıt, beyaz tahtalar ve yapışkan notlar gibi basılı kopya formlarında tutar.

Scrum değerleri

Scrum, tüm ampirik süreç kontrolü gibi, şeffaflık, inceleme ve adaptasyon olmak üzere üç sütun tarafından desteklenen geri beslemeye dayalı ampirik bir yaklaşımdır. Scrum çerçevesindeki tüm çalışmalar, sonuçtan sorumlu olanlar tarafından görülebilmelidir: 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 olduğunu sık sık incelemesi gerekir. Çalışma. Ekip, sık yapılan incelemeyle çalışmalarının kabul edilebilir sınırların dışına çıktığını tespit edebilir ve süreçlerini veya geliştirilmekte olan ürünü uyarlayabilir.

Bu üç temel, Scrum'ın aşağıdaki beş değerinin sağladığı takımda güven ve açıklık gerektirir:

  1. Bağlılık: Takım üyeleri, her bir sprintte takım 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: Takım üyeleri, yalnızca takım hedeflerine ve sprint biriktirme listesine odaklanır; birikimleri 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, teknik olarak yetenekli olmaları ve iyi niyetle çalışmaları için birbirlerine saygı duyarlar.

Uyarlamalar

Scrum'ın diğer yazılım geliştirme metodolojileri ile hibritleştirilmesi yaygındır çünkü Scrum tüm ürün geliştirme yaşam döngüsünü kapsamaz ; bu nedenle, kuruluşlar daha kapsamlı bir uygulama oluşturmak için ek süreçler ekleme ihtiyacı bulur. Örneğin, ürün geliştirmenin başlangıcında, kuruluşlar genellikle iş gerekçesi, gereksinimlerin toplanması ve önceliklendirilmesi, ilk üst düzey tasarım ve bütçe ve program tahmini hakkında süreç rehberliği ekler.

Scrum'ı kullanan çeşitli yazarlar ve insan toplulukları, Scrum'ın belirli problemlere veya organizasyonlara nasıl uygulanacağı veya uyarlanacağı konusunda daha ayrıntılı teknikler de önerdiler. Pek çoğu, bu metodolojik teknikleri , mimari ve yazılımdaki tasarım kalıplarına benzeterek, 'kalıplar' olarak adlandırır .

Scrumban

Ana madde: Scrumban

Scrumban, Scrum ve Kanban tabanlı bir yazılım üretim modelidir . Scrumban, özellikle üretim kusurları veya programlama hataları gibi sık ve beklenmedik iş öğeleriyle ürün bakımı için uygundur . Bu gibi durumlarda, takıma ve eldeki duruma bağlı olarak Scrum'ın günlük etkinlikleri ve diğer uygulamaları hala uygulanabilmesine rağmen, Scrum çerçevesinin zaman sınırlı sprintlerinin daha az faydalı olduğu algılanabilir. Eşzamanlı tamamlanmamış iş ve kusurlar için iş aşamalarının ve sınırlamalarının görselleştirilmesi Kanban modelinden aşinadır. Bu yöntemler kullanılarak ekibin iş akışı , her bir iş kalemi veya programlama hatası için minimum tamamlanma süresine izin verecek şekilde yönlendirilir ve diğer yandan her ekip üyesinin sürekli olarak istihdam edilmesini sağlar.

Çalışmanın 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 ekiplerde Assembla , Jira veya Agilo gibi sahne illüstrasyon yazılımları kullanılabilir.

Scrum ve Kanban arasındaki en büyük fark, Scrum'da çalışmanın sabit bir süre süren sprintlere bölünmesi, oysa Kanban'da iş akışının sürekli olmasıdır. Bu, Scrum'da her sprintten sonra boşaltılan çalışma aşaması tablolarında görülebilirken, Kanban'da tüm görevler aynı tabloda işaretlenmiştir. Scrum, çok yönlü bilgi birikimine sahip ekiplere odaklanırken Kanban, uzmanlaşmış, işlevsel ekipleri mümkün kılar.

Scrum'lar

Scrum of scrum, aynı ürün üzerinde çalışan birden fazla ekip için, özellikle örtüşme ve entegrasyon alanlarında yazılım sağlamanın nasıl koordine edileceğine odaklanarak, karşılıklı bağımlılıklarındaki ilerlemeyi tartışmalarına olanak tanıyan, Scrum'ı ölçekte çalıştırma tekniğidir. Scrumların kadansına (zamanlamasına) bağlı olarak, her bir scrum takımı için ilgili günlük scrum, bir üyenin diğer ekiplerden elçilerle birlikte scrumların scrumlarına katılması için bir elçi olarak atanmasıyla sona erer. Bağlama bağlı olarak, elçiler teknik katkıda bulunanlar veya her takımın scrum yöneticisi olabilir.

Basit bir ilerleme güncellemesinden ziyade, scrumlar ekiplerin tanımlanan riskleri, engelleri, bağımlılıkları ve varsayımları (RIDA'lar) çözmek, azaltmak veya kabul etmek için toplu olarak nasıl çalıştıklarına odaklanmalıdır. Scrum'lar, bu RIDA'ları, bir risk panosu (bazen çözümlenmiş, sahip olunan, kabul edilmiş ve hafifletilmiş baş harflerinden sonra ROAM panosu olarak da bilinir) gibi kendine ait bir biriktirme listesi 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 saldırıya benzer şekilde çalışmalıdır:

  • Son görüşmemizden bu yana ekibiniz hangi riskleri, engelleri, bağımlılıkları veya varsayımları çözdü?
  • Ekibiniz biz tekrar görüşmeden önce hangi riskleri, engelleri, bağımlılıkları veya varsayımları çözecek?
  • Ekibinizi yavaşlatan veya önlerine çıkan yeni riskler, engeller, bağımlılıklar veya varsayımlar var mı?
  • Başka bir ekibin yoluna çıkabilecek yeni bir risk, engel, bağımlılık veya varsayımı tanıtmak üzere misiniz?

As Jeff Sutherland yorumladı,

Başlangıçta Scrums Scrum'ını tanımladığım için (Ken Schwaber IDX'te benimle çalışıyordu), Scrum of Scrum'ın bir 'meta Scrum' olmadığını kesinlikle söyleyebilirim. Kullandığım Scrum of Scrum, tüm ekiplerin çalışan yazılımlarını sprint sonunda Bitti Tanımına teslim etmekten veya sprint sırasındaki sürümlerden sorumludur. PatientKeeper, Sprint başına üretime dört kez teslim edildi. Ancestry.com, iki haftalık Sprint başına 220 kez üretime sunar. Hubspot, günde 100-300 kez canlı yazılım sunar. Scrum Master'ın Scrum'ı bu işi yapmaktan sorumludur. Dolayısıyla Scrum of Scrum, operasyonel bir dağıtım 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 sekize kadar takım için tasarlanmıştır; 'LeSS Huge' olarak bilinen ikinci düzey, yüzlerce geliştiriciyle geliştirme için ek ölçeklendirme öğeleri sunar. "Ölçeklendirme Scrum, standart gerçek tek takımlı Scrum'ı anlamak ve benimseyebilmekle başlar. Büyük Ölçekli Scrum, tek takımlı Scrum öğelerinin amacını incelemeyi ve standart Scrum'ın kısıtlamaları dahilinde kalırken aynı amaca nasıl ulaşılacağını bulmayı gerektirir. tüzük."

Bas Vodde ve Craig Larman , LeSS çerçevesini, özellikle telekomünikasyon ve finans sektörlerinde büyük ölçekli ürün geliştirme ile çalışma deneyimlerinden geliştirdiler. Scrum'ı alarak ve neyin işe yaradığını keşfetmek için birçok farklı deney deneyerek gelişti. 2013 yılında, deneyler LeSS çerçeve kurallarına katılaştırılmıştır. LeSS'nin amacı, organizasyon karmaşıklığını 'ölçekten düşürmek', gereksiz karmaşık organizasyonel çözümleri ortadan kaldırmak ve bunları daha basit yollarla çözmektir. Daha az rol, daha az yönetim, daha az organizasyon yapısı.

eleştiriler

Scrum, çoğunlukla kavramları kötü uygulayan ancak aynı sonuçları bekleyenler veya Scrum'ın gerektirdiği kültürel değişiklikleri yanlış anlayanlar tarafından birçok kez ateş altında kaldı:

  • Scrum olayları azaltmış olacak bildirilmiştir verimliliği bu yüzden aşırı-titiz ziyade toplantı kısa bir zaman kutulu tartışma olarak yürütülür ve daha iyi genellikle etkinliğin amacı ve hedefinin bir yanlış anlama nedeniyle fiili üretken görevlere harcanan olabilir zaman israf .
  • Scrum uygulamaları, Çevik Manifesto ruhu içinde doğru bir şekilde takip edilmediğinde , bir mikro yönetim biçimi haline gelme ve uygulamaların ortadan kaldırmaya çalıştığı aynı işlev bozukluğunu yeniden ortaya çıkarma eğilimindedir .
  • Scrum ayrıca, işi tamamlamak için gereken çabanın doğru bir şekilde tahmin edilebileceğini varsayar, ancak bu genellikle oldukça tahmin edilemez olabilir .
  • Scrum, deneysel analiz ve deney yapma ö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 form olarak algılanır.
  • Scrum'a ilk giriş, hemen yüksek kaliteli sonuçlar üretmeyecektir; sabırsızlık, Scrum'ı yerleştirme ve büyüme şansından mahrum eder.

Scrum'a yönelik yaygın işlevsiz yaklaşımlar, artık Dark Scrum ve Scream dahil olmak üzere anti-kalıplar olarak kabul edilmiştir.

Ayrıca bakınız

Referanslar

daha fazla okuma

Dış bağlantılar