GoldenLine
Zaloguj się
Karol Traczykowski

Karol Traczykowski Head of New Ventures
@ ZnanyLekarz.pl

Temat: jak pogodzić backend z frontendem ?

Hej,
mam problem i chętnie poznałbym Waszą opinię na ten temat.

Załóżmy, że trzeba zrealizować jakiś serwis/aplikację z dość zaawansowanym backendem i sensownym interfejsem użytkownika. Chciałoby się na koniec iteracji oddać na produkcję lub do testowania jakieś kompletne funkcjonalności (działający backend + UI do niego).

Zazwyczaj jest tak, że frontend developer 'ostylowuje' dane wystawione mu przez backendowców. Zatem siłą rzeczy, frontendowiec zaczyna pracować nad danym modułem co najmniej w końcowej fazie prac backendowców. Jeśli jeszcze do tego osób od frontendu jest mniej, to na koniec iteracji okazuje się, że mamy spory kawałek funkcjonalności dla których jest backend, ale nie ma frontendu, więc de facto nie nadają się do wdrożenia lub testowania.

Jak poradzić sobie z takim problemem? ew. gdzie robię błąd ?

Z góry dzięki za odpowiedzi.
Link do wypowiedziLink
Piotr T.

Piotr T. Spring/Microservices

Temat: jak pogodzić backend z frontendem ?

Karol Traczykowski:

Zazwyczaj jest tak, że frontend developer 'ostylowuje' dane wystawione mu przez backendowców. Zatem siłą rzeczy, frontendowiec zaczyna pracować nad danym modułem co najmniej w końcowej fazie prac backendowców.
Jeśli backendowcy zaczną od zdefiniowania interfejsu i napiszą proste atrapy to frontendowiec będzie mógł zacząć pracę wcześniej.Zamiast się nudzić ;)Piotr T. edytował(a) ten post dnia 24.06.10 o godzinie 15:53
Link do wypowiedziLink
Paweł Lipiński

Paweł Lipiński Właściciel,
Pragmatists Sp. z
o.o.

Temat: jak pogodzić backend z frontendem ?

To trochę zależy co to za UI. Jeśli to faktycznie tylko ostylowanie HTMLa za pomocą CSS to poleciłbym zaangażowanie UIowców w cały frontend, tak żeby mogli tworzyć UI gdy reszta "walczy" z danymi. Wtedy pozostaje tylko ustalenie jakiegoś wspólnego interfejsu.
Jeśli jednak nie możecie tego zorganizować inaczej (tzn UIowcy tylko stylują i kropka), to polecałbym coś bardziej a'la scrumban - dorzućcie na scrumboard'dzie kolumnę 'UI' i każde zadanie związane z UI będzie tam wpadało po wyjściu od backendowców. A za 'done' będziecie uważać te zadania, które już mają frontend. Jeśli będziecie mieli krótkie sprinty, to może być całkiem niezłe rozwiązanie - opóźnienie Ui'a będzie nieduże.

Paweł
Link do wypowiedziLink
Łukasz S.

Łukasz S. Engagement Manager,
Capgemini

Temat: jak pogodzić backend z frontendem ?

Paweł Lipiński:
Jeśli jednak nie możecie tego zorganizować inaczej (tzn UIowcy tylko stylują i kropka), to polecałbym coś bardziej a'la scrumban - dorzućcie na scrumboard'dzie kolumnę 'UI' i każde zadanie związane z UI będzie tam wpadało po wyjściu od backendowców. A za 'done' będziecie uważać te zadania, które już mają frontend.

Sam Scrumboard pomoże jedynie lepiej pokazać anomalie (w tym przypadku frontendowców jako wąskie gardło). To nie jest rozwiązanie problemu.
Jeśli będziecie mieli krótkie sprinty, to może być całkiem niezłe rozwiązanie - opóźnienie Ui'a będzie nieduże.

Jedyna różnica w długości sprintów to wydolność zespołu w dostarczaniu wartości biznesowych. W dłuższym sprincie dostarczamy więcej w krótszym mniej. Frontedowcy nadal będą zawaleni robotą pod koniec cyklu pracy nad daną funkcjonalnością.
Karol Traczykowski:
Zazwyczaj jest tak, że frontend developer 'ostylowuje' dane wystawione mu
przez backendowców. Zatem siłą rzeczy, frontendowiec zaczyna pracować nad
danym modułem co najmniej w końcowej fazie prac backendowców. Jeśli jeszcze do > tego osób od frontendu jest mniej, to na koniec iteracji okazuje się, że mamy > spory kawałek funkcjonalności dla których jest backend, ale nie ma frontendu, > więc de facto nie nadają się do wdrożenia lub testowania.

Jak poradzić sobie z takim problemem? ew. gdzie robię błąd ?

Ja bym się zastanowił czy nie można pozbyć się tych "silosów", tj. frondendowców i backenowców. W zespole Scrum wszyscy pracują razem. Czy tak jest w przypadku FE-ów i BE-ców? Jeśli tak to czy można jakoś zdywersyfikować Ich kompetencje? To by bardzo pomogło w płynnym "wypuszczaniu" kolejnych funkcjonalności (w nawiązaniu do zasady przepływu jednej sztuki).
Link do wypowiedziLink
Sebastian Nowak

Sebastian Nowak Programista
aplikacji
internetowych

Temat: jak pogodzić backend z frontendem ?

U mnie w firmie wyglada to mniejwięcej tak: Jest jedna strona prototypes.html, na której są zbite wszystkie możliwe elementy jakie składają się na cały serwis/aplikacje (tabele, listy, formularze, buttony .... wszystko). I to jest robione na bieżąco, w miarę potrzeb przez ludzi od frontendu. Potem "backendowcy" - programiści sami z tych kawałków tworzą już konkretne podstrony wplatając w to swoje dane. Generalnie jest to wygodne bo taki programista przekleja sobie sporo kodu HTML z tych prototypes nie musi nic stylować bo tym już się zajeli ludzie od tego i idzie to całkiem sprawnie. Podejście sprawdza się przy Ruby on Rails, PHP. Ale myślę, że w innych technologiach też da radę pracować w ten sposób.
A jak to zorganizować? Frontendowcy najwięcej pracy mają na początku by ogarnąć jakieś prototypy, wizualizacje i tworzą prototypes.html ze stylami i JavaScriptem. A potem poprawki plus dokładanie nowych elementów.
Link do wypowiedziLink
Krystian K.

Krystian K. Agile Coach, Autor

Temat: jak pogodzić backend z frontendem ?

Karol Traczykowski:
Zazwyczaj jest tak, że frontend developer 'ostylowuje' dane wystawione mu przez backendowców. Zatem siłą rzeczy, frontendowiec zaczyna pracować nad danym modułem co najmniej w końcowej fazie prac backendowców.

Chwileczkę. Stawiasz tutaj założenia, które nie muszą być prawdziwe.
Mamy User Story i tam jako załącznik może być interfejs użytkownika. Może to być zdjęcie szkicu na kartce. Dzięki temu fronted developer wie jak to mniej więcej ma być i backend developer wie jakie dane dostarczyć.
Jeżeli frontend i backend deweloperzy pracują razem w Sprincie, to powinni być w stanie dostarczyć jedno i drugie na raz. Oczywiście proces dewelopmentu oddziela model, view i controller.
Jeśli jeszcze do tego osób od frontendu jest mniej, to na koniec iteracji okazuje się, że mamy spory kawałek funkcjonalności dla których jest backend, ale nie ma frontendu, więc de facto nie nadają się do wdrożenia lub testowania.

Deweloperzy backend mogą zrobić sobie prototyp interfejsu na przykład proste tabelki z HTML zamiast ostylowanych DIVów.
Testerzy mogą przez ten prototyp testować i automatyzować. Dobrze zrobiona automatyzacja pozwala na zmianę parametrów w jednym miejscu w momencie zmiany interfejsu.

Sprint dostarcza potentially shippable product - nie musi to być produkt z ostatecznym interfejsem. Jeżeli faktycznie faza projektowania frontendu trwa dłużej niż Sprint, podłączamy nowy interfejs w kolejnym Sprincie.

Można też wypełniać interfejs danymi stopniowo implementując zasady steel thread i INVEST.
Link do wypowiedziLink

konto usunięte

Temat: jak pogodzić backend z frontendem ?

Karol Traczykowski:
Jak poradzić sobie z takim problemem? ew. gdzie robię błąd ?

Karol, w kilku znanych mi zespolach robiacych aplikacje Webowe historyjki tego typu de facto rozbijane sa na dwie mniejsze - pierwsza z nich dotyczy stworzenia "backendu" i najprostszego UI (bez cudowania z CSS, JS i innymi wodotryskami) natomiast celem drugiej jest dostarczenie ladnego UI. Czesto pierwsza i druga historyjka znajduja sie w roznych iteracjach dzieki czemu oddzielane sa dyskusje o funkcjonalnosci od rozmow o kolorach przycisku.

Teoretycznie takie podejscie ma kilka wad (np. historyjki sa od siebie uzaleznione). Natomiast w praktyce dobrze sie sprawdza w sytuacji gdy kto inny zajmuje sie frontendem, a kto inny koduje wlasciwa funkcjonalnosc. Ale moze rzeczywiscie, jak proponuje Lukasz, mozna uniknac tak sztywnego podzialu kompetencji?

Pozdrawiam,
Kuba
Link do wypowiedziLink

konto usunięte

Temat: jak pogodzić backend z frontendem ?

Dzielić historyjki (user stories) na mniejsze. Jednak tak, żeby to nadal były prawdziwe dobre historyjki, np. zgodne z zasadami INVEST, o czym wspomniał Krystian.

Niestety w zespołach złożonych z ludzi przywiązanych do swoich specjalizacji naturalną tendencją jest dzielenie wg. warstw aplikacji. Jest to pójście na łatwiznę i przemycanie podejścia kaskadowego.

Polecam dobry artykuł o wzorcach dzielenia historyjek Patterns for Splitting User Stories.Bogdan B. edytował(a) ten post dnia 25.06.10 o godzinie 18:14
Link do wypowiedziLink
Paweł Z.

Paweł Z. coach zespołów, LGBT
Coaching

Temat: jak pogodzić backend z frontendem ?

Też myślę, że takie ścisłe rozdzielenie kompetencji prowadzi do modelu kaskadowego.
User Stories w zasadzie też nie powinny rozdzielać za mocno warstw. Zwykle dostarczenie jakiejś historii wymaga angażowania przekroju warstw.
User story dzieli się odpowiednio na Taski tak, aby każdy miał co robić.

Odpowiednia architektura pozwala na takie zrównoważenie zadań - MVC nie nadaje się moim zdaniem do aplikacji webowych (i nie chodzi nawet o to że ciężko jest testować...) Jest dużo lepszy pattern - MVP.
Link do wypowiedziLink
Karol Traczykowski

Karol Traczykowski Head of New Ventures
@ ZnanyLekarz.pl

Temat: jak pogodzić backend z frontendem ?

Wielkie dzięki za wszystkie odpowiedzi. Cieszę się, że tyle osób zabrało głos :)

Zdecydowanie chciałbym uniknąć dzielenia historyjek na backendowe + frontendowe, a tym bardziej realizacji ich w oddzielnych iteracjach. Z powodów wspomnianych m.in. tu: http://xp123.com/xplor/xp0308/index.shtml (nie są Valuable i Intependent). Poza tym ciężko zmusić klienta/PO do oglądania/testowania czegoś co jeszcze nie wygląda zbyt dobrze.

Z drugiej strony ciężko mi sobie wyobrazić programistę, który sprawnie zaimplementuje od A do Z funkcjonalności wymagające wiedzy/doświadczenia z zakresu skalowalności i optymalizacji po stronie backendu oraz zaprezentuje to w ładnym, interaktywnym, pełnym wodotrysków UI.

Stąd wydaje mi się, że pewnej specjalizacji nie da się uniknąć. Oczywiście developerzy stale i blisko ze sobą współpracują. Nie jest też tak, że developer PHP/Python/Java nie dotknie JS/CSS i odwrotnie.

Jeszcze raz dzięki za pomoc. Postaram się skupić na realizacji:
Jeżeli frontend i backend deweloperzy pracują razem w Sprincie, to powinni być
w stanie dostarczyć jedno i drugie na raz
;)

EDIT:

Swoją drogą, czy przykład do Pattern #6: Data Entry Methods Patterns for Splitting User Stories:
As a user, I can search for flights between two destinations.
...using simple date input.
...with a fancy calendar UI.

nie jest właśnie podziałem podchodzącym pod rozdzielenie warstw ?Karol Traczykowski edytował(a) ten post dnia 26.06.10 o godzinie 16:14
Link do wypowiedziLink
Krystian K.

Krystian K. Agile Coach, Autor

Temat: jak pogodzić backend z frontendem ?

Karol Traczykowski:
Swoją drogą, czy przykład do Pattern #6: Data Entry Methods Patterns for Splitting User Stories:
As a user, I can search for flights between two destinations.
...using simple date input.
...with a fancy calendar UI.

nie jest właśnie podziałem podchodzącym pod rozdzielenie warstw ?

Nie jest. Tutaj chodzi o stopniowe budowanie interfejsu i tak samo stopniowe budowanie backendu. Dodajemy po kolei opcje wyszukiwania, które są w pełni funkcjonalne zamiast w jednym Sprincie budować cały interfejs, który nie ma funkcjonalności i "uzbrajać" go w kolejnych Sprintach.
Link do wypowiedziLink
« Wróć do tematów
Odpowiedz

Podobne tematy


Następna dyskusja:

[crosspost]Jak, bez uzycia ...




Wyślij zaproszenie do
Anuluj