Çevik MİT’ler, Doğru bilinen Yanlışlar

2001 yılında, yazılım geliştirme yöntemlerinde karşılaşılan sorunlar üzerinde görüşmek üzere küçük bir grup yazılım geliştirici bir araya gelerek, yeni yazılım geliştirme çerçevesinde hedefledikleri değerleri belirlediler.

• Odağımız, süreçler ve araçlar yerine takımlar-bireylerle ile iletişim-etkileşim üzerine olmalı
• Kapsamlı dokümantasyona yerine geliştirilecek ürün üzerinde efor harcamak
• Sözleşme ve Pazarlıklar yerine Müşterilerle olan iş-birliğine odaklanmak - Plana bağlı kalmak yerine Değişime cevap verecek esnekliği sağlamak.

Bu maddeler Agile Manifestosu olarak yayınlandı ve Agil geliştirmenin temel dayanağı haline geldi. Ancak Agile kullanan şirketlerde gördüğüm bazı hatalı uygulamalar olabiliyor, yanlış anlamaları ortadan kaldırmak için ne yapıldığını

Süreçler ve Araçlar yerine Takımlar-Bireylerle ile İletişim-Etkileşim üzerine olmalı

Süreçler, şirketlerin zamanla öğrenilmesi ve geliştirilmesini sağlayan şeydir ve nihayetinde süreçler tekrarlanabilir sonuçlar doğurur. Araçlar, bir Takımın karşılaştığı sorunları fark etme şeklini temelde değiştirebilir.

Sahip olduğunuz tek araç bir çekiç ise, her sorun bir çivi gibi görünür.

Kapsamlı dokümantasyona yerine geliştirilecek ürün üzerinde odaklanmak

Dokümantasyon modası geçmiş bir gereklilik midir?

Bu maddede geçen, "Kapsamlı" kelimesine dikkat edin. Kaynak kodun her satırının her ayrıntısının yorumlanması ve belgelendirilmesi gerekmez ve her gereksinimin mikro düzeyde yazım denetimi yapmak zorunda kalmaz. Ancak, yeterli dokümantasyon gerekmeksizin gereksinimleriniz eksik olacaktır ve bu, gereksinimleri açıklığa kavuşturma toplantısında boşa harcanmasına neden olabilir ya da daha da kötüsü, yazılımınızda daha çok zaman alıcı ve daha pahalı revizyonlara neden olabilir.

Nerede olduğunu bilmiyorsanız, nereye gitmek istersen yolunu bulmanın çok zor olduğunu söyleyebilirim.

Ve insanların hastalanacağını, işten ayrılabileceğini ve emekli olacağını düşündüğünüzde, geri kalan Takım üyelerinin kesintisiz olarak çalışmalarına devam etmeleri için gerekli olan kurumsal bilgiyi onlarla birlikte alarak.

Sözleşme ve Pazarlıklar yerine Müşterilerle olan iş-birliği yapmak

Sözleşme önemli değildir, sözleşme yapmaya gerek yok mudur?

Çünkü iş başladığında tam olarak bilinmeyen, teslimatlar önceden belirtilmeyen genişlikte olabileceği düşünülürse, müşteri ve geliştirme takımı işbirliği içinde çalışarak makul sonuçları alarak her iki tarafın çıkan sonuçtan tatmin olmasıdır.

Tüm paydaşlar arasında iş-birliğine dayalı ürün geliştirme, çevik yaklaşım, bir projeyle ilgili paydaşlar arasında kapsamlı ve kapsamlı iletişim savunmaktadır. İletişim hızlı problem çözümünü ve ürün geliştirmeyi kolaylaştırır. Günlük Stand Up’ lar (Daily Stand Up, Daily Scrum) , takımın her üyesinin en son durumunu, bir sonraki planını ve karşı karşıya olduğu engelleri ortaya koyduğu bir toplantı düzeni. Bu yaklaşım düzeni, Takımın her üyesinin ne’ler yaptığından haberdar eder ve bir engeli çözmek, diğerlerinin durma sebebini ortadan kaldırır. Takım olarak öğrenme, kurumsal gelişim.

Plana bağlı kalmak yerine Değişime cevap verecek esnekliği sağlamak.

Plan yapmak ve planlamaya efor harcamak gerekli değildir, gibi anlaşılıyor.

Tam tersi, plan yapmak çok önemlidir, ancak burada söz konusu olan kısa süreli planlama yapmaktır. Plan, en çok 4 haftalık plan yapılır. Belirli bir zaman dilimindeki planların, kimlerin neler üzerinde çalıştıklarını bilmek, bağımlılıkları tanımlamak için belgelendirmek gerekir. Ancak iş değişikliği için çağrı yapması durumunda kısa vadeli planlar bile değiştirilebilir. Takım, ürün parçasını gerçekleştirdikten sonra, iş ihtiyaçlarına cevap verecek, değişiklik talepleri gerçekleştirilir.

Müşterinin Geliştirme takımı içinde yer alması, nihai ürüne çok şey katmaktadır. Ürün geliştikçe, son kullanıcı ne istediğini net bir şekilde kavradığından, ürüne değer katacak değişiklikleri hakkında geri bildirimde bulunmaya devam eder. Böylece daha iyi bir çözüm yaratılmasını sağlanır. Müşteri son anda bile değişiklik isteyebilir, Değişiklik Odaklı yaklaşım

Çevik yaklaşımlarda sürekli geri-bildirim mekanizması nedeniyle değişim devam eder. Ürün sahiplerinin ürün çıkış tarihini sürekli olarak güncellemelerini gerektirir. Değişen gereksinimler, teslim planları ve çizelgelerde değişikliklere neden olmaması beklenir. Ürün çıkış tarihlerine ürün sahibi/müşteri karar verir.

Gereksinim toplama,

Çevik Takımlar, gereksinimleri toplama sürecinde çok daha az zaman harcarlar. Başlangıçta gereksinimler yüksek seviyededir, tam zamanlı (Just-In-Time) yaklaşımıdır. Temel fonksiyonlar / özellikler geliştirilirken, gereksinimler kapsamlı ve detaylı tartışmalar yoluyla toplanır. Gereksinim üzerinde en net olduğu zaman, en doğru zamandır. Takımın bu konuda en net görüntüyü elde etmesi için şartlar ideal olarak görsel biçimdedir. Başlangıçta minimum gereksinimi toplamanın arkasındaki düşünce, belki de asla şekillenmeyecek bir şeyi tartışırken efor kaybını en aza indirmektir. Çevik yaklaşımda varsayımlara ve belirsizliklere yer yoktur.

Karar verme,

Çevik yaklaşımda, Liderler, Takımdaki karar vericiler yapmak yerine, her üyelerin birlikte kararlarını alması ve uygulama geliştirmede ilerleme yetkisi vardır. Kararlar genellikle Takım üyeleri tarafından, nihai ürüne ve dolayısıyla tasarlanan hedefe faydalı olacak şekilde yapılır. Karar verirken kimse bir diğer üyeden daha yetkili değildir, her üye eşittir. Dolayısıyla kararlar geliştirmeyi ilgilendiren tüm kararlar Takım tarafından özgürdür. Otonomi.

Tekrar eden küçük teslimatlar,

Çevik yaklaşımda hedef, büyük bir problemi çok sayıda daha küçük alt parçalara ayırıp problemin çözülmüş parçasını son müşteriye sunmaktır. Böylece çevik yaklaşımda küçük ve artımlı iterasyon (sprint) planlanarak ürün, artan bir şekilde son müşteriye teslim edilmektedir. Ayrıca, ürün geliştirilirken sabit bir geri bildirim mekanizması sağlar ve böylece iyileştirme için bir yer sağlar. Ürün çıkış tarihlerine müşteri karar verir.

Test, proje yaşam döngüsü ile bütünleşik,

Çevik testi çok erken başlar ve test araçları, ilk sprintten hemen sonra test etmeye başlar. Test takımı, uygulamayı çok erken test etmeye başlar ve fonksiyonları tekrar tekrar test eder. Uygulama için bir regresyon paketi oluşturulur ve her sürümde aynı paketi güncellenir. Uygulamaya giderek daha fazla fonksiyon eklendiğinde, regresyon çerçevesine giderek daha fazla test durumu eklenir. İlerleyen iterasyonlar da Test durumlarının insan gücüyle yapılamayacak kadar büyüyerek Regression Test ürünlerinin kullanımını gerektirebilir.