Çevik metodolojiler kullanarak yazılımı yeniden yazma

Agile yöntemlerini kullanarak tüm bir uygulamayı yeniden yazmanız gerektiğini varsayalım, nasıl yapardınız?

Sanırım mevcut sisteminizin davranışına dayanarak çok sayıda kullanıcı hikayesi yazabilirsiniz. Ve sonra bunları küçük iterasyonlarda uygulayın. Ancak bu, ÖN YUKARI gereksinimlerimiz olduğu anlamına gelmez ??

Ayrıca, ne zaman yayınlamaya başlayacaksınız? Agile, erken ve sık sık bırakmamız gerektiğini söylüyor, ancak tüm yeniden yazma işlemi tamamlanmadan önce bırakmanın pek bir anlamı yok.

Üst düzey destanlara ayırın. Uygulamanın her bir fonksiyonel alanını, her seferinde bir adım atın.

Bir destanı bir grup öyküye (kullanılabilir parçalar - uygulamayı geliştiren herhangi bir şey) ayırın ve mevcut bir uygulamanız yoksa, tek bir istisna dışında bunları yönetin: Mümkünse, bu tek işlevselliği orijinal uygulamanın bir parçası olarak ya da onun yanında uygulayabilir.

Agilistler "erken ve sıklıkla serbest bırak" dediğinde, bu mutlaka üretim anlamına gelmez. Mevcut bir uygulamanın yerini alacaksanız, sık sık yayınlamak için bir hazırlama alanı kullanmalı ve kullanıcılarınızın sistemi orada test ettiğinden emin olmalısınız. Bu, onlara bir sonraki iş parçasına öncelik vermeleri ve üretime bıraktığınız hiçbir şeyin ürünü amorti etmemesini sağlamak için yer verecektir.

Bir bileşeni üretime bıraktıktan sonra bir sonrakine geçin.

Biz sadece böyle bir deneyim (scrum ürün sahibi olarak bana) var. Serbest bırakılabilir bir şeye ulaşmak iki yılımızı aldı. Ama yine de, çevik bize birçok fayda sağladı.

Birincisi: Tam bir yeniden yazma, doğası gereği çevik değildir. Bunun yerine, mevcut ürünü parça parça yeniden düzenlemeyi düşünmelisiniz. Bu başka bir soruda tartışıldı. Diyelim ki bir yeniden yazma olmalı.

Sonra gerçekten, mevcut ürünün ilgili tüm kullanım durumlarını kapsayan bir geri günlüğü ile başlarsınız. Ama lütfen yazı yazma olarak yaklaşmayın. Bu çok fazla ayrıntı olurdu. Tam olmalıdır (aksi takdirde sürüm planlaması yapamazsınız). Ve çok ayrıntılı olmamalıdır (aksi takdirde özellikleri önceden yazıyorsunuz). İşte böyle yaklaştık:

• eski ürün kullanıcılarını sınıflandırır. Eski ürünün sadece küçük bir kısmına ihtiyaç duyan kullanıcıları belirleyin ve yine de faydalı bir şey elde edin. İlk destanlarınızı tanımlarlar.

• Ardından başka bir kullanıcı kategorisinin yeni ürüne geçmesine izin verecek destanlar ekleyin. Vb. Tüm kullanıcıları kapsayan bir geri kaydınız olana kadar.

• büyük olasılıkla, bu destanların daha fazla bölünmeye ihtiyacı olacaktır. Mümkünse, her bir parçanın yine de bir değeri olacak şekilde bölünmeye çalışın. Bu mümkün değilse, en azından her parçanın gösterilebildiğinden emin olun.

• 20-50 destanınız olduğunda, ekibin bunları tahmin etmesini sağlayın.

• en çok destanı takımın bir sprint içinde mümkün olduğuna inandığı Kullanıcı Hikayeleri'ne bölün. Bunu henüz tüm destanlar için yapma, sadece üstte olanlar için. Gerisini bölmek için bolca zamanınız olacak.

Harici olarak ne zaman serbest bırakılır! Bu bir ticari karardır. En azından bu yaklaşım size belirli kullanıcı kategorilerinden daha önce yayın yapma fırsatı verir. Yönetim, görünüşte hiç bitmeyen bu proje hakkında endişelenirse kullanışlı olabilir.

Yapabiliyorsanız Şimdi Bırakın

Kodu ne zaman yayınlamaya başladığınızla ilgili sorunuz harika. İki şartın geçerli olduğunu düşünüyorum. Birincisi, "yeterince iyi kaliteye" sahip olmanız, ikincisi ise bir MVP (minimum uygulanabilir ürün) gereksinimlerini karşıladığınızdan.

Roma (ve Çevik) Bir Günde İnşa Edilmedi

Belki de ilk günden devralmak için anahtar teslim çevik bir ekiple hazırsınız demektir. Çoğu kuruluş için, bir ekip oluşturma, eğitim, yeniden yapılandırma ve olağan biçimlendirme, fırtına, norming, performans döngüsü çalışmaları ve masrafları vardır. Riskler ve maliyetler konusunda hazırlıklı olun, gerçekçi beklentiler belirlemeye dikkat edin ve yaklaşımınızı savunmak için hazırlıklı olun.

Yeniden Kullanım Önyükleyicisi Olun

Füzyon gücü gibi, kodun yeniden kullanımı ekonomik sorunlarımızın gelecekteki çözümü olacaktır ve her zaman olacaktır . Benim düşüncem, geliştiricilerin genellikle yeniden kullanmaya inandıklarını söylediklerini, ancak başka birinin zaten yaptıklarını inşa ettikleri türden ziyade, yeni bir çerçeve oluşturduktan sonra başlayan türden yeniden kullanımdır. Birisi başkasının temeli üzerine inşa etmeye karar verene kadar bu nasıl işler? En iyi ihtimalle, takım liderliğinin değiştiği her birkaç yılda bir yeniden yazma anlamına gelir.

Neden Erken Ve Sık Bırakmalıyız?

Erken bırakmak ve çoğu zaman birçok nedenden dolayı bir mantradır. Ürünün ne olması gerektiği konusundaki tartışmalarımıza hayat verir, nerede olduğumuzu gerçeğe dönüştürür ve bize yinelemeli / artımlı değişiklikler için bir temel sağlar. Sürümlerin hızı, çeviklik için neredeyse değişmez, fark, sürümleri kimin alacağıdır (müşteri taşıyıcıları veya son kullanıcılar). Çeviklikten önce, bakımın yazılım sistemlerinin maliyetinin% 60'ını oluşturduğu tahmin ediliyordu. Bu, yöneticiler ve diğerleri için çok fazla bir şaşkınlık kaynağıdır, bazıları ürün sürümünün yazılımın öleceği yerdir. Onlar için, piyasaya sürüldükten sonraki her şey, bir kez ödediği bir ürünü düzeltmek için yeniden çalışmak ve ödeme yapmaktır.

Ön sürüm doğal değil

Kent Beck, ön sürümün yazılım ürünleri için doğal olmayan bir durum olduğunu yazıyor. Kesinlikle elverişsiz bir zamandır çünkü müşterinizin olmadığı ve sizin için ödeme yapan ürün yerine ürün için ödeme yaptığınız bir zamandır.

Önceki Ekibi Eleştirmeyin

Projenin kahramanları ve kurtuluşu olarak yeniden yazmayı devralan geliştiricileri kursa da, önceki takımın başarılarını eleştirmenin bir maliyeti olduğunu düşünüyorum.

• Birincisi, insanların önceki takım hakkında kendi düşüncelerini oluşturmalarına izin verirseniz, gerçek göreviniz için daha fazla zamanınız ve enerjiniz olur.
• Bir önceki ekibin üyeleriyle, hem geliştiriciler hem de ürün yöneticileri, proje yöneticileri veya müşteriler gibi paydaşlarla çalışmanız gerekirse garip olacaktır.
• Çalıştırabilirseniz, önceki takımın yaptığı şey için kredi alırken (veya daha da kötüsü) kredi alabilirsiniz.
• Ortalama olarak, bir önceki takım muhtemelen ortalama idi. Ortalama olarak, ortalama olabilirsiniz. Bir önceki ekibe göre daha fazla çalışmanız var, çünkü bir projeye ek olarak yeni bir metodolojiniz var.
• Eski takım korkunç olsaydı, siz de korkunç değilseniz, sonunda korkunç olmaktan daha iyi olduğu için kredi alacaksınız. Korkunçtan daha iyiylerse ve belirgin bir şekilde daha iyi değilseniz, korkunç olduklarını söylemek hoş olmayan karşılaştırmaları davet edebilir.
• Eski takım düşündüğünüzden daha iyiyse ve organizasyon bozulduğu veya sorun kötü tanımlandığı veya çok zor olduğu için sorun yaşarsanız, beklentileri önemli ölçüde yükseltmediyseniz işler sizin için daha iyi olacaktır.
• Eğer aldıklarını beklerse, ama daha iyisini yaparsanız, bu sizin için bir kazançtır.
• Eleştiriden kaçınmak hem iyi bir tavırdır hem de sınıfınız olduğunu gösterir.

@Chuck tarafından yapılan yorumlar ve Netscape'e yapılan referanslar, aslında yeniden yazmadığını ve OP'nin yapması gerekip gerekmediğini soran geribildirimleri geçerli yanıtlar ile soruyor. - Gerçekten çevik bir yazılım geliştirme döngüsü yeniden yazmayı engeller. Yeniden yazma neredeyse her zaman Agile'nin arkasındaki ilkelerin çoğunu ihlal eder. Mevcut yazılımı temel hat olarak kullanan bu Çevik ilkeler ( Agile Manifesto'dan ) bir yeniden yazma ile karşılanamaz.

• Değerli yazılımın erken ve sürekli teslimi . - müşteri zaten sahip olduklarına göre ölçüldüğünde erken değer elde etmeyecektir
• Çalışan yazılımı sık sık - haftalar veya aylar - proje ne kadar büyük olursa, müşterinin yakın zamanda kendileri için daha faydalı bir şey alacağını söyleyebilir misiniz?
• Çalışan yazılım ilerlemenin birincil ölçüsüdür - taban çizgisine kıyasla çalışmak acele etmeyecektir
• Çevik süreçler sürdürülebilir kalkınmayı teşvik eder. - Müşterinin çalışma temeline sahip olduğu düşünüldüğünde, gelişmiş işlevsellik sağlama baskısı devam edecektir. Bunun sürdürülebilir bir hızda yapılması pek olası değildir.
• Basitlik - yapılmayan iş miktarını en üst düzeye çıkarma sanatı - esastır. Bu gerçekten her şeyi söylüyor ...

"Agile metodolojilerini kullanarak tüm bir uygulamayı yeniden yazmanız gerektiğini varsayalım, bunu nasıl yapardınız?"

Soru yanlış bir önermeye dayanıyor - Yeniden yazmanın Çevik olduğu düşünülebilir.

Yeniden yazılan uygulamayı bir seferde bir parça bırakıp bırakamayacağınızı ve eskisiyle yan yana üretip üretemeyeceğinizi düşünün.

Özellikle web uygulamaları için, uygulamanın tek bir bölümünü yeni bir platforma taşımak ve yük dengeleyici rota taleplerinizi uygun sisteme taşımak oldukça kolay olabilir. Ardından, ilk sayfanızı üretime sokmanızı ve bunları çevik bir şekilde sunmanızı sağlayacak hikayeleri yazın.

Masaüstü uygulamaları daha karmaşık olabilir, ancak çoğu zaman mümkün olacaktır.

Dikişleri arıyorsunuz - eski sistemin sorumluluklarının tamamen yeniden yazılmasına gerek kalmadan yenileri tarafından alınmasının mümkün olduğu yerler.

Belki de yeni bir web hizmetine veya çerçevesine taşınabilen bazı bağımsız iş mantığı vardır ve eski uygulama, eski kodu yerine değiştirilerek kullanılabilir. Kalan şey tek bir ısırıkta yönetilinceye kadar dikişlerde parçalar oymaya devam edin.

Herhangi bir dikiş bulamazsanız, gerçekten diğer bazı cevaplarda önerilen büyük patlama yaklaşımını aramanız gerekebilir. Ancak, özellikle eski sistemi paralel olarak geliştirmeye devam etmeniz bekleniyorsa, hedefinize ulaşmadan önce uzun bir yürüyüşe hazır olun ...

Agile, erken ve sık sık bırakmamız gerektiğini söylüyor, ancak tüm yeniden yazma işlemi tamamlanmadan önce bırakmanın pek bir anlamı yok.

Aslında, IMHO bu kilit noktadır - üretimde yeniden yazılmış uygulamanın parçalarını ne kadar erken alırsanız (ve eski sistemin işlevselliğini ideal olarak değiştirirseniz), projenizin başarılı olma şansı o kadar artar. Bunun çok anlamlı olmadığını düşünüyorsanız, daha fazla düşünün - neredeyse her zaman parçaları serbest bırakma olasılıkları vardır.

Muhtemelen birisinin eski uygulamadaki bir şeyi değiştirmesi gerektiği anlamına gelir, örneğin, yeniden yazma tamamlanmadığı sırada yeniden yazılmış uygulama ile etkileşim kurmak için bazı yeni arayüzler ekleyin. Ancak tecrübelerime göre, bu tür ek çalışmalar her zaman kendi bedelini ödüyor.

Yeni uygulamanın ilk bölümleri üretildikten sonra, çevik, yinelemeli yaklaşım belirginleşecektir. Gereksinimler değişecek, kullanıcı hikayeleriniz değişecek veya yeni öncelikler alacak ve umarım eski sistemin daha fazla işlevselliğini küçük adımlarla değiştireceksiniz.