Proje Yönetimi Planı Bölüm 1: Çevik, Scrum, Kanban ve Yalın'ın Kapsamlı Bir Karşılaştırması

genel bakış

Günümüzde yazılım geliştirmede birçok metodoloji kullanılmaktadır. Şelale, Çevik, Scrum, Kanban, Yalın, Aşırı Programlama gibi moda sözcükleri duymuş olabilirsiniz.

Bu yazıda bu terimleri tanımlayacağım, birbirleriyle nasıl ilişkili olduklarını ve birbirlerinden nasıl farklı olduklarını tartışacağım. Yukarıda bahsedilen moda sözcüklerin çoğu, orijinal olarak Toyota Üretim Sistemine (TPS) dayanan Yalın Üretim kavramlarına dayanmaktadır, bu yüzden önce bunun hakkında konuşacağız.

Yalın Metodoloji

Yalın ve Yalın Üretimin Kökenleri

"Yalın" teriminin kökenleri, orijinal olarak Henry Ford'dan ilham alan Sakichi Toyoda, Kiichiro Toyoda ve Taiichi Ohno tarafından geliştirilen Toyota Üretim Sistemine (TPS) dayalı bir üretim modelini tanımlamak için üretildiği üretimdir. TPS, "tüm atıkların tamamen ortadan kaldırılması" felsefesine odaklandı ve 1950'lerden 1970'lere kadar üretimde devrim yarattı. TPS, 1990 yılında “Dünyayı Değiştiren Makine” yayınlandığında “Yalın Üretim” olarak bilinir hale geldi.

TPS, Toyota'da üç geniş atık türü belirledi:

• Muda: “atık” olarak tercüme edildi. Toyota'da yedi tür muda tespit edildi ve sekizincisi daha sonra eklendi. Bunlar:
  • Kusurlar: Kusurları bulma ve düzeltme çabası
  • Aşırı üretim: talepten önce üretim
  • Bekleme: Bir sonraki üretim adımını beklemek, kesintiler vb.
  • Kullanılmayan Yetenek: yeteneklerin yeterince kullanılmaması, yetersiz eğitim vb.
  • Taşıma: İşleme için gerekli olmayan hareketli parçalar veya ürünler
  • Envanterler: bitmiş envanter ve devam eden işler
  • Hareket: İşleme için gerekenden daha fazla hareket etme veya yürüme

  • Fazla İşleme: zayıf takımlama veya ürün tasarımından

• Muri: "aşırı yük" olarak tercüme edildi. Muri genellikle mura'dan kaynaklanır, ancak muda'dan kaynaklanabilir. Muri, arızalar, devamsızlık, güvenlik sorunları vb.
• Mura: "düzensizlik" olarak tercüme edildi. Mura, müşteri talebindeki dalgalanmalarda, ürün başına işlem sürelerinde veya farklı operatörler için döngü sürelerindeki değişikliklerde bulunabilir. Mura azaltılmadığında, muri ve dolayısıyla muda olasılığı artar. Mura, tedarik zincirinde açıklık yaratılarak, ürün tasarımı değiştirilerek ve tüm operatörler için standart işler yaratılarak azaltılabilir.

TPS, şu iki temel kavramı uygulayarak israfı ortadan kaldırmak için çalıştı:

• Jidoka: "insan dokunuşuyla otomasyon" olarak gevşek bir şekilde tercüme edildiğinde, "Kalitenin üretim sürecinde inşa edilmesi gerektiğini" şart koşar. yani bir sorun oluştuğunda, ekipman hemen durarak kusurlu ürünlerin üretilmesini engeller.
• Tam Zamanında: Yalnızca “gerekeni, gerektiğinde ve ihtiyaç duyulan miktarda” yapmak.

TPS geliştikçe, bu temel sütunlar ve değerler Jidoka ve JIT kavramları üzerine inşa edildi ve yerleşti:

• Devamlı gelişme:
  • Zorluk: hayalleri gerçekleştirmek için uzun vadeli bir vizyon oluşturmak ve zorlukları cesaret ve yaratıcılıkla karşılamak
  • Kaizen: iş operasyonlarını sürekli iyileştirmek, her zaman yenilik ve evrimi teşvik etmek, her seferinde bir mudayı ortadan kaldırmak
  • Genchi Genbutsu: genchi genbutsu uygulamak, doğru kararlar vermek, fikir birliği oluşturmak ve hedeflere en hızlı şekilde ulaşmak için gerçekleri bulmak için kaynağa gitmek
• İnsanlara Saygı:
  • Saygı: başkalarına saygı duymak ve birbirimizi anlamak için her türlü çabayı göstermek, sorumluluk almak ve karşılıklı güven oluşturmak için elimizden gelenin en iyisini yapmak
  • Ekip çalışması: kişisel ve profesyonel büyümeyi teşvik etmek, gelişim fırsatlarını paylaşmak ve bireysel ve ekip performansını en üst düzeye çıkarmak
• Andon: durumun veya sorunun görsel bir göstergesi
• Heijunka: tesviye veya üretim tesviye anlamına gelir
• Hansei: kendini yansıtma anlamına gelir. Verimliliği artırmak için çalışanlar, daha iyilerini bulmak için mevcut süreçlerin arkasındaki varsayımlara meydan okumalıdır.
• Kanban: üretimi kontrol etmek için görsel bir araç olarak kullanılan bir tabela
• Poka-yoke: Hata önleme veya hata önleme olarak da anılır
• Çekme Sistemi: Malzeme gerektiği gibi bir iş istasyonuna çekilir
• Seiri: israfı yansıtan ilkedir. Seiri, gereksiz olanın kaldırılması gerektiğini belirtir. Bu, TPS'nin orijinal yedi israfının tümünü kapsar.
• Standardizasyon: Tüm işleri insan hareketi etrafında düzenler ve muda olmadan verimli bir üretim dizisi oluşturur. Bu, kaliteye, sabit bir hıza yol açmaya yardımcı olur ve sürekli iyileştirmeye izin verir.

Aşağıdaki şema, temel kavramların ve temel değerlerin birbiriyle nasıl ilişkili olduğunu göstermektedir.

Yalın yönetim

Toyota Ürün Sistemi ve Yalın Üretim zamanla gelişti ve yönetim dahil birçok alanda uygulandı.

Yalın Yönetim, sürekli iyileştirme ve insanlara saygı gibi temel değerleri uyguladı ve bunu, israfı sürekli iyileştirmek ve ortadan kaldırmak için birkaç kez tekrarlanacak olan beş kuralcı Yalın ilkesine damıttı:

1. Değeri Tanımla: Ürün ailesine göre son müşteri açısından bir değer belirtin.
2. Değer Akışını Eşle: Değer yaratmayan adımları mümkün olduğunca ortadan kaldırarak, her ürün ailesi için değer akışındaki tüm adımları tanımlayın.
3. Akış Yarat: Ürünün müşteriye doğru sorunsuz bir şekilde akabilmesi için değer yaratan adımların sıkı bir sırayla gerçekleşmesini sağlayın.
4. Çekme Oluşturun : Akış tanıtıldığında, müşterilerin bir sonraki yukarı akış faaliyetinden değer çekmesine izin verin.
5. Mükemmeli Arayın : Değer belirlendikçe, değer akışları tanımlanır, boşa giden adımlar çıkarılır ve akış ve çekme devreye girer, işleme yeniden başlar ve mükemmel değerin israf olmadan yaratıldığı bir mükemmellik durumuna ulaşılana kadar devam eder.

Yalın yönetimin bu ilkeleri ve diğer yönleri, Womack & Jones 1996'da “Yalın Düşünce”yi yayınladığında resmileştirildi.

Yalın Yazılım Geliştirme

Yalın o zamandan beri yönetim, yazılım geliştirme ve diğer alanlara uygulanmıştır.

1980'lerde ve 1990'larda, geleneksel şelale metodolojileri kullanılarak yürütülen projeler daha uzun sürdüğü için yazılım geliştirme endüstrisi bir krize yaklaşıyordu. Bu, genellikle bir iş ihtiyacının belirlenmesi ile bir yazılım çözümünün sunulması arasında büyük bir gecikmeyle sonuçlandı. Bazen bu gecikme, havacılık ve uzay endüstrisi gibi belirli gereksinimleri olan belirli endüstrilerde birkaç yıl veya hatta on yıllar içinde ölçülmüştür.

Bu çok yıllı zaman dilimleri sırasında gereksinimler, sistemler ve hatta tüm işletmeler değişti. Çoğu zaman, projeler kısmen iptal edilir veya kapsamlarını tamamlarlar, ancak teslim ettikleri şeyin artık projenin başında tanımlanan iş ihtiyaçlarını karşılamadığını öğrenirler.

Şelale metodolojisi, paydaşları, muhtemelen neye ihtiyaçları olduğundan emin olmasalar da bir sözleşme yazmaya zorlandıkları için her şeyi düşündükleri için ödüllendirdi. Şelale metodolojisi, gereksinimler veya tasarım aşamasında kararlar alınmasını zorunlu kıldı ve bu kararları sözleşmeyi değiştirmeden ve projeye maliyet eklemeden değiştirmek çok zordu. Yazılım projelerinin yüksek bir yüzdesi tamamen başarısız oldu, geç ve bütçenin üzerinde teslim edildi veya ihtiyaç duyulanı teslim edemedi.

Bu genel hayal kırıklığı, çeşitli düşünce liderlerinin Şelaleyi iyileştirmeye çalışmasına neden oldu. İlk örnekler arasında, hızlı bir prototip geliştirerek ve gereksinimleri daha da geliştirmek için iş dünyası ile işbirliği yaparak gereksinimleri ve tasarım aşamalarını kısaltarak israfı azaltmaya odaklanan Hızlı Uygulama Geliştirme (RAD) sayılabilir. Ayrıca, küçük bir projenin tamamlandığı ve sürekli yinelemelerde özelliklerin eklendiği yinelemeli geliştirmeye doğru bir hareket vardı. Bu metodolojiler yardımcı olurken, Şelale ile ilgili temel sorunları çözmedi.

1990'larda ve 2000'lerin başında, birkaç yazar Yalın ilkelerin yazılım geliştirmeye uygulanması hakkında kitaplar yayınladı. Robert Charette, 1993 yılında “Yalın Yazılım Geliştirme” ve 2003 yılında “Yalın Yazılım Geliştirmenin 12 İlkesi”ni yayınladı.

Tom ve Mary Poppendieck, 2003 yılında “Yalın Yazılım Geliştirme: Çevik Bir Araç Takımı”nı yayınladı. Bu kitap, Yalın Üretimdeki yedi israf biçimiyle doğrudan ilişkili olan Yalın Geliştirme'nin yedi ilkesini detaylandırdı. İki farklı Yalın yayın ve Çevik (bir sonraki bölümde tartışılacaktır) arasındaki benzerlikler ve farklılıklar aşağıdaki şemada gösterilmektedir.

Yalın ve Çevik Arasındaki Farklar

Dr. Charette'e göre, Yalın ve Çevik arasındaki temel farklardan biri, Çevik'in aşağıdan yukarıya, Yalın ise yukarıdan aşağıya olmasıdır.

Çevik Çerçeve

Çevikliğin Kökenleri ve Çevik Manifesto

Charette ve Poppendiecks kitaplarını yayınladıklarında, aynı sorunları çözmeye yardımcı olmak için Çevik Çerçeve oluşturuldu. 2001 yılının Şubat ayında, bir grup Çevik öncü, bir çözüm bulmak için Utah, Snowbird'deki kötü şöhretli Snowbird toplantısında bir araya geldi.

Sonuç, değişen gereksinimlere ve müşteri ihtiyaçlarına uyum sağlamaya, israfı azaltmaya ve artımlı, yinelemeli bir yaklaşım kullanarak faydaları daha hızlı sunmaya çalışan bir metodoloji için bir dizi değer ve ilke ortaya koyan Çevik Manifesto oldu.

Çevik Manifesto aşağıdaki gibidir:

“Yazılım geliştirmenin daha iyi yollarını yaparak ve başkalarının yapmasına yardım ederek ortaya çıkarıyoruz. Bu çalışma sayesinde şu değerlere ulaştık:

• Süreçler ve araçlar üzerinden bireyler ve etkileşimler
• Kapsamlı belgeler üzerinde çalışan yazılım
• Sözleşme müzakeresi üzerinden müşteri işbirliği
• Bir planı takip ederek değişime yanıt verme

Yani sağdaki maddelerde değer varken soldaki maddelere daha çok değer veriyoruz.”

Çevik Manifesto'nun arkasındaki 12 ilke, manifestodaki değerlerle uyumludur:

“Şu ilkeleri takip ediyoruz:

1. En yüksek önceliğimiz, değerli yazılımları erken ve sürekli teslim ederek müşteriyi memnun etmektir.
2. Geliştirmede geç olsa bile değişen gereksinimleri memnuniyetle karşılayın. Çevik süreçler, müşterinin rekabet avantajı için değişimden yararlanır.
3. Daha kısa zaman ölçeğini tercih ederek, çalışan yazılımı birkaç haftadan birkaç aya kadar sık ​​sık teslim edin.
4. İş adamları ve geliştiriciler, proje boyunca günlük olarak birlikte çalışmalıdır.
5. Motive olmuş bireyler etrafında projeler oluşturun. Onlara ihtiyaç duydukları ortamı ve desteği verin ve işi tamamlamaları için onlara güvenin.
6. Bir geliştirme ekibine ve içinde bilgi aktarmanın en verimli ve etkili yöntemi yüz yüze görüşmedir.
7. Çalışan yazılım, ilerlemenin birincil ölçüsüdür. Çevik süreçler sürdürülebilir kalkınmayı teşvik eder.
8. Sponsorlar, geliştiriciler ve kullanıcılar, süresiz olarak sabit bir hızı sürdürebilmelidir.
9. Teknik mükemmelliğe ve iyi tasarıma verilen sürekli dikkat, çevikliği artırır.
10. Sadelik - yapılmayan iş miktarını en üst düzeye çıkarma sanatı - esastır.
11. En iyi mimariler, gereksinimler ve tasarımlar kendi kendini organize eden ekiplerden ortaya çıkar.
12. Ekip, düzenli aralıklarla nasıl daha etkili olunacağını düşünür, ardından davranışını buna göre ayarlar ve ayarlar.”

Yukarıdaki değerler ve ilkeler, Jidoka, JIT, Genchi Genbutsu, Kaizen, Hansei, Heijunka ve israfı azaltma gibi Yalın ilkelerin uygulamalarıdır.

Yazılım Geliştirmede Uygulanan Çevik İlkeler

Çevik, Çevik değerler ve ilkeler kümesini uygulayan herhangi bir süreç için geçerli olan bir şemsiye çerçevedir.

Bazı örnekler:

• Aşırı Programlama
• Scrum
• kanban

Scrum

Pisliğin Kısa Tarihi

Scrum, birçoğu Çevik Manifesto'yu imzalayan birden fazla kişi tarafından ayrı ayrı icat edilen Çevik ilkeleri uygulayan bir çerçevedir:

• Hirotaka Takeuchi ve Ikujiro Nonaka, ilk olarak "Scrum" terimini, "Yeni Ürün Geliştirme Oyunu" adlı beyaz kağıtlarında üretim bağlamında tanıttılar. 1986'da Harvard Business Review'da yayınlandı.
• Jeff Sutherland, John Scumniotales ve Jeff McKenna, 1993 yılında Easel Corporation'da Scrum'ı uygulamışlardır.
• Ken Schwaber, 1990'larda şirketi Advanced Development Methods'da Scrum olacak olanı kullandı.

Schwaber ve Sutherland, 1990'lar boyunca, çeşitli konferanslarda konuşan, yazılım geliştirme bağlamında çerçeveyi geliştirmek ve iyileştirmek için işbirliği yaptı. Schwaber, 2001 yılında “Scrum ile Çevik Yazılım Geliştirme” kitabında yöntemi açıklamak için Mike Beedle ile birlikte çalıştı.

Schwaber, her iki ana Scrum sertifika yetkilisini de oluşturmaya devam etti:

• Scrum Alliance: 2001'de oluşturuldu. Sertifikalı Scrum akreditasyon serisini kurun.
• Scrum.org: 2009 yılında Schwaber'in Scrum Alliance'dan ayrılmasından sonra oluşturuldu. Paralel Professional Scrum akreditasyon serisini kurun.

Zamanla, Scrum çerçevesinin daha büyük ekiplere ve projelere ölçeklenmesini sağlamak için birkaç çerçeve/sertifikasyon kuruluşu oluşturuldu, çünkü Scrum başlangıçta küçük ekipler için tasarlandı (7 artı veya eksi 2 üye):

• SAFe: Ölçekli Çevik Çerçeve
• LeSS: Büyük Ölçekli Scrum
• Scrum@scale: Jeff Sutherland tarafından yaratılan Ölçekte Scrum

Scrum Değerleri

Scrum Alliance'a göre:

Scrum, ekiplerin ürünleri kısa döngülerde teslim etmesine yardımcı olan, hızlı geri bildirim, sürekli iyileştirme ve değişime hızlı adaptasyon sağlayan basit ama inanılmaz derecede güçlü bir ilkeler ve uygulamalar dizisidir.

Scrum, Çevik ilkeleri uygulayan yazılım geliştirmek için kuralcı, artımlı ve yinelemeli bir çerçevedir. Scrum değerleri ve ilkeleri aşağıdaki çizelgelerde özetlenmiştir ve Yalın ve Çevik değer ve ilkelerle önemli ölçüde uyumludur.

Scrum'a Genel Bakış

İş, sprint adı verilen ve genellikle 1-3 hafta olan kısa süreli yinelemelere bölünür. Bu, Şelalenin derinlemesine planlamasına tam bir tezat oluşturuyor. Mevcut sprint için planlanan iş, Ürün İş Listesi (Pull System, Heijunka) adı verilen öncelikli iş kalemlerinin en üstünden seçilir ve sprint başladığında sabitlenir. Amaç, her sprint sonunda hızlı geri bildirim sağlayan çalışan bir yazılıma sahip olmaktır.

Sprint sonunda ekip, tamamlanan işi, sprintin nasıl gittiğini gözden geçirmek ve bir sonraki sprinti planlamak için toplanır. Sprint uzunluğu, sprint ritüelleri ve kadansı ile birlikte her sprint için sabitlenir.

Sprint'ler, sprint'teki işi tamamlamak için gereken tüm becerileri içeren çapraz işlevli ekipler tarafından yürütülür. Günlük planlama ve ilerleme takibi, saldırı tahtası ve sprint tükenmişlik çizelgeleri gibi görsel eserler kullanılarak yapılır.

Bir sprintteki iş, öncelikli bir biriktirme listesinden çekilir. Bu yöntemlerin izlenmesi, zaman içinde değişen gereksinimlere izin verir ve son kullanıcılardan sürekli geri bildirim almayı teşvik eder.

Aşağıdaki zihin haritası diyagramı, ilerleyen bölümlerde tartışılacak olan Scum'un bazı ana kavramlarını özetlemektedir.

Scrum Rolleri

Scrum'ın üç rolü vardır:

• Scrum Master : Scrum Master, Scrum ekibinin hizmetkar lideridir. İşbirliğini kolaylaştırmaya yardımcı olan, engelleri kaldıran, Scrum sürecini uygulayan ve koruyan ve ekibi koruyan ekibin koçlarıdır. Bu, tipik olarak, sprint ritüellerini organize edip kolaylaştırdıkları, ürün sahibinin uygun şekilde önceliklendirilmiş ve bakımlı bir birikime sahip olduğundan emin oldukları, ekibin bir sprint için aşırı taahhütte bulunmaya baskı yapmadığından emin oldukları, kapsamın bir sprinte eklenmediğinden emin oldukları anlamına gelir. sprint, Bitti Tanımına uyulmasını sağlar. Ekip üyelerine (Genchi Genbutsu) görev atamazlar ve bir projenin tesliminden sorumlu değildirler.
• Ürün Sahibi : Ürün sahibi, ürünün tesliminden 'tek burulabilen boyun' sorumludur. Ürün sahibi, inşa etmek istedikleri şeyin vizyonunu tanımlar ve bu vizyonu takıma ve organizasyona iletir. Ürün sahibi, iş ve pazar gereksinimlerinin sahibidir ve ürün biriktirme listesinin oluşturulması ve yönetilmesi yoluyla yapılması gereken tüm çalışmalara öncelik verir. Hangi özelliklerin ne zaman gönderileceğine karar verirler. Herkesin ürün biriktirme listesindeki öğeleri anladığından emin olmak için ekip ve diğer paydaşlarla birlikte çalışırlar. Sprint demosunda bir sprintte tamamlanan işi kabul eder veya reddederler.
• Takım Üyesi : Scrum takımı, tipik olarak beş ila yedi üyeden oluşan, kendi kendini organize eden, çapraz fonksiyonel bir takımdır. Projedeki herkes birlikte çalışır ve birbirine yardım eder ve mimar, programcı, tasarımcı veya testçi gibi farklı rollere bağlı olmak zorunda değildir. Herkes birlikte çalışma setini tamamlar. Scrum takımı, her bir sprinti ne kadar tamamlayabileceklerini planlar ve planın sahibidir (Genchi Genbutsu).

Scrum Akışı, Aktiviteler ve Törenler

Yukarıda tartışıldığı gibi, Scrum'ın tanımlanmış bir akışı ve bir dizi ritüel ve etkinliği vardır. Bir sprintin akışı aşağıdaki gibidir.

Sprint Planlama:

Bir sprint başlamadan önce, Scrum Master, ürün sahibinin yaklaşan sprintin hedeflerini belirlediği ve ardından takımın çalışmalarını hedeflere göre planladığı, sprint planlama toplantısı olarak adlandırılan, scrum ekibi ve ürün sahibi ile bir toplantıyı kolaylaştırır.

Bu genellikle aşağıdaki faaliyetlerle yapılır:

• Sprint Kapasitesi: Takım, gün sayısı, takım üyesi sayısı, tatiller vb. dikkate alarak sprint kapasitesini belirler.
• Sprint Hedefleri: Ürün sahibi, sprint için hedeflerin ne olduğunu tanımlar. Ürün biriktirme listesinin hedeflere göre önceliklendirilmesi (yani ilgili hikayelerin en üstte olması) ve bakımlı olması çok önemlidir.
• İş Seçimi: hikayeler veya görevler, biriktirme listesinin tepesinden tahmini kapasiteye ulaşılana kadar sprint'e çekilir. Hikayeler eklendikçe, ürün sahibi hikayeyi açıklayacak ve ekipten gelen soruları yanıtlayacak, ürün sahibi ve Scrum ekibi hikaye hakkında iyi ve ortak bir anlayışa sahip olana kadar hikayeyi gerektiği gibi güncelleyecektir. Bu aktivite tamamlandığında, takımın önerilen bir başlangıç ​​sprint kapsamı olur.
• Görev Dağılımı: Scrum ekibi, hikayeyi nasıl tamamlayacaklarını ve tüm kabul kriterlerini ve Savunma Bakanlığı'nı ele alacaklarını planlamaya vurgu yaparak her hikayeyi ayrıntılı olarak tartışır. Hikayeyi tamamlamak için gereken alt görevlerin bir listesini üretecekler. Alt görevlerin listesi tamamlandıktan sonra, hikayenin tahmini gözden geçirilir ve gerekirse güncellenir.
• Sprint Taahhüdü: Tüm hikayeler parçalandıktan ve tahminler güncellendikten sonra, önerilen ilk sprint kapsamı gözden geçirilir. Hikayeler sprintten çıkarılabilir ve biriktirme listesine geri alınabilir ve/veya ek hikayeler eklenebilir. Bu yapıldıktan sonra, YALNIZCA Scrum ekibi (Scrum Master veya ürün sahibi değil) işi sprintte tamamlamayı taahhüt eder ve sprint başlatılır.

Sprint için taahhüt edilen toplam iş veya kapsam miktarı hikaye puanlarıyla ölçülür.

Sprint Yürütme

Sprint sırasında, ekip üyeleri üzerinde çalışmak için sprint Yapılacaklar listesinin en üstünden iş öğelerini (kullanıcı hikayeleri, görevler vb.) çeker. Çeşitli ekip üyeleri, çeşitli iş öğeleri veya bunların alt görevleri üzerinde çalışacaktır. Uygun olduğunda, bir öğeyi tamamlanıncaya kadar Scrum Board'da bir sütundan diğerine (tipik olarak Yapılacak > Devam Ediyor > Test > Bitti veya bunun bir varyasyonu) taşıyarak durumunu güncellerler.

İlerleme, tamamlanan ve kalan iş miktarını hikaye noktalarında ölçülen bir iş bitim tablosu kullanılarak takip edilir. Kalan kat noktaları Y ekseninde, kalan süre X ekseninde gösterilir. Hikayeler tamamlandığında, Burndown grafiği güncellenir.

Günlük olarak, Scrum Master şunlara odaklanır:

• Günü planlamak ve ilerlemeyi gözden geçirmek için günlük standup toplantısını kolaylaştırır (aşağıya bakın)
• Ekibin gün için bir planı olmasını sağlar
• Engelleri kaldırır
• Sprint kapsamını ve ekibi dikkat dağıtıcı şeylerden korur
• Takımın iş bitim çizelgesini ve diğer Scrum istatistiklerini korumasına yardımcı olur

Günlük Standup

Sprintte her günün başında, Scrum Master, günü planlamak ve sprint ilerlemesini gözden geçirmek için scrum ekibi ve ürün sahibi ile 15 dakikalık kısa bir toplantı düzenler. Bu, herkesin Scrum Kurulunun önünde durduğu ve toplantıdaki her kişinin, sprint tahtasındaki belirli maddelere atıfta bulunarak aşağıdaki soruları 2 dakika veya daha kısa sürede yanıtladığı kısa bir toplantıdır:

• Dün ne yaptın?
• Bugün ne yapmayı planlıyorsun?
• İşinizi tamamlamanızı engelleyen herhangi bir engel var mı?

Bu, herkesin herkesin ne üzerinde çalıştığını görmesine, hangi ilerlemenin kaydedildiğini veya kaydedilmediğini görmesine ve engelleri ve/veya ihtiyaç duyulan yardımı belirlemesine olanak tanır.

Sprint Tamamlama

Scrum Master, bir sonraki sprinti planlamadan önce sprintten çıkmak için iki seremoniyi kolaylaştırır.

Sprint Demosu

Sprint'in sonunda, Scrum Master, tamamlanan her hikayenin çalışan yazılım üzerinde ürün sahibine ve ekibin geri kalanına gösterildiği bir sprint demo toplantısını kolaylaştırır. Ürün sahibi, tüm kabul kriterleri karşılanırsa hikayeyi kabul edecek veya hikayeyi reddedecektir. Bir hikaye reddedilirse, eksiklikler belirlenir ve hikaye, daha sonra tamamlanacak veya hiç tamamlanmayacak şekilde öncelik sırasına göre ürün biriktirme listesine geri konur. Çoğu zaman, bir hikayenin ürün sahibinin kabul etmediği kısımları ayrı hikaye(ler)e bölünür ve orijinal hikaye kapatılır.

Sprint (Hız) başına tamamlanan toplam hikaye noktası sayısı hesaplanır ve sprint kapatılır. Hız, ekibin çıktı düzeyini izlemek için kullanılır ve özelliklerin veya sürümlerin ne zaman tamamlanacağını tahmin etmek için kullanılır.

Sprint Retrospektifi

Sprint demosundan sonra, ancak bir sonraki sprint planlama toplantısından önce, Scrum Master, ekibin henüz tamamlanan sprint üzerinde düşündüğü ve neyin iyi gittiğini ve neyin iyi gitmediğini tartıştığı bir sprint retrospektifini kolaylaştırır, böylece süreci sürekli ve aşamalı olarak iyileştirebilirler. ve zamanla kalite (Kaizen, Hansei). Takımın tartışma oluşturmasına yardımcı olmak için kullanılabilecek çok sayıda geriye dönük format veya alıştırma vardır.

İyileştirme eylem öğelerinin bir listesi oluşturulur ve bazen ürün biriktirme listesine öğelerin eklenmesi, Savunma Bakanlığı veya ekip tüzüğünde değişiklikler vb. ile sonuçlanır.

Ürün İş Listesi Yönetimi

Ürün İş Listesi Oluşturma

Bir sprint planlanmadan veya yürütülmeden önce, ürün sahibinin bir ürün iş yığını oluşturması gerekir. Biriktirme listesi genellikle ürün sahibi tarafından yazılan hikayeler olarak adlandırılan özellik geliştirme öğeleriyle başlar ve zaman içinde ekibin herhangi bir üyesi tarafından potansiyel olarak yaratılan geliştirme veya KG görevleri, ani artışlar ve kusurlar vb. ile doldurulur. Biriktirme listesindeki tüm öğeler öncelik sırasına göre düzenlenir.

İş Listesi Bakımı

İlk ürün biriktirme listesi oluşturulduktan ve önceliklendirildikten sonra, devam eden biriktirme listesi düzeltme süreci devreye girer. Amaç, bir sprint planlama toplantısı sırasında bir sprint'e çekilmeye hazır olmaları için, biriktirme listesindeki en üstteki öğelerin her zaman en azından yeterince taranmasını ve tahmin edilmesini sağlamaktır. Bu genellikle, ürün yöneticisi ve Scrum Master tarafından kolaylaştırılan ekip ile düzenli olarak devam eden birikmiş iş yığını düzenleme toplantıları yaparak yapılır.

Toplantıdan önce, ekibe gözden geçirme ve bakım toplantısına hazırlanmaları için bir hikaye listesi gönderilir. Bakım toplantısında, her bir öğe kabul kriterleri, karmaşıklık, risk, boyut, uygulama stratejisi vb. açısından tartışılır. Kabul kriterleri ve hikayenin diğer detayları takım, ürün sahibi ve Scrum Master'a kadar gözden geçirilir ve revize edilir. hikaye hakkında ortak bir anlayışa sahip olmak. Bu noktada, hikaye, planlama pokeri adı verilen bir teknik kullanılarak hikaye noktalarında tahmin edilir.

Öykü Noktası Tahmini

Öykü puanları, öykülerin önceki, bilinen, iyi anlaşılmış iş parçalarıyla karşılaştırıldığı göreceli boyutlandırmayı kullanan bir çaba birimidir. Her zaman “bu hikaye daha büyük mü, daha küçük mü yoksa yaklaşık olarak aynı boyutta mı” sorusunu başka bir eserle soruyorsunuz.

Fibonacci ölçeği (1, 2, 3, 5, 8, 13, 21…), her bir artışın bir öncekinin yaklaşık iki katı olduğu (yani, beş noktalı bir hikaye, aşağı yukarı iki katı kadar) en yaygın kullanılan ölçektir. üç noktalı bir hikaye kadar büyük). Bazen T-shirt bedenleri (XS, S, M, L, XL) ve hatta balık (minnow, akvaryum balığı, alabalık, ton balığı, balina vb.) gibi diğer ölçekler kullanılır. Bir şeyin boyutunu diğerine göre karşılaştırmanıza izin veren herhangi bir ölçek işe yarayacaktır.

Hikaye noktaları, geliştirme, test etme, tasarım ve Bitti Tanımı için gereken diğer çeşitli görevler dahil olmak üzere ekibin bir hikayeyi uygulama çabasının tamamını temsil eder. Tahmin, işin miktarını, karmaşıklığını ve riskini hesaba katar. Hikayenin göreceli boyutu belirlendikten sonra, tahmin olarak ölçekte bir boyut atanır.

Ekipler, önce tüm ekibin referans hikaye olarak anladığı “en orta” boyutta bir hikaye seçerek tahmin için bir temel oluşturarak hikaye noktası tahmin sürecine hazırlanır. Daha büyük ve daha küçük olan bazı ek referans hikayeleri de seçilmiştir.

Hikaye puanı tahmini, planlama toplantıları sırasında ve bazen Planning Poker kullanılarak sprint planlaması sırasında yapılır:

1. Her ekip üyesi/tahmincisi bir dizi karta sahiptir.
2. İş listesi öğeleri, yukarıda açıklandığı gibi birer birer tartışılır.
3. Öğe tamamen tartışıldıktan sonra, her tahminci kendi tahminini temsil etmek için özel olarak bir kart seçer.
4. Tüm tahminciler tahminlerini yaptıklarında, aynı anda kartlarını gösterirler.
   • Tüm tahminler eşleşirse, tahminciler başka bir biriktirme listesi öğesi seçer ve aynı işlemi tekrarlar.
   • Tahminler farklılık gösterdiğinde, tahminciler bir fikir birliğine varmak için konuyu tartışırlar.

Hikaye noktası tahmininin avantajları şunlardır:

• Hızlı: tahminler, halihazırda tamamlanmış ürün biriktirme listesi kalemlerine göredir.
• Yeterince Doğru: Kapsama ilişkin bir genel bakış sunmak, gelecekteki çalışmaları planlamak, öncelikleri belirlemek ve beklentileri yönetmek için yeterince doğru.
• Belirsizliği Kucaklıyor: Öykü noktaları, bilinmeyen bir zaman aralığı belirtir. Belirli bir Fibonacci benzeri hikaye noktaları dizisinden seçim yapmak, belirsizliğin yakalanmasını sağlar.
• Takım Sporu: Herkesi içerir (geliştiriciler, tasarımcılar, QA, ürün yöneticileri). İşin boyutunu belirlemek için birden fazla bakış açısı kullanır, ancak yalnızca işi yapan ekip üyeleri tahmin edebilir
• Takım Hızını Ölçer: Bir takımın bir sprintte ne kadar iş yaptığını, işi yapmak için harcanan zamana karşı ölçer. Ekip geliştikçe, aynı boyuttaki hikayeleri daha hızlı tamamlayacak ve zaman içinde daha yüksek hikaye puanı hızı elde edecek.

Sürüm Tahmini ve İzleme

Öykü noktası tahmini, aşağıdaki teknik kullanılarak bir yayın planlama bağlamında da kullanılır:

1. Boyutlandırılacak tüm hikayeleri listeleyin
2. Bunları küçükten büyüğe sıralayınız
   • Birinci ve ikinci kullanıcı hikayesini alın.
   • Hangisinin daha büyük olduğuna karar verin ve daha büyük olanı aşağıya koyun
   • Sonra bir sonrakini alın ve diğer ikisine göre nereye uyduğuna karar verin.
   • Tüm hikayeler artık listede olana kadar işlemi tekrarlayın (küçükten büyüğe bir sırayla)
3. Hikayeleri boyutlandırın

Bir sürümdeki tüm hikayeler için ekibin hızıyla birleştirilmiş hikaye tahminleri, bir sürümün ne zaman tamamlanacağını tahmin etmenize ve ilerlemesini izlemenize olanak tanır. Bu genellikle bir sürüm tükenme tablosunda gösterilir.

Scrum Eserleri ve Terimleri

• Ürün İş Listesi: Belirli bir ürün için özellikleri (öyküleri), teknik görevleri, ani artışları ve kusurları içerebilen tüm iş kalemlerinin iş listesi listesi
• Sürüm Yakma: Sürüm düzeyinde ilerlemeyi göstermek ve Sprint Velocity kullanılarak bir sürümün ne zaman tamamlanacağını tahmin etmek için kullanılan grafiksel bir çizelge. Tamamlanan hikaye noktaları Y ekseninde gösterilir ve sprintler X ekseninde gösterilir.
• Sprint İş Listesi: Belirli bir sprintte tamamlanacak tüm iş öğelerinin bir iş listesi listesi. Sprint iş listesinin içeriği, sprint planlama toplantısında kararlaştırılır.
• Scrum Board: Sprint için taahhüt edilen işin ilerlemesini izleyen bir masa stili tahta. Durumlar en üstte dikey sütunlarda gösterilir ve iş öğeleri tamamlanıncaya kadar her bir durum boyunca taşınır. Scrum panosu, sprint planlama toplantısı sırasında doldurulur ve bir sprint sonunda sıfırlanır.
• Sprint Burndown: Tamamlanan ve kalan iş miktarını, sprint boyunca hikaye noktalarında ölçülen grafiksel bir çizelge. Kalan kat noktaları Y ekseninde, kalan süre X ekseninde gösterilir.
• Sprint Hızı: Bir Scrum takımının bir sprintte tamamladığı hikaye puanlarının sayısı.
• Engeller İş Listesi: Takımın çalışmaya devam edebilmesi için Scrum Master tarafından ele alınması gereken engellerin listesi. Bir ekip üyesi engellendiğinde, ekibe ve Scrum Master'a görünürlük sağlamak için engeller biriktirme listesine bir öğe ekler.
• Epik: Bir epik, birden çok ilgili kullanıcı hikayesinden oluşan geniş bir çalışma grubudur.
• Kullanıcı Hikayesi: Bir kullanıcı hikayesi, bir yazılım özelliğinin son kullanıcı perspektifinden bir açıklamasıdır. Kullanıcı hikayesi, kullanıcının türünü, ne istediğini ve nedenini açıklar. Bir kullanıcı hikayesi, bir gereksinimin basitleştirilmiş bir tanımını oluşturmaya yardımcı olur ve kabul kriterlerini içerir. Kullanıcı hikayeleri ürün sahibi tarafından oluşturulur ve korunur.
• Görev: Görev , Scrum Master veya takım üyesi tarafından girilen, doğrudan veya dolaylı olarak kullanıcı hikayeleriyle ilgili olabilecek bir çalışmadır. Bunlar genellikle teknik niteliktedir ve kabul kriterlerini içerecektir.
• Spike: Spike , bir kullanıcı hikayesini nasıl uygulayacağınıza veya tahmin edeceğinize karar vermeden önce araştırma, prototip ve/veya mimari yapmanız gerektiğinde kullanılan özel bir görev türüdür.
• Alt görev : Bir alt görev, bir kullanıcı hikayesini veya görevini tamamlamaya yönelik bir uygulama adımı olarak girilen bir görevdir. Genellikle bir sprint planlama toplantısı sırasında takım tarafından girilir.
• Story Point Estimates: Fibonacci ölçeğine (1, 2, 3, 5, 8, 13, 21…) dayalı göreceli bir boyutlandırma tahmin ölçeği.
• Kabul Kriterleri: Bir ürün sahibinin bir hikayeyi tamamlanmış olarak kabul etmesinden önce tamamlanması gereken, her hikayede yer alan hikayeye özgü, test edilebilir öğelerin listesi.
• Bitti Tanımı (DoD): Herhangi bir hikayenin tamamlanmış olarak kabul edilebilmesi için tamamlanması gereken ortak adımların veya kriterlerin bir listesi. Ekip bu konuda hemfikirdir ve her hikayede listelenmesine gerek kalmaması için belgeler.

Scrum'ın Avantajları ve Dezavantajları

Scrum'ın birincil avantajı, Çevik değer ve ilkelerin yanı sıra Seiri, Jidoka, Tam Zamanında, Kaizen, Genchi Genbutsu, Heijunka, Çekme Sistemi ve Yinelemeler gibi Yalın kavramların uygulanmasıdır. Applying these principles allow project teams to receive continuous feedback, quickly adapt to changing requirements and uncertainty, reduce waste, increase visibility and transparency, and strive for continuous improvement. By always focusing on the most important items in the product backlog and only working in short iterations that always produce working software, Scrum is more customer focused and allows customers to see what they like (and don't like) and make changes as needed. The overhead cost in terms of process and management is smaller, thus leading to quicker, cheaper results.

Scrum is a great methodology for projects with requirements that are not clearly known and/or expected to change. This applies to most projects. Scrum is also great for experienced, motivated teams as it allows teams to organize the work themselves and it provides visibility, transparency, and accountability for both progress and problems. All of this will result in teams improving and becoming more productive over time.

Scrum does have some disadvantages and is not the best methodology in some situations:

• Transparency: Scrum increases transparency and accountability which is both an advantage and disadvantage as problems and poor performance within and outside the team and are exposed. This can be uncomfortable and can lead to resistance if not handled properly within the Scrum framework of continuous improvement.
• Team Experience and Commitment: Inexperienced and/or uncommitted Scrum teams or Scrum Masters can cause serious problems through misapplying the Scrum methodology. There are no defined roles in the Scrum team as everyone does everything, so it requires committed team members with technical experience to follow the Scrum process and improve over time. It can also be very detrimental if other parts of the organization are resistant to Scrum.
• Scope Creep: There is a risk of scope creep, especially if there isn't a defined end date as stakeholders are allowed to add to the scope. Being able to change scope and priorities is one of the main advantages of Scrum, but it can also be a disadvantage if discipline isn't used.
• Poorly defined work: Poorly defined and understood user stories or tasks can lead to rework, inaccurate estimates, and scope creep. Although Scrum is focused on working software over documentation, the product owner needs to be clear on what they want and be able to clearly communicate that in conversations and in the user stories.
• Scaling: Adopting the Scrum framework in large teams is challenging as Scrum is meant for smaller teams.

kanban

What Is Kanban?

Kanban is a lighter weight process that applies many of the Lean and Agile values as well as a subset of the Scrum values and principles but there are also some fundamental differences. Kanban focuses on visualization, flow, and limiting work in progress.

Kanban is Japanese for “signboard” or “billboard.” Toyota line-workers used a kanban (ie, an actual board) to signal extra capacity in various steps in their manufacturing process. In software, this is done with a Kanban board, which is very similar to the Scrum board. There is a prioritized backlog of To Do items and vertical columns for each status that a work item can have. Like Scrum, work items are moved from one status to another; however, in Kanban, the amount of work in progress is strictly limited to a maximum number of items in each status based on team capacity. New work cannot be pulled in until existing work is moved to the next step in the process. In Scrum, work in progress in indirectly limited by controlling the amount of work planned for a sprint.

In Kanban, there are no fixed iterations or sprints, just a constant flow where work items are pulled from one stage to the next. This means that the Kanban board is never reset. It also means that many of the Scrum rituals not used. Kanban teams often have daily standup meetings but they are not prescribed. There are no regularly planned sprint planning meetings, sprint demos or sprint retrospectives, so the process is more lightweight. Some of the activities in those rituals may or may not be performed at an informal level. Continuous improvement is accomplished by tracking and analyzing the flow of items from one state to another and making constant incremental improvements based on what issues are uncovered.

Kanban also doesn't prescribe the roles that Scrum does. The only role needed is the team member role, however, there is often a project manager that manages the team and the backlog. Often a single Kanban board can serve multiple function based roles and/or teams that only work on items in a certain status. For example, a development team might pull items from To Do to In Progress and move them to Testing, and the test team might test items in Testing and move them to Done.

Many of the backlog management activities for prioritizing and grooming of work items still need to be done to ensure that a given work item is well understood and ready to be worked on, however, estimating the work items is prescribed as optional.

Kanban vs. Scrum

The following table compares Scrum and Agile:

Summary: The End of Part 1

In this part, we reviewed a few of the most popular methodologies used for Software Development. By now you should have a good understanding of Lean, Agile, Scrum, and Kanban and their historical roots in Lean Manufacturing and TPS. In the next part of the series, we will continue reviewing and comparing other Software Development methodologies such as Waterfall, JTBD, and SAFe (and other scaling frameworks), as well as hybrid methodologies, so you have all of them conveniently explained in one place.