Çevik, Scrum ve Kanban: Bu Sözler Gerçekten Ne Anlama Geliyor?

Bir yazılım geliştiricisi, "yeni JavaScript çerçevesi" veya "yeni IDE" hakkında bir haber duyduğunda, bunun ne hakkında olduğunu açıklamak için daha fazla soru sormasına gerek yoktur. Ancak “yeni bir çevik çerçeve” duyarsa, muhtemelen Homer-Simpsonvari başını sallayarak, bunun ne hakkında olduğunu biliyormuş gibi yapacaktır, ancak bir ve yalnızca bir sorusu olacaktır: “Agile çerçeve” ne halt ediyor? anlamına gelmek?

Modern yazılım geliştirme ortamında, "çevik", "scrum" ve "kanban" gibi kelimeleri giderek daha fazla duyuyoruz ve bunlar genellikle yanlış kullanılıyor. Bu yazıda, bu terimlerden bazılarını açıklamaya ve netleştirmeye çalışacağım.

Atik

Kalabalığın en zekisi olmak istiyorsanız, iş sürecinden bahsederken her cümlede “çevik” kelimesini kullanmalısınız. Oldukça geniş bir yelpazeye sahip, bahsettiğiniz konu hakkında fazla bilgi sahibi olmanızı zorunlu kılmıyor ve gerçekten çok güzel bir sıfat ya da zarf: “düşünme çevik”, “çevik yaklaşım”, “çevik ilkelere göre”. Ama "çevik" gerçekten ne anlama geliyor?

"Çevik", "çevik yazılım geliştirme" anlamına gelir, çevik ilkeleri izleyen geliştirme yaklaşımı. Ama "çevik ilkeler" nedir? Çevik Manifesto'ya ve çevik gelişimin temellerini oluşturan çevikliğin 12 ilkesine bir göz atın. Manifesto'dan:

Çevik ilkeler, işleyen yazılımın sürekli teslimini, ekipler arasında yakın iletişimi ve değişen ihtiyaçlara yüksek düzeyde uyum sağlamayı teşvik eder. Yaptığınız işte bu değer ve ilkelere uyuyorsanız, çevik bir ortamda çalıştığınızı söyleyebilirsiniz. Dolayısıyla, çevik yazılım geliştirme bir metodoloji değil, aynı prensipleri takip eden bir dizi farklı metodoloji, çerçeve ve tekniktir. “Çevik”in düşünmek ve karar vermek için bir çerçeve olduğu söylenebilir.

Fakat işimizde bu ilkeleri takip etmek neden bu kadar önemlidir?

Manifesto ve ilkeler, yazılım geliştirmenin zorluklarına yanıt olarak on yıllar boyunca gelişen en iyi çözümleri aramanın sonucudur. 70'ler, 80'ler ve 90'lar boyunca, dünyanın her yerindeki farklı geliştiriciler ve ekipler, çalışma yöntemleri ve problem çözme yaklaşımları deniyor, farklı çerçeveler ve teknikler (scrum ve Extreme Programming gibi) icat ediyor ve hatta aynı noktaya geliyorlardı. paralel fikirler. Sonunda, Şubat 2001'de on yedi geliştirici bir araya geldi ve tüm bu farklı fikir ve deneyimler için ortak paydalar buldu. Manifesto böyle oluştu.

Scrum

Ne anlama geldiğini bilmeden “çevik” yöntemlerden bahsederseniz, konuyu bilen muhatabın önünde ağzınızı açıp, sizi açığa çıkaracak şeyler söyleyebilirsiniz: “Scrum ve diğer çevik metodolojiler”.

Scrum bir metodoloji değildir, ancak hepimiz Game of Thrones'daki cinayet sayısından çok daha sık duymuşuzdur. Scrum her soruya cevap vermeyecek ve karşılaştığınız her duruma yanıt vermek için size kesin prosedürü sağlamayacaktır. Ve muhtemelen bu yanlış yorumlamanın bir sonucu olarak, çoğu scrum uygulaması da yanlıştır: Takımlar değer kazanmaz. Bu, muhtemelen scrum hakkındaki en aptalca ifadeyle sonuçlanır: “Scrum çalışmıyor.”

scrum nedir? Scrum Kılavuzu, scrum'u şu şekilde tanımlar:

Yani bu bir çerçevedir ve diğer herhangi bir çerçeve gibi olabilir ve düzenli olarak yanlış şekilde kullanılır. Scrum'ı etkili bir şekilde kullanmak, yalnızca scrum tarafından belirlenen yapıyı benimsemeyi değil, tüm ekip genelinde çevik ilkeler için derin bir anlayışa ve takdire sahip olmayı gerektirir.

Scrum şu rollerden oluşur: Ürün Sahibi, Scrum Master, Geliştirme Takımı.

Ayrıca dört Scrum seremonisi vardır: Planlama Toplantısı, Günlük Scrum, Sprint İnceleme, Sprint Retrospektifi

Ve üç yapı: Product Backlog, Sprint Backlog, Product Increment.

Scrum projeleri, sprint dediğimiz düzenli zaman dilimlerinde düzenlenir. Genellikle iki hafta sürerler.

Bir Ürün Sahibi , projenin yönünü yönlendirmekten sorumludur. Yeni görevler ve özellikler belirlendikçe, ürün sahibi bunları bir ürün biriktirme listesine ekler. Bir sprint, geliştirme ekibinin üzerinde çalışmak için biriktirme listesinden görevleri seçtiği ve bunların nasıl uygulanacağını planladığı bir planlama toplantısıyla başlar. Bunu, geliştirme ekibinin ilerlemeyi izlemek için biriktirme listesini kullandığı ve faaliyetleri senkronize etmek ve gerekirse planı ayarlamak için günlük toplantı için toplandığı geliştirme takip eder. Geliştirmenin sonucu, ürüne uygulanabilecek ve hemen piyasaya sürülebilecek bir ürün artışı olmalıdır. Sprint'in sonunda, ürün artışı, sprint incelemesinde Ürün Sahibine sunulur ve burada daha fazla değişiklik gerekiyorsa ürün biriktirme listesi genişletilir. Daha sonra tüm ekip, çalışma süreci ve nasıl geliştirilebileceği hakkında konuştukları sprint retrospektifine katılır.

Scrum'ı öğrenmek ve anlamak kolaydır, ancak benimsemesi zordur. Bu çerçevenin bir proje için uygun olup olmamasının birçok nedeni vardır. Sadece günlük gelişimde değil, aynı zamanda kültürel olarak da çoğu zaman çok fazla değişiklik gerektirir. Scrum, uzun süre dayanan ve farklı türden uzmanları içeren karmaşık ürünlerin geliştirilmesine en iyi şekilde uyar.

Scrum neden bu kadar popüler ve neden geleneksel şelale modeline göre bir avantajı var? Basitçe söylemek gerekirse, bir ürüne ve müşterilere daha fazla değer sağladığı için. Şelale gibi “ağır” yöntemlerle, kimsenin aylarca projeden hiçbir şey görmediği korku hikayeleri boldur. Scrum ile bu mümkün değil.

Scrum, tamamen son kullanıcılara teslim edilen değerle ilgilidir. Scrum'ı gerçekten kullanıyorsanız, her sprintte değerli bir şey sunmanız gerekir. Değer ölçülebilir ve ekip ayrıca bir sonraki yinelemede daha fazla değer sağlamak amacıyla engelleri incelemeye ve uyum sağlamaya zorlanır.

Çoğu yazılım geliştirmede bir gökdelen inşa etmiyoruz; Başlamadan önce tüm planı hazırlamamıza ve sonuna kadar bu plana bağlı kalmamıza gerek yok. Yazılım geliştiriyoruz ve farklı durumlara uyum sağlama ve geliştirme sırasında ürün gereksinimlerini değiştirme yeteneğine sahibiz. Uzun bir süre boyunca, birçok geliştirici bunu sekizinci ölümcül günah olarak gördü, ancak ürün açısından, öngörülebilirliği optimize etmek ve riski kontrol etmek için büyük bir fayda sağlıyor. Scrum, bu yetenek etrafında geliştirilmiştir ve uygulanması, gerekli değişikliklerle başa çıkmak için güvenilir ve verimli bir yol sağlar.

Scrum ile bağlantılı olarak birçok teknik kullanılır: poker planlama, eşli programlama, test odaklı geliştirme (TDD), davranış odaklı geliştirme (BDD) ve diğerleri. Onlar gerçekten scrum'un bir parçası değil, daha çok uyumlu tekniklerdir. Scrum ile aynı anda sıklıkla bahsedilen bir yöntem kanbandır ve bu iki şeyin birbiriyle ilişkisinde ne anlama geldiği konusunda çok fazla kafa karışıklığı vardır.

kanban

Scrum ve kanban hakkında konuştuğunuzda, kalabalıktan sıkça sorulan bir soru "Hangisi daha iyi, scrum mu kanban mı?" olacaktır. Ve ne cevap vereceğinizi bilemeyeceksiniz çünkü bu elma ile portakalı karşılaştırmak veya "Hangisi daha iyi, krep mi bira mı?" diye sormak gibi bir şey. İkisi de daha iyi.

Kanban, ekip üyelerini aşırı yüklemeden tam zamanında teslimatı hedefleyen basit bir yöntemdir. Hedefin sonunda maksimum değer sunmak olduğu için scrum'a benzer, ancak scrum'dan çok daha esnektir.

Kanban, yazılım geliştirme topluluğu tarafından icat edilmedi. Aslında, Toyota'daki üretim süreçlerinde kökleri vardır ve diğer alanlarda geniş bir kullanıma sahiptir. İzlemeniz gereken katı prosedürler ve kanbanı uygulamanız ve kullanmanız için katı bir yol yoktur; daha ziyade bir dizi ilke ve uygulamadır ve bu uygulamalardan ihtiyaçlarınıza uygun olanı seçebilirsiniz. Ancak, iş aşamalarını ve görevleri temsil eden sütunlardan oluşan bir kanban panosunun kullanımını içeren, yazılım geliştirmede en sık kullanılan kanban uygulaması vardır.

Sütunlar, geliştirme sürecindeki bir görevin durumunu temsil eder. En basit örnek üç sütundan oluşur: "Yapılacaklar", "Devam Ediyor" ve "Bitti". Bu nedenle, görevler "Yapılacaklar"a eklenir, geliştirme başladığında "Devam Ediyor"a taşınır ve son sütuna taşındığında "Bitti" olarak kabul edilir. Ama elbette, daha karmaşık olabilir:

İş Listesi → Spesifikasyonu Tanımlama → Geliştirmeye Hazır → Geliştirme → Kod İnceleme → Test Etme → Dağıtıldı (→ Gerçekten kimse kullanmıyor → Tamamen Kaldırıldı).

Her sütunun alt sütunları olabilir; örneğin “Geliştirme”, “Planlama” ve “Kodlama” olarak ikiye ayrılabilir; "Test", "Birim Testi" ve "Entegrasyon Testi" olarak ikiye ayrılabilir. Uygunsa, sütunlar uzmanlara ayrılabilir. Ekip, sütunları ve aşamaları ihtiyaçlarına göre tanımlar. "Çekme" felsefesine göre, görevler yalnızca talep anında olduğunda iş akışına girmelidir.

Bu panonun amacı, kanban'daki ilk temel uygulama olan iş akışını görselleştirmektir . Aslında kanban tahta olmadan da yapılabilir! Görevin durumunu gösteren farklı arka plan renklerine sahip bir Google sayfasındaki basit bir görev listesi olabilir veya Gantt çizelgeleri, diyagramlar, tablolar olabilir… Ofisinizde her birinin temsil ettiği bir dizi kova bile olabilir. görevin durumu ve topların görev olarak kullanıldığı yerler. Sadece iş akışını görselleştirin ve tüm sürece şeffaflık sağlayın.

Bir diğer önemli ilke, çabalarınızın parti boyutunu küçültmektir . Basitleştirilmiş, bu, çoklu görevlerden kaçınmak anlamına gelir. Bu, aynı anda üzerinde çalıştığınız görevlerin hacmini azaltmak anlamına gelebilir. Bir ekipte üç tasarımcınız varsa, ekip "Tasarım" sütunundaki maksimum görev sayısını üç olarak ayarlayabilir.

Scrum gibi, kanban da ekibi süreçteki en önemli figür olarak görür. Ancak, scrum'un yaptığı gibi roller önermez ve mevcut sürecinizde değişiklik yapmaktan kaçınmak için mevcut rolleri koruyabilirsiniz. Aynı şey sürekli iyileştirme için de geçerlidir: Kanban genellikle sizi sürekli olarak öğrenmeye ve geliştirmeye teşvik eder, ancak scrum'un Sprint Retrospektifi'nde olduğu gibi sadece bu süreç için belirli bir olay öngörmez.

Hangisini Kullanmalıyım?

Scrum ve kanban birbirini dışlamaz ve gerçekten karşılaştırılabilir değildir. Scrum'da tanımlanmış roller vardır, kanban ise "Ne olur, mevcut rollerinizi ve sorumluluklarınızı koruyun" der. Scrum sizi çalışma şeklinizi değiştirmeye zorlayacaktır; kanban, mevcut işleminizle başlamanıza izin verir. Scrumda, olaylar için açık bir program çerçeve tarafından belirlenir; kanban'da etkinliğiniz yok. Yine de pek çok benzerlikleri var: Her ikisi de değer odaklı, ekip üyelerine sistemin “patronları” olarak saygı duyuluyor ve temelde aynı misyona sahipler: İsrafı sürekli olarak ortadan kaldırmak ve engelleri kaldırmak.

Ancak, “Özel projemde ve belirli ekibimde ne kullanmalıyım?” Sorusu. çok daha mantıklı. Kanban, çok fazla süreç ve kültürel değişiklik gerektirmez ve çoğu durumda, benimsemek scrum'dan daha kolay olacaktır. Öte yandan Scrum, süreci yönlendirmek için önemli ölçüde daha fazla yapı sunar ve bu, herkes aynı sayfada olduğu sürece büyük miktarda ek yükü ortadan kaldırabilir.

Ancak her ikisinin de güzelliği, ikisinin de katı bir kurallar dizisi olmamasıdır. Günlük toplantı veya inceleme gibi sizin için en iyi scrum öğelerini seçip seçmenizi engelleyen hiçbir şey yok. Ve bir kanban panosunu scrum'a dahil etmemeniz için hiçbir sebep yok.

Scrum, tüm ekip onu iyi anladığında oldukça etkili bir çerçeve olduğunu kanıtlamıştır. Ancak deneyimlerime göre, bazı müşterilerle hücumda çalışmayı zor buluyorum. Doğru scrum uygulaması için gereken süreç ve kültürel değişiklikler çok fazla olabilir (özellikle yeni bir Google oluşturduğuna inanan biriyle uğraşırken!). Öte yandan, kanban daha esnektir ve insanları değişmeye zorlamaz. Bazı yazarlar ayrıca kanbanın çevikliğe giden iyi bir yol olduğunu ve scrum'un daha kolay uygulanmasını sağladığını söylüyor. Diğerleri, scrum kullanmanın sonunda kanbana yol açması gerektiğini söylüyor.

Gerçek şu ki, her proje farklıdır ve herkese uyan tek bir çözüm yoktur. Bir proje yöneticisi olarak, ekibiniz için en iyi olanı belirlemek size kalmıştır.