agile manifesto understanding agile values
Çevik Manifesto Giriş:
Önceki eğitimimiz Çevik Metodoloji Agile modellerini ve metodolojilerini detaylı olarak bize anlattı.
Ancak şimdiye kadar neden ilk etapta Agile'a ihtiyaç olduğu ve Agile'nin şelale modeli gibi mevcut yazılım geliştirme metodolojilerinin eksikliklerinin üstesinden nasıl geldiğiyle ilgili değiliz.
Bu eğiticide, Agile ve Agile manifestosunun ayrıntılarına daha derinlemesine gireceğiz. Manifesto'nun ne dediğini ve içinde yer alan değerlerin ve ilkelerin neler olduğunu göreceğiz.
Ne öğreneceksin:
Giriş
Bizim gördüğümüz gibi önceki eğitim , önceki geliştirme metodolojileri çok fazla zaman alıyordu ve yazılım dağıtım için hazır olduğunda, iş gereksinimleri değişecek ve bu nedenle mevcut ihtiyaçları karşılamayacaktı.
O zamanlar eksik olan değişim hızı pek çok soruna neden oluyordu. Farklı kalkınma metodolojilerinin liderleri, ileriye dönük karar vermek için bir araya geldiklerinde ve daha iyi bir yöntem üzerinde anlaşabildiler ve ayrıca manifesto için ifadeleri tamamlayabildiler.
Bu, uygulayıcıların anlamasına, başvurmasına ve uygulamaya koymasına yardımcı olmak için 4 değer ve 12 ilke olarak ele alınmıştır. Ve o noktada, hiçbiri bunun proje yönetiminin geleceği üzerindeki etkisini hayal edemezdi.
Çevik Manifesto
Manifesto, Agile'ın özünü minimum kelimelerle yakalamak için çok dikkatli bir şekilde ifade edildi ve aşağıdaki gibi okundu -
'Bunu yaparak ve başkalarının yapmasına yardım ederek bir yazılım geliştirmenin daha iyi yollarını ortaya çıkarıyoruz. Bu çalışma sayesinde aşağıdaki değere geldik:
- Süreçler ve araçlardan ziyade bireyler ve etkileşimler.
- Kapsamlı dokümantasyon yerine çalışan yazılım.
- Sözleşme pazarlığı yerine müşteri işbirliği.
- Bir planı takip etmek yerine değişime yanıt vermek.
Yani sağdaki öğelerde değer varken, soldaki öğelere daha çok değer veriyoruz. '
Gördüğümüz gibi, bunlar oldukça özlü ve basit ifadelerdir ve kurucuların neyi tanıtmak istediklerini çok açık hale getirir. Genellikle geleneksel proje planları katıdır ve prosedürleri ve zaman çizelgelerini vurgular, ancak çevik manifesto tam tersi şeyleri yayar.
Tercih eder:
- İnsanlar
- Ürün
- İletişim ve
- Cevaplanabilirlik
Agile değerleri ve ilkeleri hakkında daha derin bir anlayışa sahip olarak kurucuların geliştirmek istediği bu yeni paradigmayı ayrıntılı olarak keşfedeceğiz.
4 Çevik Değer
12 ilkeyle birlikte dört değer, çevik yazılım sunumuna rehberlik eder. Şimdi her bir değeri ayrıntılı olarak tartışacağız.

# 1) Süreçler ve Araçlardan ziyade Bireyler ve Etkileşimler
Süreci daha duyarlı hale getirdiği için bireyler ve etkileşimler, süreçlere ve araçlara tercih edilir. Bireyler aynı hizaya gelirse ve birbirlerini anlarlarsa ekip, araçlar veya süreçlerle ilgili sorunları çözebilir.
Ancak takımlar süreçlere körü körüne bağlı kalmakta ısrar ederse, bireyler arasında yanlış anlaşılmalara neden olabilir ve beklenmedik engeller yaratarak proje gecikmelerine neden olabilir.
Bu nedenle, ileriye giden yolda rehberlik edecek süreçlere körü körüne bağlı kalmak yerine ekip üyeleri arasında etkileşim ve iletişim olması her zaman tercih edilir. Bunu başarmanın yollarından biri, geliştirme ekibiyle işbirliği içinde çalışan ve kararlar alabilen ilgili bir ürün sahibine sahip olmaktır.
Bireylerin kendi başlarına katkıda bulunmalarına izin vermek, aynı zamanda masaya getirebileceklerini özgürce sergilemelerine de olanak tanır. Bu ekip etkileşimleri ortak bir sorunu çözmeye yönelik olduğunda, sonuçlar oldukça güçlü olabilir.
# 2) Kapsamlı Belgeler Üzerinden Çalışan Yazılım
Geleneksel proje yönetimi, aylarca gecikmeyi gerektiren kapsamlı dokümantasyon içeriyordu. Bu eskiden proje teslimatını olumsuz etkilerdi ve ortaya çıkan gecikmeler kaçınılmazdı.
pl sql geliştirici mülakat soruları ve cevapları
Bu projeler için oluşturulan dokümantasyon türü çok ayrıntılıydı ve o kadar çok doküman oluşturuldu ki, birçoğuna proje ilerlemesi sırasında atıfta bulunulmadı. Bu, proje ekiplerinin birlikte yaşadığı gereksiz bir kötülüktü.
Ancak bu aynı zamanda doğumdaki sorunları daha da kötüleştirdi. Odak noktası bu ölçüde dokümantasyondu çünkü ekipler spesifikasyonlara göre% 100 bitmiş bir ürün elde etmek istiyordu. Bu nedenle odak noktası, tüm özellikleri ayrıntılarıyla yakalamaktı.
Ancak yine de nihai ürün, beklentilerden oldukça farklıydı veya alaka düzeyini kaybedecekti. Bu nedenle Agile, çalışan bir yazılımın müşteri beklentilerini ölçmek için yığınla dokümantasyondan çok daha iyi bir seçenek olduğunu söylüyor.
Bu, belgelerin gerekli olmadığı anlamına gelmez. Bu sadece, çalışan bir ürünün, aylar önce oluşturulmuş bir belgeden daha iyi bir müşteri ihtiyaç ve beklentilerine uyum göstergesi olduğu anlamına gelir. Aynı zamanda, takımların yanıt verdiklerini ve sprint bittiğinde çalışan yazılımı müşteriye gösterirken gerektiğinde ve gerektiğinde değişime adapte olmaya hazır olduklarını ima eder.
Sprintler sırasında ürünün test edilmemesi, bir sonraki sprint için çok sayıda maliyet ve çaba gerektirir. İşlevsellik dağıtıldıktan sonra, bu değişikliklerin maliyeti önemli ölçüde artar.
3. Sözleşme Pazarlığı Üzerinden Müşteri İşbirliği
Müzakere, ayrıntıların hala ele geçirildiği ve sonuçlandırılmadığı anlamına gelir. Hala yeniden pazarlık için alan var. Ancak müzakere bittikten sonra üzerinde tartışma yapılamaz. Agile'ın söylediği, müzakere yerine işbirliğine gitmektir.
İşbirliği, hala tartışma alanı olduğu ve iletişimin devam ettiği anlamına gelir.
Tek seferlik bir şey değil. Bunun yaptığı şey, iki kat avantaj sağlar - ekibin daha erken bir aşamada gerekirse bir rota düzeltmesi yapmasına yardımcı olurken, müşterinin de vizyonunu iyileştirmesine ve kurs sırasında gerekirse gereksinimlerini yeniden tanımlamasına yardımcı olur. proje.
Diğer bir husus ise, geleneksel yazılım geliştirme modellerinin, geliştirme başlamadan önce, dokümantasyon ve müzakere aşamasında müşteriyi dahil etmesine rağmen, proje geliştirme sırasında olduğu kadar dahil edilmemeleridir.
İhtiyaçlar dondurulduktan sonra, ürünü yalnızca ürün hazır olduğunda görebilirler. Çeviklik, tüm yaşam döngüsü boyunca müşteri katılımına izin vererek bu engeli aşar.
Bu, Agile ekiplerinin müşteri ihtiyaçlarına daha iyi uyum sağlamasına yardımcı olur. Bunu başarmanın yollarından biri, açıklığa kavuşturmak ve işi müşteri öncelikleriyle uyumlu hale getirmek için gerçek zamanlı olarak ekibe yardımcı olabilecek, kendini adamış ve ilgili bir ürün sahibi kullanmaktır.
4. Bir Planı Takip Etmektense Değişime Cevap Vermek
Standart düşünce süreci, değişikliklerin pahalı bir mesele olduğu ve her ne pahasına olursa olsun değişikliklerden kaçınmamız gerektiğidir. Gereksiz odak noktası, zaman çizelgelerine ve ürün özelliklerine bağlı kalarak teslim etmek için belgelere ve ayrıntılı planlara odaklanmaktır.
Ama deneyimin de bize öğrettiği gibi, değişimler çoğunlukla kaçınılmazdır ve ondan kaçmak yerine onu kucaklamaya çalışmalı ve bunun için plan yapmalıyız.
Çevik, bu geçişi yapmamıza izin veriyor. Agile'ın düşündüğü şey, değişimin bir masraf olmadığı, projenin iyileştirilmesine yardımcı olan hoş bir geri bildirim olduğudur. Kaçınılması gereken bir şey değil, onun yerine değer katıyor.
Agile tarafından önerilen kısa sprintler ile takımlar hızlı geri bildirim alabilir ve kısa sürede önceliklerini değiştirebilir. Yinelemeden yinelemeye yeni özellikler eklenebilir.
Bunu neden yapıyoruz? Çünkü şelale yaklaşımı kullanılarak geliştirilen özelliklerin çoğu hiçbir zaman kullanılmamaktadır. Bunun nedeni şelale modelinin planı takip etmesidir, oysa bu en az bildiğimiz aşamadır.
Çevik aynı zamanda planlar, ancak aynı zamanda planlamanın gerektiği zaman yeterince yapıldığı tam zamanında yaklaşımı da izler. Ve sprintler ilerledikçe planlar her zaman değişmeye açıktır.
12 Çevik İlke
Takımların Agile'a geçişine yardımcı olmak ve rehberlik etmek ve takip ettikleri uygulamaların Agile kültürüyle uyumlu olup olmadığını kontrol etmek için manifesto oluşturulduktan sonra eklenen 12 Agile ilkesi vardır.
Çevik İttifak tarafından 2001'de yayınlanan orijinal 12 ilkenin metni aşağıdadır:
# 1) En yüksek önceliğimiz, değerli bir yazılımın erken ve sürekli teslimi yoluyla müşteriyi memnun etmektir.
#iki) Değişen gereksinimleri, geliştirmenin sonlarında bile karşılayın. Çevik süreçler, müşterinin rekabet avantajı için değişimden yararlanır.
# 3) Çalışan yazılımı birkaç haftadan birkaç aya kadar, daha kısa zaman ölçeğini tercih ederek sık sık teslim edin.
# 4) İş adamları ve geliştiriciler proje boyunca her gün birlikte çalışmalıdır.
android için iyi ücretsiz mp3 indirici
# 5) Motive olmuş bireyler etrafında projeler oluşturun. Onlara ihtiyaç duydukları ortamı ve desteği verin ve işi bitireceklerine güvenin.
# 6) Geliştirme ekibine ve geliştirme ekibine bilgi aktarmanın en verimli ve etkili yöntemi yüz yüze görüşmedir.
# 7) Çalışan yazılım, ilerlemenin birincil ölçüsüdür.
# 8) Çevik süreçler, sürdürülebilir gelişimi destekler. Sponsorlar, geliştiriciler ve kullanıcılar süresiz olarak sabit bir hızda devam edebilmelidir.
# 9) Teknik mükemmelliğe ve iyi tasarıma sürekli dikkat, çevikliği artırır.
# 10) Basitlik - Yapılmayan iş miktarını maksimize etme sanatı çok önemlidir.
#eleven) En iyi mimariler, gereksinimler ve tasarımlar kendi kendini organize eden ekiplerden ortaya çıkar.
# 12) Ekip düzenli aralıklarla nasıl daha etkili olabileceği üzerine düşünür, ardından davranışını buna göre ayarlar ve düzeltir.
Bu çevik ilkeler, geliştirme ekipleri için pratik rehberlik sağlar.
12 ilkeyi düzenlemenin bir başka yolu, onları aşağıdaki dört ayrı grupta ele almaktır:
- Müşteri memnuniyeti
- Kalite
- Takım çalışması
- Proje Yönetimi
# 1) En yüksek önceliğimiz, değerli bir yazılımın erken ve sürekli teslimi yoluyla müşteriyi memnun etmektir - Müşteriler, sonunda ürünü yalnızca kendilerinin görebileceği belirsiz bir bekleme süresinden geçmek zorunda kalmak yerine, her sprintte çalışan bir yazılımın teslim edildiğini görmekten heyecan duyacaklar.
Burada müşteri proje sponsoru veya geliştirme için ödeme yapan kişi olarak tanımlanabilir. Ürünün son kullanıcısı da bir müşteri ancak son kullanıcı bir kullanıcı olarak anıldığı için ikisini birbirinden ayırabiliriz.
#iki) Değişen gereksinimleri, geliştirmenin sonlarında bile karşılayın. Çevik süreçler, müşterinin rekabet avantajı için değişimden yararlanır - Değişiklikler, genel zaman çizelgelerine çok fazla gecikme olmaksızın dahil edilebilir.
Agile ekipleri her şeyden önce kaliteye inandıkları için, değişiklikleri önlemek ve iş ihtiyaçlarına hizmet etmeyen bir ürün sunmaktansa değişiklikleri dahil etmeyi ve müşteri gereksinimlerine göre teslim etmeyi tercih ederler.
# 3) Çalışan yazılımı birkaç haftadan birkaç aya kadar, daha kısa zaman ölçeğini tercih ederek sık sık teslim edin - Bu, sprintlerde çalışan ekipler tarafından halledilir. Sprintler zaman kutulu yinelemeler olduğundan ve her sprint sonunda çalışan bir yazılım sunduğundan, müşteriler düzenli olarak ilerleme hakkında bir fikir edinir.
# 4) İş adamları ve geliştiriciler proje boyunca her gün birlikte çalışmalıdır - Her ikisi birlikte işbirliği içinde çalışırken daha iyi kararlar alınır ve ikisi arasında rota düzeltme ve değişim çevikliği için sürekli bir geri bildirim döngüsü vardır. Paydaşlar arasındaki iletişim her zaman çevikliğin anahtarıdır.
# 5) Motive olmuş bireyler etrafında projeler oluşturun. Onlara ihtiyaç duydukları ortamı ve desteği verin ve işi tamamlamaları için onlara güvenin - Takımları desteklemeli, güvenmeli ve motive etmelisiniz. Motive olmuş bir takımın başarılı olma olasılığı daha yüksektir ve ellerinden gelenin en iyisini yapmaya istekli olmayan mutsuz takımlardan daha üstün bir ürün ortaya çıkaracaktır.
Bunu yapmanın yollarından biri, geliştirme ekibini kendi kendine organize olma ve kendi kararlarını alma konusunda güçlendirmektir.
# 6) Geliştirme ekibine ve içinde bilgi aktarmanın en verimli ve etkili yöntemi yüz yüze görüşmedir - Ekipler aynı konumdaysa ve tartışmalar için yüz yüze görüşebilirse iletişim daha iyi ve daha etkilidir. Güven oluşturmaya yardımcı olur ve çeşitli paydaşlar arasında anlayış getirir.
# 7) Çalışan yazılım, ilerlemenin birincil ölçüsüdür - Çalışan bir yazılım, diğer tüm KPI'ları yener ve yapılan işin en iyi göstergesidir.
# 8) Çevik süreçler, sürdürülebilir gelişimi destekler. Sponsorlar, geliştiriciler ve kullanıcılar süresiz olarak sabit bir hızda devam edebilmelidir - Teslimatın tutarlılığı vurgulanmaktadır. Ekip, proje süresince hızını koruyabilmeli ve ilk birkaç sprintten sonra tükenmemelidir.
# 9) Teknik mükemmelliğe ve iyi tasarıma sürekli dikkat, çevikliği artırır - Ekip, değişiklikleri dahil edebilmek ve yüksek kaliteli bir ürün üretmek için tüm becerilere ve iyi bir ürün tasarımına sahip olmalıdır.
c ++ tarih ve saat
# 10) Basitlik - Yapılmayan iş miktarını maksimize etme sanatı esastır ve sadece yapıldı tanımını karşılamak için yeterlidir.
#eleven) En iyi mimariler, gereksinimler ve tasarımlar kendi kendini organize eden ekiplerden ortaya çıkar - Kendi kendine organize olan ekipler güçlendirilir ve çalışmalarının sahipliğini üstlenir. Bu, ekip üyeleri arasında açık iletişime ve düzenli fikir paylaşımına yol açar.
# 12) Ekip düzenli aralıklarla nasıl daha etkili olabileceği üzerine düşünür, ardından davranışını buna göre ayarlar ve düzeltir - Kendini geliştirme, daha hızlı sonuçlara ve daha az yeniden çalışmaya yol açar.
Sonuç
Müşteri odaklılık ve iletişime odaklanma, bugün görünür olan çevikliğe başarıyı getirdi.
Sadece yazılım dağıtımında değil, diğer endüstrilerde de sonuçları olan kanıtlanmış bir tekniktir ve bugün kendi başına bir endüstri haline gelmiştir.
Bu dizide yakında yayınlanacak öğreticimiz, rolleriyle birlikte Scrum Takımı hakkında daha fazla bilgi verecektir !!
PREV Eğitimi | SONRAKİ Eğitici
Önerilen Kaynaklar
- Çevik Scrum Çevrimiçi Testi: Çevik Scrum Bilginizi Test Edin
- Çevik Bir Test Cihazının Zihniyet Değişimi: Çevik Manifesto ile Uyum
- Kanban vs Scrum vs Agile: Farklılıkları Bulmak İçin Ayrıntılı Bir Karşılaştırma
- Çevik Scrum Süreci Kullanılarak Kısa Sürede Yüksek Değerli Yazılım Özellikleri Nasıl Sağlanır
- SAFe Çevik Eğitimi: Ölçekli Çevik Çerçeve Nedir?
- Çevik Sürece Başarılı Geçiş için Çevik Test Zihniyetini Geliştirmeye Doğru 4 Adım
- JIRA Çevik Eğitimi: Çevik Projeleri Yönetmek İçin JIRA'yı Etkili Bir Şekilde Kullanma
- Çevik Manifesto'ya Dayalı DevOps Uygulaması (Bölüm 2 - Blok 1)