Ç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, Çevik Manifestosu'nda 2001 yılında ortaya çıkarılmıştı. 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şikliğe yanıt verme.

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

Çevik'in bir şey olmadığını anlamak önemlidir. Çevik'i yapmazsınız. Bunun yerine Ç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 sevk 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 olmayanlar

Çevik 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'in olmadığı birkaç noktayı göz önünde bulundurun.

• Çevik, kovboy kodlaması değildir. Çevik, yazılım geliştirmeye yönelik "bunu kullandıkça çözeceğiz" yaklaşımıyla karıştırılmamalıdır. Böyle bir fikir gerçeklerden daha uzak olamaz. Çevik, her sprint'te müşterilere teslim edilen hem bitti hem de açık bir değer tanımı gerektirir. Çevik, bireyler ve ekipler için özerkliğe değer verirken, artan otonominin artan değer ürettiğinden emin olmak için uyumlu özerkliği vurgular.
• Çevik, titizlik ve planlama olmadan 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, yol haritası olmaması için 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önde özetlemeden farklıdır.
• Çevik, belirtimler olmadan 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. Belirtimlere yönelik Çevik bir yaklaşım, özelliklerin doğru boyutlandırıldığından ve ekip sıralarının ve teslimlerinin uygun şekilde yansıtıldığı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 izlemesi sprint'in başarısız olması anlamına gelmez. Teams, sorunlar ve beklenmeyen sorunlar için kaynakları önceden ekleyerek kesintileri planlayabilir. Daha sonra bu sorunları giderebilir ancak geliştirmeyle ilgili gelişmelerden haberdar olabilirler.
• Çevik, büyük kuruluşlar için uygun 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'e yönelik ölçeklenebilir yaklaşımların esneklikten ödün veren yapı ve yöntemler sunması da bir diğer etki alanıdır. Bu yanılgılara rağmen Çevik ilkelerini başarıyla ölçeklendirmek mümkündür. Bu zorlukları aşma hakkında bilgi için bkz . Çevik'i büyük ekiplere ölçeklendirme.
• Çevik 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 herkes Çevik yaklaşımını düşünse? 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'ın Diego Lo Guidice'i bunun en iyi şekilde blogu olan Transforming Application Delivery (Ekim 2020) bölümünde yer alıyor.

"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. Dikkat edilmesi gereken önemli noktalardan biri, Çevik geliştirmenin bir kuruluşun geçerli yaklaşımıyla karşılaştırmasına ve karşıtlığına odaklanır.