Dikey kullanıcı hikayelerinin dezavantajları

Çevik yaklaşım içine çalışma yapısı etmektir dikey kullanıcı öyküleri ve gelen uygulamanın odaklanmış ancak tam olarak işleyen bir parça teslim sonuna uca . Bu, yazılım geliştirme konusundaki yeni yaklaşım olduğundan, bunun neden yatay öykülerden daha iyi olduğuna dair birçok literatür okudum, ancak bu yaklaşımın dezavantajları hakkında fazla bir şey bulamıyorum.

Zaten çevik serin yardımı içtim ve pastanın dikey olarak dilimlenmesinin yatay dilimlemeye göre çok fazla avantajı olduğunu kabul ediyorum. İşte ortaya çıkabilecek dezavantajların kısa bir listesi:

• Bir geliştirici başlangıçta bir özelliği uygulamada daha yavaş olabilir, çünkü hikayeyi geliştirmek için gerekli tüm teknolojileri anlaması gerekir (UI + hizmet katmanı + veri erişimi + ağ vb.)
• Genel mimari tasarım (uygulamanın omurgasını oluşturmak) bu mantraya tam olarak uymuyor (ancak bazıları genel mimariyi geliştirmenin / değiştirmenin bir kullanıcı hikayesinin bir parçası olduğunu iddia edebilir)

Kullanıcı öykülerini dikey olarak dilimlemenin bazı dezavantajları nelerdir?

Not: Şimdi bu soruyu sormamın nedeni, bir takımı hikayeleri 'dikey yol' yazmaya başlamaya ikna etmeye çalışacağım ve olası ödünleşmeleri vaktinden önce getirebilmek istiyorum. dezavantajlarla karşı karşıya kaldıklarında yaklaşımın başarısız olduğunu düşünmeyin.

Uzun vadeli dezavantajları bilmiyorum. Kısa vadede ve bu tür gelişime yeni bir ekip için ana dezavantaj, biraz alışmaya ve biraz öğrenmeye ihtiyaç duymasıdır.

Dikey çalışmanın en etkili yolu, tam yığın geliştiricilere sahip olmaktır: bu şekilde bir hikaye genellikle bir kişi tarafından (veya birden fazla ancak boru hattı görevleri olmadan ) yürütülebilir . Açıkçası bu, geliştiricilerin yığın boyunca dikey olarak çalışmasını gerektirir (bir web uygulaması durumunda html'den veritabanına).

Ekibiniz dikey öyküler üzerinde çalışmaya alışkın değilse, tam tersini yapacaklardır: her kişi sadece uygulamanın bir katmanı / katmanı hakkında bilgi sahibi olacaktır. Dikey öyküler tanıtırken, ekibin bunları katmanlara karşılık gelen görevlere ayırmasını ve ardından görevleri farklı kişilere dağıtmasını bekleyebilirsiniz. Bu çok verimsiz olacak.

Bu konuda verebileceğim en iyi yaklaşım, uzun vadeli hedefin tamamen farklı olduğunu açıkça ortaya koyarken bu boru hattını başlangıçta tolere etmektir. Güven oluşturmak ve sonuçta insanların tamamen bağımsız olmalarını sağlamak için katmanlar arası ekip üyelerinin program eşleştirmelerini sağlayın.

Bu yaklaşımın teknik borç getirdiğine dair diğer cevaba katılmıyorum. Başka bir yaklaşım da olabilir, ama olabilir.

Bu soruyu çok düşünüyorum.

Bence bireysel sorumluluklarla dilimleme ile takım sorumluluklarına göre dilimleme arasında ayrım yapmak önemlidir. Bu cevabı ağırlıklı olarak dilimleme takımlarına odaklayacağım.

Bazı geçmişler için: Tam yığın geliştiriciler, tek katmanlı geliştiriciler, dikey (tam yığın) ekipler, yatay (tek katmanlı) ekipler ve çapraz ekiplerle projelerde çalıştım. Çapraz ekip ile bir hikaye için gerekli olan tüm katmanları içeren, ancak sistemdeki tüm katmanları içermeyen ve muhtemelen aynı katmanlara odaklanan birden fazla geliştirici içeren; diğer bir deyişle ruhsal açıdan dikey fakat görünüşte veya uygulama detayında biraz yatay olabilir.

Son zamanlarda yatay takımlardan köşegen (neredeyse dikey) takımlara geçen bir grupta çalıştım. Aynı grup insanın iki farklı şekilde hizalandığını görmek özellikle öğretici olmuştur. Bazı avantajları ve dezavantajları oldukça açık hale getirir.

Fikrimi şu ana kadar karşılaştırarak özetleyeceğim:

Yatay Takımlar

Avantajları:

• Endişelerin ve gevşek bağlı katmanların iyi ayrılmasını teşvik eder
• Çok daha kolay iş yükü dağıtım yönetimi
• Uzman teknik ipucunun yönetilmesi kolay
• Katmanlar arası işbirliği, en iyi uygulamalar, gurur ve mükemmeliyet kültürünü teşvik eder
• Doğal / acil iletişim kalıplarına uyum sağlar

Dezavantajları:

• Katmanların izolasyonuna yol açabilir ve böylece katmanlar arası iletişimi engelleyebilir
• Etkilenmezse katman "kabarcık" kültürünü etkinleştirir
• Genelci liderlikten yararlanmak zor
• Hinderler genelcileri

Dikey / Çapraz Takımlar

Avantajları:

• Bir takımda bir kullanıcı hikayesinin tüm parçaları ("tek noktadan alışveriş")
• Özellikle n katmanlı hikayeleri tek bir sprint'te sunmanıza yardımcı olur (buna gerçekten ihtiyacınız olsa da)
• Katmanlar arası işbirliğini ve genel becerilerin büyümesini teşvik eder
• Genelcileri destekler

Dezavantajları:

• Çok daha zor iş yükü dağıtım yönetimi
• Endişelerin ve sıkıca bağlı katmanların zayıf bir şekilde ayrılmasını sağlar
• Katman içi iletişimi kısıtlayarak uzmanlaşmayı engeller; yatay / uzman davranışları hafifletmeden bu yapıdan bir mükemmellik kültürünün nasıl ortaya çıkabileceğini görmek zordur

Ekip üyeliğinin herkese uyan tek bir çözümü olduğunu düşünmüyorum. Bununla birlikte, dikey ekibin genelleme gerektiren kuruluşlar için daha iyi bir şekilde sıralandığı oldukça basit görünüyor. Mühendisleriniz genelciyse ve tam yığın halinde çalışmayı seviyorsanız, dikey ekipleri düşünmek için oldukça iyi bir neden. Yatay ekip, uzman gerektiren kuruluşlar için daha iyi sıralanıyor. Mühendisleriniz uzmansa, yatay ekipleri düşünmek için oldukça iyi bir neden.

Diğerlerinin de belirttiği gibi, diğer yönü kesen ikincil yapılar / davranışlar, her iki sistemin dezavantajlarını azaltmaya yardımcı olabilir. İlginç bir azaltıcı etken sprint süresidir. Kısa sprintler, yatay takımların bazı dezavantajlarını daha tolere eder. Bu hafta arka ucunu ve gelecek hafta ön ucunu oluşturabilirseniz, bu yeterince hızlı olabilir mi?

Bu önerilen ilkelerin bazılarını gerçek dünya sorununa uygulamak için ... Yatay dilimlerin üzerinde çalıştığım her katmandaki çok zorlu teknik sorunları çözen çok gerçek bir SaaS geliştirme ekibi için oldukça iyi çalıştığını söyleyeceğim. uzmanlığın bana göre inanılmaz derecede önemli olduğu yerlerde, dağıtım sıklığı (ve yüksek ayrıntı düzeyinde / sıklıkta güvenilirlik) iş başarısı için kritik önem taşıyordu. Bu sonucun, yatay dilimlemenin genel bir üstünlük ifadesi değil, çok özel bir gerçek dünya ekibi için olduğunu lütfen unutmayın.

Bir uyarı: Muhtemelen birkaç nadir istisnai general tanımamış olsam da, modern yazılım geliştirme dünyasındaki herhangi bir bireyin önemli kanıtlar olmadan genel yetenek yeteneklerine inanmaya karşı önyargılıyım. Özellikle, her katman karmaşık bir şekilde büyüdükçe ve alternatif dillerin / platformların / çerçevelerin / uygulamaların çoğalmasıyla birlikte, genelliğin uzun (dikey?) Bir düzen olduğunu hissediyorum. Bu günlerde, özellikle tüm esnafların bir krikosu kolayca bir usta olabilir. Ayrıca, anekdot olarak, çoğu kişinin yine bazı istisnalar dışında biraz uzmanlaşmak istediğini düşünüyorum.

Bulduğum en büyük dezavantaj, bir ekibin birleşik bir mimari yaklaşımın ardından uygulamayı geliştirmesini zorlaştırması.

Projenin ilk aşamalarında herkes katmanlarını tek başına yazacak. Hikayeler (ve ilgili katmanlar) işe yarayacak, ancak teslim edilen ürüne sprint sonunda bakıldığında, her geliştiricinin mimari fikirleri arasındaki küçük farklılıkları görmek kolay olacak.

Bu tür şeyler kaçınılmazdır, ancak bir engelleyici değildir. Bununla iki şekilde savaşmaya çalıştım:

1. Her hikayeyi uygulamadan önce ekiple uzun tasarım tartışmaları yapın
   • Bu çabuk yoruluyor. Herkesin bilinçli bir karar vermesi için henüz çok erken ve sonra da yine de kesinlikle değiştirmek zorunda kalacak şeyler üzerinde tartışıyorsunuz.
2. Teknik borç oluşturduğunuzu aklınızda tutarak göreceli olarak tecrit edin .
   • Buradaki anahtar, teknik (mimari) borcu bir mesele olarak kaydetmektir. Bu geri ödenmesi gereken bir şey.
   • Birkaç sprintten sonra tutarlı ve birleşik bir mimariye karar vermek daha kolay olacaktır. Bu, teknik borcunuzun bir kısmını geri ödemek için sert bir sprint istemeniz gerektiğinde (mevcut kodu yeniden düzenleyin). Alternatif olarak, projenin bir sonraki tekrarında parça parça geri ödeyebilirsiniz.

Bunun dışında düşünebileceğim diğer tek sorun genellikle bir projenin başında eklenecek çok sayıda kaynak kodu olmasıdır. Dikey dilim öyküleri yazmak, takımın ilk birkaç öyküdeki süratinin bu ön koşul plakası nedeniyle yapay olarak düşük olacağı anlamına gelir ... ancak herkes bunun sadece birkaç sprint'i etkilemesi gerektiğini bildiği sürece her şey yolundadır.

Ben de herhangi bir dezavantaj bilmiyorum, ancak dikey hikayeler kötü uygulanabilir.

Kariyerime ilk başladığımda XP yapmaya hevesli bir takıma katıldım, ancak onunla hiçbir deneyimi yoktu. Dikey kullanıcı hikayeleri kullanırken bir takım hatalar yaptık.

Yatay çalışma yaparken karşılaştığımız sorunlardan biri, özelliklerin katmanlar arasında iyi bütünleşmemiş olmasıydı. API'ler genellikle spesifikasyon, eksik özellikler ve diğer birçok sorunla eşleşmedi. Genellikle, geliştiricinin başka bir şeye geçmesi nedeniyle, ya onları beklemeniz ya da kendiniz yapmanız gerekir.

Dikey Hikayeler yapmaya geçmek bu sorunları çözdü ve entegre olmak için yeniden çalışma israfını azalttı / ortadan kaldırdı.

Bu çalışma biçimini destekleyen bir dizi XP uygulaması vardır. Herkesin herhangi bir alanda çalışabilmesi gerekir ve herkesin bulduğu hataları düzeltmesi beklenir ( Toplu Kod sahipliği ).

Dikey öykülerde değişiklik yaparken, aşina olmadığınız alanlarda çalışmak zor olabilir. Eşli Programlama , takımda onlarla eşleştirilen birini kapmaktan emin değilseniz yardımcı olabilir. Yeni bir kod tabanı ile hızlanmak için en hızlı yolu olarak çift programlama buldum.

Katmanlar üzerinde güçlü sahipler olmadan, bazı çoğaltmaların ortaya çıktığını gördük. Bu büyük bir sorun olmasa da, Refactor'u Acımasızca uyguladığımızdan emin olmamız gerekiyordu (desteklemek için uygun testlerle).

Bir takım problemlerden bahsetmeme rağmen, bunun nedeni Dikey Kullanıcı Hikayeleri olduğunu sanmıyorum. Aslında, problemleri daha belirgin hale getirdi. Geçişi yaptıktan sonra, takımlar veya uygulama katmanları arasında sorunlar artık gizlenmedi.