Kullanıcı hikayeleri tarafından bırakılan arka uç geliştiricileri

10

Arka uç geliştirmede kullanıcı hikayelerine dikey olarak dilimlemeyi planladım. Ancak ekibimizdeki bir arka plan adamı bunun çalışmalarını görünmez hale getirdiğinden şikayet etmeye başladı.

Cevabım şuydu

sprint planlama ve inceleme toplantılarında, paydaşların önündeki arka uç görevlerini görünür kılmak için tartışıyoruz ve
proje sırasında yüksek kalitenin korunması, diğer ekiplerden daha yavaş bir başlangıç hızıyla sonuçlanacaktır, ancak proje sırasında sabit bir hıza sahip olacağız. Ve hız paydaşlar tarafından oldukça görünür.

Hâlâ şöyle bir hikayeye sahip olmakta ısrar ediyor: "Bir geliştirici olarak iş mantığını kapsülleyebilmem için bir etki alanı katmanına ihtiyacım var."

Ekibi kirletmeden önce sorunu nasıl çözebilirim?

Sorunun kökü, yönetimimizin sistematik olarak arka uç çalışmasını görünmez olarak görmesi ve destekli devs madencileri veya diğer aşağılayıcı terimler olarak görmesidir.

— Szili
kaynak

7

Ben arka uç hikayeleri olmayacaktı, hiçbir mantıklı .. Ancak, bu tür yöneticilere sahip olmak istemem .. Arka uç geliştiricilerin bir süre önce rock

— yıldızları

2

Ayrı arka uç hikayeleri yapmak, arka uç çalışmasının ön uçtan ayrı olarak önceliklendirilebileceği anlamına gelir. Bu, önceliklerin, arka uç çalışmanın ön uç hikayelerine yeniden dahil edilinceye kadar birikmiş işin alt kısmına düşeceği şekilde atanma riskine sahiptir. Yönetim tarafından takdir edilmeme sorunu için, Workplace.SE'de bunu sormanızı tavsiye ederim.

— Bart van Ingen Schenau

Fantezi çözümüm, tüm tarafların zaman zaman tokatlanmasını içerir. tokat sızlanmayı durdur. tokat Verilerin ve iş mantığının kiranızı ödeyen işletmenin başarısına katkıda bulunduğu kritik öneme sahip olan rolü göz ardı etmeyi bırakın. tokat Başkalarının öğle yemeğini yemeyi bırak. Bu annenin buzdolabý deđil.

— Erik Reppen

1

konuları dikey olarak dilimleyin, ardından ortaya çıkan öyküleri yatay görevlere dilimleyin.

— jwenting

5

Açıklanan durumla ilgili birkaç yanlışlık var, bariz sorun arka uç geliştiricilere verilen saygısızlık. Bu soru çevik olarak etiketlendiğinden, bunun sadece sosyal bir sorun olduğunu öne süren diğer cevapları geri iteceğim. Hikayenizde, cahil yönetim ya da hikayeleri nasıl dilimlediğinizle ilgili olmayan birkaç kötü koku ve olası anti-desen var.

Takımdaki bir grup kişinin işten şan almadığı için kaybolmuş hissetmesi, birçok olası sorunun şaplaklarını tamamladı.

Sadece arka uç gelişimi yapan insanlar olmamalıdır. Ortak bir Agile yaklaşımı, ortak kod sahipliğini uygulayan genelleme uzmanlarından oluşan çapraz fonksiyonel ekiplere sahip olmaktır. Bireyler sadece arka uç veya ön uç gelişimine odaklanmamalıdır, ancak bazı şeylerde kesinlikle diğerlerinden daha deneyimli veya daha iyi olacaktır.
Mimarlık değer kazanmaz. Bir kullanıcının bakış açısından - gerçekten önemli olan tek bakış açısı - katmanlarınız veya etki alanı dilleriniz olması veya çözümün programlanmış olması bile önemli değildir. Önemli olan tek şey kullanıcılar için değer yaratıp yaratmadığınızdır. Arka uç geliştiriciden önerilen "hikaye" saçma bir gerekliliktir - bir kullanıcı / müşterinin bakış açısıyla istenen işlevselliği elde etmek için hiçbir şey yapmayan tasarım kararlarının bir özetidir. Başka bir deyişle, herhangi bir kullanıcı öyküsü herhangi bir sayıda farklı mimari tasarımla elde edilebilir. Bir kullanıcı öyküsünün arka uçta hiçbir değişiklik yapılmadan tamamlanmış olması mümkündür. Bu onu geçersiz bir hikaye yapmaz.
Sistematik düşünmek hala önemlidir. Mimarlık değer kazanmasa da, başarı için hala kritiktir. Arka uç geliştiricinin bazı geçerli endişeleri vardır. Sistemi nasıl kuracağınızı düşünmelisiniz. Bu kararları not ediyor olmalısınız. Sadece ön uç özellikler, tüm ihtişamı alacak şeyler olsa da, tüm sistem önemlidir.

Benim tavsiyem mimariye birinci sınıf bir vatandaş olarak davranmak - ama bunu doğru şekilde yapmak. Paydaşlarla bir kalite özellikleri atölyesi gerçekleştirin . Önemli paydaşları mimari incelemelere dahil edin veya en azından önemli kilometre taşlarındaki temel tasarım kararlarını özetleyin. Mimariyi büyük kağıda çizin ve tüm ekibin görebilmesi için görünür kılın.

Herkesin sistemin her yerinde (ön uç ve arka uç) gelişmesini zorunlu kılın, gerekirse etkili bir şekilde gerçekleşmesi için programı eşleştirin. Kullanıcı odaklı kullanıcı hikayeleri oluşturmaya devam edin. Ancak, sistemin neden bu şekilde tasarlandığını gösteren ve "arka uç" tasarımı ile ilgili karar almaya iten temel kalite özellik senaryolarını da belirleyin. Artık görünmez olmayacak şekilde mimari tasarımı yükseltin.

— Michael
kaynak

1

İşlem yapılabilir bir cevap için teşekkür ederiz! Yanlış ifadelerimin neden olduğu bir anlayışı açıklığa kavuşturmak istiyorum. O sadece bir "arka uç geliştirici" değil aslında o firmware bile tüm yığın üzerinde çalışıyor. Acı noktası, arka uç mimarisinin doğru tanınmamasıdır. Ve mimarlık kendi başına değer kazanmasa da, özensiz bir mimari sistemleri kırabilir veya en azından onları çok pahalı hale getirebilir. Planım, inceleme ve planlama toplantıları sırasında mimari hakkında daha fazla konuşmayı kolaylaştırmaktı ve kaliteli atölye de harika bir araç gibi görünüyor!

— Szili

FWIW, bir geliştiricinin tüm yığını çalıştırması her zaman pratik değildir. Mevcut şirketimdeki bir gereksinim bir IBM anabilgisayarında CICS geliştirme, MQ, Mule ESB'de Java, Datapower ve son olarak jquery ve diğer şablonlarla zengin bir web kullanıcı arayüzü olabilir. Başka bir kullanıcı hikayesi CORBA'nın VMS COBOL ile konuşmasını içerebilir ve başka bir arka uç Gupta'da yazılmıştır.

— Alan Shutko

@AlanShutko - tam olarak. "Bir kişinin ön ucu başka birinin arka ucu" değil mi? Bu, özellikle bir sistemdeki birden fazla bileşen hakkında konuşurken "arka uç" ve "ön uç" gibi argodan hoşlanmamamın nedenlerinden biridir. Demek istediğin çok önemli! "Tam yığın" bile, sistemin farklı bölümlerinde farklı anlamlara gelebilecek göreceli bir terimdir!

— Michael

11

Bu sosyal bir sorun gibi görünüyor, bu yüzden sosyal bir çözüme ihtiyaç duyacak.

(Seni anladığım gibi) arka uç geliştiricileri yok sayılır ve kaybolur ve çalışmalarının yeterince değerli olmadığını düşünürse, geliştirme sürecinin bunu değiştirmek için yapabileceği çok az şey vardır.

Eğer doğru anlarsam, devs en azından kendi "kendi" kullanıcı hikayeleri olması gerektiğini hissediyorum, böylece onlara işaret ve "Biz bunu yaptım, sadece biz arka uç çocuklar / gals" diyebiliriz. Ancak, bu şekilde "yatay" olarak kesilmiş öykülere sahip olmak kötü bir fikirdir ve onları dikey olarak dilimlemenize katılıyorum.

En iyi çözüm muhtemelen söz konusu geliştirici (ler) ile (bireysel veya grup olarak) sessiz bir konuşma yapmak ve saygı duyulan bir sorun gibi görünen temel sorunu ele almaktır. Bir noktada, bunun muhtemelen yönetime yükseltilmesi gerekecektir.

— sleske
kaynak

cevaplar için teşekkür ederim. Sorun aslında sosyal bir sorundur. Bugün dünkü tartışmayı konuştuk ve söz konusu geliştirici bana bunun, arka projemizdeki yıllarca sistematik saygısızlıktan, mevcut projemize ve scrum sürecini anlamasından çok daha fazla olduğunu söyledi. Dikey olarak kesilmiş öykülerle ilerlemeye karar verdik.

— Szili

1

@Szili: Arka ucun çalışması, herhangi bir saygıyı hak etmeyecek kadar kötü mü, yoksa tanınmadığı için işaretlenmiş mi?

— Blrfl

Arka uç çalışması mükemmel. Doğru tanıma ve hatta yönetim zorbalığı problemdir.

— Szili

4

Sorunun kökü, yönetimimizin sistematik olarak arka uç çalışmasını görünmez olarak görmesi ve destekli devs madencileri veya diğer aşağılayıcı terimler olarak görmesidir.

Aslında sorun budur. Açıkçası hikayelerle çözmeyeceksiniz!

Genel olarak, çevik gelişimin özelliklerinden biri şeffaflıktır. Bu aynı zamanda kurumsal sorunlarınızı daha belirgin hale getirdiği anlamına gelir .

Bu soruna standart çevik çözüm, arka uç geliştiricilerin arka uç katmanının rahatlık alanlarında çalışmak yerine yukarıdan aşağıya hikayeler aldığı, gelişime daha "dikey" veya "tam yığın" bir yaklaşım benimsemektir ve frontend devs de arka uca doğru uzanır (*).

Başka bir deyişle: herkesin son kullanıcılarınız için değer üretmesini sağlayın.

^{(*) Not: tüm öykülerin bir ön uç bileşeni veya bir arka uç bileşeni olması gerekmez. Kullanıcı arabirimi öğeleri ek arka uç çalışması olmadan yeniden karıştırılabilir ve performans bir özelliktir .}

— Sklivvz
kaynak

3

Arka uç gelişimi hakkında sıfır anlayışa sahip olduğunuz anlaşılıyor. Ön uç çocuklar ön uçtaki tüm veri modelleme ve mantık uygulamasını yaptıktan sonra altı ay beklediklerinde iyi bir arka uç adamın ne kadar az değer verdiğini görün. Çoğu iyi mühendislik anlık değer üretmek konusunda iyi değildir, uzun vadeli temettüler üretmekle ilgilidir. Köprü inşasına uygulanan yaklaşımınız her köprüyü sadece bir hafta boyunca ayakta tutacaktır ve bir plan veya mimara sahip olmayacaktır, çünkü bunlar hemen değer değildir.

— Jimmy Hoffa

1

Hayır @JimmyHoffa Arka uç gelişimine oldukça aşinayım. Cevabım hemen hemen ders kitabı çevik. Fark edebileceğiniz gibi, sadece ön uç insanlara sahip olmayı savunmuyorum. Eğer çevik sevmiyorsanız, kullanmayın, ama ben sadece bir metodolojinin nasıl çalıştığını açıklıyorum, bu yüzden benim hakkımda bir şey varsaymayın, ya da başka bir şey.

— Sklivvz

2

Pistten ayrıldığı kısım, arka uç adamların değer üretmediğini ve sadece ön uç işi yapması gerektiğini söylediğiniz bölümdür, eğer bu cevaptaki niyetiniz bu değilse, daha net olması için gerçekten yeniden yazmalısınız. burada ne demek istiyorsun.

— Jimmy Hoffa

1

@JimmyHoffa Ama değil son kullanıcıya, herhangi bir değeri üreten. Sadece arka uç geliştiricilerinden oluşan bir ekip olsaydı, kullanıcılar ön uç geliştiriciler olurdu. Bu durumda mantığınız mantıklı olacaktır, ancak durum böyle görünmemektedir.

— Sklivvz

1

Eğer dünyanızda değer sadece kullanıcı etkileşimli bir ürünün yaratılmasıyla üretiliyorsa ve arka uç geliştiriciler buna gerek duymuyorsa, o zaman dünyanızda mimarlar ve proje yöneticileri, iş analistleri, İK ve diğer herkes de ilgisizdir. Benim dünyamda değer, gelecekteki özellik gelişimi bir erişim veritabanının örümcek ağı üzerinden dolaşmayı gerektirmeyecek şekilde bir sistem tasarımı ve uygulamasının kalitesiyle üretilir, çünkü yalnızca kullanıcı ile etkileşime girebilen ürüne değer verilir ... Kalite uygulaması değerdir . Belki hemen değil, uzun vadede.

— Jimmy Hoffa

1

Sorunlarınız:

İşletmenizde hiçbir amaca hizmet etmeyen yönetim katmanlarınız var. Scrum, çevik, umrumda değil. Yönetim ve geliştirme, teknoloji hakkında! @ # $ İngilizce ipucu veren bir ürün yöneticisi tarafından ele alınan ticari kaygılarla izole edilmelidir. Belki Steve Jobs için işe yaradı, ancak teknolojiye uygun olmayan yöneticilerin dev'e yakın olmanın sağlıklı bir şey olduğu veya nihayetinde bir ekibin yapabileceği en kaliteli ürünü üretmeye hizmet etmediğim bir durumda bulunmadım.
Görünüşler konusunda problem çözmekten daha endişeli olan geliştiricileriniz var. Bu ya çok ciddi bir kültür problemidir (muhtemelen tüm bu "madencilik" fenomeni göz önüne alındığında) ve / veya bir dev kalite sorununuz var, bu da güven eksikliği göz önüne alındığında beni şok etmeyecek.

Orada olması gerekmeyen insanları planlama ve ayağa kalkma. Arka ucun ön uçtan daha az önemli olduğu konusunda fikirleri olan herkes, orada olması gerekmeyen ve aslında süreci orada bulunarak engelleyen kişidir.

Hendek hikayeleri. Evet, ciddiyim. Bu tür sorunlara neden oluyorlarsa, hava kilidini dışarı atın. Şu anki işimde, belirli bir görev için "bitmiş" ölçütlere sadık kalıyoruz, bu da genellikle uygulamaya göre daha fazla odaklanmış durumda. Eğer mektuba uymazsanız işe yaramaz, ama gerçekten de profesyonel olursak, bizim için sorun yaratan hiçbir şeye ihtiyacımız yoktur. Onları parçala, omzunun üzerinden at.

Ve gerçekten endişelenmeleri gereken insanların sprint planlaması için fazla clueless olan insanlar değil, yakın akranları olduğunu hatırlatmak isteyebilirsiniz.

— Erik Reppen
kaynak

İyi tavsiye. Çevik manifestoda "kullanıcı hikayeleri" hakkında hiçbir şey olmadığını ve sadece belirli süreçlerle ortaya çıkan popüler bir uygulama olduğunu unutmayın. Kullanıcı hikayeleri olmadan olabildiğince çevik olabilir ..

— Michael

Bu doğru. Çevik manifestoların etrafında inşa edilen tüm eğitim endüstrisinin standartlarının birçoğu tarafından “doğru yapmak” için yeterli olacağından emin değilim, ama her zaman olduğu gibi fikirler ve hangilerinin sizin için anlamlı olduğu ve ekibiniz IMO, bu eğilimlere öncelik vermelidir. Ayrıca, bu cepheden, üniversite öğrencilerine flört kurallarının ne olduğunu soracağınız gibi, "nasıl çevik" yapılacağına dair doğru cevaplar alacaksınız. Eleştirel düşünmenin yerini tutamaz.

— Erik Reppen

Kullanıcı hikayelerinden vazgeçmem. Aslında, son kullanıcılara saygısızlık geleneğimiz olduğu için onları tanıtmak için çok çalışıyorum. Steve Jobs benzetmesi, CEO'muz multi-milyon şirketi ön plana çıkaran mükemmel bir teknik adam olduğu için çok uygundur. Başarısız olduğu tek şey bir yönetim katmanı oluşturmaktır, bu yüzden yapılan işle çok el ele tuttu. Bu, görünüşler için endişelenen yıldız kültürünün ortaya çıkmasına yol açtı. Özetlemek gerekirse: kültürel bir sorunumuz var. Ancak verilen şekilde göz önüne alındığında, bebeğin adımlarını atmak için cevaptaki gibi araçlara ihtiyacım var.

— Szili

Her iki durumda da, UX sorunları yaşıyorsanız deneyimli bir anal-retentive UI dev öneriyoruz. Çok az sayıda genel ekibin tam bir takım ödemek isteyeceği bazı müthiş genelistleri yasaklayan hiçbir yedek yoktur.

— Erik Reppen