Çevik geliştirme nedir?

Çevik geliştirme, yinelemeli yazılım geliştirmeyi tanımlamak için kullanılan bir terimdir. Yinelemeli yazılım geliştirme, çalışmayı genellikle sprint olarak adlandırılan kısa artışlarla tamamlayarak DevOps yaşam döngüsünü kısaltır. Sprint'ler genellikle bir-dört hafta uzunluğunda olur. Çevik yazılım geliştirme genellikle daha büyük projeleri önceden planlayan ve plana göre tamamlayan geleneksel veya şelale geliştirme ile karşılaştırılır.

Üretim kalitesinde kodun her sprintte teslim edilmesi için Çevik geliştirme ekibinin hızlandırılmış bir tempoyu hesaba katması gerekir. Tüm kodlama, test ve kalite doğrulama işlemleri her sprint'in her birinde yapılmalıdır. Bir ekip düzgün şekilde ayarlanmadığı sürece sonuçlar beklentilerin altında olabilir. Bu hayal kırıklıkları harika öğrenme fırsatları sunsa da, başlamadan önce bazı önemli dersleri öğrenmek yararlı olacaktır.

Bu makalede Çevik geliştirme ekipleri için birkaç önemli başarı faktörü açıklanmaktadır:

• Sürekli backlog iyileştirmesi
• Erken ve sık entegrasyon
• Teknik borcu en aza indirme

Titiz iş listesi geliştirmesi

Çevik geliştirme ekibi, genellikle kullanıcı hikayeleri olarak adlandırılan gereksinimlerin sırayla ele alınması ile çalışır. İş listesi önceliklendirilir ve en önemli kullanıcı hikayeleri en üstte yer alır. Ürün sahibi iş listesine (backlog) sahiptir ve müşteri ihtiyaçlarına göre kullanıcı hikayelerini ekler, değiştirir ve yeniden önceliklendirir.

Çevik bir ekibin üretkenliğindeki en büyük engellerden biri, kötü tanımlanmış bir iş birikimidir. Açıkça tanımlanmış gereksinimlere sahip olmadığı sürece bir ekibin her sprint için tutarlı bir şekilde yüksek kaliteli yazılım sağlaması beklenemez.

Ürün sahibinin görevi, her sprint'in, mühendislerin üzerinde çalışabilecekleri kullanıcı hikayelerini net bir şekilde tanımladığından emin olmaktır. Backlog'un en üstündeki kullanıcı hikayeleri, ekibin başlamak üzere her zaman hazır olmalıdır. Bu kavram, geri bildirim incelemesi olarak adlandırılır. Bir Agile geliştirme ekibi için birikim listesini hazır tutmak çaba ve disiplin gerektirir. Neyse ki yatırıma değer.

Bir kapsamı daralttığınızda, aşağıdaki önemli noktaları unutmayın.

1. Kullanıcı hikayelerini iyileştirme genellikle uzun süreli bir etkinliktir. Zarif kullanıcı arabirimleri, güzel ekran tasarımları ve müşteriyi memnun eden çözümlerin oluşturulması zaman ve enerji alır. Çalışkan ürün sahipleri, kullanıcı hikayelerini önceden iki-üç sprint'e kadar daraltıyor. Tasarım yinelemelerini ve müşteri incelemelerini dikkate alır. Her kullanıcı hikayesinin Çevik ekibin müşteriye sunmaktan gurur duyduğu bir şey olduğundan emin olmak için çalışır.

2. Ekip 'incelendi' demeden bir kullanıcı hikayesi incelenmiş sayılmaz. Ekibin kullanıcı hikayesini gözden geçirmesi ve üzerinde çalışmaya hazır olduğunu kabul etmesi gerekir. Bir ekip sprint'in birinci gününe kadar kullanıcı hikayesini görmüyorsa, büyük olasılıkla sorunlar oluşabilir.

3. İş yığınının alt sıralarında yer alan kullanıcı hikayeleri belirsiz kalabilir. Düşük öncelikli öğeleri iyileştirerek zaman kaybetmeyin. Çalışılacak işlerin en üstüne odaklanın.

Erken ve sık entegrasyon

Sürekli tümleştirme ve sürekli teslim (CI/CD) ekibinizi Çevik geliştirmenin hızlı hızına göre ayarlar. Mümkün olan en kısa sürede derleme, test ve dağıtım işlem hatlarını otomatikleştirin. Bu otomasyonu, yeni bir projeye başladığınızda ekibinizin ilk gerçekleştirdiği görevlerden biri olarak ayarlayın.

Otomasyon sayesinde ekip yavaş, hataya açık ve zaman açısından yoğun el ile dağıtım işlemlerinden kaçınıyor. Ekipler her sprint'i serbest bıraktığından, bu görevleri el ile yapmak için zaman yoktur.

CI/CD, yazılım mimarinizi de etkiler. Derlenebilir ve dağıtılabilir yazılımlar sunmanızı sağlar. Ekipler dağıtılması zor bir özellik uyguladığında, derleme ve dağıtımların başarısız olması durumunda hemen fark ederler. CI/CD, bir ekibi dağıtım sorunlarını oluştukları anda düzeltmeye zorlar. Ürün her zaman göndermeye hazırdır.

Etkin Çevik geliştirme için kritik öneme sahip bazı önemli CI/CD etkinlikleri vardır.

1. Birim testi. Birim testleri insan hatasına karşı ilk savunmadır. Birim testlerini kodlamanın bir parçası olarak düşünün. Kodla testleri denetleyin. Her derlemede birim testlerinin yapılmasını sağlayın. Birim testlerinin başarısız olması, build'in de başarısız olması anlamına gelir.

2. Yapı otomasyonu. Derlemeler çalıştırıldığında derleme sistemi kodu ve testleri doğrudan kaynak denetiminden otomatik olarak çekmelidir.

3. Dallanma ve derleme politikaları. Bir ekip belirli bir dalda kodu denetlerken otomatik olarak yapı oluşturmak için dal ve yapı oluşturma ilkelerini yapılandırın.

4. Bir ortama dağıtın. Oluşturulan projeleri otomatik olarak üretimi taklit eden bir ortama dağıtan bir yayın işlem hattı ayarlayın.

Teknik borcu en aza indirme

Kişisel finansla, borçtan uzak kalmak, altından kazınmaktan daha kolaydır. Aynı kural teknik borç için de geçerlidir. Teknik borç, daha önce alınan kısayollar nedeniyle ekibin ele alması gereken her şeyi içerir. Örneğin, sıkı bir zamanlamanız varsa, son tarihi karşılamak için kaliteden ödün verebilirsiniz. Teknik borç, bu kalite eksikliğini telafi etmek için kodu yeniden düzenlemeniz gerektiğinde daha sonra ödediğiniz ücrettir. Kötü tasarım, hatalar, performans sorunları, işletimsel sorunlar, erişilebilirlik sorunları ve diğer sorunları gidermeye yönelik düzeltmeler örnek olarak verilebilir.

Teknik borcu kontrol altında tutmak cesaret gerektirir. Kodun yeniden çalışmasını geciktirmek için birçok baskı vardır. Özellikler üzerinde çalışmak ve borcu göz ardı etmek iyi hissettirir. Ne yazık ki, birisi teknik borcu er ya da geç ödemelidir. Finansal borçlar gibi teknik borcun da mevcut olduğu süre kadar ödemesi zorlaşır. Akıllı ürün sahibi, her sprint'in teknik borcunu ödemek için zaman olduğundan emin olmak için ekibiyle birlikte çalışır. Özellik geliştirme ile teknik borcun azaltılmasını dengelemek zor bir görevdir. Neyse ki , üretken, müşteri odaklı ekipler oluşturmaya yönelik bazı basit teknikler vardır.

Her zaman Çevik Olun

Çevik olmak, deneyimden öğrenme ve sürekli geliştirme anlamına gelir. Çevik geliştirme, daha sıkı süreç döngüleri nedeniyle geleneksel proje planlamasından daha fazla öğrenme döngüsü sağlar. Her sprint, takımın öğrenmesi için yeni bir şey sağlar.

Örneğin:

• Ekip müşteriye değer verir, geri bildirim alır ve ardından bu geri bildirime göre kapsamlarını değiştirir.
• Otomatikleştirilmiş derlemelerinde temel testlerin eksik olduğunu öğrenirler. Bu sorunu çözmek için sonraki sprint'lerine çalışma eklerler.
• Bazı özelliklerin üretimde kötü performans sergilediğini ve bu nedenle performansı iyileştirmeye yönelik planlar yaptıklarını fark ederler.
• Takımdaki biri yeni bir uygulamadan haberdar olur. Ekip, birkaç sprint için denemeye karar verir.

Çevik geliştirmeyle yeni başlayan ekiplerin daha fazla öğrenme fırsatı beklemesi gerekir. Büyüme ve gelişmeye yol açtıkları için sürecin çok değerli bir parçasıdırlar.

Sonraki Adımlar

Bir ekip için doğru olan Çevik geliştirme sürecine karar vermenin birçok yolu vardır. Azure DevOps çeşitli işlem şablonları sağlar. Planlamalarında farklı temel yapılar arayan ekipler bu şablonları başlangıç noktası olarak kullanabilir. Ekibin kültürüne ve hedeflerine en uygun işlem şablonunu seçme hakkında bilgi için bkz. Azure Boards'ta çalışmak için süreç akışı veya süreç şablonu seçme.

Kuruluşlar büyüdükçe disiplinli kalmak zor olabilir. Büyük ekiplere Agile uygulamayı ölçeklendirme hakkında daha fazla bilgi edinin.