Agile, Scrum ve Kanban: Bu Kelimeler Gerçekten Ne Anlama Geliyor?

Bir yazılım geliştiricisi “yeni bir JavaScript çerçevesi” veya “yeni bir IDE” hakkında haberler duyduğunda, bunun ne hakkında olduğunu netleştirmek için daha fazla soru sormasına gerek kalmaz. Ancak “yeni bir çevik çerçeve” hakkında bir şeyler duyarsa, büyük olasılıkla, ne hakkında olduğunu biliyormuş gibi Homer-Simpsons başını sallayacak, ancak bir ve yalnızca bir sorusu olacak: “Çevik çerçeve” ne halt ediyor? Ne anlamına gelmekte?

Modern yazılım geliştirme ortamında, “Agile”, “scrum” ve “kanban” gibi kelimeleri giderek daha fazla duyuyoruz ve bunlar genellikle uygunsuz şekilde kullanılıyor. Bu yazıda, bu terimlerin bazılarını açıklamaya ve netleştirmeye çalışacağım.

Agile(Çevik)

Kalabalığın aklı başında olmak istiyorsanız, iş sürecinden bahsederken diğer tüm cümlelerde “çevik” kelimesini kullanmalısınız. Oldukça geniş bir yelpazeye sahiptir, sizi bahsettiğiniz konu hakkında çok fazla bilgi sahibi olmaya zorlamaz ve gerçekten güzel bir sıfat veya zarftır: “Çevik düşünme”, “çevik yaklaşım”, “Çevik ilkelere göre.” Ama “çevik” gerçekten ne anlama geliyor?

“Çevik” , çevik ilkeleri izleyen geliştirme yaklaşımı olan “ çevik yazılım geliştirme “ anlamına gelir . Ama “çevik ilkeler” ne halt ediyor? Agile Manifesto’ya ve çevik gelişimin temellerini oluşturan 12 Agile ilkesine bir göz atın . Manifesto’dan:

Süreçler ve araçlardan ziyade bireyler ve etkileşimlerKapsamlı dokümantasyon yerine çalışan yazılımSözleşme müzakeresi yerine müşteri işbirliğiBir planı takip etmek yerine değişime yanıt vermek

Çevik ilkeler, çalışan yazılımların sürekli olarak sunulmasını, ekipler arasında yakın iletişimi ve değişen ihtiyaçlara yüksek düzeyde uyarlanabilirliği teşvik eder. İşinizde bu değerleri ve ilkeleri takip ederseniz çevik bir ortamda çalıştığınızı söyleyebilirsiniz. Dolayısıyla, çevik yazılım geliştirme bir metodoloji değil, sadece aynı ilkeleri takip eden bir dizi farklı metodoloji, çerçeve ve tekniktir. “Çevik” in bir düşünme ve karar verme çerçevesi olduğu söylenebilir.

Çevik, düşünmek ve kararlar almak için bir çerçevedir.

Ama işimizde bu ilkelere uymak neden bu kadar önemli?

Manifesto ve ilkeler, yazılım geliştirmenin zorluklarına yanıt olarak on yıllar boyunca gelişen en iyi çözümleri araştırmanın sonucudur. 70’ler, 80’ler ve 90’lar boyunca, tüm dünyada farklı geliştiriciler ve ekipler, problem çözme, farklı çerçeveler ve teknikler (scrum ve Extreme Programming gibi) icat etme ve hatta paralel olarak aynı fikirlere gelme metotları ve yaklaşımları üzerinde deneyler yapıyorlardı. Son olarak, Ş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 yaratıldı.

Çevik Manifesto, on yıllar boyunca ortaya çıkan farklı deneyimlerin ve pratik çözümlerin sonucudur.

Scrum

Ne anlama geldiklerini bilmeden “çevik” yöntemlerden bahsederseniz, konuyu bilen muhatap önünde sizi ortaya çı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 adlandırıldığını duymuşuzdur . Scrum, her soruya bir yanıt vermez ve karşılaştığınız her duruma yanıt vermeniz için size kesin bir prosedür sağlamaz. Ve muhtemelen bu yanlış yorumun bir sonucu olarak, çoğu scrum uygulaması da yanlıştır: Takımlar değer kazanmaz. Bu muhtemelen scrum hakkında en aptalca ifadeyle sonuçlanır: “Scrum çalışmıyor.”

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

“İnsanların, mümkün olan en yüksek değere sahip ürünleri üretken ve yaratıcı bir şekilde sunarken, karmaşık uyarlanabilir sorunları ele alabileceği bir çerçeve.”

Yani bu bir çerçeve ve diğer tüm çerçeveler gibi olabilir ve düzenli olarak yanlış şekilde kullanılabilir. Scrum’ı etkili bir şekilde kullanmak, yalnızca scrum tarafından belirlenen yapıyı benimsemeyi değil, aynı zamanda tüm ekipte Agile ilkeleri için derin bir anlayışa ve takdire sahip olmayı gerektirir.

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

Ayrıca dört Scrum buluşması vardır: Planlama Toplantısı, Günlük Scrum, Sprint İncelemesi, Sprint Retrospektifi

Ve üç eser: Product Backlog, Sprint Backlog, Product Increment.

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

Bir Ürün Sahibi projenin gidişatına rehberlik etmekten sorumludur. Yeni görevler ve özellikler belirlendikçe, satın alma sahibi bunları bir ürün biriktirme listesine ekler. Bir sprint, geliştirme ekibinin iş yığınından üzerinde çalışmak için görevleri seçtiği ve bunların nasıl uygulanacağını planladığı bir planlama toplantısı ile başlar. Bunu, geliştirme ekibinin ilerlemeyi izlemek için iş yığınını kullandığı ve gerektiğinde etkinlikleri senkronize etmek ve 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. Daha sonra, tüm ekip sprint retrospektifine katılır ve burada çalışma süreci ve nasıl geliştirilebileceği hakkında konuşurlar.

Scrum’ı öğrenmek ve anlamak kolaydır, ancak benimsemek zordur. Bu çerçevenin bir projeye uygun olmasının veya 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ürde 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 ifade etmek gerekirse, çünkü bir ürüne ve müşterilere daha fazla değer katar. Şelale gibi “ağır” yöntemlerle, aylarca kimsenin projeden hiçbir şey görmediği korku hikayeleri bolca bulunur. Scrum ile bu mümkün değil.

Scrum, son kullanıcılara sunulan değerle ilgilidir . Gerçekten bir scrum kullanıyorsanız, her sprintte değerli bir şey sunmanız gerekir. Değer ölçülebilir ve ekip aynı zamanda bir sonraki yinelemede daha fazla değer sunmak amacıyla engelleri incelemek ve uyum sağlamak zorunda kalır.

Çoğu yazılım geliştirmede bir gökdelen inşa etmiyoruz; Başlamadan önce tüm planı hazırlamamız ve sonuna kadar bu plana bağlı kalmamız gerekmez. 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, birçok geliştirici bunu sekizinci ölümcül günah olarak gördü, ancak ürün açısından tahmin edilebilirliği optimize etmek ve riski kontrol etmek için büyük bir avantaj. Scrum, bu yetenek etrafında geliştirilir ve uygulanması, gerekli değişikliklerle başa çıkmanın güvenilir ve verimli bir yolunu sunar.

Scrum ile bağlantılı olarak birçok teknik kullanılır: planlama pokeri, çift programlama, test odaklı geliştirme (TDD), davranış odaklı geliştirme (BDD) ve diğerleri. Onlar gerçekten bir scrum parçası değil, daha çok uyumlu teknikler. Scrum ile aynı zamanda sıklıkla bahsedilen yöntemlerden biri kanban’dır ve bu iki şeyin birbirleriyle ilişkisinde ne anlama geldiğine dair ç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 veya kanban?” olacaktır. Ve neye cevap vereceğinizi bilemeyeceksiniz çünkü bu elma ve portakalları karşılaştırmak ya da “Hangisi daha iyi, krep mi bira mı?” Diye sormak gibi. İkisi de daha iyi.

Kanban, ekip üyelerini aşırı yüklemeden, tam zamanında teslimatı amaçlayan 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ökenleri 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 uyacak şekilde seçim yapabilirsiniz. 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 bir kanban uygulaması vardır .

Sütunlar, geliştirme sürecindeki bir görevin durumunu temsil eder. En basit örnek üç sütundan oluşur: “Yapılacak İş”, “Devam Ediyor” ve “Bitti”. Dolayısıyla, 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. Ancak elbette daha karmaşık olabilir:

Backlog → Spesifikasyon Tanımlama → Geliştirmeye Hazır → Geliştirme → Kod İnceleme → Test → Dağıtıldı (→ Kimse gerçekten 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” vb. Olarak ikiye ayrılabilir. Sütunlar, uygunsa uzmanlara ayrılabilir. Ekip, kolonları ve aşamaları ihtiyaçlarına göre tanımlar. “pull” felsefesine göre, görevler iş akışına yalnızca onlara talep anında geldiğinde girmelidir.

Bu panonun amacı, kanban’daki ilk temel uygulama olan iş akışını görselleştirmektir . Aslında, kanban bir pano olmadan da yapılabilir! Bir Google sayfasında görevin durumunu gösteren farklı arka plan renkleriyle basit bir görev listesi olabilir veya Gantt çizelgeleri, şemaları, tabloları olabilir … Hatta ofisinizde her birinin temsil ettiği bir kova kümesi olabilir görevin durumu ve topların görev olarak kullanıldığı yer. 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 azaltmaktır . Basitleştirilmiş, bu, çoklu görevden kaçınmak anlamına gelir. Bu, aynı anda üzerinde çalıştığınız görevlerin hacmini azaltmak anlamına gelebilir. Bir takımda üç tasarımcınız varsa, takım “Tasarım” sütunundaki maksimum görev sayısını üçe ayarlayabilir.

Scrum gibi kanban da takımı süreçteki en önemli figür olarak görür. Ancak, scrum’ın yaptığı gibi roller önermiyor 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 öğrenmeye ve gelişmeye teşvik eder, ancak scrum’ın Sprint Retrospektifi gibi, yalnızca bu süreç için belirli bir olay öngörmez.

Hangisini Kullanmalıyım?

Scrum ve kanban birbirini dışlayan ve gerçekten karşılaştırılabilir değildir. Scrum’da tanımlanmış roller vardır, kanban ise “Ne halt, mevcut rollerinizi ve sorumluluklarınızı koruyun.” der. Scrum çalışma şeklinizi değiştirmeniz için sizi zorlar; kanban mevcut süreci ile başlamanızı sağlar. Scrum’da, olaylar için net bir zamanlama çerçeve tarafından belirlenir; kanban’da olaylar olmaz. Ancak, bir çok benzerlikler var: her ikisi de değer odaklı, ekip üyeleri sistemin “patronları” olarak saygı ve aslında, onlar aynı misyonu var: sürekli engelleri ortadan kaldırmak için.

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

Ama her ikisinin de güzelliği, ikisinin de katı kurallar olmasıdır. Günlük toplantı veya inceleme gibi sizin için en iyi scrum öğelerini seçmekten sizi alıkoyan hiçbir şey yoktur. Ve scrum içine bir kanban panosu dahil etmemeniz için hiçbir neden yoktur.

Scrum, tüm takım onu ​​iyi anladığında oldukça etkili bir çerçeve olduğunu kanıtlamıştır. Bununla birlikte, deneyimlerime göre, bazı müşterilerle scrum içinde çalışmayı zor buluyorum. Uygun scrum uygulaması için gerekli süreç ve kültürel değişiklikler çok fazla olabilir (özellikle o yeni bir Google yapıyor inanıyor birisi ile ilgili!). Ö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ın daha kolay uygulanmasını sağladığını söylüyor. Diğerleri, scrum kullanmanın sonunda kanban’a 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.

Kaynak: GORAN PRIJIC – Agile, Scrum, and Kanban: What the Heck Do These Words Really Mean?