Aşırı Programlama. Yazılım geliştirme metodolojileri

Tüm eylemler için kapsamlı bir ekonomik gerekçe - yalnızca müşterinin ihtiyaç duyduğu şey yapılır ve projenin kârsız olmasına yol açmaz.

Temel mimarinin mümkün olduğu kadar erken oluşturulması.

Bileşen mimarisini kullanma.

Prototipleme, artımlı geliştirme ve test etme.

Mevcut durumun düzenli olarak değerlendirilmesi.

Değişim yönetimi, proje dışından değişikliklerin sürekli geliştirilmesi.

Gerçek ortamda çalışan bir ürün yaratmaya odaklanın.

Kaliteye odaklanın.

Sürecin projenin ihtiyaçlarına göre uyarlanması.

Ekstrem Programlama

Ekstrem Programlama (XP) yazılım geliştirmenin evrimsel bir yöntemi olarak ortaya çıktı"Aşağı". Bu yaklaşım sözde yöntemin bir örneğidir“Canlı” geliştirme (Çevik Geliştirme Metodu) . “Canlı” yöntemler grubu, aşırı programlamaya ek olarak SCRUM, DSDM (Dinamik Sistem Geliştirme Yöntemi, dinamik sistemler geliştirme yöntemi) yöntemlerini içerir.Özellik Odaklı Geliştirme (sistem fonksiyonlarının yönlendirdiği geliştirme), vb.

Canlı yazılım geliştirmenin temel ilkeleri, 2000 yılında ortaya çıkan canlı geliştirme manifestosunda yer almaktadır.

Bir projede yer alan kişiler ve onların iletişimi süreçlerden ve araçlardan daha önemlidir.

Çalışan bir program, kapsamlı dokümantasyondan daha önemlidir.

Müşteriyle işbirliği, sözleşmenin ayrıntılarını tartışmaktan daha önemlidir.

Değişiklikler üzerinde çalışmak planlara bağlı kalmaktan daha önemlidir.

“Yaşayan” yöntemler, yazılım geliştirmenin aşırı bürokratikleşmesine, nihai sonucu elde etmek için gerekli olmayan, bir projeyi yürütürken çoğu “ağır” süreçlere uygun olarak hazırlanması gereken yan belgelerin bolluğuna karşı bir protesto olarak ortaya çıktı. , ekstra işÖrneğin CMM'de gerektiği gibi kuruluşun sabit sürecini desteklemek. Bu tür iş ve belgelerin çoğu, doğrudan yazılım geliştirme ve kalite güvencesi ile ilgili olmayıp, geliştirme sözleşmelerinin resmi hükümlerine uymayı, çeşitli standartlara uygunluk sertifikalarını almayı ve onaylamayı amaçlamaktadır.

"Canlı" yöntemler, geliştiricilerin çabalarının çoğunu geliştirme görevlerine ve gerçek kullanıcı ihtiyaçlarını karşılamaya odaklamasına olanak tanır. Belge yığınlarının olmaması ve bunları tutarlı bir durumda tutma ihtiyacı, gereksinimlerdeki ve gelecekteki programın çalışmak zorunda kalacağı ortamdaki değişikliklere daha hızlı ve verimli bir şekilde yanıt vermenizi sağlar.

Bununla birlikte, XP'nin kendi geliştirme süreci diyagramı vardır (genel olarak konuşursak, "geliştirme süreci" nin oldukça katı bir eylem planı olarak yaygın olarak kullanılan anlayışı "canlı" geliştirme fikrinin kendisiyle çelişmesine rağmen), Şekil 2'de gösterilmiştir. 15.

XP'nin yazarlarına göre, bu teknik bazı genel eylem kalıplarını takip etmekten ziyade aşağıdaki tekniklerin bir kombinasyonunu kullanmaktır. Bununla birlikte, her teknik önemlidir ve Ward Cunningham ve Ron Jeffries ile birlikte bu yaklaşımın yazarlarından Kent Beck'e göre, kullanılmadan geliştirme XP olarak kabul edilmez.

Canlı planlama oyunu

Görevi, bir sonraki yazılım versiyonundan önce yapılması gereken iş miktarını mümkün olduğunca çabuk belirlemektir. Karar, öncelikle müşterinin önceliklerine (yani ihtiyaçlarına, daha başarılı olması için sistemden neye ihtiyacı olduğuna) göre verilir.

işinizi yürütme) ve ikinci olarak teknik değerlendirmelere (yani geliştirmenin karmaşıklığına ilişkin değerlendirmeler, sistemin diğer unsurlarıyla uyumluluk vb.) dayanarak. Planlar gerçeklikten veya müşterinin isteklerinden sapmaya başladığı anda değiştirilir.

"İçeriye atma" çözümleri

Şekil 15. XP'deki iş akışı şeması.

Sık sürüm değişiklikleri (küçük sürümler)

İlk çalışan sürüm mümkün olan en kısa sürede ortaya çıkmalı ve hemen kullanılmaya başlanmalıdır. Sonraki sürümler oldukça kısa aralıklarla hazırlanır (küçük bir programdaki küçük değişiklikler için birkaç saatten, büyük yeniden çalışmalar için bir veya iki aya kadar) büyük sistem).

Sistemin metaforu

Metafor oldukça basit ve takım için anlaşılır Form sistemin temel mekanizmasını açıklamalıdır. Bu kavram mimariyi anımsatıyor ancak alınan teknik kararların ana özünü çok daha basit bir şekilde, sadece bir veya iki cümleyle anlatmalıdır.

Basit tasarım çözümleri

Herhangi bir zamanda sistem mümkün olduğu kadar basit tasarlanmalıdır. Önceden özellik eklemenize gerek yoktur; yalnızca açıkça talep edildikten sonra. Gereksiz tüm karmaşıklık keşfedildiği anda ortadan kaldırılır.

Test Odaklı Geliştirme(test odaklı geliştirme)

Geliştiriciler önce testler yazar, ardından testlerin çalışması için modüllerini uygulamaya çalışırlar. Müşteriler, sistemin gerçekten çalıştığını görebilmeleri için sistemin ana yeteneklerini gösteren testleri önceden yazarlar.

Sürekli yeniden düzenleme

Programcılar, gereksiz karmaşıklığı ortadan kaldırmak, kodun anlaşılırlığını artırmak, esnekliğini artırmak, ancak testlerin her yeniden çalışmasından sonra çalıştırılarak doğrulanan davranışını değiştirmeden sistemi sürekli olarak yeniden çalışıyorlar. Aynı zamanda basit çözümler sunan çözümlere kıyasla daha şık ve esnek çözümler tercih edilmektedir. İstenen sonuç. Başarısız bir şekilde yeniden tasarlanan bileşenler, testin yürütülmesi sırasında tanımlanmalı ve son bozulmamış durumuna (bunlara bağlı bileşenlerle birlikte) geri döndürülmelidir.

Çiftler programı

Kodlama bir bilgisayarda iki programcı tarafından gerçekleştirilir. Eşleştirme keyfidir ve görevden göreve değişir. Klavyenin elinde olduğu kişi mevcut sorunu en iyi şekilde çözmeye çalışıyor. İkinci programcı çalışmayı analiz eder

önce ve tavsiyelerde bulunur, belirli kararların sonuçlarını, yeni testleri, daha az doğrudan ancak daha esnek çözümleri dikkate alır.

Kodun toplu mülkiyeti

İÇİNDE Ekibin herhangi bir üyesi, kodun herhangi bir bölümünü istediği zaman değiştirebilir. Hiç kimsenin kendi sorumluluk alanı olmamalıdır; tüm kodlardan bir bütün olarak ekip sorumludur.

Sürekli entegrasyon

Sistem toplanır ve mümkün olduğunca sık, günde birkaç kez, birkaç programcı bir sonraki işlevi uygulamayı bitirdiğinde entegrasyon testine tabi tutulur.

40 saatlik çalışma haftası

Fazla mesai yapmak bir işaret olarak kabul ediliyor büyük problemler projede. Art arda 2 hafta fazla mesai yapılmasına izin verilmez; bu, programcıları yorar ve çalışmalarını önemli ölçüde daha az üretken hale getirir.

Müşterinin ekibe dahil edilmesi(yerinde müşteri)

İÇİNDE Geliştirme ekibinde her zaman iş günü boyunca mevcut olan ve sistemle ilgili tüm sorulara cevap verebilecek bir müşteri temsilcisi bulunur. Onun sorumluluğu, sistemin işlevleri, arayüzü, gerekli performansı, zor durumlarda sistemin doğru çalışması, diğer uygulamalarla iletişimi sürdürme ihtiyacı vb. ile ilgili her türlü soruyu derhal yanıtlamaktır.

Kodu iletişim aracı olarak kullanma

Kod, bir ekip içindeki en önemli iletişim aracı olarak görülüyor. Kodun netliği ana önceliklerden biridir. Bu netliği sağlayan kodlama standartlarına uymak zorunludur. Bu tür standartlar, kod netliğine ek olarak, minimum düzeyde dil (kod ve bilgilerin kopyalanmaması) sağlamalı ve tüm ekip üyeleri tarafından kabul edilmelidir.

Çalışma alanını aç

Ekip, planlama yaparken ve önemli teknik kararlar alırken iletişimi kolaylaştırmak ve grup tartışmalarına olanak sağlamak için oldukça geniş bir odada barındırılıyor.

Kuralları gerektiği gibi değiştirmek (sadece kurallar)

Her ekip üyesinin listelenen kuralları kabul etmesi gerekir, ancak ihtiyaç duyulması halinde, tüm üyelerin bu değişiklik üzerinde hemfikir olması halinde ekip bunları değiştirebilir.

Kullanılan tekniklerden de görülebileceği gibi, XP, bu tekniğin yazarları tarafından vurgulanan, küçük ekipler (en fazla 10 programcı) içinde kullanılmak üzere tasarlanmıştır. Daha büyük bir ekip, başarı için gerekli olan iletişim kolaylığını ortadan kaldırır ve listelenen tekniklerin çoğunun uygulanmasını imkansız hale getirir.

XP'nin avantajları, eğer uygulanabilirse, daha fazla esneklik, değişen gereksinimlere ve bireysel müşteri isteklerine yanıt olarak yazılımda hızlı ve doğru bir şekilde değişiklik yapma yeteneği, ortaya çıkan kodun yüksek kalitesi ve herhangi bir değişiklik yapma ihtiyacının olmamasıdır. Müşterileri, sonucun beklentilerini karşıladığına ikna edin.

Bu yaklaşımın dezavantajları, yeterince büyük ve karmaşık projelerin bu tarzda uygulanamaması, projenin zamanlamasını ve karmaşıklığını yeterince uzun bir süre için planlayamamak ve uzun vadeli bir projenin sonuçlarını oran açısından net bir şekilde tahmin edememektir. sonucun kalitesi ve zaman ve kaynak maliyetleri. Ayrıca, XP'nin olası çözümlerin önceden kazanılan deneyimlere dayanarak hemen bulunamadığı ancak ön araştırma gerektiren durumlar için uygun olmadığı da belirtilebilir.

Tanımlanan bir dizi teknik olarak XP, ilk olarak C3 projesi (Chrysler Kapsamlı Tazminat Sistemi, bir ödeme muhasebe sisteminin geliştirilmesi) üzerinde çalışırken kullanıldı.

Daimler Chrysler çalışanları). Bu projedeki 20 katılımcıdan 5'i (yukarıda bahsedilen XP'nin 3 ana yazarı dahil) proje sırasında ve sonrasında XP'ye ayrılmış 3 kitap ve çok sayıda makale yayınladı. Bu tekniğin kullanımına örnek olarak bu projeden çeşitli kaynaklarda defalarca bahsedilmektedir. Aşağıdaki veriler, anekdotsal kanıtlar hariç, bahsedilen makalelerden derlenmiştir ve oldukça karmaşık projelere uygulandığında bazı XP teknikleriyle ilgili sorunları göstermektedir.

Proje Ocak 1995'te başladı. Mart 1996'dan itibaren Kent Beck'in dahil edilmesinden bu yana XP kullanılarak çalıştırılmaktadır. Bu zamana kadar, işlevlerin aşamalı olarak uygulanmasına yönelik bütçe ve planların ötesine geçmişti. Geliştirme ekibi çıkarıldı ve bundan sonraki yaklaşık altı ay boyunca proje oldukça başarılı bir şekilde gelişti. Ağustos 1998'de yaklaşık 10.000 çalışana hizmet verebilecek bir prototip ortaya çıktı. Projenin başlangıçta 1999 ortasında tamamlanması bekleniyordu ve ortaya çıkan yazılım, şirketin 87.000 çalışanının sosyal haklarını yönetmek için kullanılacaktı. XP'yi 4 yıl çalıştırdıktan sonra, zaman çerçevelerine ve bütçeye tam olarak uyulmaması nedeniyle Şubat 2000'de durduruldu. Oluşturulan yazılım hiçbir zaman 10.000'den fazla çalışana ait verilerle çalışacak şekilde kullanılmadı, ancak 30.000 şirket çalışanına ait verileri işleyebildiği gösterildi. Proje ekibinde yer alan müşteri rolünü üstlenen kişi, birkaç ay bu şekilde çalıştıktan sonra iş yüküne dayanamayıp proje sonuna kadar yeterli bir yedek alamayarak işten ayrıldı.

Ders 3 için Edebiyat

W. Royce. Yazılım proje yönetimi. M.: Lori, 2002.

A. Jacobson, G. Butch, J. Rambo. Birleşik yazılım geliştirme süreci. St.Petersburg: Peter, 2002.

Kroll, RUP'un Ruhu. www-106.ibm.com/developerworks/rational/library/ içerik/RationalEdge/dec01/TheSpiritoftheRUPDec01.pdf

K. Beck. Aşırı Programlama. St.Petersburg: Peter, 2002.

http://www.agilemanifesto.org/

K. Beck, et. al. Chrysler “Aşırılıklara” gidiyor. Dağıtılmış Hesaplama, 10/1998.

A. Cockburn. Bir Projenin Metodolojisinin Seçilmesi. IEEE Yazılımı, 04/2000.

L. Williams, R.R. Kessler, W. Cunningham, R. Jeffries. Eşli Programlama Durumunu Güçlendirmek. IEEE Yazılımı 4/2000.

G. Keefer. Aşırı Programlamanın Güvenilir Yazılım Geliştirme Açısından Zararlı Olduğu Değerlendiriliyor. AVOCA Teknik Raporu, 2002.

Şu şekilde mevcuttur: http://www.avoca-vsm.com/Dateien-Download/ExtremeProgramming.pdf.

İyi çalışmanızı bilgi tabanına göndermek basittir. Aşağıdaki formu kullanın

Bilgi tabanını çalışmalarında ve çalışmalarında kullanan öğrenciler, lisansüstü öğrenciler, genç bilim insanları size çok minnettar olacaklardır.

http://www.allbest.ru/ adresinde yayınlandı

İçerik

• giriiş
• 1. XP nedir?
• 3.1 Temel tekniklerXP
• 4. Avantajlar ve dezavantajlar
• 5. Kullanım geçmişi
• Çözüm

giriiş

Genellikle XP olarak kısaltılan Extreme Programming, her iki tarafın (programcılar ve iş adamları) çabalarını ortak, ulaşılabilir hedeflere odaklayan bir yazılım geliştirme ve yazılım işi disiplinidir. XP kullanan ekipler çok hızlı bir şekilde kaliteli yazılım üretirler. İK disiplinini oluşturan teknikler, insan yaratıcılığına ve insanın kararsız ve yanılabilir yaratıklar olduğunun kabulüne dayandığı için seçilmiştir.

XP genellikle bir dizi teknik olarak sunulur, ancak XP'nin kendisi bitiş çizgisi değildir. Bu sürecin sonunda uzun zamandır beklenen altın yıldızı almak için İK'yı daha iyi uygulamaya ve geliştirmeye gerek yok. Aksine, XP başlangıç ​​çizgisidir. XP şu soruyu sorar: "Kaliteli yazılım üretmeye devam edebilmemiz için çabalarımız ne kadar minimum düzeyde olabilir?"

Extreme Programming, belirsiz veya hızla değişen gereksinimler altında bir yazılım ürünü geliştiren küçük ve orta ölçekli uzman ekipleri için basitleştirilmiş bir üretim metodolojisidir.

1. XP nedir?

EkstremMketenprogramıMfitil(İngilizce) Aşırı Programlama, XP) esnek yazılım geliştirme metodolojilerinden biridir. Metodolojinin yazarları Kent Beck, Ward Cunningham, Martin Fowler ve diğerleridir.

XP, yazılım geliştirmenin basitleştirilmiş, verimli, esnek, öngörülebilir, bilime dayalı ve son derece eğlenceli, düşük riskli bir yoludur. İK aşağıdaki yönlerden diğer yöntemlerden farklıdır:

Son derece kısa geliştirme döngüleri kullanan XP, hızlı, gerçek ve sürekli geri bildirim sunar.

XP, genel bir proje planının oldukça hızlı bir şekilde ortaya çıkmasına neden olan artımlı planlamayı kullanır, ancak bu planın projenin ömrü boyunca geliştiği anlaşılmaktadır.

XP, şu veya bu işlevselliğin uygulanması için, işin değişen doğasına ve bununla bağlantılı olarak değişen müşteri gereksinimlerine verilen yanıtı iyileştiren esnek bir program kullanır.

XP dayanmaktadır otomatik testler, hem programcılar hem de müşteriler tarafından geliştirilmiştir. Bu testler sayesinde geliştirme sürecini takip etmek, sistemin doğru evrimleşmesini sağlamak ve sistemde var olan aksaklıkları hızlı bir şekilde tespit etmek mümkün olmaktadır.

XP sözlü iletişime, testlere ve kaynak koduna dayanmaktadır. Bu üç araç, bir sistemin yapısı ve davranışı hakkında bilgi alışverişinde bulunmak için kullanılır.

XP, sistemin kendisi var olduğu sürece devam eden gelişen bir tasarım sürecine dayanmaktadır.

XP, en yaygın beceri ve yeteneklere sahip programcılar arasındaki yakın etkileşime dayanmaktadır.

XP, hem bireysel programcıların kısa vadeli içgüdülerini hem de tüm projenin uzun vadeli çıkarlarını tatmin eden tekniklere dayanmaktadır.

XP bir yazılım geliştirme disiplinidir. Bu bir disiplindir çünkü XP'de XP kullanacaksanız yapmanız gereken bazı şeyler vardır. Test yazıp yazmamayı seçmemelisiniz, çünkü yapmazsanız yaptığınız programlama aşırı değildir.

XP metodolojisi, iki ila on programcının üzerinde çalışabileceği, mevcut bilgisayar ortamının katı sınırlarıyla sınırlı olmayan ve gerekli tüm test çalışmalarının bir gün içinde tamamlanabileceği projeler üzerinde çalışmak üzere tasarlanmıştır.

2. Nerede başlıyor? aşırı programlama

Aşırı programlama nerede başlar? Yerli bir yazılım geliştiricisinin tipik konumunun, geliştirme maliyetlerini mümkün olduğunca azaltmakla yükümlü olduğu anlayışından. Ve bunun için müşteriyle yoğun bir şekilde işbirliği yapmak, onun çıkarlarını anlamak ve sonunda tam olarak istediğini yapmak gerekir: ne fazla ne de az.

Ekstrem programlama, genel olarak inanıldığı gibi belirli tekniklere değil, yalnızca dört temel prensibe dayanmaktadır: iletişim, basitlik, Geri bildirim ve cesaret. Başlamanız gereken yer burası.

Extreme Programming hazır bir çözüm sunar: her şeyi mümkün olduğu kadar basit tutun, müşteriyi kendinize saklayın veya müşteriyle kalın, geliştirme sürecini aktif olarak izlemesine izin verin, değişimi memnuniyetle karşılayın - ve başarı neredeyse garanti edilir.

XP takımlarında iletişim her zaman teşvik edilir - en çok hızlı düzeltme bilgi ve tecrübe alışverişi. Maksimum geliştirme hızına ihtiyaç duyulduğunda bu çok önemlidir. Ancak diğer faydalı çabalar gibi iletişim de sürekli destek gerektirir. Bu nedenle ekipten birinin iletişimi izleme sorumluluğunu üstlenmesi, sözde diplomat olması gerekiyor. İletişim ve eylemlerinizi diğer ekip üyelerine açıklama ihtiyacı, sizi her şeyi mümkün olduğunca basit bir şekilde yapmaya zorlar. İlk seferde işe yaramazsa, ana hedefe, kodun diğer geliştiriciler için maksimum anlaşılırlığına ulaşılıncaya kadar tekrar tekrar basitleştirme üzerinde çalışırlar.

Ne yaparsak yapalım - iğneye iplik geçirmek ya da bir partiye gitmek - her zaman bir hedefe ulaşmak için çabalıyoruz. Eğer bundan saptığımızı fark edersek eylemlerimizi buna göre düzenleriz. Şimdi gözleriniz kapalıyken iğneye iplik geçirmenin veya ayna olmadan güzel giyinmenin ne kadar zor olduğunu hayal edin! Ancak program geliştirirken genellikle şu olur: sonucunu göremediğimiz bir şey yaparız. Bu nedenle ekstrem programlamada eylemlerinizin sonucunu mümkün olduğu kadar çabuk görmek bir kuraldır. Veya konuşurken teknik dil, mümkün olan en hızlı geri bildirimi sağlayın.

Extreme Programming bize şunu soruyor: Neden cesaret geliştirmiyorsunuz? Sonuçta işinde çok önemli. Cesaret olmadan, bir görevi belirli bir zaman diliminde tamamlama sorumluluğunu üstlenmek mümkün müdür? Cesaret olmadan, çıkmaza girdiğinizi fark edip bir adım geri çekilip çözüm aramak mümkün mü? Ve son olarak, geliştiricinin, yalnızca tüm son teslim tarihleri ​​dolduğunda oldu bittiyle sunmak yerine, görevi değerlendirmedeki hatasını kabul etmesine ve başkalarını bu konuda zamanında uyarmasına ne olanak tanıyacak? Cesaretin faydaları ortadadır ve en küçük görevde bile her başarı bu cesareti geliştirebilir.

3. XP Teknikleri

Extreme Programming (XP), aşağıdan yukarıya yazılım geliştirmenin evrimsel bir yöntemi olarak ortaya çıktı. Bu yaklaşım Çevik Geliştirme Yöntemi olarak adlandırılan yöntemin bir örneğidir. "Canlı" yöntemler grubu, aşırı programlamaya ek olarak SCRUM, DSDM (Dinamik Sistem Geliştirme Yöntemi, dinamik sistemler geliştirmek için bir yöntem), Özellik Odaklı Geliştirme (sistem işlevleri tarafından yönlendirilen geliştirme) vb. yöntemleri içerir.

Canlı yazılım geliştirmenin temel ilkeleri, 2000 yılında ortaya çıkan canlı geliştirme manifestosunda yer almaktadır.

· Bir projede yer alan kişiler ve onların iletişimi, süreç ve araçlardan daha önemlidir.

· Çalışan bir program, kapsamlı dokümantasyondan daha önemlidir.

· Müşteri ile işbirliği, sözleşmenin detaylarını görüşmekten daha önemlidir.

· Değişiklikler üzerinde çalışmak planlara bağlı kalmaktan daha önemlidir.

“Yaşayan” yöntemler, yazılım geliştirmenin aşırı bürokratikleşmesine, nihai sonucu elde etmek için gerekli olmayan, bir projeyi yürütürken çoğu “ağır” süreçlere uygun olarak hazırlanması gereken yan belgelerin bolluğuna karşı bir protesto olarak ortaya çıktı. , örneğin CMM'de bunun gibi organizasyonun sabit sürecini desteklemek için ek çalışma. Bu tür iş ve belgelerin çoğu, doğrudan yazılım geliştirme ve kalite güvencesi ile ilgili olmayıp, geliştirme sözleşmelerinin resmi hükümlerine uymayı, çeşitli standartlara uygunluk sertifikalarını almayı ve onaylamayı amaçlamaktadır.

"Canlı" yöntemler, geliştiricilerin çabalarının çoğunu geliştirme görevlerine ve gerçek kullanıcı ihtiyaçlarını karşılamaya odaklamasına olanak tanır. Belge yığınlarının olmaması ve bunları tutarlı bir durumda tutma ihtiyacı, gereksinimlerdeki ve gelecekteki programın çalışmak zorunda kalacağı ortamdaki değişikliklere daha hızlı ve verimli bir şekilde yanıt vermenizi sağlar.

Bununla birlikte, XP'nin kendi geliştirme süreci diyagramı vardır (genel olarak konuşursak, oldukça katı bir eylem planı olarak yaygın olarak kullanılan "geliştirme süreci" anlayışı, Şekil 1'de gösterilen "canlı" geliştirme fikriyle çelişmektedir). .

XP'nin yazarlarına göre, bu teknik bazı genel eylem kalıplarını takip etmekten ziyade aşağıdaki tekniklerin bir kombinasyonunu kullanmaktır. Bununla birlikte, Ward Cunningham ve Ron Jeffries ile birlikte bu yaklaşımın yazarlarından Kent Beck'e göre, her teknik önemlidir ve kullanılmadan geliştirme XP olarak kabul edilmez.

· Canlıplanlama (planlamaoyun)

Görevi, bir sonraki yazılım versiyonundan önce yapılması gereken iş miktarını mümkün olduğunca çabuk belirlemektir. Karar, her şeyden önce müşterinin önceliklerine (örn. ihtiyaçları, işini daha başarılı bir şekilde yürütmek için sistemden neye ihtiyaç duyduğu) ve ikinci olarak teknik değerlendirmelere (örn. karmaşıklık tahminleri) dayanarak verilir. geliştirme, sistemin diğer unsurlarıyla uyumluluk vb.). Planlar gerçeklikten veya müşterinin isteklerinden sapmaya başladığı anda değiştirilir.

Pirinç.1 XP İş Akışı Diyagramı

· SıkdeğiştirmekVversiyonlar (küçükSalıverme)

İlk çalışan sürüm mümkün olan en kısa sürede ortaya çıkmalı ve hemen kullanılmaya başlanmalıdır. Sonraki sürümler oldukça kısa aralıklarla hazırlanır (küçük bir programdaki küçük değişiklikler için birkaç saatten, büyük bir sistemin büyük bir yeniden çalışması için bir veya iki aya kadar). Ürünün sürümleri (sürümleri) mümkün olduğunca sık hizmete sunulmalıdır. Her sürümün tamamlanması mümkün olduğunca az zaman almalıdır. Ayrıca her versiyonun işe yararlılık açısından yeterince anlamlı olması gerekir.

· Metafor (metafor) sistemler

Metaforun ekip için oldukça basit ve anlaşılır bir biçimde, sistemin temel mekanizmasını anlatması gerekir. Bu kavram mimariyi anımsatıyor ancak alınan teknik kararların ana özünü çok daha basit bir şekilde, sadece bir veya iki cümleyle anlatmalıdır.

Mimarlık, bir sistemin bileşenleri ve bunların birbirine nasıl bağlı olduğu hakkında bir fikirdir. Geliştiriciler, sisteme bazı yeni işlevlerin nereye ekleneceğini ve bazı yeni bileşenlerin neyle etkileşime gireceğini anlamak için mimariyi kullanır.

Sistem metaforu çoğu teknikte mimari olarak adlandırılan şeyin bir benzeridir. Sistem metaforu, ekibe sistemin şu anda nasıl çalıştığı, yeni bileşenlerin nereye eklendiği ve bunların hangi formu alması gerektiği konusunda fikir verir.

· Basittasarımçözümler (basittasarım)

Herhangi bir zamanda sistem mümkün olduğu kadar basit tasarlanmalıdır. Önceden özellik eklemenize gerek yoktur; yalnızca açıkça talep edildikten sonra. Gereksiz tüm karmaşıklık keşfedildiği anda ortadan kaldırılır.

XP, çalışma süreci boyunca problemin koşullarının tekrar tekrar değişebileceği gerçeğinden yola çıkıyor, bu da geliştirilmekte olan ürünün bütünüyle önceden tasarlanmaması gerektiği anlamına geliyor. İlk başladığınızda bir sistemi baştan sona detaylı bir şekilde tasarlamaya çalışırsanız zamanınızı boşa harcıyorsunuz demektir. XP, tasarımın proje boyunca sürekli yapılması gereken önemli bir süreç olduğunu varsayar. Tasarım, sürekli değişen gereksinimler dikkate alınarak küçük adımlarla gerçekleştirilmelidir. Her an mevcut problemin çözümüne uygun, en basit tasarımı kullanmaya çalışıyoruz. Aynı zamanda sorunun koşulları değiştikçe biz de onu değiştiriyoruz.

· GelişimAçıktemeltest yapmak (Ölçek- sürmüşgelişim)

Geliştiriciler önce testler yazar, ardından testlerin çalışması için modüllerini uygulamaya çalışırlar. Müşteriler, sistemin gerçekten çalıştığını görebilmeleri için sistemin ana yeteneklerini gösteren testleri önceden yazarlar.

XP iki tür teste özellikle önem vermektedir:

ü birim testi;

b kabul testi.

aşırı programlama yazılımı

Bir geliştirici, geliştirdiği sistemin modüllerinin tüm testleri kesinlikle çalışana kadar yazdığı kodun doğruluğundan emin olamaz. Birim testleri, geliştiricilerin kodlarının düzgün çalıştığını doğrulamasını sağlar. Ayrıca diğer geliştiricilerin belirli bir kod parçasına neden ihtiyaç duyulduğunu ve nasıl çalıştığını anlamalarına da yardımcı olurlar. Birim testleri ayrıca geliştiricinin endişelenmeden yeniden düzenleme yapmasına olanak tanır.

Kabul testleri, sistemin gerçekten belirtilen yeteneklere sahip olmasını sağlar. Ayrıca kabul testleri, geliştirilmekte olan ürünün doğru çalıştığını doğrulamanıza olanak tanır.

XP için, TDD (Test Odaklı Geliştirme) adı verilen yaklaşım daha yüksek önceliğe sahiptir, önce geçemeyen bir test yazılır, ardından test geçecek şekilde kod yazılır ve ancak bundan sonra kod yeniden düzenlenir.

· Devamlıgeri dönüşüm (yeniden düzenleme)

Her yeni işlevin eklenmesinin ve kod büyümesinin geliştirmeyi, hataları tanımlamayı ve sonraki değişiklikleri yapmayı karmaşıklaştırdığı bir sır değil. Ekstrem Programlamanın püf noktalarından biri, kod iyileştirmeleriyle işlevsellik eklemeyi telafi etmektir. Bu kod işleme veya yeniden düzenlemedir.

Programcılar, gereksiz karmaşıklığı ortadan kaldırmak, kodun anlaşılırlığını artırmak, esnekliğini artırmak, ancak testlerin her yeniden çalışmasından sonra çalıştırılarak doğrulanan davranışını değiştirmeden sistemi sürekli olarak yeniden çalışıyorlar. Aynı zamanda basitçe istenilen sonucu veren çözümlere kıyasla daha zarif ve esnek çözümler tercih edilmektedir. Başarısız bir şekilde yeniden tasarlanan bileşenler, testin yürütülmesi sırasında tanımlanmalı ve son bozulmamış durumuna (bunlara bağlı bileşenlerle birlikte) geri döndürülmelidir.

Yeniden düzenleme, kodun işlevselliğini değiştirmeden iyileştirmeye yönelik bir tekniktir. XP, kod bir kez yazıldığında, proje süresince neredeyse kesinlikle birkaç kez yeniden yazılacağı anlamına gelir. XP geliştiricileri, geliştirmek için önceden yazılmış kodu acımasızca yeniden işler. Bu işleme yeniden düzenleme denir. Test kapsamının olmayışı, sistemi kırma korkusu nedeniyle yeniden düzenlemenin reddedilmesine neden olur ve bu da kodun kademeli olarak bozulmasına yol açar.

· Programlamaçift ​​halde (çiftprogramlama)

Deneyimli geliştiriciler, diğer kişilerin kodlarını periyodik olarak incelemenin kalite üzerinde olumlu bir etkisi olduğunu fark etmişlerdir. Extreme Programming'in ustaları bu yaklaşımı, geliştirme sırasında kodu çift programlama adı verilen bir teknikle sürekli gözden geçirerek geliştirdiler.

Kodlama bir bilgisayarda iki programcı tarafından gerçekleştirilir. Eşleştirme keyfidir ve görevden göreve değişir. Klavyenin elinde olduğu kişi mevcut sorunu en iyi şekilde çözmeye çalışıyor. İkinci programcı, birincinin çalışmasını analiz eder ve tavsiyelerde bulunur, belirli kararların sonuçlarını, yeni testleri, daha az doğrudan ancak daha esnek çözümleri dikkate alır. Gerekirse klavye serbestçe birinden diğerine aktarılır. Bir proje üzerinde çalışırken çiftler sabit değildir: takımdaki her programcının tüm sistemi iyi anlayabilmesi için bunların karıştırılması önerilir. Bu şekilde eşli programlama ekip içindeki işbirliğini geliştirir.

· Toplumülkkod (toplumülkiyet)

Toplu mülk her ekip üyesinin tüm kaynak kodundan sorumlu olduğu anlamına gelir. Böylece herkes programın herhangi bir bölümünde değişiklik yapma hakkına sahiptir. Eşli programlama bu uygulamayı destekler: farklı çiftler halinde çalışarak tüm programcılar sistem kodunun tüm bölümlerine aşina olur. Paylaşılan kod sahipliğinin önemli bir avantajı, geliştirme sürecini hızlandırmasıdır; çünkü bir hata oluşursa herhangi bir programcı bunu düzeltebilir.

Her programcıya kodu değiştirme hakkı vererek, ne yaptıklarını bildiklerini düşünen ancak belirli bağımlılıkları dikkate almayan programcıların neden olduğu hatalar riskini üstleniyoruz. İyi tanımlanmış UNIT testleri bu sorunu çözer: incelenmemiş bağımlılıklar hatalara neden olursa, UNIT testlerinin bir sonraki çalıştırması başarısız olur.

· Devamlıentegrasyon (süreklientegrasyon)

Sistem toplanır ve mümkün olduğunca sık, günde birkaç kez, birkaç programcı bir sonraki işlevi uygulamayı bitirdiğinde entegrasyon testine tabi tutulur.

Geliştirdiğiniz sistemi yeterince sık entegre ederseniz, onunla ilgili sorunların çoğundan kaçınabilirsiniz. Geleneksel yöntemlerde entegrasyon genellikle bir ürün üzerinde çalışmanın en sonunda, geliştirilmekte olan sistemin tüm bileşenlerinin tamamen hazır olduğu düşünüldüğünde gerçekleştirilir. XP'de, geliştiriciler tüm birim testlerinin doğru çalıştığından emin olduktan sonra, tüm sistemin kod entegrasyonu günde birkaç kez gerçekleştirilir.

Basitliğine rağmen bu tekniğin, entegre edilen işlevsellik için mevcut birim testlerinin başarısı, işlevsel veya kabul testlerinin varlığı ve elbette önceki bir duruma geri dönme yeteneği gibi kendi kullanım kuralları vardır. . Tipik olarak, ilgili zorlukların entegrasyonu ve çözümü, birkaç programcı tarafından ayrı bir bilgisayarda gerçekleştirilir. Bu, entegrasyonun istenmeyen sonuçları riskini en aza indirmenize olanak tanır.

· 40 saatçalışmabir hafta

Fazla mesai yapmak projede daha büyük sorunların işareti olarak görülüyor. Art arda 2 hafta fazla mesai yapılmasına izin verilmez; bu, programcıları yorar ve çalışmalarını önemli ölçüde daha az üretken hale getirir.

Bir kişi, özellikle de bir programcıysa, işi uğruna pek çok şey yapabilir: işe geç kalmak, hafta sonları işe gitmek, tatillerden vazgeçmek, birkaç gün klavye başında oturarak uyanık kalmak... Genel olarak en sevdiğiniz aktivite uğruna neler yapabilirsiniz? Ancak aşırı programlama, bu tür fedakarlıklara ve kabul edilen iş hukuku standartlarının ihlaline kategorik olarak karşıdır.

Bu sadece yasallık ve insanlık kaygılarıyla değil, her şeyden önce iş verimliliğini ve sıkı organizasyonu artırma ihtiyacıyla da belirlenir. Sonuçta aşırı programlama, bireyler için değil tüm grup için tasarlanmış kolektif bir oyundur. Ve örneğin çift programlama gibi bir şey ancak katılımcıların biyoritimleri senkronize edildiğinde mümkündür. Ve bir kişi dokuzda, ikincisi on ikide işe gelirse veya biri cumartesi ve pazar günleri çalışmanın kendisi için daha iyi olduğuna, diğeri ise sakıncalı olduğuna karar verirse bu imkansızdır.

Ancak en önemli şey, sağlığı ve performansı korumak için kişinin uygun dinlenmeye ihtiyacı olmasıdır. Sekiz saatlik çalışma günü ve beş günlük çalışma haftası tam olarak maksimum üretkenlik amacıyla belirlenmiştir. Pek çok Batılı şirkette işten geç ayrılmak, iyi performans gösterememe veya kişinin çalışma süresini doğru şekilde yönetememe olarak görülüyor. Çoğu durumda bu doğrudur. Tıbbi açıdan bakıldığında işteki gecikmeler sürekli yorgunluğa, sinirliliğe ve beyin aktivitesinde azalmaya yol açar. Bu etkili mi? Böyle bir ekipte sürekli çalışma nasıl organize edilir? açık iletişim geliştiriciler arasında ve çift programlama mümkün olacak mı? Cevap olumsuz. Standartlar standarttır ve uyulması gerekir.

· Dahil etmemüşteriVtakım (Açık- alanmüşteri)

Yazılım geliştirmenin temel sorunu, programcıların geliştirilen yazılımdaki bilgi eksikliğidir. konu alanı. Extreme programlama bu durumdan bir çıkış yolu buldu. Hayır, bu müşterinin işletmesindeki geliştirici stajı değildir - o zaman programlamak istemeyecektir. Tam tersine müşterinin geliştirme sürecine katılımıdır.

Geliştirme ekibinde her zaman iş günü boyunca mevcut olan ve sistemle ilgili tüm sorulara cevap verebilecek bir müşteri temsilcisi bulunur. Onun sorumluluğu, sistemin işlevleri, arayüzü, gerekli performansı, zor durumlarda sistemin doğru çalışması, diğer uygulamalarla iletişimi sürdürme ihtiyacı vb. ile ilgili her türlü soruyu derhal yanıtlamaktır.

Birçoğu müşteriyi geliştirme sürecine dahil etme olasılığından şüphe ediyor. Aslında müşteriler farklıdır. Müşteriyi veya temsilcisini çekmek mümkün değilse, bazen geliştirilmekte olan alanda bir uzmanın geçici olarak işe alınması tavsiye edilir. Bu adım, işteki belirsizlikleri azaltacak, geliştirme hızını artıracak ve projeyi müşterinin almak istediği şeye yaklaştıracaktır. Bu aynı zamanda mali açıdan da faydalı olabilir: Sonuçta, bir programcının maaşı bazen diğer sektörlerdeki uzmanların maaşından önemli ölçüde daha yüksektir.

· KullanımkodNasıltesisleriletişim

Kod, bir ekip içindeki en önemli iletişim aracı olarak görülüyor. Kodun netliği ana önceliklerden biridir. Bu netliği sağlayan kodlama standartlarına uymak zorunludur. Bu tür standartlar, kod netliğine ek olarak, minimum düzeyde dil (kod ve bilgilerin kopyalanmaması) sağlamalı ve tüm ekip üyeleri tarafından kabul edilmelidir.

· Açıkçalışmauzay (açıkçalışma alanı)

Ekip, planlama yaparken ve önemli teknik kararlar alırken iletişimi kolaylaştırmak ve grup tartışmalarına olanak sağlamak için oldukça geniş bir odada barındırılıyor.

· Değiştirmektüzükİlegereklilik (Sadecetüzük)

Her ekip üyesinin listelenen kuralları kabul etmesi gerekir, ancak ihtiyaç duyulması halinde, tüm üyelerin bu değişiklik üzerinde hemfikir olması halinde ekip bunları değiştirebilir.

Kullanılan tekniklerden de görülebileceği gibi, XP, bu tekniğin yazarları tarafından vurgulanan, küçük ekipler (en fazla 10 programcı) içinde kullanılmak üzere tasarlanmıştır. Daha büyük bir ekip, başarı için gerekli olan iletişim kolaylığını ortadan kaldırır ve listelenen tekniklerin çoğunun uygulanmasını imkansız hale getirir.

3.1 Temel XP Teknikleri

Aşırı programlamanın on iki temel tekniği (kitabın ilk baskısına dayanmaktadır) Aşırı programlama açıkladı) dört gruba birleştirilebilir:

· Kısa geri bildirim döngüsü (İnce ölçekli geri bildirim)

o Test odaklı geliştirme

o Planlama oyunu

o Müşteri her zaman yakındadır (Tüm ekip, Yerinde müşteri)

o Eşli programlama

Toplu işlem yerine sürekli

o Sürekli Entegrasyon

o Yeniden Düzenleme (Tasarım İyileştirme, Yeniden Düzenleme)

o Sık Küçük Sürümler

· Herkes tarafından paylaşılan anlayış

o Sadelik (Basit tasarım)

o Sistem metaforu

o Kolektif kod sahipliği veya seçilmiş tasarım modelleri (Kolektif kalıp sahipliği)

o Kodlama standardı veya Kodlama kuralları

· Programcı refahı:

o Haftada 40 saatlik çalışma (Sürdürülebilir tempo, Haftada kırk saat)

Bir oyunVplanlama

Dünyamız, durumun sabitliğine güvenemeyecek kadar değişken ve öngörülemez. Aynı şey yazılım geliştirmede de olur: Nadir bir sistemle, nihai biçiminin, geliştirmenin en başında önceden ayrıntılı olarak bilindiğini söyleyebilirsiniz. Tipik olarak müşterinin iştahı yemek yerken gelir: Sürekli olarak bir şeyi değiştirmek, bir şeyi geliştirmek veya bir şeyi sistemden tamamen atmak ister. Bu, herkesin çok korktuğu gereksinimlerin değişkenliğidir. Neyse ki, insana tahmin etme yeteneği verilmiştir olası seçenekler ve böylece durumu kontrol altında tutun.

Extreme Programming'de planlama, gelişimin ayrılmaz bir parçasıdır ve planların değişebileceği gerçeği en baştan dikkate alınır. Durumu tahmin etmenize ve değişikliklere acısız bir şekilde katlanmanıza olanak tanıyan teknik olan dayanak noktası, planlama oyunudur. Böyle bir oyun sırasında bilinen sistem gereksinimleri hızlı bir şekilde toplanabilir, değerlendirilebilir ve önceliğe göre planlanabilir.

Diğer tüm oyunlar gibi planlamanın da katılımcıları ve hedefi vardır. Burada önemli olan elbette müşteridir. Şu veya bu işlevselliğe olan ihtiyacı ileten odur. Programcılar her işlevsellik hakkında yaklaşık bir değerlendirme yapar. Planlama oyununun güzelliği, geliştirici ile müşteri arasındaki amaç birliği ve dayanışmada yatmaktadır: Zafer durumunda herkes kazanır, yenilgi durumunda ise herkes kaybeder. Ancak aynı zamanda her katılımcı zafere giden kendi yoluna gider: Müşteri en önemli görevleri bütçeye uygun olarak seçer ve programcı görevleri uygulama becerisine göre değerlendirir.

Extreme programlama, geliştiricilerin görevlerini tamamlamalarının ne kadar süreceği ve hangisinin bir sorunu çözmek için daha istekli olacağı ve kimin diğerini çözeceği konusunda kendilerinin karar verebileceklerini varsayar.

İdeal bir durumda, müşteri ile programcı arasındaki planlama oyunu, bir sonraki geliştirme yinelemesi başlayana kadar her 3-6 haftada bir oynanmalıdır. Bu, önceki yinelemenin başarılarına ve başarısızlıklarına göre ayarlamalar yapmayı oldukça kolaylaştırır.

4. Avantajlar ve dezavantajlar

XP'nin avantajları, eğer uygulanabilirse, daha fazla esneklik, değişen gereksinimlere ve bireysel müşteri isteklerine yanıt olarak yazılımda hızlı ve doğru bir şekilde değişiklik yapma yeteneği, ortaya çıkan kodun yüksek kalitesi ve herhangi bir değişiklik yapma ihtiyacının olmamasıdır. Müşterileri, sonucun beklentilerini karşıladığına ikna edin.

Bu yaklaşımın dezavantajları, yeterince büyük ve karmaşık projelerin bu tarzda uygulanamaması, projenin zamanlamasını ve karmaşıklığını yeterince uzun bir süre için planlayamamak ve uzun vadeli bir projenin sonuçlarını oran açısından net bir şekilde tahmin edememektir. sonucun kalitesi ve zaman ve kaynak maliyetleri. Ayrıca XP'nin, olası çözümlerin önceden kazanılan deneyimlere dayanarak hemen bulunamadığı ancak ön araştırma gerektiren durumlar için uygun olmadığı da belirtilebilir.

5. Kullanım geçmişi

Tanımlanan bir dizi teknik olarak XP, ilk olarak C3 projesi (Chrysler Kapsamlı Tazminat Sistemi, Daimler Chrysler'de çalışanlara sağlanan faydaların muhasebeleştirilmesi için bir sistemin geliştirilmesi) üzerinde çalışırken kullanıldı. Bu projedeki 20 katılımcıdan 5'i (yukarıda bahsedilen XP'nin 3 ana yazarı dahil) proje sırasında ve sonrasında XP'ye ayrılmış 3 kitap ve çok sayıda makale yayınladı. Aşağıdaki veriler, oldukça karmaşık projelere uygulandığında bazı XP teknikleriyle ilgili sorunları göstermektedir.

Proje Ocak 1995'te başladı. Mart 1996'dan itibaren Kent Beck'in dahil edilmesinden bu yana XP kullanılarak çalıştırılmaktadır. Bu zamana kadar, işlevlerin aşamalı olarak uygulanmasına yönelik bütçe ve planların ötesine geçmişti. Geliştirme ekibi çıkarıldı ve bundan sonraki yaklaşık altı ay boyunca proje oldukça başarılı bir şekilde gelişti. Ağustos 1998'de yaklaşık 10.000 çalışana hizmet verebilecek bir prototip ortaya çıktı. Projenin başlangıçta 1999 ortasında tamamlanması bekleniyordu ve ortaya çıkan yazılım, şirketin 87.000 çalışanının sosyal haklarını yönetmek için kullanılacaktı. XP'yi 4 yıl çalıştırdıktan sonra, zaman çerçevelerine ve bütçeye tam olarak uyulmaması nedeniyle Şubat 2000'de durduruldu. Oluşturulan yazılım hiçbir zaman 10.000'den fazla çalışana ait verilerle çalışacak şekilde kullanılmadı, ancak 30.000 şirket çalışanına ait verileri işleyebildiği gösterildi. Proje ekibinde yer alan müşteri rolünü üstlenen kişi, birkaç ay bu şekilde çalıştıktan sonra iş yüküne dayanamayıp proje sonuna kadar yeterli bir yedek alamayarak işten ayrıldı.

Çözüm

Yukarıdaki yöntemlerin tümü tesadüfen bir araya getirilmemiştir. Bunların tutarlı kombinasyonu, geliştirme sürecini entelektüel rezonansa getirebilir, ürünün kalitesini önemli ölçüde artırabilir ve piyasaya sürülme süresini hızlandırabilir. Tüm ekstrem programlamaların ana güzelliği öngörülebilirlik ve geliştirme maliyetlerinin en aza indirilmesidir; Müşteriye teslim almak istediği ürünü piyasaya sürüldüğünde sağlamak; ve tabii ki geliştiricilerin iş başında iletişimi ve eğitimi.

Önerilen metodolojiye ilişkin görüşler farklılık gösterebilir. Extreme Programming'in mevcut geliştirme teknolojilerinin yerini almayı amaçlamadığını anlamak önemlidir. Aksine, XP geleneksel yaklaşımları kullanan takımlara ek ivme sağlayabilir. Tüm sorularınızın cevabını burada aramamalısınız. Bu bir programlama teknolojisi değil, işi organize etmeye yönelik bir teknolojidir ve bu biçimde yaşam hakkına sahiptir.

Allbest.ru'da yayınlandı

Benzer belgeler

IDS Scheer'in şirketin iş süreçlerini modellemeye yönelik bir yazılım ürünü olan optimal ve işlevsel bir ARIS modelinin geliştirilmesinin aşamalarının ve özelliklerinin analizi. Ekstrem programlamanın temel kavramlarının, metodolojilerinin ve yaklaşımlarının incelenmesi.

test, eklendi: 06/04/2011


Yazılım geliştirmenin ana aşamaları (yazılım paketi), sistem gereksinimlerinin analizi. Adım adım detaylandırma yöntemi. Programlama dilleri düşük seviye ve yüksek düzeyde (zorunlu, nesne yönelimli, işlevsel, mantıksal).

sunum, 10/13/2013 eklendi


Geliştirme dili, uygulama ortamı, geliştirme araçları. Programın uygulanması için sanal ortamın özellikleri ve bunların bir yazılım ürününün geliştirilmesinde dikkate alınması. Sistem makroları ve bunların geliştirme metinlerinde kullanımı. Görsel programlama araçları.

öğretici, 26.10.2013 eklendi


Yazılım güvenilirliği sorunu, göstergeleri ve destek faktörleri. Programların ve dokümantasyonun geliştirme sürecini izleme yöntemleri, hataların önlenmesi. Yazılım hata ayıklama sürecinin aşamaları, yapılandırılmış programlama teknikleri ve modülerlik ilkesi.

sunum, 30.04.2014 eklendi


Makine kodları ve montajcı. İlk üst düzey programlama dilleri. FORTRAN programlama dili. ALGOL'ün avantajları ve dezavantajları. Bilimsel ve muhasebe programları. Temel programlama dili oluşturulurken izlenen temel ilkeler.

kurs çalışması, eklendi 06/21/2014


Dağıtılmış yazılım geliştirmenin kavramı ve temel farkı, avantajları ve dezavantajları. Kavramsal çözüm ve geliştirme türünün seçimi. Açık kaynak yazılımın özellikleri. Açık Kaynak fikri ve gelişimi.

kurs çalışması, eklendi 12/14/2012


Yazılım yaşam döngüsü kavramı. İki tür faaliyet ayırt edilir: teknik projeler: tasarım ve üretim. Esnek metodolojilerin takipçilerinin manifestosunun ana ilkeleri. Temel prensipler aşırı programlama

sunum, 14.08.2013 eklendi


Pascal programlama dili için uluslararası standart. Turbo Pascal'da nesne yönelimli programlama teknikleri. Dilin sembolleri, alfabesi. Program geliştirme aşamaları. Algoritma kavramı ve algoritmalaştırma. Pascal'da programların yapısı.

kurs çalışması, eklendi 02/28/2010


Kontrol sistemleri için modern yazılım geliştirme araçları. Evrensel programlama dilleri ve SCADA sistemleriyle karşılaştırılması. Çok kanallı ölçüm dönüştürücüleri Ш9327 kullanarak yazılım geliştirme.

tez, eklendi: 07/13/2011


Çevrede çalışmak için temel teknikler Delphi programlama. Basit uygulamalar oluşturmak için teknolojinin özellikleri. Uygulama geliştirme ortamı bileşenleriyle çalışma. Bilgi girişi, düzenlenmesi, seçimi ve çıkışı. Dallanma yapısını kullanmanın yönleri.

Muhtemelen hayatında en az bir kez her tasarımcı veya analist, projesini mümkün olduğu kadar ucuza ve dahası mümkün olan en kısa sürede almaya çalışan bir müşteriyle karşı karşıya kalmıştır. Ancak projenin maliyeti gerçek bir pazarlık konusuysa, proje teslim tarihlerinin ayarlanması konusunda pazarlık yapmak çok daha zordur. Günümüzde modern dinamik pazarın durumu, icracılar ile müşteriler arasındaki güvenin azalması ve yemek yerken iştahı gelen yatırımcıların davranışları (az ya da çok çalışan bir müşteri varsa) ile açıklanabilen, günümüzde giderek daha fazla sabırsız müşteri var. ürünün versiyonu, daha fazla geliştirme için parayı çok daha isteyerek veriyorlar), vb. Bu bağlamda, klasik geliştirme metodolojileri (müşteri önemli miktarda fon yatırdığında ancak uzun bir süre gerçek sonuçlar alamadığında, gerçek tasarım ve bilgi toplamanın uzun bir döngüsünün olduğu), çıkarlarla çok sıkı bir çatışmaya girmektedir. sabırsız müşteri. Bütün bunlar, alternatif tasarım metodolojilerinin iki ana yönde geliştirilmesine ivme kazandırdı: başarılı bir şekilde gelişen geliştirme sürecinin gerçek kanıtını sağlayarak müşteri güvenini artırmak ve ürün geliştirme süresini keskin bir şekilde azaltmak. Bu tür metodolojilerin bir grubuna “aktif programlama” adı verilir.

Hızlandırılmış ve işbirliğine dayalı uygulama geliştirme

Tipik olarak son kullanıcılar ve müşteri yönetimi, gerçek kullanıma hazır bileşenlerin mevcut olmaması durumunda tasarım sürecinin başarısız olduğuna inanır. Çoğu zaman müşteri, belirli bir sonuç elde etmek ve bunu mümkün olduğu kadar çabuk göstermek için proje uygulama aşamasını planlanandan önce gerçekleştirmekte ısrar eder. Bu durumda Hızlandırılmış Uygulama Geliştirmeyi (AAD) veya İşbirliğine Dayalı Uygulama Geliştirmeyi (CAD) seçmek çok cazip geliyor. Bu tür yöntemler, çalışan bir prototip geliştirmeyi ve daha sonra bunu, neyi sevip neyi sevmediğini not eden kullanıcılara göstermeyi içerir. Bundan sonra tasarımcı, yapılan yorumları dikkate alarak prototipi geliştirir ve ardından ne olduğunu tekrar gösterir. Kullanıcılar gördükleri şeyden memnun kalana ve prototip çalışan bir uygulama haline gelinceye kadar süreç tekrarlanır. Genellikle bir zaman sınırı ve yineleme sayısı belirlenir, aksi takdirde kullanıcılar prototipte sürekli olarak yeni iyileştirmeler talep edeceklerdir. Teorik olarak bu, kullanıcıların tam olarak ihtiyaç duyduğu sistemi elde etmenizi sağlar.

Burada her iki durumda da çok kısa sarmal döngülere sahip yinelemeli bir geliştirme modeli görüyoruz. Her iki yöntemde de tasarımın ilk aşamalarında harcanan süre azalır: strateji (ya tamamen atlanır ya da analizle birleştirilir), analiz (çoğu durumda bilgilerin ilk seçimi ve formların analizi ile sınırlıdır - kural olarak, raporlar, raporlar, vb.) sistem fonksiyonlarının yapısını eski haline getirmek için kullanılan), tasarım (birincil prototipin mümkün olan en kısa sürede elde edilmesini amaçlayan). Geliştirmenin sonucu, daha sonra endüstriyel uygulamaya konu olacak bir prototiptir. Bu durumda test, müşterinin aktif katılımıyla gerçekleştirilir veya müşteri bir testçi (en iyi ihtimalle beta testçisi) olur.

Uygulamada, uygulama geliştirmeye yönelik bu yaklaşım aşağıdaki sorunlarla ilişkilidir:

Tüm dikkat ekran formlarında yoğunlaşır ve veri işleme kuralları ve sistem işlevleriyle ilgili her şey perde arkasında kalır. Raporlar bir başlangıç ​​ürünü değil, bir bilgi sisteminin türev ürünü iken, raporlarla çalışmaya başlamanın cazibesi vardır.

Kullanıcılar, prototip sürümü üzerinde anlaşmaya varılması durumunda modülün hazır olduğunu varsayarlar. Aslında bu, sistem işlevlerini çağırmak ve diğer modüllerle etkileşim kurmak için bir dizi "taslak" içeren bir resim olabilir.

Modüller birbirinden izole olarak tasarlanmıştır. Bunun sonucu olarak modüller arasındaki çelişkiler, işlevlerin ve verilerin kopyalanması ortaya çıkar ve bunlar yalnızca bir modül kümesinin test edilmesiyle belirlenebilir.

İşlevsellik paralel olarak çeşitli yönlere genişletilir, bu nedenle veri ambarının yapısının kontrol edilmesi gerekir. URP ile veritabanı tasarımı, tabloların aceleyle bir araya getirildiği ve sonucun bir dizi çelişkili ve yinelenen veri olduğu bir hurdalığa benzer.

URP yöntemini kullanırken dokümantasyon genellikle iki nedenden dolayı yoktur: Yeterli zaman yoktur ve kullanıcının olup bitenlerin özünü belgeler olmadan anlayabildiği yanılsaması yaratılır. Uygulama kullanıcının beklediğinden farklı çalışmaya başladığında sorunlar ortaya çıkar.

İstisnaların ele alınma şeklinin farklı modüller için farklı olduğu ortaya çıkıyor.

Modülleri entegre etme sorunu ortaya çıkıyor: Kural olarak, tam bir sistem işe yaramıyor, çünkü başlangıçta daha sonra aceleyle birbirine bağlanan bir dizi bileşen olarak tasarlandı.

Ürün kalite kontrolü, proje geliştirmenin zamanlaması ile sıkı bir çatışmaya girer, bunun sonucunda ürünün bir sonraki versiyonunun test ve uygulama aşamaları pratik olarak birleştirilir ve doğrudan müşterinin test sitesine aktarılır. Ürünün kalitesinden son derece memnun olmayan müşterinin bu durumda ne olacağı açıktır; diğer bir deyişle, kirli çamaşırlar toplum içinde kesinlikle yanlış zamanda yıkanıyor.

Şu soru ortaya çıkıyor: Bu tür sorunlar çözülebilir mi ve nasıl? Sonuçta, projeyi gerçekten mümkün olduğu kadar çabuk almak istiyorsunuz! Bir dereceye kadar, aşırı programlama (eXtreme Programming, XP), daha genç aktif programlama metodolojileri alanında bir evrim ve hatta belki de bir devrim olarak düşünülebilir. Bu metodolojinin özellikle geliştirme ekibiniz için uygun olup olmadığına karar vermek size bağlıdır ve yalnızca siz karar verirsiniz, çünkü örneğin herkes ekstrem sporlardan hoşlanmaz.

Ekstrem Programlama

Geliştirmeyi hızlandırmak için kullanılan XP ilkeleri ve yöntemleri

Kent Beck, aşırı programlamanın baba-ideoloğu olarak kabul ediliyor. XP, değerlendirmeleri coşkuludan keskin olumsuza kadar çok çelişkili olan oldukça genç bir metodolojidir. Ana ilkeler şunlardır:

Çözümlerin basitliği.

Küçük gruplarda yoğun gelişim (en fazla 10 kişi), grup içinde ve gruplar arasında aktif iletişim (iletişim).

Geliştirme sürecine fiilen katılan müşteriden gelen geri bildirim.

Yeterli derecede cesaret ve risk alma isteği.

Geliştirmeyi hızlandırmanın ilk faktörü yinelemedir: Geliştirme, müşteriyle aktif bir ilişki kurularak kısa yinelemelerle gerçekleştirilir. XP yinelemeli bir geliştirme sürecidir ve kendi içinde devrim niteliğinde değildir. Tekrarların kısa tutulması, önerilen sürenin 2-3 hafta ve 1 ayı geçmemesi önerilmektedir. Bir yinelemede, bir grup programcının sistemin her biri bir kullanıcı hikayesinde açıklanan çeşitli özelliklerini uygulaması gerekir. Bu durumda kullanıcı hikayeleri, modülün oluşturulduğu temel bilgilerdir. Kullanıcı hikayeleri kullanım senaryolarından farklıdır: bir kullanıcı hikayesi kısadır - 1-2 paragraf, kullanım senaryoları ise genellikle oldukça ayrıntılı, ana ve alternatif akışlarla yazılır - dolayısıyla yaklaşık bir sayfa artı bir diyagramla sonuçlanır (en yaygın biçimlendirme, şu anda UML'de önerilmektedir); Kullanıcı hikayeleri, genellikle bir sistem analisti tarafından yazılan kullanım senaryolarının aksine, kullanıcıların kendileri (XP'de ekibin bir parçası olan) tarafından yazılır. XP'de proje giriş verilerinin tanımının resmileştirilmemesi, müşteriyi ekibin tam üyesi olarak geliştirme sürecine aktif olarak dahil ederek ve müşteriyle sürekli iletişim kurarak (aktif iletişim ve sürekli geri bildirim desteği) telafi edilmeye çalışılır. ). Bu durumda, müşterinin programlama mutfağına dahil olma derecesi aşırıdır ve bu, iletişim ve geri bildirim yoluyla geliştirme süresini kısaltma arzusundan kaynaklanmaktadır.

Ürün geliştirmeyi hızlandıran ikinci faktör, küçük grupların ve eşli programlamanın (iki programcının ortak bir işyerinde birlikte kod oluşturması) varlığıdır. Bütün bunlar, grupta yüksek düzeyde iletişim sağlamanın yanı sıra sorunları (hem hatalar hem de kaçırılan son teslim tarihleri) mümkün olduğunca erken tespit etmeyi amaçlamaktadır. Eşli programlamanın amacı projeyi istikrara kavuşturmaktır, çünkü bu metodolojide yoğun çalışma programına dayanamayan bir programcının ayrılması nedeniyle kod kaybetme riski yüksektir. Bu durumda, çiftin ikinci programcısı kodun "halefi" rolünü oynar (klasik yöntemlerde teknik dokümantasyonda uygulanır). Grupların çalışma alanında tam olarak nasıl dağıtıldığı da önemlidir - XP, herkesin herkese hızlı ve ücretsiz erişimini varsayan açık bir çalışma alanı kullanır; Tipik olarak çalışma alanı bir daire etrafında inşa edilir.

Süreç gelişimini hızlandırmanın üçüncü faktörü, ilk en basit çalışma çözümünü yapmaktır. Bu durumda yöntemin aşırılığı, analizin yüzeyselliği ve sıkı zaman çizelgesi nedeniyle yüksek derecede karar riskiyle ilişkilendirilir. Uygulandı minimum set sistemin ilk ve sonraki her yinelemedeki ana işlevleri; işlevsellik her yinelemede genişletilir.

Uygulamalar

XP genellikle başarıya ulaşmak için gerçekleştirilmesi gereken 12 eylem (uygulama) dizisi ile karakterize edilir. iyi sonuç. XP uygulamaları, XP sürecinin kendisini tanımlamaz, ancak XP bu uygulamaları tanımlar; yani, uygulamaların gerçekleştirilmesi sonuçları garanti etmez. Uygulamaların hiçbiri temelde yeni değil, ancak XP bunları bir araya getiriyor.

Süreç planlama (planlama oyunu). Tüm ekip bir araya gelerek bir sonraki iterasyonda sistemin hangi özelliklerinin uygulanacağına dair ortak bir karara varılır. Özellikler kümesi kullanıcı hikayelerine göre belirlenir. Her özelliğin XP karmaşıklığı programcıların kendileri tarafından belirlenir.

Müşteriyle yakın etkileşim (geri bildirim, yerinde müşteri). Müşteri, XP ekibinin bir üyesi olmalıdır (tesis müşterisi). Kullanıcı hikayeleri yazıyor, belirli bir yinelemede uygulanacak hikayeleri seçiyor ve işle ilgili soruları yanıtlıyor. Müşterinin otomasyona tabi tutulan konu alanında uzman olması gerekmektedir. Müşteriden sürekli geri bildirim (feed-back) almak gerekir.

Sistem metaforu. İyi bir sistem metaforu, sınıfları ve değişkenleri basitçe adlandırmak anlamına gelir. İÇİNDE gerçek hayat bir metafor aramak son derece zor bir iştir; İyi bir metafor bulmak kolay değil. Her durumda, takımın tek tip adlandırma kurallarına sahip olması gerekir.

Basit mimari (basit tasarım). Sistemin herhangi bir özelliği mümkün olduğunca basit bir şekilde uygulanmalıdır. XP ekibindeki programcılar şu sloganla çalışıyor: "Gereksiz bir şey yok!" İlk en basit çalışma çözümü benimsenir, gerekli işlevsellik düzeyi uygulanır. şu an. Bu, programcının zamanından tasarruf etmesini sağlar.

Kodlama kuralları. Diğer uygulamaları desteklemek için kodlama standartlarına ihtiyaç vardır: paylaşılan kod sahipliği, eşli programlama ve yeniden düzenleme. Birleşik bir standart olmadan, bu uygulamaları gerçekleştirmek en azından daha zordur ve gerçekte tamamen imkansızdır: grup sürekli bir zaman sıkıntısı içinde çalışacaktır. Ayrıntılı standartlara gerek yoktur, yalnızca önemli şeylerin standartlaştırılması gerekir. XP'deki en önemli standardizasyon nesnelerinin belirlenmesi özneldir.

Yeniden düzenleme. Yeniden düzenleme optimizasyondur mevcut kod Kodu basitleştirmek için sürekli çalışmayı içeren basitleştirmeye doğru. Programcılar, kodu şeffaf tutarak ve kod öğelerini yalnızca bir kez tanımlayarak daha sonra düzeltmeleri gereken hataların sayısını azaltır. Sistemin her yeni özelliğini uygularken programcı, mevcut kodu basitleştirmenin mümkün olup olmadığını ve bunun yeni özelliğin uygulanmasına nasıl yardımcı olacağını düşünmelidir. Ayrıca, yeniden düzenleme tasarımla birleştirilemez: yeni kod oluşturuluyorsa yeniden düzenlemenin ertelenmesi gerekir.

Eşli programlama en ünlü XP uygulamalarından biridir. Tüm programcılar çiftler halinde çalışmalıdır: biri kodu yazar, diğeri izler. Bu nedenle, bir grup programcıyı tek bir yere yerleştirmek gerekir ki bunu müşterinin tesislerinde yapmak en kolay yoldur (gerekli tüm ekip üyeleri coğrafi olarak tek bir yerde bulunur); XP, dağıtılmamış programcı ve kullanıcılardan oluşan ekiplerde en başarılı şekilde çalışır.

Haftada 40 saat çalışma. Bir programcı günde 8 saatten fazla çalışmamalıdır. Fazla mesai ihtiyacı, bu özel gelişme alanındaki bir sorunun açık bir göstergesidir; Ayrıca müşteri XP'de fazla mesai için ödeme yapmaz. Fazla mesainin nedenlerini bulmak ve en kısa sürede ortadan kaldırmak temel kurallardan biridir.

Toplu kod sahipliği. XP ekibindeki her programcının sistemin herhangi bir yerindeki koda erişimi olmalı ve herhangi bir kodda değişiklik yapmalıdır. Zorunlu kural: Bir programcı değişiklik yaparsa ve bundan sonra sistem düzgün çalışmazsa, hataları düzeltmesi gereken kişi bu programcıdır. Aksi takdirde sistemin işleyişi tam bir kaosa benzeyecektir.

Sürümlerin sık sık değiştirilmesi (küçük sürümler). Minimum yineleme bir gün, maksimum yineleme bir aydır; Sürümler ne kadar sıklıkla yapılırsa, sistem kusurları da o kadar fazla tespit edilecektir. İlk sürümler, eksikliklerin ilk aşamalarda tespit edilmesine yardımcı olur, ardından sistemin işlevselliği genişletilir (aynı kullanıcı hikayelerine dayanarak). Kullanıcı ilk sürümden başlayarak geliştirme sürecine dahil olduğundan sistemi değerlendirir ve kullanıcı hikayesi artı geri bildirim sağlar. Buna dayanarak bir sonraki yineleme belirlenir: Yeni sürümün ne olacağı. XP'nin amacı kullanıcılara sürekli geri bildirim sağlamaktır.

Sürekli entegrasyon. Sistemin yeni parçalarının entegrasyonu mümkün olduğunca sık, en az birkaç saatte bir gerçekleşmelidir. Entegrasyonun temel kuralı şudur: Tüm testlerin başarıyla geçmesi halinde entegrasyon gerçekleştirilebilir. Testler başarısız olursa, programcının ya düzeltmeler yapması ve ardından sistemin bileşenlerini entegre etmesi ya da hiç entegre etmemesi gerekir. Bu kural katı ve açıktır - sistemin oluşturulan kısmında en az bir hata varsa entegrasyon gerçekleştirilemez. Sık entegrasyon, montaj için bir hafta harcamak yerine bitmiş sistemi daha hızlı elde etmenizi sağlar.

Test yapmak Diğer metodolojilerin çoğunun aksine, XP'de test yapmak en önemli bileşenlerden biridir. Aşırı bir yaklaşım, kod yazmadan önce testler yazmaktır. Her modülün bir birim testi olmalıdır - bu modülün testi; Böylece, XP'de regresyon testi gerçekleştirilir (geri dönüş testi, işlevsellik eklenirken “kalitenin bozulmaması”). Çoğu hata kodlama aşamasında düzeltilir. Testler programcıların kendileri tarafından yazılır; herhangi bir programcının herhangi bir modül için test yazma hakkı vardır. Bir diğer önemli prensip: Test, kodu belirler ve bunun tersi geçerli değildir (bu yaklaşıma test odaklı geliştirme denir), yani, tüm testler başarılı bir şekilde geçerse bir kod parçası depoya konulur, aksi takdirde bu kod değişikliği iptal edilir. Reddedilmiş.

Dolayısıyla XP, kaynak kodu dışında geliştirme sürecinin tüm eserlerini son derece önemsemiyor. XP süreci son derece gayri resmidir ancak yüksek düzeyde öz disiplin gerektirir. Bu kurala uyulmazsa XP anında kaotik ve kontrol edilemeyen bir sürece dönüşür. XP, programcıların çok sayıda rapor yazmasını ve çok sayıda model oluşturmasını gerektirmez. XP'de her programcı, sorumluluklarını profesyonelce ve büyük bir sorumlulukla yerine getiren nitelikli bir çalışan olarak kabul edilir. Takımda bu yoksa, XP'yi tanıtmak kesinlikle anlamsızdır; önce takımı yeniden inşa etmeye başlamak daha iyidir. Geliştirme riski yalnızca XP'nin ideal olduğu bir ekipte azalır; diğer tüm durumlarda XP, ticari riskleri azaltmak için banal insan faktörü dışında başka hiçbir yöntem olmadığından, en yüksek risk derecesine sahip geliştirme sürecidir. , XP'de.

Metodolojiyi kullanmanın mevcut riskleri

Dikkate alınıp önlenmediği takdirde bir projeyi başarısızlığa uğratabilecek XP risklerini vurgulamakta fayda var.

Planlama oyunu. Programcılar yalnızca belirli bir yinelemede müşteri tarafından seçilen özellikler için gerekli olan işlevleri uygular. Bu kararın bir sonucu olarak, sistemin gelişimi perde arkasında kalıyor ve bunun sonucunda geliştirme sırasında "taslaklar" oluşturmaya ve kodu yeniden yazmaya ihtiyaç duyuluyor.

Müşterinin sürekli katılımı (yerinde müşteri). Sistem üzerinde çalışma süresi boyunca müşteri temsilcisi geliştirme ekibinde yer alır ve bu kişi veya ekibin niteliklerine yönelik gereksinimler oldukça yüksektir. Müşteri uzman düzeyinde personel sağlamayı kabul etmezse proje en yüksek risk grubuna girer.

Metafor. Genel form sistem, müşterinin ve programcıların birlikte üzerinde çalıştığı bir metafor veya metafor seti kullanılarak tanımlanır. Bir süreç günlüğe kaydedilmezse ve adlandırma yapısı standartlaştırılmazsa süreç sonsuza kadar yinelenebilir hale gelebilir.

Basit mimari (basit tasarım). Geliştirilen sistem, zamanın her anında tüm testleri gerçekleştirir ve programcı tarafından tanımlanan tüm ilişkileri destekler, kod kopyaları yoktur ve mümkün olan minimum sayıda sınıf ve yöntemi içerir. Bu kural kısaca şu şekilde ifade edilebilir: “Her düşünceyi bir kez ve yalnızca bir kez formüle edin.” Bu prensip kod yazma hızıyla çelişmektedir. Yüksek öz disiplin ve katı kod standartları olmadığında sistem anında risk altına girer.

Sürümlerin sık sık değiştirilmesi (küçük sürümler). Sistem, ortaya çıkan tüm sorunların nihai çözümü beklenmeden, uygulamanın başlamasından sonraki birkaç ay içinde devreye alınır. Yeni sürümlerin yayınlanma sıklığı günlükten aya kadar değişebilir. Böyle bir dönemde az çok karmaşık bir bileşeni test etmek imkansızdır; müşteri aslında bir beta testçisi gibi davranır. Sürekli güvenilir çalışma gerektiren sistemler (7/24 gereklilik olarak adlandırılır) risk altındadır.

Sistemin yeniden düzenlenmesi. Sistem mimarisi sürekli gelişmektedir. Mevcut proje dönüştürülürken tüm testlerin doğru yapılması sağlanır. Ekstrem programlama, sistemin bir kısmını yeniden yapmanın her zaman mümkün olduğu gerçeğinden yola çıkar. özel maliyetler. Ancak pratik çoğu zaman bunun tersini gösterir.

Sürekli entegrasyon. Yeni kod birkaç saat içerisinde mevcut sisteme entegre edilir. Daha sonra sistem tek bir bütün haline getirilerek tüm testler gerçekleştirilir. Bunlardan en az birinin doğru şekilde yapılmaması durumunda yapılan değişiklikler iptal edilir. Bu durumda, yalnızca yerel hataları değil, aynı zamanda yanlış koddan kaynaklanan hataları da tam olarak kimin düzelteceği her zaman açık değildir. Bu aşamada karmaşık testlerin yapılması planlanmamaktadır; Ayrıca bir hata tespit edilse bile değişiklikler kaydedilir.

Çiftler programı. Tüm proje kodları iki kişilik gruplar tarafından tek bir yazılım kullanılarak yazılır. iş yeri. Bu durumda insan faktörü belirleyici bir rol oynuyor: çift ya çalışıyor ya da çalışmıyor, üçüncü bir seçenek yok.

40 saatlik haftalar. Fazla mesainin hacmi bir çalışma haftasını geçemez. Çok sık meydana gelen münferit fazla mesai örnekleri bile, acil müdahale gerektiren ciddi sorunların işaretidir. Aşırı programlama kullanma pratiğinin gösterdiği gibi (destekçiler tarafından verilen bir dizi olumlu örneğe rağmen) Bu method), bu yaklaşımla fazla mesai istisna değil kuraldır ve bu durumda sorunlarla mücadele sürekli bir olgudur. Ürünün mevcut ham versiyonunun daha az ham olan başka bir versiyonla değiştirilmesi döneminde yoğunlaşır. Müşteri, sistem iyileştirmesine ilişkin tutarlı kanıtlar alamazsa ciddi bir sorununuz var demektir.

Kolektif mülkiyet. Her programcı, gerekirse sistemdeki kodun herhangi bir bölümünü istediği zaman iyileştirme fırsatına sahiptir. Kaynak kodu kontrol standardı olmadan geliştirme süreci tamamen kontrol edilemez hale gelir.

Çalışma alanını açın. Geliştirme ekibi, daha küçük odalarla çevrili büyük bir odada bulunuyor. Çalışma alanının merkezinde, programcı çiftlerinin çalıştığı bilgisayarlar kurulur (ve yukarıdaki ilkelere uygun olarak, geliştirme sürecine çok aktif bir şekilde dahil olduğu için tüm bunlar müşterinin tesislerinde bulunmalıdır). Coğrafi olarak dağınık bir geliştirici ve müşteri grubu varsa, proje etkileşim protokolünün standartlaştırılmasını gerektiriyor (hızlı, güvenilir, sorunsuz) veya risk grubuna giriyor.

Testler. Programcılar her zaman birim testleri yazarlar. Birlikte ele alındığında bu testlerin doğru şekilde çalışması gerekir. Yineleme aşamaları için müşteriler, doğru çalışması için de gerekli olan fonksiyonel testleri yazar. Ancak pratikte bu her zaman başarılamaz. Doğru kararı vermek için, bilinen bir kusuru olan bir sistemi teslim etmenin ne kadara mal olacağını anlamanız ve bunu, bu kusurun giderilmesini geciktirmenin maliyetiyle karşılaştırmanız gerekir. Programcıların kendileri tarafından yazılan testler (özellikle fazla mesai yaparken) tam olarak işlevsel değildir ve çok kullanıcılı çalışmanın özelliklerini kesinlikle hesaba katmaz. Geliştiricilerin genellikle daha gelişmiş testler için yeterli zamanı yoktur. Bu sorun, insan faktörünün büyük rolü ile ilişkili olan kontaktörlerin belirli bir süre kullanılmasıyla çözülür: çünkü teknik döküman başlangıçta yoktur, daha sonra bilgi programcılar arasındaki iletişim yoluyla iletilir. Ancak elbette baştan sona her şeyle aynı kişilerin ilgileneceği şekilde bir geliştirme sistemi kurmak mümkün. Yukarıdakilere, sistem testinin bileşenlerin (birimlerin) test edilmesiyle sınırlı olmadığını eklemek gerekir; Aralarındaki etkileşim testleri daha az önemli değildir ve aynı durum güvenilirlik testleri için de geçerlidir. Bununla birlikte Extreme Programlama yöntemi test oluşturmayı içermez. bu sınıfın. Bu, bu tür testlerin kendilerinin oldukça karmaşık kodları temsil edebilmesiyle açıklanmaktadır (bu özellikle sistemin gerçek çalışmasını taklit eden testler için geçerlidir). Bu teknoloji aynı zamanda başka bir önemli test sınıfını da hesaba katmaz - işlenen bilgi hacmi arttığında sistem davranışı testleri. Sürüm değişikliklerinin yüksek sıklığıyla, böyle bir testi gerçekleştirmek teknolojik olarak imkansızdır çünkü uygulanması, örneğin bir hafta içinde istikrarlı ve değişmemiş proje kodu gerektirir. Bu durumda, ya bileşenlerin gelişimini askıya almanız ya da test sırasında projenin değişmeden kalacak, diğeri değişecek paralel bir versiyonunu oluşturmanız gerekecektir. Daha sonra kod birleştirme sürecinden geçmeniz gerekecek. Ancak bu durumda, aşırı programlama yöntemleri, belirli değişiklikler altında sistemin davranışını tahmin etmeye izin veren araçların geliştirilmesini sağlamadığından, testin yeniden oluşturulması gerekecektir. XP bu sorunları aynı insan faktörü ve öz disiplinle çözmeyi öneriyor.

Kurallardan başka bir şey değil. Extreme programlama teknolojisini kullanarak çalışan ekibin üyeleri belirtilen kurallara uymayı taahhüt eder. Ancak bunlar kurallardan başka bir şey değildir ve üyeleri yapılan değişiklikler konusunda prensipte anlaşmaya varırsa ekip bunları herhangi bir zamanda değiştirebilir. Bu prensip büyük ölçüde insan faktörüne bağlıdır; Geliştirme disiplininin ihlali, son teslim tarihlerinin kaçırılmasına neden olur ve sonuç olarak projenin çökmesine yol açar.

Sonuç olarak, ciddi ve sık değişen proje gereksinimlerine potansiyel olarak son derece uyarlanabilir, ancak aynı zamanda bir takım temel eksikliklerden arınmış olmayan ve büyük ölçüde insan faktörüne bağımlı olan bir yöntem elde ediyoruz.

Bu nedenle aşırı programlama yönteminin uygulanmasının sonucu ya aşırı iyi ya da aşırı kötü olabilir.

Extreme Programming veya XP, eXtreme Programming esnek bir yazılım geliştirme metodolojisidir. Diğer çevik metodolojiler gibi belirli araçlara, süreçlere ve rollere sahiptir. Her ne kadar XP'nin yazarı yeni bir şey icat etmemiş olsa da, çevik gelişimin en iyi uygulamalarını alıp bunları maksimuma kadar güçlendirdi. Bu yüzden programlamaya ekstrem denir.

Yöntemin yazarı Amerikalı geliştirici Kent Beck'tir. 90'lı yılların sonlarında Chrysler Kapsamlı Ücretlendirme Sistemi projesini yönetti ve burada aşırı programlama uygulamalarına öncülük etti. Deneyimini ve yarattığı konsepti 1999 yılında yayınlanan Extreme Programming Understanded kitabında anlattı. Bunu XP uygulamalarını detaylandıran diğer kitaplar izledi. Ward Cunningham, Martin Fowler ve diğerleri de metodolojinin geliştirilmesinde yer aldılar.

XP, geçerli olması bakımından diğer çevik metodolojilerden farklıdır. sadece yazılım geliştirme alanında. Scrum, kanban, yalın gibi başka bir işte veya günlük hayatta kullanılamaz.

XP metodolojisinin amacı, bir yazılım ürününe yönelik sürekli değişen gereksinimlerle başa çıkmak ve geliştirme kalitesini artırmaktır. Bu nedenle XP karmaşık ve belirsiz projeler için çok uygundur.

XP metodolojisi dört süreç etrafında inşa edilmiştir: kodlama, test etme, tasarım ve dinleme. Ek olarak Extreme Programming basitlik, iletişim, geri bildirim, cesaret ve saygı değerlerine sahiptir.

1. Bütün ekip

XP kullanan tüm proje katılımcıları tek bir ekip olarak çalışır. Müşterinin bir temsilcisini içermelidir, gerçek olması daha iyidir son kullanıcıürün ve iş anlayışı. Müşteri, ürüne ilişkin gereksinimleri ortaya koyar ve işlevselliğin uygulanmasına öncelik verir. İş analistleri ona yardımcı olabilir. Uygulama tarafında ekip, geliştiricileri ve test uzmanlarını, bazen ekibe rehberlik eden bir koçu ve ekibe kaynak sağlayan bir yöneticiyi içerir.

2. Planlama oyunu

XP'de planlama iki aşamada gerçekleştirilir: sürüm planlaması ve yineleme planlaması.

Sürüm planlaması sırasında programlama ekibi, bir sonraki sürüm için, yani 2-6 ay sonra hangi işlevselliği almak istediğini öğrenmek için müşteriyle buluşur. Müşteri gereksinimleri genellikle belirsiz olduğundan, geliştiriciler bunları belirler ve bunları parçalara ayırır; bunların uygulanması bir günden fazla sürmez. Müşterinin, ürünün çalışacağı çalışma ortamını anlaması önemlidir.

Görevler kartlara yazılır ve müşteri önceliklerini belirler. Daha sonra geliştiriciler her görevin ne kadar zaman alacağını tahmin ediyor. Görevler tanımlanıp değerlendirildiğinde müşteri belgeleri inceler ve işin başlaması için onay verir. Projenin başarısı için müşterinin ve programlama ekibinin aynı alanda oynaması kritik öneme sahiptir: Müşteri, bütçe dahilinde gerçekten ihtiyaç duyulan işlevselliği seçer ve programcılar, müşterinin gereksinimlerini kendi yetenekleriyle yeterince karşılaştırır.

XP'de, ekibin yayın tarihine kadar tüm görevleri tamamlayacak zamanı yoksa sürüm geri çekilmez, ancak müşteri için en az önemli olan işlevsellik kısmı kesilir.

Yineleme planlaması gerçekleştirilir iki haftada bir, bazen daha fazla veya daha az sıklıkla. Müşteri her zaman mevcuttur: Bir sonraki yinelemenin işlevselliğini belirler ve ürün gereksinimlerinde değişiklikler yapar.

3. Sık sık sürüm yayınlanıyor

XP'de sürümler sık ​​sık yayınlanır, ancak çok az işlevselliğe sahiptir. İlk olarak, az miktarda işlevselliğin test edilmesi ve tüm sistemin işlevselliğinin sürdürülmesi kolaydır. İkinci olarak, müşteri her yinelemede iş değeri taşıyan bir işlevsellik parçası alır.

4. Kullanıcı testleri

Müşteri, bir sonraki ürün özelliğinin işlevselliğini kontrol etmek için otomatik kabul testlerini kendisi tanımlar. Ekip bu testleri yazar ve bunları bitmiş kodu test etmek için kullanır.

5. Toplu kod sahipliği

XP'de herhangi bir geliştirici herhangi bir kod parçasını düzenleyebilir, çünkü... Kod, yazarına atanmamıştır. Tüm ekip kodun sahibidir.

6. Sürekli Kod Entegrasyonu

Bu, yeni kod parçalarının hemen sisteme yerleştirildiği anlamına gelir; XP ekipleri her birkaç saatte bir veya daha sık yeni bir yapı yükler. İlk olarak, nasıl olduğu hemen anlaşılıyor son değişiklikler sistemi etkiler. Yeni bir kod parçası bir şeyi bozarsa, hatayı bulmak ve düzeltmek bir hafta sonrasına göre çok daha kolaydır. İkincisi, ekip her zaman birlikte çalışır En son sürüm sistemler.

7. Kodlama Standartları

Herkes kodun sahibi olduğunda, kodun tek bir profesyonel tarafından yazılmış gibi görünmesi için tutarlı tasarım standartlarını benimsemek önemlidir. Kendi standartlarınızı geliştirebilir veya hazır olanları benimseyebilirsiniz.

8. Sistem metaforu

Sistem metaforu, ekip arasında ortak bir vizyon yaratmak için sistemin tanıdık bir şeyle karşılaştırılmasıdır. Genellikle sistem metaforu, mimariyi tasarlayan ve sistemi bir bütün olarak hayal eden kişi tarafından düşünülür.

9. Sabit tempo

XP ekipleri sabit bir tempoyu korurken maksimum üretkenlikle çalışır. Aynı zamanda aşırı programlama, fazla mesaiye karşı olumsuz bir tavır sergiliyor ve haftada 40 saatlik çalışmayı teşvik ediyor.

10. Test odaklı geliştirme

Metodolojinin en zor uygulamalarından biri. XP'de testler, test edilmesi gereken kodu yazmadan ÖNCE programcıların kendileri tarafından yazılır. Bu yaklaşımla her bir işlevsellik parçası %100 testlerle karşılanacaktır. Birkaç programcı kod deposuna kod yüklediğinde birim testleri hemen çalıştırılır. Ve HEPSİ çalışmalı. O zaman geliştiriciler doğru yönde ilerlediklerinden emin olacaklardır.

11. Eşli programlama

İki geliştiricinin tek bir bilgisayarda tek bir ürün işlevi üzerinde çalıştığını hayal edin. Bu, en tartışmalı XP uygulaması olan çift programlamadır. Eski atasözü "bir kafa iyidir, iki kafa daha iyidir" yaklaşımın özünü mükemmel bir şekilde göstermektedir. Bir sorunu çözmek için iki seçenekten en iyisi seçilir, kod anında optimize edilir ve hatalar oluşmadan yakalanır. Sonuç olarak, iki geliştiricinin iyi derecede bilgili olduğu temiz bir kodumuz var.

12. Basit tasarım

XP'de basit tasarım, gelecekteki işlevleri tahmin etmeye çalışmadan yalnızca şu anda ihtiyacınız olanı yapmak anlamına gelir. Basit tasarım ve sürekli yeniden düzenlemenin sinerjik bir etkisi vardır; kod basit olduğunda optimize edilmesi kolaydır.

13. Yeniden Düzenleme

Yeniden düzenleme, bir sistemin tasarımını yeni gereksinimleri karşılayacak şekilde sürekli iyileştirme sürecidir. Yeniden düzenleme, yinelenen kodu kaldırmayı, uyumu artırmayı ve birleştirmeyi azaltmayı içerir. XP sürekli yeniden düzenleme gerektirir, bu nedenle kod tasarımı her zaman basit kalır.

XP'nin Avantajları ve Dezavantajları

XP metodolojisi, bunu ekiplerine hiç uygulayamayanlar tarafından birçok tartışmaya ve eleştiriye neden oluyor.

Ekstrem Programlamanın faydaları, ekip XP uygulamalarından en az birini tam olarak kullandığında anlam kazanır. Peki denemeye değer olan şey:

• Müşteri, geliştirmenin başlangıcında nihai şeklini tam olarak hayal etmese bile, tam olarak ihtiyaç duyduğu ürünü alır.
• Ekip, basit kod tasarımı, sık planlama ve sürümler yoluyla hızlı bir şekilde kod değişiklikleri yapar ve yeni işlevler ekler
• sürekli test ve sürekli entegrasyon nedeniyle kod her zaman çalışır
• ekip kodun bakımını kolayca yapar, çünkü tek bir standarda göre yazılmıştır ve sürekli olarak yeniden düzenlenir
• Eşli programlama, yeniden çalışma eksikliği, müşterinin ekipte bulunması nedeniyle hızlı geliştirme hızı
• yüksek kod kalitesi
• kalkınmayla ilişkili riskler azalır çünkü Projenin sorumluluğu eşit olarak dağıtılır ve bir ekip üyesinin ayrılışı/gelişi süreci bozmaz
• geliştirme maliyetleri daha düşüktür çünkü Ekip, dokümantasyon ve toplantılar değil, kod odaklıdır

Tüm avantajlara rağmen XP her zaman çalışmaz ve bir takım zayıf yönleri vardır. Yani aşırı programlamanın dezavantajları:

• projenin başarısı müşterinin katılımına bağlıdır ve bunu başarmak o kadar da kolay değildir
• Bir projeye harcanan zamanı tahmin etmek zordur çünkü... başlangıçta kimse bilmiyor tam liste Gereksinimler
• XP'nin başarısı büyük ölçüde programcıların seviyesine bağlıdır; metodoloji yalnızca kıdemli uzmanlarla çalışır
• yönetimin ikili programlamaya karşı olumsuz bir tutumu var, neden bir programcı yerine iki programcıya ödeme yapması gerektiğini anlamıyor
• Programcılarla düzenli toplantılar müşteriler için pahalıdır
• çok fazla kültürel değişim gerektiriyor
• yapı ve dokümantasyon eksikliği nedeniyle büyük projelere uygun değil
• Çünkü Çevik metodolojiler işlevsel odaklıdır; ürün kalitesine yönelik işlevsel olmayan gereksinimlerin kullanıcı hikayeleri biçiminde tanımlanması zordur.

XP İlkeleri

Kent Beck ilk kitabında Extreme Programlamanın ilkelerini dile getirdi: basitlik, iletişim, geri bildirim ve cesaret. Kitabın yeni baskısında beşinci ilkeyi ekledi: saygı.

1. Sadelik

XP'de geliştirme, mevcut işlevsellik ihtiyacını karşılayacak en basit çözümle başlar. Ekip üyeleri yalnızca şu anda yapılması gerekenleri dikkate alır ve yarın, bir ay sonra veya hiçbir zaman ihtiyaç duyulmayacak olan kod işlevselliğini koymaz.

2. İletişim

XP'de geliştiriciler arasındaki iletişim dokümantasyon yoluyla değil canlı olarak gerçekleştirilir. Ekip birbirleriyle ve müşteriyle aktif olarak iletişim kurar.

3. Geribildirim

XP'de geri bildirim aynı anda üç yönde uygulanır:

1. Modüllerin sürekli testi sırasında sistemden geri bildirim
2. müşteriden gelen geri bildirim, çünkü ekibin bir parçası ve kabul testlerinin yazımına katılıyor
3. Geliştirme süresine ilişkin planlama sırasında ekipten geri bildirim.

4. Cesaret

Bazı aşırı programlama teknikleri o kadar sıra dışıdır ki, cesaret ve sürekli öz kontrol gerektirirler.

5. Saygı

Extreme Programming'de saygı, takıma saygı ve kendine saygı açısından ele alınır. Ekip üyeleri derlemeyi, birim testlerini bozacak veya meslektaşlarının çalışmalarını yavaşlatacak değişiklikleri yüklememelidir. Herkes bunun için çabalıyor en yüksek kalite kod ve tasarım.

XP metodolojisini ve iş sürecini uygulamaya yönelik algoritma

Beck Kent, bir projedeki sorunları çözmek için XP'nin uygulanmasını öneriyor. Ekip en acil sorunu seçiyor ve Ekstrem Programlama uygulamalarından birini kullanarak çözüyor. Daha sonra daha fazla pratik yaparak bir sonraki probleme geçin. Bu yaklaşımla, sorunlar XP kullanımı için motivasyon görevi görür ve ekip, metodolojinin tüm araçlarına yavaş yavaş hakim olur.

XP'yi mevcut bir projeye uygulamak için aşağıdaki alanlarda yavaş yavaş tekniklerine hakim olmanız gerekir:

• test yapmak
• tasarım
• planlama
• yönetmek
• gelişim

Test yapmak.

Ekip, yeni kod yazmadan ÖNCE testler oluşturur ve eski kodu kademeli olarak yeniden işler. Eski kod için testler gerektiği gibi yazılır: yeni işlevsellik eklemeniz, bir hatayı düzeltmeniz veya eski kodun bir kısmını yeniden işlemeniz gerektiğinde.

Tasarım.

Ekip, genellikle yeni işlevsellik eklemeden önce eski kodu kademeli olarak yeniden düzenler. Testlerde olduğu gibi, eski kodun yeniden düzenlenmesi yalnızca gerektiğinde yapılır. Aynı zamanda ekip, kodun yeniden işlenmesi için uzun vadeli hedefler oluşturmalı ve bu hedeflere yavaş yavaş ulaşmalıdır.

Planlama.

Ekibin müşteriyle yakın etkileşime geçmesi gerekiyor. Bu aşamada geliştiricilerle aynı takımda çalışmanın avantajlarını kendisine aktarmak ve takıma entegre etmek önemlidir.

Yönetmek.

XP'ye geçişte yöneticilerin rolü, tüm ekip üyelerinin yeni kurallara göre çalışmasını sağlamaktır. Proje yöneticisi, yeni ortamda iş ile başa çıkamayan bir ekip üyesinden ne zaman ayrılacağına veya yeni bir tane bulup onu işe uygun şekilde entegre edeceğine karar verir.

Gelişim.

Geliştirmedeki dönüşümler, programlama için iş istasyonlarının çiftler halinde düzenlenmesiyle başlar. Bir sonraki zorluk, geliştiriciler için ne kadar zor olursa olsun, çoğu zaman çiftler halinde programlama yapmaktır.

XP metodolojisine göre çalışan bir projede süreç şu şekilde yapılandırılmıştır:

XP'yi kim kullanıyor?

Versionone tarafından 2016 yılında yapılan bir araştırmaya göre, çevik şirketlerin yalnızca %1'i ekstrem programlamayı saf haliyle kullanıyor. Diğer %10'luk kısım ise hibrit scrum ve XP metodolojisi kullanarak çalışıyor.

İlginç bir şekilde, XP saf haliyle en yaygın metodolojiden uzak olsa da uygulamaları çevik metodolojiler üzerinde çalışan şirketlerin çoğunluğu tarafından kullanılıyor. Bu, aynı çalışmanın verileriyle kanıtlanmıştır:

XP kullanan takımlar hakkında bilgi bulmak kolay değil ama başarılarının sebebinin bu metodoloji olduğunu reklam edenler var. Extreme Programlamaya bir örnek Pivotal Software, Inc.'dir.

Önemli Yazılım A.Ş.

dayalı iş analizi için yazılım geliştiren Amerikan yazılım şirketi Büyük veri ve danışmanlık hizmeti vermektedir. Pivotal ürünler Ford, Mercedes, BMW, GAP, Humana, büyük bankalar, devlet kurumları, sigorta şirketleri vb. tarafından kullanılmaktadır.

Pivotal, çevik metodolojilerin mümkün olan tek yöntem olduğunu savunuyor. modern gelişme. Esnek metodolojilere yönelik tüm seçenekler arasından şirket, müşteriler ve programlama ekipleri için bir kazan-kazan yaklaşımı olarak XP'yi seçti. Her iş günü, hareket halindeyken yapılan bir toplantıyla başlar ve tam olarak saat 18:00'de sona erer; fazla mesai yoktur. Pivotal, oyun planlamayı, eşli programlamayı, sürekli testi, sürekli entegrasyonu ve diğer XP uygulamalarını kullanır. Birçok uygulama için kendi yazılımları vardır.

Aşırı Programlama,
Ekstrem Programlama: Planlama,
Ekstrem Programlama: Test Odaklı Geliştirme / Kent Beck

Metodolojinin yaratıcısı Kent Beck'ten ekstrem programlama üzerine. XP konseptini örneklerle anlatan ve avantajlarını gerekçelendiren ilkiyle başlayın. Daha sonra yazar, bireysel XP uygulamalarını ayrıntılı olarak anlattığı birkaç kitap daha yayınladı.

Yeniden Düzenleme: Mevcut Kodun İyileştirilmesi / Martin Fowler

Ekstrem programlama: süreç formülasyonu. İlk adımlardan acı sona / Ken Auer, Roy Miller

Extreme Programming temiz ve bakımı kolay kodlar için çaba gösterdiğinden, kitap listesi size nasıl daha iyi programlama yapacağınızı öğreten tüm yayınları içerir.

Bir ekipte XP'yi uygulamaya yönelik uygulamalar

XP metodolojisini kullanan projeler üzerinde çalışan ekipler, çevik projeler için görev yöneticilerini ve hizmetleri kullanır. Piyasada bu tür pek çok ürün var, birkaç örneğe bakacağız.

Ücretsiz ve açık kaynak görev yöneticisi. Ana işlevler: aynı anda birden fazla proje üzerinde çalışma, esnek görev yönetimi sistemi, Gantt şeması, zaman kontrolü, belgelerle çalışma, e-posta yoluyla görevler oluşturma vb.

Basit, kullanışlı hizmet işbirliği projeler üzerinde. Görev yöneticisi, mesaj panosu, yerleşik sohbet, dosya depolama alanı ve takvim içerir

Jira

Çevik projelerin geliştiricileri için özel olarak tasarlanmış güçlü bir hizmet. Bir hata izleyiciyi ve proje yönetimi hizmetini birleştirir. Birçok işlevin yanı sıra diğer hizmetlerle senkronizasyon. Farklı büyüklükteki ekipler için çözümler.

Projeler üzerinde çalışmak için. Görevleri belirlemenize ve yürütme sürecini kontrol etmenize, bir görev üzerinde birbirinizle yazışmanıza, filtreler ayarlamanıza, zaman ve mali harcamaları hesaba katmanıza ve dosyalarla çalışmanıza olanak tanır.

Karar

Extreme Programming, basit bir mimariyle yüksek kaliteli, uygulanabilir koda odaklanan esnek bir metodolojidir. Amacı, projelerdeki belirsizlik düzeyini azaltmak ve ürün gereksinimlerindeki değişikliklere gerçekten esnek bir şekilde yanıt vermektir.

Bu metodoloji yalnızca sahaya yöneliktir. yazılım geliştirme başka bir işe uyarlanamaz.

Bu, uygulanması en zor metodolojilerden biridir çünkü on üçe kadar uygulama içerir!

Çok az şirket saf XP üzerinde çalışma riski taşır ancak geliştirme uygulamaları çevik projelerde en popüler olanlardır. Ve bu onların etkililiği lehine güçlü bir argümandır.

Hiç kimse sizi XP'yi ya hep ya hiç esasına göre uygulamaya zorlamıyor. Günün sonunda çevik metodolojilerin uygulamalarında esnek olması ve belirli bir ekibin ve projenin ihtiyaçlarına göre uyarlanması gerekir.