it-swarm.dev

Scrum'da tasarımla nasıl başa çıkıyorsunuz?

Scrum'da tasarımla nasıl başa çıkıyorsunuz? Her scrum yinelemesi için hala iyi yazılmış tasarım belgeleriniz var mı? Sadece UML diyagramlarını içeren tasarım notları mı yapıyorsunuz? Yoksa iyi yorumlanmış bir kod mu var?

Her yineleme tasarımı değiştirmeyi içerebilir, bu yüzden insanların bunu nasıl yakaladığını bilmek istedim, böylece yeni geliştiriciler etki alanını anlamak ve mümkün olduğunca hızlı bir şekilde işe başlamak için kolay bir işe sahipler.

26
Seth

scrum olması her şeyin her sprint'i değiştirdiği anlamına gelmez!

Scrum yaklaşık gerekli olanı yapmak (ancak daha fazla değil). Yine de tasarımı yapmanız ve belgelendirmeniz gerekiyor. Sadece miktar sabit değildir ve nasıl yapılır.

Her sprint planlamasının bir kısmı ne yapılması gerektiğine karar vermektir. Biriktirme listesindeki bir şeyin başka şeyleri etkilediği için tasarlanması gerekiyorsa, tasarım süreçleri için belirli bir görev eklemeniz ve bunu uygulama görevinden önce yapmanız gerekir.

11
Martin York

Bu konuda söyleyecek çok şeyim var. Şirketlerin/ekiplerin/insanların yazılıma Agile yaklaşımı kullandıklarını söyledikleri birçok durum gördüm, ancak gerçekte Agile yöntemlerinin ilkelere uymadan vaat ettiği ödülleri toplamak istiyorlar.

Hızlı yinelemenin çalışması için test odaklı geliştirme yapmalısınız (TDD'yi isteksizce yapmanız gerektiğini söylemekten kestim). TDD'de testleriniz, kodun tasarımını ve amacını ifade eder ("kod dokümantasyondur" dedikleri zaman "testler dokümantasyondur" demeleri gerekir). Elinizdeki özelliği anladığınızı ifade eden birim testleri yazarak, kodun yapması gerektiğini düşündüğünüzü açıkça belirtmiş olursunuz. Sonra bunu yapan kodu yazın. Sonra bu kodu refactor böylece iyi mimari ilkeleri "Kırmızı-Yeşil-Refactor" uyun.

Her check-in ile (hatta her check-in'den önce) birim testlerinizi yapmak, yazdığınız yeni kodun uygulamanın diğer bazı alanlarında beklenen işlevselliği bozmadığını doğrular. Bu, enkazdan vazgeçerek kodu değiştirmenizi sağlayan bir güvenlik ağı sağlar. Eldeki gereksinimler hakkındaki anlayışınız arttıkça, testi bu yeni bilgiyi yansıtacak şekilde değiştirebilirsiniz. Gerçek tasarım Birim testlerinde yatmaktadır. Diğer her şey (kapsanmayan kod dahil) bir yalandır.

İşte bazı önerilen okumalar

Bunlar çevik gelişime gerçekten nasıl yaklaşacağınızı öğrenmek için iyi yerlerdir.

10
Michael Brown

Scrum bir yazılım geliştirme metodolojisi değil, bir proje yönetimi metodolojisidir. Scrum tipik olarak bir Agile metodolojisi ile birlikte kullanılır. Cevabınız burada yatıyor.

2
Steven A. Lowe

Projenin genel mimarisi ve üst düzey tasarım, proje sahipleri hikayeleri oluştururken scrum ekiplerinin dışında yapılacaktı.

Hikayeler ve müşterinin beklentileri arasındaki ilişkiyi görmeye yardımcı olmak için hangi biçimde yazılırsa, genel bir tasarımın yeterli olması gerekir.

Her bir hikaye için gereken tasarımın bir kısmı, planlama sırasında ürün sahibiyle planlama ve müzakere sırasında yapılacaktır.

Bir hikaye için tasarım çabasının büyük kısmı sprint'te yapılacaktı.

Hikaye tahmin edilecek kadar tanımlanmamışsa, daha sonra bir sprint için uygun bir hikayenin yaratılabileceği yeterli tasarım çalışması yapmak için mevcut sprint'te bir zaman kutusu ayrılabilir.

1
Blake

Scrum, çevik değerleri 'a dayalı yinelemeli ve artımlı bir modeldir. Bu, ayrı bir tasarım aşamanız olmadığı anlamına gelir. Fikir, proje boyunca analiz, uygulama, test ve entegrasyonla sürekli uğraştığınız gibi tasarımla sürekli ilgilenmeniz gerektiğidir.

Bunun çalışması için biraz planlama yapmalısınız. Takımın ilerideki sprint için görevleri tahmin ettiği sprint planlama toplantısını girin. Çoğu insan bunun sadece bir tahmin toplantısı değil, aynı zamanda bir tasarım çabası olduğunu da fark etmez. Örneğin, bir görev "Yeni araba modeli için kod ekle" olabilir. Bunu henüz tahmin edemezsiniz, biraz daha fazla bilgi sahibi olmanız gerekir. Böylece ekip tasarımı tartışır ve geniş bir çözüm bulur ("alt sınıf Araba?") Ve bunu görev için bir hatırlatma olarak ekler. Nadiren bundan daha fazla formaliteye ihtiyacınız var. Artık sorunu nasıl çözeceğiniz hakkında bir fikriniz var. Henüz tüm ayrıntılara sahip değilsiniz ve bu iyi, rahat bir tahmin yapabilmek için tasarımın yeterli olduğunu biliyorsunuz. Hiç bir diyagram oluşturmak zorunda kalmadan (bu noktada).

gerçek fiziksel belgeler için, herkesin görmesi için bir duvarda sistemlere genel bakış diyagramı oluşturmak için I recommend . Genel bakış sadece en önemli sınıf ve modüllere sahip olmalı ve nadiren güncellenmelidir. Ayrıca, sistemdeki en önemli sınıflar için birkaç durum diyagramı oluşturmak çok yararlıdır. İnsanların işlerin nasıl bağlandığını hızlı bir şekilde görmelerini kolaylaştırmak için tipik kullanım durumlarından birkaç seçili dizi diyagramı serpin. Kodunuzdan sınıf hiyerarşi diyagramları oluşturabileceğinizi varsayıyorum, böylece bu problem kolayca çözülebilir.

Tüm diyagramların gerçek uygulamadan sonra oluşturulduğunu unutmayın. Bu, "kapsamlı dokümantasyon üzerinde çalışan yazılım" ve tam zamanında tasarımla uyumludur.

Ve evet, okunabilir kod kesinlikle dokümantasyon.

1
Martin Wickman

Gereksinimlerin sık sık değiştiği kadar ön tasarım yoktur. Yani sınıf seviyesine kadar tasarlamak genellikle zaman kaybıdır. Bununla birlikte, daha yüksek düzeydeki mimari kararları çizmek faydalı olabilir.

Ağır hizmet tasarım belgeleri yapmanın problemi, yaratıldıkları anda kullanılmamasıdır. Bu yüzden en iyi sonuç, genellikle kısa sürede tamamen değişmesi muhtemel olmayan yüksek düzeyli belgelerdir.

1
Vadim

Bugün Eclipse topluluğunun içinde, modelin kodu/geliştirmeyi yürüttüğü MDD'ye odaklanan geleneksel UML araçları ve yinelemelerin yalnızca modeli değil, geliştirme sürecini de yönlendirmesi gerektiğini düşünen Omondo arasında bir bölünme vardır.

Onlara katılıyorum çünkü MDD bok gibi, UML gerçekten mükemmel bir yol çünkü diğer ekip üyeleriyle iletişim kurmak için standartlaşıyor. alt text

0
UML_GURU

Anladığım kadarıyla, projenin başında topladığınız ön gerekliliklerle daha üst düzey bir tasarım yaptığınızdır. Bu tasarımı iyi belgeliyorsunuz.

Gereksinimi gerçekten uygulamaya başladığınızda, daha düşük seviye tasarımı istediğiniz gibi değiştirirsiniz, ancak daha yüksek seviye tasarımı değiştirmekten kaçınırsınız.

Beş dakika önce bana böyle açıklandı ...

0
indyK1ng