Scrum ve Kanban: iki güçlü Çevik metodoloji açıklandı
Yayınlanan: 2021-05-27Yani karmaşık bir projeyi yönetmek üzeresiniz? Yapılması gereken bir sürü iş var ama panik yapmayın! Bir proje yöneticisi olarak, bütçeyi planlamak, izlemek, yönetmek, yürütmek, kaliteyi doğrulamak ve nihai projeyi zamanında yayınlamaktan sorumlu olacaksınız. Neyse ki sizin (ve ekibinizin de) çalışmasını daha kolay ve çok daha verimli hale getirebilecek birçok proje yönetimi metodolojisi var!
Bu yazıda, son yıllarda yazılım geliştirme dünyasında fırtınalar estiren en popüler iki Agile metodolojisine – Scrum ve Kanban – odaklanmak istiyorum. Bu günlerde, proje yönetimi için bu iki çerçeveyi benimsemeyen bir yazılım evi bulamazsınız. Hepsi ne hakkında? Scrum ve Kanban hakkında bilmeniz gereken her şeyi okuyun ve öğrenin!
Proje yönetiminde Çevik metodoloji tam olarak nedir?
Günümüzde şirketler artık geliştirme sürecinin tüm aşamalarında test etmeden tek bir proje üzerinde çalışmıyor. Sadece ödemiyor! Neden?
Bir düşünün: Tüm ekibiniz birkaç ay boyunca, diyelim ki, arka uç ve ön uç geliştiricilerinizin, tasarımcılarınızın ve metin yazarlarınızın tüm çalışmaları bittiğinde test edip değerlendirdiğiniz bir mobil uygulama geliştirmek için çalışıyor. Ancak o zaman ürününüzün artık pazar gereksinimlerine ve kullanıcı gereksinimlerine yanıt vermediğini fark ederseniz? Daha sonra, çok fazla zaman, para ve enerji tüketen tüm projenin sonraki yinelemelerini tanıtmanız gerekir.
Çevik metodoloji, iş akışını ve her aşamada değişikliklerin kolay uygulanmasını önemli ölçüde iyileştiren harika bir çözümdür. Agile'ın arkasındaki temel ilke, bir "büyük" ve karmaşık projeyi birkaç küçük öğeye (veya özelliğe) bölmek ve bunları birbiri ardına yayınlamaktır. Burada hem geliştirme hem de test etme, projeyi sürekli olarak doğrulamayı ve gerekli tüm iyileştirmeleri sunmayı kolaylaştıran iki eşzamanlı etkinliktir.
İşin ilginç yanı, uzun yıllar BT ve yazılım geliştirme şirketlerinde Çeviklik hakimken, bu metodoloji o kadar etkili oldu ki günümüzde pazarlama, satış, İK veya operasyonlar gibi diğer birçok alanda kullanılmaktadır. Verison One tarafından hazırlanan Çevik Durum Raporuna göre 2020 yılında teknoloji şirketlerinin ve yazılım evlerinin %95'i çeşitli Çevik yöntemler uyguluyordu.
Scrum çerçevesi: neden bu kadar harika?
Pek çok insan, oldukça benzer görünseler de eşanlamlı olmayan iki kavramı karıştırma eğilimindedir – bunlar Çevik ve Scrum'dır. Özetle, Çevik, Çevik Manifesto'da belirtilen tüm yöntem ve yaklaşımları belirten bir şemsiye terim iken, Scrum aslında bu yöntemlerden biridir. Bu kadar basit!

Scrum nedir ve ne zaman kullanılabilir?
Scrum, esas olarak geliştirme sürecinin en az birkaç ay sürdüğü karmaşık ürünler oluşturmak için uygulanan bir proje yönetimi çerçevesidir. Her şeyden önce şeffaflığa, tüm ekip üyeleri arasında devam eden iletişime ve toplu sorumluluğa dayanır. Bu strateji, hedef kitlenin ihtiyaçlarını karşılayan ve mevcut pazar taleplerine yanıt veren projenin nihai versiyonunun sunulmasını kolaylaştırır.
Scrum özellikle son yıllarda öncü bir çerçeve haline gelse de, aslında yeni bir şey değil. Harvard Business Review, The New Product Development Game makalesini yayınladığı 1986 yılına geri dönelim. Orada, yazarlar Honda veya Canon gibi şirketler tarafından kullanılan ve başarılarına yol açan bir yönetim yaklaşımını tanımladılar. Daha sonra, 1993'te bu kavramlar Jeff Sutherland ve Easel Corporation ekibine Scrum adı verilen ekip tabanlı bir süreç oluşturma konusunda ilham verdi.
Scrum Takımındaki Roller ve Sorumluluklar
Bir Scrum takımında, tüm roller en başından itibaren açıkça tanımlanır ve genellikle tüm proje boyunca değişmez. Kural olarak, bu çerçevenin 3 temel rolü vardır: Ürün Sahibi, Scrum Master ve Geliştirme Takımı.
Saldırı ustası
Bir Scrum Master, her şeyin doğru şekilde yapıldığından ve geliştirme sürecinin sorunsuz bir şekilde çalıştığından emin olan bir tür (ancak tamamen değil) takım lideridir. Bir Scrum Master'ın ana sorumlulukları şunlardır:
- herkesin dijital ürünün yeni özelliklerini sunmak için daha verimli çalışması için ekip üyelerine koçluk yapmak
- sonraki sprintler için tüm görevleri planlamak (aşağıda size Scrum'daki sprintler hakkında daha fazla bilgi vereceğim) ve ürün birikimini sürdürmek
- proje yönetimi için Scrum ilkelerinin önemi konusunda paydaşları ve tüm ekip üyelerini eğitmek
- Tüm görevlerin plana göre gerçekleştirilip gerçekleştirilmediğini değerlendirmek
- verilen bir sprintte görevlerin gerçekleştirilmesini engelleyen tüm engelleri ortadan kaldırmaya çalışmak.
Bir Scrum Master'ın her zaman bir Ürün Sahibi ile yakın çalışması son derece önemlidir. Birlikte sonraki sprintleri planlarlar, tamamlanan görevlerin kalitesini değerlendirirler, takım için bir yön belirlerler ve projenin değişiklik gerektirip gerektirmediğini belirlerler. Basitçe söylemek gerekirse, Scrum Master Geliştirme Takımının başarılı olmasına ve tüm özellikleri zamanında teslim etmesine yardımcı olmak için elinden gelenin en iyisini yapar.
Ürün sahibi
Bir Ürün Sahibi, fiili ticari kazançlar sağlayabilecek ürünün nihai sürümünü sunmaktan sorumludur. Bu nedenle, tüm Scrum ekibinde öncelikleri belirleyen ve en belirleyici role sahip olan Ürün Sahibidir. Burada önemli olan, ürün birikiminin, en büyük iş değerine sahip oldukları için, hangi ürün özelliklerinin geliştirilmesi gerektiğini belirleyen Ürün Sahibi tarafından yönetilmesidir.
Bir Ürün Sahibinin ana sorumlulukları şunlardır:
- ürün birikimini yönetmek
- paydaşlarla iletişim kurmak
- her sprintin ana hedefini tanımlamak
- yeni özelliklerin piyasaya sürülmesini planlamak
- Geliştirme Takımının çalışmalarını değerlendirmek ve gerektiğinde sprinti iptal etmek
Geliştirme Takımı
Bir Geliştirme Takımı olmadan, asıl işi onlar yaptıkları ve belirli sprintler için planlanan tüm görevleri tamamladıklarından Scrum mümkün olmazdı.
Tipik olarak Geliştirme Ekibi, iOS, makine öğrenimi, arka uç veya ön uç geliştirme gibi belirli bir alanda uzmanlığa sahip kişilerden oluşur . Hepsi bir dijital ürünün yüksek kaliteli özelliklerini sunmak için güçlerini birleştiriyor. Bununla birlikte, "geliştirme ekibi" terimi genellikle mühendisleri ifade etse de, bunun her zaman doğru olmadığını unutmamalısınız. Pazarlamacılar, tasarımcılar, analistler, testçiler, metin yazarları veya satış uzmanları da bir miktar değer getirebilir ve bir Scrum ekibinin parçası olabilir.
Geliştirme Takımı oluştururken göz önünde bulundurulması gereken şeylerden biri de üye sayısıdır. Burada bile Scrum bazı temel kurallar belirler! Böyle bir ekibin 3 ila 9 kişiden oluşması ve tüm özellikleri sunabilecek becerilere sahip olması gerektiği söyleniyor. Tabii ki, hepsi projenin karmaşıklığına ve müşterinin ihtiyaçlarına bağlıdır; bazen 4 veya 5 geliştirici, dijital bir ürün oluşturmak için tamamen yeterlidir.
Ancak Geliştirme Takımının Scrum'daki rolü tam olarak nedir? Temel olarak, şunları yapmalıdır:
- tüm ürün özelliklerini Ürün Sahibinin talimatlarına göre oluşturun
- belirli bir sprintte kaç öğe oluşturulacağını belirleme
- tüm görevlerin sprint sonunda tamamlanması için iş yükünü verimli bir şekilde yönetin
- ilgili tüm kararları birlikte almak
- 'biz' yaklaşımına sahip olun – tüm kararları ekip verir, sorunları birlikte çözer ve her bir kişi diğer meslektaşlarından sorumlu hisseder

Özetle Scrum geliştirme süreci
Scrum'ın ne olduğunu ve Scrum takımını kimin oluşturduğunu zaten biliyorsunuz, bu yüzden şimdi bu metodolojideki geliştirme sürecinin nasıl göründüğünü ve nasıl doğru yapılacağını anlamanın zamanı geldi.
Scrum sürecinde, her adım önemlidir ve takımınıza gerçek değer katar. İşte atlamamanız gereken ana aşamalar:
- Ürün İş Listesi : Aşağıdaki sprintlerde oluşturulması gereken tüm öğelerin listesi. Her bir özelliğin veya öğenin tam olarak ne zaman piyasaya sürülmesi gerektiğini bilen bir Scrum Master ile birlikte bir Ürün Sahibi tarafından yönetilir.
- Sprint Planlama Toplantısı : Bu toplantının temel amacı Geliştirme Takımının her bir üyesinin bir sonraki sprintte ne yapacağını belirlemektir. Her zaman sprint başlamadan önce düzenlenir, böylece herkes tüm görevleri son teslim tarihinden önce tamamlayıp tamamlayamayacağını değerlendirebilir. Her takım üyesinin sprintin ana hedefini tam olarak kavradığından emin olun.
- Sprint İş Listesi : Bunlar, takımın belirli bir Sprint'te gerçekleştirmeyi seçtiği Ürün İş Listesinden alınan seçilmiş görevlerdir.
- Sprint : Tüm sihrin gerçekleştiği yer burasıdır. Sprint, Geliştirme Takımının Bahar Planlama Toplantısı sırasında verilen tüm görevleri tamamlamaya çalıştığı genellikle 1-4 hafta süren kısa bir dönemdir.
- Günlük Scrum'lar (Aynı zamanda Standup olarak da adlandırılır): Her gün aynı saatte yapılan ve herkesin 1-2 cümlede iş ilerlemesini rapor ettiği ekstra kısa toplantılar: tamamlananlar ve hala yapılması gerekenler hakkında konuşurlar.
- Sprint Değerlendirmesi : Sprint bittiğinde, herkes tamamladıklarını diğer takım arkadaşlarına ve hatta Sprint İncelemelerine oldukça sık katılan paydaşlara sunma şansına sahiptir.
- Sprint Retrospektifi : Şimdi tüm Sprint döngüsünü bitiren son toplantı zamanı. Herhangi bir takım üyesinin bir sonraki sprint için nelerin geliştirilebileceğine dair bazı önerileri veya fikirleri varsa, bunu Sprint Retrospektif toplantısında yapabilirler.

Scrum süreci için, her Scrum döngüsünün aynı yapıya sahip olduğundan emin olmak önemlidir : bir Sprint Planlama Toplantısı ile başlar, sonra herkes işe başlar ve sprint için belirlenen görevleri tamamlar ve en sonunda her takım üyesi gösterir. ne başardılar.

Hatırlamanızı istediğim bir şey daha var: Scrum'ın çok katı bir değişim felsefesi var. Bu pratikte ne anlama geliyor? Scrum takım üyeleri, sprint sırasında görevleri veya ana hedefleri değiştirmemelidir. Planlanan sonuçları sağlayamazlarsa, gelecek için öğeleri tamamlamak için gereken süreyi daha iyi tahmin etmek için bir ders olmalıdır.
Kanban hakkında birkaç kelime
Artık Scrum'ın ne olduğunu ve onunla dijital bir ürünün nasıl oluşturulacağını öğrendiğinize göre, ikinci Çevik metodolojiye biraz daha odaklanmanın zamanı geldi. Eminim buna zaten aşinasınızdır – henüz farkında olmasanız bile!
Kanban nedir ve ne zaman uygulanabilir?
Kanban terimi Japonca'dan gelir ve basitçe "görsel sinyal" olarak tercüme edilebilir. Temelde bu metodolojinin konusu budur. Kanban'da her öğenin kendi görsel temsili vardır - ekip üyelerinin beyaz tahtalara koyduğu ve durumunu değiştirdiği bir kart ('yapılacak', 'yapılıyor' veya 'tamamlandı' gibi).
Bu yaklaşım herhangi bir endüstri tarafından kolayca uygulanabilir, ancak çoğunlukla karmaşık ve zaman alıcı projelerde yer alan yazılım geliştirme ekipleri tarafından tercih edilir. Ve iyi bir nedenle - Kanban, gerçek zamanlı iletişimi kolaylaştırır ve tüm ekip arkadaşlarının çalışmalarını tamamen şeffaf hale getirir.
İlginçtir ki, Kanban aslında Scrum'dan çok daha eski bir metodolojidir. Başlangıçları, Toyota'nın fabrikalarında beyaz tahtalara yerleştirilen ve işçilerin her an değiştirebileceği ayrı bir kart sistemi tanıttığı 1940'lara kadar uzanıyor. Sonuç olarak, bu strateji çalışmalarını çok daha sorunsuz hale getirdi ve ekipler arasındaki iletişimi hızlandırdı.
Kanban takımında kim kimdir?
Scrum'ı tartışırken, her bir ekip üyesinin (Scrum Master, Ürün Sahibi ve geliştiriciler) tam rollerini, sorumluluklarını ve yetkinliklerini tanımladım. Burada işler çok farklı. Kanban, kimin daha fazla yetkiye veya sorumluluğa sahip olduğunu tanımlamaz, çünkü pratikte tüm ekip üyeleri eşittir ve güçlerini ve beceri setlerini toplu olarak birleştirirler.
Ayrıca Kanban, bir projede kaç kişinin birlikte çalışabileceğini belirtmez, bu nedenle herhangi bir ekip yapısı kabul edilebilir. Ancak, iş akışını iyileştirmek istiyorsanız, bir çapraz geliştirme ekibi oluşturmayı düşünebilirsiniz. Bu çözüm sayesinde, farklı uzmanlık alanlarına sahip ekip üyeleri, ürün geliştirmenin her aşamasında bilgilerini paylaşabilir ve geri bildirimde bulunabilir. Bu sayede diğer ekiplere danışmanıza hiç gerek kalmayacak!
Kanban panosu nedir ve nasıl oluşturulur?
Kanban panosu, bu metodolojinin kalbi ve ruhudur. Her görevin ilerlemesini gerçek zamanlı olarak görselleştirmek için oluşturulmuş bir proje yönetim aracıdır. Takım arkadaşlarınızın önemli bir özellik üzerinde çalışmaya başlayıp başlamadıklarını veya belki de zaten bitirdiklerini merak ediyorsanız, tahtayı kontrol edin ve şimdi biliyorsunuz!
Bu örnek, Kanban'ın tam olarak ne olduğunu ve işi nasıl görselleştirdiğini gösterir:

Dolayısıyla Kanban panolarının arkasındaki genel konsept oldukça basittir: etiketlenmiş birkaç sütununuz var ve her birine görsel kartlar yerleştiriyorsunuz. Bunlar yapışkan veya bilet olabilir. Bu kartların her birine, şu anda dahil olduğunuz projenin adını veya inşa ettiğiniz belirli iş öğesini yazıyorsunuz. Ardından, ekibinizin geri kalanının güncellenmesi ve şu anda tam olarak ne üzerinde çalıştığınızı bilmesi için tek yapmanız gereken belirli bir sütuna belirli bir kartı tahsis etmektir.
Yukarıda görebileceğiniz örnek, aşağıdaki tipik sütun kategorilerini göstermektedir:
- 'yapmak'
- 'devam etmekte'
- 'test yapmak'
- 'tamamlamak'
Ancak, iş akışınızı daha geniş bir şekilde tanımlayabileceğinizi ve ek sütunlar ekleyebileceğinizi unutmayın; bunların seçimi, yönetmekte olduğunuz projeye bağlı olacaktır.
Ekibinizin başarılı olmasını istiyorsanız, bilmeniz gereken bir şey daha var - ekibinizin aynı anda üzerinde çalışabileceği öğeler için sınırlar belirlemelisiniz. Bu nedenle Kanban ayrıca Work In Progress (WIT) Limitlerinin ayarlanmasını tavsiye eder. Nasıl uygulamaya geçirilir? Bir sütunda aynı anda kaç kartın kalabileceğini (örn. 'Devam ediyor') belirtmeniz gerekir. Takımınız bu sınıra ulaşırsa, daha fazla kart ekleyemezler. Bu sınırları belirlemek, aşırı iş yüküyle başa çıkmak için her zaman harika bir çözümdür.
Scrum ve Kanban: Bu savaşı hangi çerçeve kazanır?
Eh, bu sorunun cevabı aslında o kadar basit değil. Bu iki Çevik strateji bazı benzer ilkeleri paylaşır ancak kullandıkları uygulamalar tamamen farklı iki şeydir. Kanban daha akıcı ve sürekli değişimi ve düzenli geri bildirimi tercih ederken, Scrum çok daha katı ve organize.
Bir sonraki yazılım projeniz için hazır mısınız?
Beraber çalışalımBu iki proje yönetimi çerçevesi arasındaki temel farklar şunlardır:
Scrum | kanban | |
---|---|---|
Roller | Scrum Master, Ürün Sahibi, Geliştirme Takımı | Tanımlanmamış roller |
Takımlar | Tek takım | Bir Kanban panosunda birkaç ekip çalışır |
iş akışı | Kısa sprintler (1-4 hafta) | Sürekli |
Teslimat | Her sprint sonunda yeni öğe/özellik | Sürekli |
Felsefeyi değiştir | Tüm sprint boyunca hiçbir değişiklik yapılamaz | Değiştirilen herhangi bir zamanda tanıtılabilir |
Anahtar metrikler | Hız | WIT, çevrim süresi |
Popüler araç | Jira | Trello |
Peki, projelerinizi yönetmek için bu Çevik çerçevelerden hangisini seçeceksiniz? Yoksa uzmanların sizin için yapmasını mı istersiniz? Bizimle iletişime geçmekten çekinmeyin - çeşitli Çevik metodolojileri tanıtarak 150'den fazla kullanıma hazır başarılı ürün teslim ettik!
Scrum yerine Kanban ne zaman kullanılır?
Kanban, sürekli bir iş akışı üzerinde çalışan ekipler için çok daha etkili bir metodolojidir . Diyelim ki düzenli olarak farklı önceliklere sahip yeni gelen talepleri alan bir ekibi yönetiyorsunuz. Bu durumda Kanban çok daha iyi bir seçenek olacaktır, çünkü bu yaklaşım zamanla sınırlı değildir – takımınızın iş akışını sprintlerle sınırlamaz ve kesin son tarihler tanımlamaz.
Basitçe söylemek gerekirse, daha fazla esneklik ve sürekli teslimat elde etmek istiyorsanız Kanban'ı kullanın.
Öte yandan, çalışmalarınız belirli zaman dilimlerinde yeni özellikler sunmaya odaklanmışsa ve açıkça tanımlanmış uzun vadeli hedefleriniz varsa, Scrum çok daha etkili olacaktır.
Trello Scrum mı Kanban mı?
Trello, görev yönetimi için Kanban yöntemini kullanan en popüler araçlardan biridir. Varsayılan olarak, mevcut durumlarına bağlı olarak görevleri bir sütundan diğerine taşımanıza olanak tanır. Bu şekilde projeye dahil olan herkes iş akışına her zaman uyum sağlayabilir.
Ancak Trello, küçük Scrum takımlarına da başarıyla uygulanabilir. Bu amaçla Scrum master, Backlog , Sprint Planning , Current Sprint , In Progress ve Done gibi farklı durumlara sahip birkaç sütun oluşturabilir ve görevleri bunlardan birine yerleştirebilir.
Kanban'ın sprintleri ve günlük stand-up'ları var mı?
Kanban, iş akışına sürekli olarak başka görevlerin eklendiği ve bir görevin teslimi için son tarihi belirtmediği akış odaklı Çevik bir yaklaşımdır. Bu nedenle sprint kullanmaz ve Kanban ekipleri Sprint Planlamaları veya Sprint Retrospektif toplantıları düzenlemez .
Dahası, Kanban, takımı günlük stand-up'lar yapmaya zorlamaz. Bununla birlikte, ekip bu tür kısa toplantıların bir miktar değer getirdiğini ve iş akışını iyileştirdiğini düşünüyorsa, yine de onları düzenlemeye izin verir.