Ç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 geliştirme genellikle daha büyük projeleri ön planda planlayan ve plana göre tamamlayan geleneksel veya şelale geliştirme ile karşıttır.

Üretim kalite kodunun her sprint'e teslim edilmesi için Çevik geliştirme ekibinin hızlandırılmış bir tempoyu hesaba eklemesi 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:

• Çalışkan kapsam iyileştirmesi
• Erken ve sık tümleştirme
• Teknik borcu en aza indirme

Çalışkan kapsam iyileştirmesi

Çevik geliştirme ekibi, genellikle kullanıcı hikayeleri olarak adlandırılan gereksinimler kapsamında çalışır. Kapsam önceliklendirilir ve en önemli kullanıcı hikayeleri en üstte yer alır. Ürün sahibi kapsamın sahibidir ve kullanıcının ihtiyaçlarına göre kullanıcı hikayelerini ekler, değiştirir ve yeniden yazar.

Çevik ekibin üretkenliğindeki en büyük sürüklenmelerden biri, kötü tanımlanmış bir kapsamdır. 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. Kapsamın en üstündeki kullanıcı hikayeleri, ekibin başlaması için her zaman hazır olmalıdır. Bu görüş, kapsam iyileştirmesi olarak adlandırılır. Bir kapsamı Çevik geliştirme ekibi için hazır tutmak için çaba ve disiplin gerekir. 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 öyle olduğunu söylemediği sürece bir kullanıcı hikayesi incelenmemiştir. 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. Kapsamın daha ilerisinde yer alan kullanıcı hikayeleri belirsiz kalabilir. Düşük öncelikli öğeleri iyileştirerek zaman kaybetmeyin. Kapsamın en üstüne odaklanın.

Erken ve sık tümleştirme

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. Birim testini her derlemenin bir parçası yapın. Başarısız birim testleri başarısız derleme anlamına gelir.

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

3. Dal ve derleme ilkeleri. Ekip kodu belirli bir dalda denetledikçe otomatik olarak derlemek için dal ve derleme ilkeleri yapılandırın.

4. Bir ortama dağıtma. 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 verirseniz. 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 borcun üzerine çalışmak 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 alıştırma duyar. 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. Çevik'i büyük ekiplere ölçeklendirme hakkında daha fazla bilgi edinin.