Çevik nedir?

Çevik, artımlı teslimi, ekip işbirliğini, sürekli planlamayı ve sürekli öğrenmeyi vurgulayan yazılım geliştirme yaklaşımlarını açıklayan bir terimdir. Çevik terimi, 2001 yılında AgileÇevik Manifestosu'nda ortaya çıkarıldı. Manifesto, yazılım geliştirme konusunda daha iyi bir yaklaşıma yol gösterecek ilkeler oluşturmak için yola çıktı. Manifesto, temelinde Çevik hareketinin temelini temsil eden dört değer deyimi bildirir. Belirtildiği gibi manifesto şunları ifade eder:

Değer verdik:

• İşlemler ve araçlar üzerindeki bireyler ve etkileşimler.
• Kapsamlı belgeler üzerinde çalışan yazılımlar.
• Sözleşme anlaşması üzerinde müşteri işbirliği.
• Planı takip etmek yerine değişikliklere yanıt vermek.

Manifesto, bu deyimlerin sağ tarafındaki öğelerin önemli veya gerekli olmadığı anlamına gelmez. Bunun yerine, soldaki öğeler daha değerlidir.

Çevik yöntemler ve uygulamalar

Agile'in bir şey olmadığını anlamak önemlidir. Çevik yöntemleri uygulamazsınız. "Çevik, yazılım geliştirme yaklaşımını yönlendiren bir zihniyettir." Her durumda çalışan tek bir yaklaşım olmadığından , Çevik terimi bildirimdeki değer deyimleriyle uyumlu çeşitli yöntemleri ve uygulamaları temsil etmeye gelmiştir.

Genellikle çerçeve olarak adlandırılan çevik yöntemler, DevOps yaşam döngüsünün aşamalarına yönelik kapsamlı yaklaşımlardır: planlama, geliştirme, teslim ve operasyonlar. Net rehberlik ve ilkelerle işi başarmak için bir yöntem reçete ederler.

Scrum , en yaygın Çevik çerçevedir ve çoğu kişinin başlangıç yaptığı çerçevedir. Öte yandan çevik uygulamalar, yazılım geliştirme yaşam döngüsünün aşamalarında uygulanan tekniklerdir.

• Poker Planlama , ekip üyelerini yapılanların anlamını paylaşmaya teşvik etmek için tasarlanmış işbirliğine dayalı bir tahmin uygulamasıdır. Birçok kişi süreci eğlenceli buluyor ve ekip çalışmasını ve daha iyi tahminleri teşvik etmeye yardımcı olduğu kanıtlandı.
• Sürekli tümleştirme (CI), kod değişikliklerini sık sık ana dala tümleştirmeyi içeren yaygın bir Çevik mühendislik uygulamasıdır. Otomatik derleme değişiklikleri doğrular. Sonuç olarak, tümleştirme borcunda bir azalma ve sürekli teslim edilebilir bir ana dal vardır.

Tüm Çevik uygulamaları gibi bu uygulamalar da Çevik bildirimindeki ilkelerle tutarlı olduklarından Çevik etiketini taşır.

Çevik olmayan şeyler

Agile popülerlik kazandıkça, birçok stereotip ve yanlış yorum, etkinliğine olumsuz bir gölge düşürmüştür. Herhangi bir sorumluluk olmadan "Evet, Çevik yapıyoruz" demek kolaydır. Bu noktayı göz önünde bulundurarak Çevik olmayan birkaç şeyi göz önünde bulundurun.

• Çevik , kovboy kodlaması değildir. Çevik, yazılım geliştirme sürecine yönelik "yolda çözeriz" yaklaşımıyla karıştırılmamalıdır. Böyle bir fikir gerçeklerden daha uzak olamaz. Çevik yöntem, her bir sprint'te müşterilere teslim edilen hem "bitti tanımı" hem de açık bir değer gerektirir. Çevik, bireyler ve ekipler için özerkliğe değer verirken, artan özerkliğin artan değer üretmesini sağlamak için uyumlu özerklik vurgular.
• Çevik yöntem titizlik ve planlamadan yoksun değildir. Aksine Çevik metodolojileri ve uygulamaları genellikle planlama disiplinini vurgular. Önemli olan, yalnızca ön planlama değil, proje genelinde sürekli planlamadır. Sürekli planlama, ekibin yürüttüğü çalışmalardan ders çıkarabilmesini sağlar. Bu yaklaşım sayesinde planlamanın yatırım getirisini (ROI) en üst düzeye çıkarır.

"Planlar değersizdir, ancak planlama her şeydir." — Dwight D. Eisenhower

• Çevik yöntem, yol haritası eksikliğine bir bahane değildir. Bu yanılgı büyük olasılıkla Çevik hareket geneline en çok zarar verdi. Çevik yaklaşımını takip eden kuruluşlar ve ekipler nereye gittiğini ve elde etmek istedikleri sonuçları kesinlikle bilir. İşlemin bir parçası olarak değişikliği tanımak, her hafta, sprint veya ay içinde yeni bir yöne yönelmekten farklıdır.
• Çevik, gereksinimler olmadan yapılan bir geliştirme değildir. Ekibinizin çalışmanın neden ve nasıl gerçekleştiğine uygun olmasını sağlamak için herhangi bir projede gereklidir. Spesifikasyonlara yönelik Çevik bir yaklaşım, spesifikasyonların doğru boyutlandırıldığından ve ekibin işleri sıraya koyma ve teslim etme biçimini uygun şekilde yansıttığından emin olmayı içerir.
• Çevik, planlanmamış işleri ve diğer kesintileri karşılayamaz. Sprint'leri zamanlamaya göre tamamlamak önemlidir. Ancak bir sorunun ortaya çıkması, geliştirmeyi aksatması, bir sprint'in başarısız olması anlamına gelmez. Takımlar, problemler ve beklenmedik sorunlar için kaynakları önceden tahsis ederek kesintileri planlayabilir. Daha sonra bu sorunları giderebilir ancak geliştirme ile yolda kalabilirler.
• Çevik, büyük kuruluşlar için uygunsuz değildir. Yaygın bir şikayet, Çevik metodolojilerinin önemli bir bileşeni olan işbirliğinin büyük ekiplerde zor olmasıdır. Çevik yaklaşımların ölçeklenebilir hale getirilmesinin, esneklikten ödün veren yapı ve yöntemler getirmesi bir diğer şikayet konusudur. Bu yanlış anlamalara rağmen Çevik ilkelerini başarıyla ölçeklendirmek mümkündür. Bu zorlukları aşma hakkında bilgi için bkz. Büyük ekiplere yönelik Çevik yöntemleri ölçeklendirme.
• Çevik metodoloji verimsiz değildir. Geliştiriciler, müşterilerin değişen ihtiyaçlarına uyum sağlamak için çalışan bir ürünü göstermek ve geri bildirim toplamak için her yinelemeye zaman ayırmaktadır. Bu çabaların geliştirme için harcadıkları süreyi azalttığı doğrudur. Ancak müşteri isteklerinin erken bir şekilde birleştirilmesi, daha sonra önemli ölçüde zaman kazandırır. Özellikler müşterinin vizyonuyla uyumlu olduğunda, geliştiriciler önemli çaplı düzeltmelerden kaçınır.
• Çevik, genellikle veri akışının merkezi olan günümüz uygulamaları için uygun değildir. Bu tür projeler genellikle kullanıcı arabirimlerine göre daha fazla veri modelleme ve ayıklama-dönüştürme yükü (ETL) iş yükü içerir. Bu durum, kullanılabilir yazılımları tutarlı ve sıkı bir zamanlamayla göstermeyi zorlaştırır. Ancak geliştiriciler hedefleri ayarlayarak çevik bir yaklaşım kullanmaya devam edebilir. Geliştiriciler, her yinelemeyi gerçekleştirmek için çalışmak yerine veri denemeleri çalıştırmaya odaklanabilir. Çalışan bir ürünü birkaç haftada bir sunmak yerine verileri daha iyi anlamayı hedefleyebilirler.

Neden Çevik?

Peki neden birisi Çevik Yaklaşımı düşünmelidir? Yazılım oluşturmayla ilgili katılım kurallarının son 10-15 yılda temel olarak değiştiği açıktır. Etkinliklerin çoğu benzer görünür, ancak bunları uyguladığımız manzara ve ortamlar belirgin şekilde farklıdır.

• Bugün yazılım satın alma işleminin nasıl bir şey olduğunu 2000'li yılların başında karşılaştırın. İnsanlar iş yazılımı satın almak için ne sıklıkta mağazaya gider?
• Müşterilerden ürünler hakkında nasıl geri bildirim toplandığını düşünün. Bir ekip, sosyal medyadan önce insanların yazılımları hakkında ne düşündüklerini nasıl anlayabilir?
• Bir ekibin, teslim ettikleri yazılımı ne sıklıkta güncelleştirmek ve iyileştirmek istediğini düşünün. Yıllık güncelleştirmeler artık modern rekabete karşı mümkün değildir.

Forrester'dan Diego Lo Guidice, Ekim 2020 tarihli Transforming Application Delivery adlı blogunda bunu en iyi şekilde ifade etmiş.

"Her şey önemli ölçüde değişti. Sürdürülebilirlik, yeşil ve temizin yanı sıra, bugün inşa ettiğimiz şeyin yarın kolay ve hızlı bir şekilde değişmesi anlamına gelir. Stratejik planlar kısa vadelidir ve planlama ve değişim süreklidir." — Diego Lo Guidice, Forrester

Kurallar değişti ve dünyanın dört bir yanındaki kuruluşlar artık yazılım geliştirme yaklaşımlarını buna göre uyarlar. Çevik yöntemler ve uygulamalar her sorunu çözmeyi sağlamaz. Ancak, çözümlerin işbirliği, sürekli planlama ve öğrenme ve yüksek kaliteli yazılımları daha sık gönderme isteğiyle ortaya çıktığı bir kültür ve ortam oluşturma sözü veriyor.

Sonraki Adımlar

Çevik yoldan yazılım geliştirmeye karar vermek, DevOps sürecinizi geliştirmek için bazı ilginç fırsatlara yol açabilir. Bir kuruluşun mevcut yaklaşımı ile Çevik geliştirmenin nasıl karşılaştırılıp zıtlık gösterdiğine odaklanan önemli bir husus seti vardır.