Çevik yöntemler kullanırken iyi tasarım nasıl elde edilir?

Yaklaşık üç yıldır çevik bir metodoloji (SCRUM) kullanıyorum ve özellikle birçok seviyedeki kısa vadeli geri bildirimlerde (erken erişime sahip müşterilerden, özellikleri test edebilen test cihazlarından) belirli avantajlar görüyorum. uygulandığında, yeni kod hakkında inceleme yoluyla çok erken geri bildirim sağlayabilen diğer geliştiricilerden vb.

Öte yandan, birincisi bu soruda açıklamaya çalışacağım iki açık sorunum var.

Sorun: İyi bir tasarım elde etmekte zorluk

Kod dağınık olur olmaz refactoring yapmaya çalışıyorum (ben genel olarak ve özellikle yeniden düzenleme zaman hataları önlemek için yardımcı olur) mümkün olduğunca birim testleri yazıyorum . Öte yandan, günlük taahhütlerle küçük artışlarla bazı karmaşık özellikler geliştirmek ve yapılandırılmadan kodu sürekli olarak yeniden düşünmek gerçekten iyi bir tasarım üretmeme izin vermiyor.

Son zamanlarda üretebildiğim tek iyi tasarlanmış modül farklı bir yaklaşımla elde ettim: Sorunu birkaç gün boyunca analiz ettim (gerçekten ciddiyetle çalışmaya başlamadan önce birkaç ay boyunca sorunum vardı) ), ilgili tüm sınıfların ve ilişkilerinin birkaç gün daha ayrıntılı bir taslağını çizdi ve daha sonra kendimi ofisime kilitledim ve yaklaşık üç hafta boyunca kesintisiz çalışarak tüm kodu yazdı. Sonuç, bir süredir ürettiğim en iyi şeydi, bulunması ve düzeltilmesi oldukça kolay olan çok az hata ve o zamandan beri ilgili değişiklikler gerektirmeyen çok net bir tasarımdı.

Şimdiye kadar, büyük resmin büyülü bir şekilde süreçte ortaya çıkması umuduyla küçük artışlarla kod yazmaya başlamaktan önce yapmak istediğim şeyin genel bir resmini elde etmeyi çok daha etkili buldum. En iyi çabamla, küçük artış geliştirme yaklaşımı beni her zaman daha kötü tasarıma götürdü.

Soru : Benzer bir deneyim yaşadı mı? SCRUM'u yanlış mı uyguluyorum ya da küçük artışlarla geliştirmek ve yine de iyi tasarlanmış bir yazılım parçası bulmak istiyorsam nelere dikkat etmeliyim? Yoksa gerçek kodlamaya başlamadan önce bir tasarım kullanıcı hikayesi mi planlamalıyım ? En azından ortalamadan daha karmaşık özellikler için bu iyi bir uygulama mıdır?

DÜZENLE - NOT

İyi tasarımın mutlak bir şey olmadığı ve kendi başına bir değeri olmadığı gerçeğinin farkındayım, ancak bağlama bağlı ve kişinin eldeki problem için yeterince iyi bir tasarıma yönelik olması gerekiyor .

Örneğin, (1) mümkün olan en kısa sürede hazır olması gereken, (2) sadece bir kez kullanılacak, (3) kullanılmayacak basit bir bileşen uygulamak zorunda kalırsam iyi tasarımı önemsemiyorum (çok fazla) sistemin diğer parçaları (YAGNI) tarafından kullanılır.

Bir bileşen (1) birkaç kez kullanıldığında ve bir ürünün birkaç farklı sürümünde (2) zaman içinde bakımı ve uzatılması gerektiğinde iyi bir tasarıma önem veriyorum, (3) buna bağlı olarak çok sayıda başka bileşeni var .

Öte yandan, günlük taahhütlerle küçük artışlarla bazı karmaşık özellikler geliştirmek ve yapılandırılmadan kodu sürekli olarak yeniden düşünmek gerçekten iyi bir tasarım üretmeme izin vermiyor.

Öyleyse yapma.

Her şey güzel çevik kutuya uymuyor. Çoğu zaman bir ürün, bireylere yetiştirilemeyen ve süratle herhangi bir aklı başında tamamlanamayan birkaç karmaşık şeye sahip olacaktır. Onları bu kutuya zorlamak sadece sorun yaratacaktır. Ancak bunlar az ve çok olmalıdır. Bileşenlerinizin çoğunun böyle olduğunu fark ederseniz, ürün sahibinizin işleri daha iyi (ekibinizle) parçalamak için çalışması gerekir. Yaptığınız gibi iyiyim: hikayeyi alın, tasarlayın, sonra birkaç hafta süreceği beklentisiyle ASAP'ı çekiçleyin.

Daha genel bir durumda, Agile'da iyi bir tasarım elde etmek için gördüğüm 3 şey var:

• Aslında tasarım yap - Gördüğüm birçok yer sprint'lerini başlatıyor ve sadece kovboy kovmaya başlıyor. Bu şekilde kötü bir tasarım elde edeceksiniz. Agile, plan - kod - test - sürümünün geliştirme sürecini değiştirmez, sadece daha ayrıntılı parçalara kısaltır. Sprint başlangıcında, gerektiği gibi oturun ve aslında çözümünüzü tasarlayın.

• Bir mimar / liderlik yapın - Projeniz yeterince büyük olduğunda, uygulamanın farklı parçaları üzerinde çalışan birden fazla scrum ekibiyle sonuçlanacaksınız. Ana işi tüm ekiplerin tasarım açısından ne yaptığını bilmek olan birinin (veya uygulamanın büyüklüğüne bağlı olarak birden fazla kişinin) olması çok yararlıdır. Soruları cevaplayabilir ve takımları daha uyumlu bir aşırı kemerli tasarıma doğru yönlendirebilirler. Her scrum takımının, diğer takımların neler yaptığını bilen bir ipucu olması da gördüm ve çok etkili oldum.

• Bir pragmatist olun - bunu yukarıda ele aldım. Çevik bir araçtır ve herhangi bir araç gibi; tüm problemler için geçerli değildir. Bazı bileşenlere başvurmak mantıklı değilse, oraya uygulama. Amacınız iyi yazılım göndermek; unutma.

Küçük artışlarla uygulamak ve iyi yapılandırılmış bir bakım kodu ile son derece mümkündür. Teorik olarak, çok basittir: her değişiklikten sonra kodun iyi yapılandırıldığından emin olursanız, her zaman iyi yapılandırılmış olacaktır. Yeniden düzenleme yaparken kod eklemeye devam ettiğiniz için kodunuz kötü yapılandırılıyor.

Tasarımda ne kadar zaman geçirirseniz geçirin, sonunda gereksinimler beklenmedik bir şekilde değişecek ve orijinal tasarıma uymayan bir kod yazmanız gerekecektir. O zaman artımlı bir değişiklik yapmanız gerekecektir. İyi bir birim test kümeniz varsa ve yeniden düzenleme konusunda yetenekli iseniz, yeni gereksinimleri karşılarken kodu iyi yapılandırılmış tutabilirsiniz.

"İyi tasarlanmış" özneldir

Ne gelmez "iyi tasarlanmış" Size ortalama? Ürün Sahibine? müşteriye?

Is "iyi tasarlanmış bir ürün sahibinin golü"? müşteri hedefi? ya da sadece sen?

Böyle mi siz düşünün "iyi tasarlanmış değil" hala Ürün Sahipleri beklentilerinin karşılanması ve müşteri mutlu etmeye? Sonra bu oldukça "iyi tasarlanmış" .

Yeterince İyi ve YAGNI

Çoğu Çevik metodolojisinde hiçbir şey "iyi tasarlanmış" dan bahsetmez, çünkü Ürün Sahibinin hikayeleri eksiksiz olarak kabul ettiği ve müşterilerin gereksinimlerini karşıladığına inandığı herhangi bir sistem "iyi tasarlanmış" dır .

Edilir beklenen geliştiriciler profesyoneliz ve olacağı pragmatik özellikleri ve hikayeleri uygulamak için en iyi uygulamaları, uygun tasarımlar ve deyimleri kullanır.

Bir geliştirici problemi olan şeyleri doğru bir şekilde yapmak için faktoring yapmıyorsanız, Ürün Sahibi bunların yapılabileceği daha kısa sürede bir şeyler talep ediyorsa, bunu yapmak ayrıcalıktır ve bunları eğitmek sizin sorumluluğunuzdur. borçlanma hikayeleri şeklinde sonuçları .

SCRUM

_{Yazılabilir Çevik Metodoloji, Çevik Metodoloji değildir. "- Jarrod Roberson}

SCRUM'un bir yazılım ürününün toplam yaşam döngüsünü yönetmek için bir araç çerçevesi olduğu varsayılmaktadır. Katı bir şey kümesi değil, sadece başlamak ve umarım geliştirmek için iyi bir yer olması gerekiyordu.

Çalıştığım çoğu dükkanda, ürünün genel mimarisini veya temasını çizmek için ekibin üst düzey üyeleri için Sprint ZERO, Sprints denir.

20'den büyük olan hikayeler genellikle birkaç 3 - 5 nokta Hikaye olana kadar parçalanır. Bu hikayelerden biri, "Bir ekip olarak bu özelliği nasıl tasarlayacağımızı tartışmak için toplanmamız gerekiyor, böylece ayrılan zaman göz önüne alındığında mümkün olduğunca az teknik borcumuz olacak."

genellikle

Genel olarak "iyi tasarlanmış" bir sistem yeterlidir ve YAGNI'yı takip eder.

Agile ve özellikle SCRUM, Agile'nin bir uygulaması olarak, bir ürünün Ürün Sahibi / Sponsorları için mümkün olduğunca şeffaf bir şekilde nasıl üretileceği hakkında daha fazladır .

Teknik tasarım / mimari açısından akıllıca bir şey değil . Bu daha çok müşterilerin ihtiyaç ve beklentilerini karşılayan yazılım sunma yaklaşımına yaklaşmaktır. "İyi tasarlanmış" parçalar dediğin şey yoksa , bu felsefenin temel bir parçası olmadığı için kendi başına başarısız olmaz.

Scrum ile birkaç aydır çalışıyoruz ve sorununuzla ilgili deneyimlerimi paylaşmak istiyorum.

Birkaç ay önce bana uygulaması için büyük bir parça verildi. Tüm spesifikasyonları hazırladım, bu yüzden yeni özellikleri uygulamaya koymak zorunda kaldım. Görev (tahmin ettiğim gibi) yaklaşık 5-6 hafta sürmekti. İlk haftayı sadece tasarım üzerinde çalıştım. Görev biraz karmaşıktı: şartnameden çıkardığım gibi 15 farklı duruma sahip olan bir ana nesne vardı ve UI her eyalet için farklı davranışlara sahip olacaktı.

Daha sonra tüm iş akışını, DB yapısını ve sınıflarını tasarladım.

Benim durumumda başka bir yaklaşım görmüyorum. Bir kerede kodlamaya dalmış olsaydım, sonunda büyük bir iğrenç karmaşa olurdu _ korumak neredeyse imkansız ve daha fazla değişiklik yapmak son derece zor. Ancak değişiklikler önümüzdeki 2 hafta içinde geldi, bu yüzden kodu yeniden çalışmak zorunda kaldım. İlk düşünce tasarımı ile bu artık kolaydı. Bu zamanımızı, paramızı ve sinirlerimizi kurtardı.

Bu deneyimden sonra, başlangıçta kabul edilebilir bir tasarım yapmaya değeceğinden kesinlikle eminim, biraz mucize ile sonunda elde edeceğinizi umuyoruz.

Arka görüş 20-20. Eğer projenin başlangıcında herşeyi anlamak ve birkaç hafta içinde kodu yazmak için elinizde bilgi varsa, bunu yapmanızı öneririm.

Kazandığınız tüm içgörülere, denenmiş ve başarısız / değiştirilmiş yaklaşımlara yeterli miktarda kredi vermiyorsunuz ve müşterinin / kullanıcıların ihtiyaç duydukları krediyi sağlama yeteneğinin artması.

Neden başarılı su düşüşü projeleri olan bir kimse çevik bir metodolojiye geçsin?

Nihai hedefin ne olması gerektiği ve bir projeye başlamadan önce hangi özelliklerin ve ne zaman uygulanması gerektiğini gösteren daha büyük bir resme ihtiyacınız vardır. Hikayeler üzerinde atomik görevler üzerinde çalışmak sorun istiyor. Gelecekteki gereksinimleri olabildiğince aklınızda tutmanız gerekir.