Çevik metodoloji nedir? Modern yazılım geliştirme açıkladı

Günümüzde her teknoloji kuruluşu, yazılım geliştirme için çevik metodolojiyi veya bunun bir sürümünü uyguluyor gibi görünüyor. Ya da en azından yaptıklarına inanıyorlar. İster çevik uygulama geliştirmede yeni olun, ister şelale yazılım geliştirme metodolojisini kullanarak yazılım geliştirmeyi onlarca yıl önce öğrenmiş olun, bugün işiniz en azından çevik metodolojiden etkileniyor.

Fakat çevik metodoloji nedir ve yazılım geliştirmede nasıl uygulanmalıdır? Çevik geliştirme uygulamada şelaleden nasıl farklıdır? Çevik yazılım geliştirme yaşam döngüsü veya çevik SDLC nedir? Ve Scrum Agile, Kanban ve diğer Agile modellerine karşı nedir? 

Agile, 2001 yılında 17 teknoloji uzmanının Agile Manifesto'yu hazırladığı zaman resmen başlatıldı. Daha iyi yazılım geliştirmek amacıyla çevik proje yönetimi için dört ana ilke yazdılar:

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

Çeviklikten önce: Şelale metodolojisi çağı

Benim gibi eski eller, şelale metodolojisinin yazılım geliştirme için altın standart olduğu günleri hatırlıyor. Yazılım geliştirme süreci, herhangi bir kodlama başlamadan önce bir ton dokümantasyon gerektiriyordu. Genellikle iş analisti olan biri, önce uygulamada işin ihtiyaç duyduğu her şeyi yakalayan bir iş gereksinimleri belgesi yazdı. Bu iş gereksinimi belgeleri uzundu ve her şeyi ayrıntılandırdı: genel strateji, kapsamlı işlevsel özellikler ve görsel kullanıcı arabirimi tasarımları.

Teknologlar iş gereksinim belgesini aldı ve kendi teknik gereksinimler belgesini geliştirdi. Bu belge, uygulamanın mimarisini, veri yapılarını, nesneye yönelik işlevsel tasarımlarını, kullanıcı arayüzlerini ve diğer işlevsel olmayan gereksinimleri tanımladı.

Bu şelale yazılım geliştirme süreci sonunda kodlamayı, ardından entegrasyonu ve sonunda bir uygulama üretime hazır olarak kabul edilmeden önce test etmeyi başlatır. Tüm süreç kolayca birkaç yıl alabilir.

Biz geliştiricilerin, belgelerin yazarlarının yaptığı gibi, tam dokümantasyon çağrıldığı için "spesifikasyonu" bilmemiz bekleniyordu ve 200 sayfasının 77. sayfasında özetlenen önemli bir detayı düzgün bir şekilde uygulamayı unutursak sık sık cezalandırıldık. sayfa belgesi.

O zamanlar yazılım geliştirmenin kendisi de kolay değildi. Birçok geliştirme aracı özel eğitim gerektiriyordu ve bugün var olan açık kaynak veya ticari yazılım bileşenleri, API'ler ve web hizmetlerinin yakınında hiçbir yer yoktu. Veritabanı bağlantılarını açma ve veri işlememizi çoklu okuma gibi düşük seviyeli şeyleri geliştirmemiz gerekiyordu.

Temel uygulamalar için bile ekipler büyüktü ve iletişim araçları sınırlıydı. Teknik özelliklerimiz bizi hizalayan şeydi ve onlardan İncil gibi yararlandık. Bir şartın değişmesi durumunda, ekip içinde değişiklikleri iletmek ve kodu düzeltmek pahalı olduğu için iş liderlerini uzun bir gözden geçirme ve imzalama sürecinden geçirirdik.

Yazılım teknik mimariye dayalı olarak geliştirildiğinden, önce alt düzey artefaktlar, daha sonra bağımlı artefaktlar geliştirildi. Görevler beceriye göre atandı ve veritabanı mühendislerinin önce tabloları ve diğer veritabanı yapılarını oluşturması yaygındı, ardından işlevselliği ve iş mantığını kodlayan uygulama geliştiricileri ve son olarak kullanıcı arabirimi üst üste bindirildi. Birinin uygulamanın çalıştığını görmesi aylar aldı ve o zamana kadar paydaşlar sabırsızlanıyor ve gerçekte ne istedikleri konusunda genellikle daha akıllı hale geliyorlardı. Değişiklikleri uygulamanın bu kadar pahalı olmasına şaşmamalı!

Kullanıcıların önüne koyduğunuz her şey beklendiği gibi çalışmadı. Bazen kullanıcılar bir özelliği hiç kullanmaz. Diğer zamanlarda, bir yetenek büyük ölçüde başarılıydı, ancak gerekli ölçeklenebilirliği ve performansı desteklemek için yeniden mühendislik gerektiriyordu. Şelale dünyasında, bunları uzun bir geliştirme döngüsünün ardından yazılım devreye alındıktan sonra öğrendiniz.

İlgili video: Agile metodolojisi gerçekten nasıl çalışıyor?

Herkes çevik yazılım geliştirmeden bahsediyor gibi görünüyor, ancak birçok kuruluş sürecin nasıl işlediğine dair kesin bir kavrayışa sahip değil. Hızla hızlanmak için bu beş dakikalık videoyu izleyin.

Çevik yazılım geliştirmenin pivotu

1970 yılında icat edilen şelale metodolojisi devrim niteliğindeydi çünkü takip edilecek net bir özellik olmasını sağlamak için yazılım geliştirmeye disiplin getirdi. Henry Ford'un 1913 montaj hattı yeniliklerinden türetilen şelale üretim yöntemine dayanıyordu; bu, nihai ürünün ilk başta belirtilenle eşleştiğini garanti etmek için üretim sürecindeki her adımda kesinlik sağlıyordu.

Şelale metodolojisi yazılım dünyasına geldiğinde, bilgi işlem sistemleri ve uygulamaları genellikle karmaşık ve monolitikti ve teslim edilmesi için bir disiplin ve net bir sonuç gerektiriyordu. Gereksinimler de günümüze göre yavaş değişti, bu nedenle büyük ölçekli çabalar daha az sorunluydu. Aslında sistemler değişmeyecekleri, sürekli savaş gemileri olacağı varsayımı altında inşa edildi. Çok yıllık zaman dilimleri yalnızca yazılım geliştirmede değil, aynı zamanda üretim ve diğer kurumsal faaliyetlerde de yaygındı. Ancak şelalenin sertliği, hız ve esnekliğin gerekli olduğu internet çağında Aşil topuğu haline geldi.

Yazılım geliştirme metodolojisi, geliştiricilerin internet uygulamaları üzerinde çalışmaya başlamasıyla değişmeye başladı. İlk çalışmaların çoğu, ekiplerin daha küçük olduğu, aynı yerde bulundukları ve genellikle geleneksel bilgisayar bilimi geçmişine sahip olmayan girişimlerde yapıldı. Web sitelerini, uygulamaları ve yeni yetenekleri pazara daha hızlı getirmek için mali ve rekabetçi baskılar vardı. Geliştirme araçları ve platformları buna yanıt olarak hızla değişti.

Bu, birçoğumuzun şelale metodolojisini sorgulamasına ve daha verimli olmanın yollarını aramasına yol açtı. Önceden tüm ayrıntılı dokümantasyonu yapacak paramız yoktu ve daha yinelemeli ve işbirliğine dayalı bir sürece ihtiyacımız vardı. Gereksinimlerdeki değişiklikleri hala tartıştık, ancak denemeye ve son kullanıcı ihtiyaçlarına uyum sağlamaya daha açıktık. Organizasyonlarımız daha az yapılandırılmıştı ve uygulamalarımız eski kurumsal sistemlere göre daha az karmaşıktı, bu nedenle uygulama satın almaya kıyasla oluşturmaya çok daha açıktık. Daha da önemlisi, işletmeleri büyütmeye çalışıyorduk, bu yüzden kullanıcılarımız bize bir şeyin işe yaramadığını söylediğinde, çoğu zaman onları dinlemeyi seçmedik.

Becerilerimiz ve yenilik yapma yeteneklerimiz stratejik olarak önemli hale geldi. İstediğiniz tüm parayı toplayabilirdiniz, ancak "şartnameyi" kölece izleyen itaatkâr kodlayıcılar gibi davranacaksanız, hızla değişen internet teknolojileriyle çalışabilen yetenekli yazılım geliştiricilerini çekemezsiniz. Neyi geliştirmemiz gerektiğini, uygulamaların ne zaman gönderilmesi gerektiğini ve hatta bazen kodun nasıl yapılandırılacağını açıklayan uçtan uca programlarla gelen proje yöneticilerini reddettik. Şelale proje yöneticilerinin tasarladığı ve durmaksızın güncellediği üç aylık ve altı aylık programlara ulaşmakta berbattık.

Bunun yerine onlara internet uygulamalarının nasıl tasarlanması gerektiğini anlatmaya başladık ve sonuçları yinelemeli olarak oluşturduğumuz bir programa göre sunduk. Küçük, bir ila dört haftalık aralıklarla taahhüt ettiğimizde yapacağımızı söylediğimiz şeyi sunmakta o kadar da kötü değildik.

2001 yılında, bir grup deneyimli yazılım geliştiricisi bir araya gelerek, klasik şelale metodolojisinden farklı bir şekilde yazılım geliştirmeyi toplu olarak uyguladıklarını fark ettiler. Ve hepsi başlangıçta değildi. Teknoloji alanındaki aydınlatıcı Kent Beck, Martin Fowler, Ron Jeffries, Ken Schwaber ve Jeff Sutherland'ı içeren bu grup, modern bir yazılım geliştirme sürecinin nasıl işlemesi gerektiğine dair ortak inançlarını belgeleyen Çevik Manifesto'yu ortaya çıkardı. Belgeleme, katı yönetim uygulamaları yerine kendi kendine organizasyon ve kendinizi katı bir şelale geliştirme sürecine kilitlemek yerine sürekli değişimi yönetme becerisi üzerinde işbirliğini vurguladılar.

Bu ilkelerden yazılım geliştirme için çevik metodoloji doğdu.

Çevik metodolojideki roller

Çevik bir yazılım geliştirme süreci her zaman kullanıcıları tanımlayarak ve ele alınacak sorunlar, fırsatlar ve değerler kapsamı hakkında bir vizyon ifadesini belgeleyerek başlar. Ürün sahibi bu vizyonu yakalar ve bu vizyonu gerçekleştirmek için çok disiplinli bir ekiple (veya ekiplerle) çalışır. İşte bu süreçteki roller.

Kullanıcı

Çevik süreçler her zaman kullanıcı veya müşteri göz önünde bulundurularak başlar. Bugün, yazılımın desteklediği bir iş akışındaki farklı rolleri veya farklı müşteri ihtiyaçları ve davranışlarını göstermek için bunları genellikle kullanıcı karakterleriyle tanımlıyoruz.

Ürün sahibi

Çevik geliştirme sürecinin kendisi, herhangi bir iç paydaş dahil olmak üzere müşterinin sesi olması gereken biriyle başlar. Bu kişi, bir ürün vizyonu oluşturmak için tüm içgörüleri, fikirleri ve geri bildirimleri saflaştırır. Bu ürün vizyonları genellikle kısa ve anlaşılırdır, ancak yine de müşterinin kim olduğuna, hangi değerlerin ele alındığına ve bunları nasıl ele alacağına dair bir strateji çizerler. Google'ın orijinal vizyonunun "İnternet erişimi olan herkesin ilgili web sitelerini ve web sayfalarını basit, anahtar kelimeye dayalı bir arayüz ve saygın kaynakları arama sonuçlarında daha üst sıralarda sıralayan bir algoritma ile bulmasını kolaylaştıralım." Gibi bir şey olduğunu hayal edebiliyorum.

Bu kişiye ürün sahibi diyoruz . Sorumluluğu, bu vizyonu tanımlamak ve ardından onu gerçekleştirmek için bir geliştirme ekibiyle çalışmaktır.

Geliştirme ekibiyle çalışmak için ürün sahibi, ürün vizyonunu, hedef kullanıcının kim olduğunu, onlar için hangi sorunun çözüldüğünü, çözümün onlar için neden önemli olduğunu daha ayrıntılı olarak anlatan bir dizi kullanıcı hikayesine ayırır. çözümü hangi kısıtlamalar ve kabul kriterleri tanımlar. Bu kullanıcı hikayeleri, ürün sahibi tarafından önceliklendirilir ve kendilerinden ne istenildiği konusunda ortak bir anlayışa sahip olmalarını sağlamak için ekip tarafından gözden geçirilir.

Yazılım geliştirme ekibi

Agile'da geliştirme ekibi ve üyelerinin sorumlulukları, geleneksel yazılım geliştirmeden farklıdır.

Ekipler multidisiplinerdir ve işi tamamlama becerisine sahip çeşitli insanlardan oluşur. Odak noktası çalışan yazılım sağlamak olduğundan, ekibin uçtan uca işleyen uygulamaları tamamlaması gerekir. Böylece, uygulamanın bir kısmının veritabanı, iş mantığı ve kullanıcı arayüzü geliştirilir ve ardından demo haline getirilir - uygulamanın tamamı değil. Bunu yapmak için ekip üyelerinin işbirliği yapması gerekir. Herkesin ne geliştirdiği, kimin ne yaptığı ve yazılımın tam olarak nasıl geliştirildiği konusunda aynı hizada olduğundan emin olmak için sık sık toplanırlar.

Yazılım geliştirme ekipleri, geliştiricilere ek olarak, yazılım projesinin türüne bağlı olarak kalite güvence (QA) mühendisleri, diğer mühendisler (veritabanları ve arka uç sistemler gibi), tasarımcılar ve analistleri içerebilir.

Scrum, Kanban ve diğer çevik çerçeveler

Yazılım geliştirme yaşam döngüsüyle uyumlu, geliştirme süreçleri ve çevik geliştirme uygulamaları hakkında ayrıntılar sağlayan birçok çevik çerçeve.

En popüler çevik çerçeveye scrum denir . Sprint adı verilen bir teslimat ritmine ve aşağıdakileri içeren toplantı yapılarına odaklanır :

  • Planlama - sprint önceliklerinin belirlendiği yer
  • Taahhüt - takımın bir kullanıcı hikayeleri listesini veya biriktirme listesini incelediği ve sprint süresince ne kadar iş yapılabileceğine karar verdiği yer 
  • Günlük standup toplantıları - ekiplerin geliştirme durumları ve stratejileriyle ilgili güncellemeleri iletebilmesi için)

Sprintler, işlevselliğin ürün sahibine gösterildiği bir demo toplantısıyla sona erer ve ardından ekibin neyin iyi gittiğini ve süreçlerinde nelerin iyileştirilmesi gerektiğini tartıştığı geriye dönük bir toplantı izler.

Birçok kuruluş, ekiplerin saldırı sürecini yönetmesine yardımcı olmak için scrum ustaları veya koçları kullanır.

Scrum hakim olsa da, başka çevik çerçeveler de vardır:

  • Kanban, ekibin bir giriş panosundan kullanıcı hikayelerini çıkardığı ve tamamlanıncaya kadar aşamalı bir geliştirme sürecinden geçirdiği bir fan-in ve fan-out süreci olarak çalışır.
  • Bazı kuruluşlar, yeni uygulamalar için çevik süreçler ve eski uygulamalar için şelale kullanan hibrit bir çevik ve şelale yaklaşımı benimser.
  • Kuruluşların uygulamayı birden çok ekibe göre ölçeklendirmesine olanak tanıyan birkaç çerçeve de vardır.

Çevik çerçeveler süreci ve işbirliğini tanımlarken, çevik geliştirme uygulamaları, çevik bir çerçeve ile uyumlu olarak gerçekleştirilen yazılım geliştirme görevlerini ele almaya özeldir.

Yani mesela:

  • Bazı ekipler, iki geliştiricinin daha yüksek kaliteli kod yürütmek ve daha kıdemli geliştiricilerin gençlere rehberlik etmesini sağlamak için birlikte kodladığı ikili programlamayı benimser.
  • Daha gelişmiş ekipler, temeldeki işlevselliğin beklenen sonuçları sağladığından emin olmak için test odaklı geliştirme ve otomasyonu benimser.
  • Birçok ekip, geliştiricinin bir kullanıcı öyküsünü yorumlamasının yalnızca istenen işlevselliğe yol açmaması, aynı zamanda güvenlik, kod kalitesi, adlandırma kuralları ve diğer teknik standartları karşılaması için teknik standartları da benimser.

Çevik metodoloji neden daha iyidir