Projenin başlangıcında çevik yöntemler ve Veritabanları

Çevik yeni ve nasıl başlayacağından emin değilim. Fikir sprintlerde projenin küçük bölümlerini oluşturmaktır. Ancak üzerinde çalıştığım proje bir veritabanı gerektirir ve veritabanı proje ile her şeyi yapmak için neredeyse işlevsel olmalıdır.

Peki Agile projeleri bunu nasıl ele alıyor, veritabanını oluşturarak başlıyor musunuz?

Bunu nasıl yapardınız, örneğin Scrum kullanıyorsanız, kullanıcı hikayelerini nasıl yapıp db'yi test edersiniz.

Kod da gerektiren bir hikayede db bölümlerini yapmak yerine.

Diyelim ki "Bir kullanıcı olarak kayıt olmalısın ..." gibi bir hikayeniz var, bu hikayenin bir parçası olarak veritabanında kullanıcı tablosu oluşturacak mısınız?

Agile veritabanını tasarlamanıza nasıl yardımcı olabilir?

Evet, hikayenin gerektirdiği şekilde gerekli tabloları ve sütunları ekleyerek veritabanını aşamalı olarak oluşturacaksınız. İlk öykünüzü başlattığınızda genellikle veritabanının tamamına ihtiyacınız yoktur - örneğin "Bir kullanıcı olarak kayıt olmanız gerekir ..." büyük olasılıkla tam olarak tanımlanmış sütun kümesine sahip tek bir tablo gerektirir.

Gerçekten tüm veritabanını gerektiren bir hikayeniz varsa hikaye Epic - sadece çok büyük ve bölünmesi gerekiyor.

Çevik yeni ve nasıl başlayacağından emin değilim.

Gönderinizi okuduktan sonra yanlış anladığınızı düşünüyorum ve çevikliğin gerçekten ne anlama geldiğini ve başarmaya çalıştığını okumaya başlamalısınız.

Fikir sprintlerde projenin küçük bölümlerini oluşturmaktır.

Kapat, ama yeterince yakın değil. Fikir, her sprint sonunda çalışan yazılım sunmaktır (sistemin bir kısmı bir sprint'e sığabilir veya sığmayabilir). Veri tabanı yalnızca ve müşteriye sunduğunuz veri tabanı ise çalışan bir yazılım olarak görülebilir.

Ancak üzerinde çalıştığım proje bir veritabanı gerektirir ve veritabanı proje ile her şeyi yapmak için neredeyse işlevsel olmalıdır.

Neden neredeyse işlevsel olmak zorunda? Sistemin her özelliği veritabanının içeriğinin tamamını veya çoğunu kullanıyor mu? Çünkü eğer değilse, tüm veritabanını önceden tasarlamanın bir anlamı yoktur.

Peki Agile projeleri bunu nasıl ele alıyor, veritabanını oluşturarak başlıyor musunuz?

Agile veritabanı veya sistem tasarımını işlemez. Projenizi nasıl yöneteceğinizi anlatır. Bunu göz önünde bulundurarak, sistemin tüm özelliklerini tanımlayarak ve bunları ürün biriktirme listesine koyarsınız. Ardından, ürün sahibi ile birlikte, biriktirme listesindeki özelliklere öncelikler atarsınız. Bunu yaptıktan sonra, biriktirme listesinden özellikler almaya ve sprintler oluşturmaya başlarsınız (genellikle 2 ila 4 hafta uzunluğunda). Bir sürat bittiğinde, sistemde müşteriye teslim edilebilecek yeni bir çalışma özelliğine sahip olmalısınız.

Bunu nasıl yapardınız, örneğin Scrum kullanıyorsanız, kullanıcı hikayelerini nasıl yapıp db'yi test edersiniz.

Yanılıyor olabilirim ama veritabanını test etmenin bir anlamı yok. Veritabanını güncelleyen kodu test edebilirsiniz. Tabii ki, veritabanının programlanabilir kısmını test edebilirsiniz, ancak bunu çağıran kodu test ederek elde edebilirsiniz.

Kod da gerektiren bir hikayede db bölümlerini yapmak yerine.

Evet.

Çevik hiçbir şekilde proje yönetiminde gümüş bir kurşun değildir ve doğru uygulanmadığında felakete yol açabilir. Bunu okumak için biraz zaman ayırmaya çalışın (burada veya yığın akışı üzerinde bol miktarda kaynak bulabilirsiniz), belki zaten çevik yapmış ve hıza ulaşmanıza yardımcı olabilecek birini bulabilirsiniz.

veritabanı, projeyle ilgili her şeyi yapabilmek için neredeyse işlevsel olmalıdır.

Büyük ölçüde yanlış.

Peki Agile projeleri bunu nasıl ele alıyor, veritabanını oluşturarak başlıyor musunuz?

Boş bir veritabanı, evet. Sonra bir sprint'i bitirmek için tabloları gerektiği gibi ekleyin.

nasıl kullanıcı hikayeleri yapmak ve db test?

Ne soruyorsun? Agile'ın veritabanı tasarımı ile ilgisi yoktur.

Hikayeyi siz yazıyorsunuz.

Bir çözüm tasarlıyorsunuz.

Tablolar ve kod oluşturursunuz.

Kodu test edersiniz.

Kod gerektiren bir hikayede db'nin bölümlerini yapmayı tercih eder misiniz?

Başka hangi seçenek var? Önce tüm DB mi? Bu imkansız.

"Bir kullanıcı olarak kayıt olmanız gerekir ..." Bu hikayenin bir parçası olarak veritabanında kullanıcı tablosu oluşturmak istiyorsunuz?

İlk olarak, bu işe yaramaz bir hikaye, çünkü kayıt olmanın bir değeri yok. Bu sadece kullanıcıların geçmek zorunda kaldığı teknik bir engeldir.

İkinci olarak, hikayeyi uygulamak için yeterli sayıda tablo oluşturacaksınız.

Agile veritabanını tasarlamanıza nasıl yardımcı olabilir?

Ne soruyorsun?

Çevik proje yönetimi. Herhangi bir tasarıma yardımcı olmaz.

Sadece büyük bir işi küçük parçalara ayırmanıza yardımcı olur.

Öncelikle artımlı bir yaklaşımı takip edin.Bir modül seçin, gereksinimlerini tanımlayın, işlevselliği tebeşirleyin, fonksiyonel bir alanı hedefleyin ve sonra modelleme, db tasarımı, algos, kodları seçin ve sonunda test edin ve işlemi tekrarlayın.

Sorunuz AgileFall geliştirme anti-paternini haykırıyor .

Bu ne? Genellikle geleneksel olarak bir Şelale yönteminde yazılım geliştiren bir kuruluştur, ancak daha sonra bunun işe yaramadığını fark ettikleri için, Agile tekniklerini benimsemek için dahili olarak mücadele ederler. Ortaya çıkan "başarısız gaz" genellikle oluşur çünkü gerçek Çevik TALEPLER birçok kurulan Şelale mağazasının yapılandırılma biçiminden temel bir örgütsel sarsıntıdır. Ve elbette, Agile bu insanların GERÇEKTEN yazılım geliştirmede ne kadar işe yaramaz olduklarını gösterdiğinde kendilerini birçok güçlü ve kararlı insanın sürece sokmaları gerektiğini düşündükleri için bu şekilde yapılandırılmış olma eğiliminde olacaklar.

Bir şekilde alttan başladığınız, veritabanınızı tasarlayıp oluşturduğunuz ve daha sonra orta katmana geçtiğiniz ve bir daha asla veritabanınıza dokunmak zorunda olmadığınız bu fikirden kaçmanız gerekir. Agile'de yapmanın yanlış yolu budur.

Bir kullanıcı hikayesi için etki alanı modelinden başlayın ve veritabanına kadar, orta katman ve sunuma kadar aşağı doğru çalışın.