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

Scrum'da tasarımla nasıl başa çıkıyorsunuz? Her scrum yineleme için iyi yazılmış tasarım dokümanlarınız var mı? Sadece UML diyagramlarını içeren tasarım notları mı yapıyorsunuz? Yoksa sadece iyi yorumlanmış kodunuz mu var?

Her yineleme, tasarımın değişmesini içerebilir, bu yüzden insanların bunu nasıl yakaladığını bilmek istedim, böylece yeni geliştiricilerin etki alanını anlamak ve mümkün olan en kısa sürede gemiye binmek için kolay bir işi olacak.

Sadece bu scrum olması her şeyin her koşuyu değiştirdiği anlamına gelmez!

Scrum gerekli olanı yapmakla ilgilidir (ama artık değil) . Yine de tasarımı yapmalısın ve hala belgelemelisin. Sadece tutarı sabit değil ya da nasıl yapılacağı.

Her bir sprint planlamasının bir parçası ne yapılması gerektiğine karar veriyor. Birikimdeki bir şeyin başka şeyleri etkilediği için tasarlanması gerekiyorsa, tasarım işlemleri için belirli bir görev eklemeniz ve bunu uygulama görevinden önce yapmanız gerekir.

Bu konuda söylenecek çok şey var. Şirketlerin / ekiplerin / insanların yazılıma Çevik bir yaklaşım kullandıklarını söyledikleri birçok durum gördüm ancak gerçekte, Çevik yöntemlerin ilkelere uymadan vaat ettikleri ödülleri kazanmak istiyorlar.

Hızlı yinelemenin çalışması için, sınamaya dayalı geliştirme yapmanız gerekir (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" deyince, "test dokümantasyondur" demeleri gerekir). Eldeki özellik hakkındaki anlayışınızı ifade eden birim testleri yazarak, kodun ne yapması gerektiğine inandığınızı açıkça belirtirsiniz. Sonra bunu yapan kodu yazarsınız. O zaman bu kodu yeniden düzenlediniz, böylece iyi mimari prensiplere "Red-Green-Refactor" u uygularsınız.

Ünite testlerinizi her check-in (hatta her check-in'den önce) yapmak, yazdığınız yeni kodun uygulamanın başka bir bölgesinde beklenen işlevselliği bozmadığını doğrular. Bu, enkazsız bırakma ile kodu değiştirmenize izin veren bir güvenlik ağı sağlar. Eldeki gereksinimleri anlama şekliniz arttıkça, testi yeni bilgileri yansıtacak şekilde değiştirebilirsiniz. Gerçek tasarım Unit testlerinde yatmaktadır. Diğer her şey (kapsanmayan kod dahil) yalandır.

İşte önerilen bazı okumalar

• Kodu temizle
• Çevik Yazılım Geliştirme İlkeleri, Kalıpları ve Uygulamaları
• Pragmatik Programcı

Bunlar çevik kalkınmaya gerçekten nasıl yaklaşılacağını öğrenmek için aramaya başlamak için iyi yerlerdir.

Scrum , bir yazılım geliştirme metodolojisi değil, bir proje yönetimi metodolojisidir. Scrum, genellikle bir Çevik metodoloji ile birlikte kullanılır. İşte cevabında yalan var.

Gereksinimlerin sıklıkla değiştiği kadar ön tasarım yoktur. Bu yüzden sınıf seviyesine göre tasarım yapmak genellikle zaman kaybıdır. Ancak, daha yüksek seviyeli mimari kararları eskiz etmek faydalı olabilir.

Ağır hizmet tasarım dokümanları yapmadaki problem, oluşturuldukları anda neredeyse eski olmalarıdır. Yani, en iyisi, genellikle kısa sürede tamamen değişmesi muhtemel olmayan yüksek seviyeli dokümantasyondur.

Scrum, çevik değerlere dayanan yinelemeli ve artımlı bir modeldir . Bu, ayrı bir tasarım aşamasına sahip olmadığınız anlamına gelir. Buradaki fikir, sürekli olarak tasarımla başa çıkmanız gerektiği , proje boyunca sürekli analiz, uygulama, test ve entegrasyon ile uğraştığınız gibi.

Bunun çalışması için biraz planlamaya ihtiyacınız var. Takımın önündeki sprint için görevleri tahmin ettiği sprint planlama toplantısına girin . Çoğu insan bunun sadece bir tahmin toplantısı değil, aynı zamanda bir tasarım çalışması olduğunun farkında değildir. Örneğin, bir görev "Yeni araba modeli için kod ekle" olabilir. Bunu henüz tahmin edemezsiniz, biraz daha fazla şey bilmeniz gerekir. Böylece ekip tasarımı tartışıyor ve geniş bir çözüm buluyor ("alt sınıf Araba?") Ve bunu göreve bir hatırlatma olarak ekliyor. Bundan daha fazla formaliteye ihtiyacınız yok. Artık sorunun nasıl çözüleceği 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).

İçin gerçek fiziksel belgelerin , ben tavsiye herkesin görmesi için bir duvara kadar planına genel bakış bir sistemleri oluşturur. Genel bakış sadece en önemli sınıfları ve modülleri içermeli ve nadiren güncellenmelidir. Ayrıca, sistemdeki en önemli sınıflar için birkaç durum diyagramı oluşturmak çok faydalı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ının birkaç seçili sıralama şemasını serpin. Kodunuzdan sınıf hiyerarşi diyagramları oluşturabildiğinizi ve problemin kolayca çözülebileceğini tahmin ediyorum.

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ım ile devam ediyor.

Ve evet, okunabilir kod kesinlikle dokümantasyondur.

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

Hikayeler ve müşteri beklentileri arasındaki ilişkiyi görmeye yardımcı olmak için ne şekilde olursa olsun yazılan genel bir tasarım yeterli olmalıdır.

Her hikaye için gereken tasarımın bir kısmı planlama sırasında ürün sahibi ile planlama ve pazarlıkta yapılacaktır.

Bir hikaye için tasarım çabasının büyük kısmı süratte yapılıyordu.

Hikaye tahmin etmeye yetecek kadar tanımlanmadıysa, mevcut sprint'te, bir sonraki sprint için uygun bir hikayenin yaratılabileceği yeterli tasarım çalışmasını yapmak üzere bir zaman kutusu belirlenebilir.

Anladığım kadarıyla, projenin başında topladığınız ön gereksinimlerle daha üst düzeyde bir tasarım yapmanız. Bu tasarımı iyi belgeliyorsunuz.

Daha sonra gereksinimi gerçekten uyguladığınızda, alt seviyedeki tasarımı istediğiniz gibi değiştirirsiniz, ancak üst seviyedeki tasarımı değiştirmekten kaçınırsınız.

Yine de bana beş dakika önce anlatılmıştı ...

Bugün Eclipse topluluğu içinde, modelin kodu / geliştirmeyi sürdüğü MDD'ye odaklanan geleneksel UML araçları ile yinelemelerin geliştirme sürecini yürütmesi gerektiğini düşünen Omondo ve kesinlikle yalnızca model değil arasında bir ayrım var.

Onlarla aynı fikirdeyim çünkü MDD berbatken UML gerçekten mükemmel bir yol çünkü diğer ekip üyeleriyle iletişim kurmak için standardize.