Z jednej strony wiemy, że jeśli budujemy aplikacje, to raczej nie zaczynamy od interfejsu użytkownika, tylko od domeny. Ale z drugiej, Agile mówi że jak najszybciej trzeba pokazać progres userowi, a nie pokażemy go bez UI'a.
Jak wy podchodzicie do połączenia tych dwóch podejść?
przecież po to mamy podział i kontrakty pomiędzy (np. REST APIs) aby pracę można było realizować niezależnie i równolegle, prawda?
więc skąd to pytanie?
a od czego by wypadałoby wyjść? pewnie od dokumentacji / wymagań umożliwiających równoległą pracę
a jeżeli backend nie jest gotowy, to może warto zwracać spreparowane dane na potrzeby prezentacji - aby pokazać jak to będzie wyglądać (nie deploy na produkcje, a demo)
Graficy przygotowują mockupy UI do ustalenia z klientem.
Ale to jest faza projektowania, nie implementacji.
Jeśli miałoby być tak, że najpierw robimy cały backend a potem front to mamy coś pokoju waterfall.
Waterfall na backend i potem może agile na front.
Agile AFAIK dlatego zdobył popularność bo nie tworzymy dużej kobyły i nie oddajemy do testów.
Wyobraźmy sobie sytuację gdy określamy w fazie projektowania, że na danym widoku mamy zaakceptowaną tabelkę z 3 kolumnami. Pod spodem prosty REST zwracający takie dane.
Przy zwinnym podejściu oddajemy taki feature. Klient klika sobie i jednak uświadamia sobie, że potrzebuje nie trzy a pięć kolumn i do tego jednak jakieś podsumowanie czyli powiedzmy drugi endpoint. Czyli jeśli użylibyśmy tego endointu gdzieś indziej to już trzeba by było zmieniać go wszędzie.
Sytuacja kiedy robimy backend i robimy front po skończeniu backendu to właśnie IMHO anty agile. Bo może skończyć się na tym, że stworzysz backend a potem będziesz go przepisywał przy iteracyjnym powstawaniu frontu.
W projektach "od zera" w jakich brałem udział, często po powstaniu jednej części, druga wyglądała zupełnie inaczej niż to jak była opisywana przez klienta na początku.
IMHO najlepiej mieć zarys aplikacji, potem w iteracjach tworzyć:
Ale ciągle w iteracjach.
Oczywiście na ile to można zrobić, bo z jakiegoś punktu gdzie jest domena oprogramowna trzeba wyjść. Nie można też popadać w skrajności.
Myślę, że wskazane byłoby, żeby nie było zadań stricte backendowych i frontendowych (przynajmniej przed ich podzieleniem). Istotą Agile jest to, że zadania mają odzwierciedlać rzeczywiste potrzeby użytkownika, a nie techniczne szczegóły. W praktyce często robi się inaczej, ale cóż… W każdym razie, należy rozwijać jedno i drugie na bieżąco, przynajmniej na poziomie sprintu, żeby zaprezentować coś co działa i nie jest żadnym mockiem; to już jest realne nawet w korpo-wariacjach na temat Agile.
somekind napisał(a):
Graficy przygotowują mockupy UI do ustalenia z klientem.
Ale to jest faza projektowania, nie implementacji.
Ale ja nie mówię o witrynach czy stronach internetowych, tylko aplikacjach jak np edytor 3d, jakaś gra online, coś co ma dużo logiki.
Poza tym "graficy przygotują mockup" to też jest rozpoczęcie od UI.
elwis napisał(a):
Myślę, że wskazane byłoby, żeby nie było zadań stricte backendowych i frontendowych (przynajmniej przed ich podzieleniem). Istotą Agile jest to, że zadania mają odzwierciedlać rzeczywiste potrzeby użytkownika, a nie techniczne szczegóły. W praktyce często robi się inaczej, ale cóż… W każdym razie, należy rozwijać jedno i drugie na bieżąco, przynajmniej na poziomie sprintu, żeby zaprezentować coś co działa i nie jest żadnym mockiem; to już jest realne nawet w korpo-wariacjach na temat Agile.
Nie bawię się w takie rozdziałki na front i backend. Chodzi mi o to jak jedna osoba dostarcza całą aplikacje, powiedzmy odtwarzacz video.
Najpierw niedookreślenie o co chodzi, a teraz okazuje się że z tematu podejść wytwarzania oprogramowania dla zespołów jest jednak jedna osoba
Z czym tak faktycznie jest problem? klient chce abyś mu pokazał progress, a ty nie masz mu co pokazać bo 2 tygodnie klepałeś "algorytmy", a to ciężej pokazać?
No to odtwarzacz video w jakichś pierwszych iteracjach powinien według mnie dać odtworzyć jeden format pliku. Potem można dodawać nastpeny format, playlistę, informacje dodatkowe. Wszystko to jednak ma front, który może być zaprojektowany przez kogoś z UX/UI w formie mockup.
Uściślijmy. Robisz apkę dla kogoś. Nie jest to Twój własny projekt w którym jesteś sam sterem, żeglarzem, okrętem fundatorem. Wtedy przez pierwszy okres musisz zaklepać coś do stanu odtwarzania jedengo formatu i przez ten czas co najwyżej opisujesz postępy.
Przecież jak tak piszesz to można robić i apkę bez żadnego frontu, która w tle robi tylko jakieś obliczenia aby na koniec zrobić może jeden output typu:
print(powalonaMedianaZarobkowProgramistowZ4PWedlugWystawianychFakturWPorwnaniuDoOpisWDzialeKariera)
Z tym mockowaniem danych na frontendzie to są niezłe jaja. Ostatnio prawie taką wersję wydaliśmy na produkcję. Frontend zamockował prawdziwymi danymi. Potem te dane zostały dodane do bazy danych, ale frontend ich nie czytał, ale wszystko było w porzadku bo to te same dane. A potem lekko się zmieniły w bazie i było zdziwienie czemu czasem działa a czasem nie XD
Riddle napisał(a):
Z jednej strony wiemy, że jeśli budujemy aplikacje, to raczej nie zaczynamy od interfejsu użytkownika, tylko od domeny. Ale z drugiej, Agile mówi że jak najszybciej trzeba pokazać progres userowi, a nie pokażemy go bez UI'a.
Jak wy podchodzicie do połączenia tych dwóch podejść?
Jeśli podchodzimy prawidłowo (czyli z użyciem TDD) to mamy ładne pokrycie testami. Wystarczy wtedy pokazać klientowi ładny raport z testów, ew. udostępnić mu Postmana. Taki barebone UI powinien wystarczyć na początek.
Dla mnie zaczynanie od frontu to jest od początku. w zasadzie nazwa "front" to wskazuje.
Najszybciej zbieramy wymagania.
Backendu najlepiej w ogóle nie robić. YAGNI
Wybór nigdy nie jest zero-jedynkowy. Wyobraż sobię sytuację, gdzie masz skomplikowany projekt od strony backendu oraz zespół: 1 front i 5 backendowców, gdzie każdy coś tam potrafi wyklikać w JSie. W podejściu "robimy UI jak najszybciej się da" wrzucamy 6 devów do klikania fronta co sprawi, że powstanie on minimalnie szybciej niż napisany przez jednego frontendowca, gdzie lepiej byłoby zacząć pracę po stronie backendu od samego początku. jak najszybciej trzeba pokazać progres userowi to dobry argument, ale nie jedyny i podczas planowania pracy trzeba myśleć o wszystkim
W moim przypadku zwykle istnieje już backend i działająca wersja webowa, a potem dopisuje się frontend mobilny o podobnej funkcjonalności. Więc backend jest najpierw.
zaczynanie od backendu to zawsze proszenie się o problemy i robienie potem roboty wielokrotnie, optymalizowanie sztucznie bo nasz model nie pasuje do tego w jaki sposób querowane są dane z frontu itd.
Użytkownik ma w pizdzie domenę. Dla niego liczy się efektywne (pod katem UI/UX) wykonywanie procesu i intuicyjne rozumienie jego stanu. A to jak to sobie w piwnicy zapiszesz ma mniejsze znaczenie.
Frontend first tez dokładniej kształtuje domenę bo mamy naoczne procesy użytkownika a nie gdybanie o wirtualnych bytach.
Najlepszy projekt w jakim pracowałem był ułożony w następujący sposób:
Wiadomo, że nie zawsze wszystko działało idealnie i zdarzały się rozjazdy/obsuwy bo ktoś się na czymś zawiesił czy tam zablokował przez co frontend webowy i backend danego ficzera były dostępne na koniec sprintu, a ten sam ficzer w apce mobilnej zaliczał obsuwe i trzeba było gonić, czasem PO nie miał czasu aby coś opisać/przygotować, albo zrobił to zbyt ogólnie, ale tak wygląda rzeczywistość, że nie zawsze wszystko będzie od linijki. Na plus 70-80% ficzerów było dowożone na czas, nie trzeba było niczego mockować, ani kombinować kto czym się powinien zająć żeby nie siedzieć bezczynnie bo cel sprintu był jasno określony i był zorientowany na cel biznesowy a nie implementacyjny czy techniczny. Na minus trudno o takiego dobrego PO jak i zespół programistyczny, który rozumie czym jest Agile i potrafi sam się zorganizować.
Robię jako Java Developer 6 lat expa backend ale zaczynam pracę teraz głównie od frontu, przedstawienia kontraktu klientowi i uzgodnieniu co chce on widzieć :D
Zaczynałem kiedyś od backendu ale biznes lepiej reaguje jak coś widzi, widziałem pare razy ten błysk w ich oku jak pokazywałem już coś na początku w React zamiast sucho opowiadać co tam w Javie robię
somekind napisał(a):
Graficy przygotowują mockupy UI do ustalenia z klientem.
Ale to jest faza projektowania, nie implementacji.
Najpierw faza projektowania i potem faza implementacji bardzo brzmi jak nie-agile.
Ja się nie znam (nie kokietuję, serio), ale czy przypadkiem nie jest tak, że DDD zaczyna mieć sens od jakiejś tam skali/złożoności projektu? W aplikacji, która ma za zadanie zebrać od zainteresowanych klientów adresy email do newslettera, prawdopodobnie trzeba użyć nieco innego podejścia niż przy przy projekcie jakiegoś ERP'a za dziesiątki milionów.
Riddle napisał(a):
Najpierw faza projektowania i potem faza implementacji bardzo brzmi jak nie-agile.
Widzę to kompletnie inaczej. Żeby dostarczyć software, ogólnie trzeba:
W mitycznym waterfallu z opowieści scrum masterów, te fazy są rozplanowane na cały czas trwania projektu, w dodatku są wykonywane przez kompletnie różne osoby. Ktoś tam zbierze wymagania, ktoś tam wymyśli architekturę, ktoś inny powie, że zaimplementował, tester powie, że nie działa, programista mu wytłumaczy, że jednak działa (przynajmniej na komputerze programisty), wszystko przy założeniu, że osoba, która zbierała wymagania wciąż jest w firmie w momencie kiedy przychodzi do testowania.
Agile można nazwać "VHF waterfall" i z grubsza będzie to oddawało istotę tego podejścia. Skraca się czas trwania tych "faz" jak tylko można najbardziej (żadne tam 2 tygodnie), ale one nadal występują, bo ostatecznie zbieranie wymagań, implementacja i testy nadal są potrzebne. Tylko podział na te etapy przestaje być zauważalny, jeżeli całość jest skrócona do np. 1 dnia, ficzery są rozwijane równolegle przez różne osoby.
Ja się nie znam (nie kokietuję, serio), ale czy przypadkiem nie jest tak, że DDD zaczyna mieć sens od jakiejś tam skali/złożoności projektu? W aplikacji, która ma za zadanie zebrać od zainteresowanych klientów adresy email do newslettera, prawdopodobnie trzeba użyć nieco innego podejścia niż przy przy projekcie jakiegoś ERP'a za dziesiątki milionów.
Bo dokładnie tak jest. Każda poważna książka czy artykuł online o DDD to wyraźnie podkreśla.
W projektach o mniejszej złożoności też można (a czasem nawet powinno) się użyć niektórych strategicznych wzorców DDD takich jak destylacja domeny, mapy kontekstów, czy ustalenie języka wszechobecnego. Te wzorce są na tyle uniwersalne że pasują do każdego projektu. Jeżeli zrobimy to dobrze to będziemy mieli fajnie zaprojektowany system/aplikację z wyraźnymi granicami, modułami i "słowniczkiem" nazw i pojęć biznesowych który każdy rozumie. Bo rzadko kiedy będziemy mieli w aplikacji tylko jedną poddziedzinę. Zwykle będzie ich więcej, więc dobrze to odkryć już na początku i tak projektować rozwiązanie aby modele biznesowe tych poddziedzin ze sobą się nie mieszały.
@markone_dev: Fajnie, że wspominają, z drugiej strony w dyskusjach często się o tym zapomina i sprowadza rozwiązania do uniwersalnych prawd objawionych "dokumentacja jest zła clean code wystarczy", "nie pisz interface'ów go KISS", "pisz interface'y bo SOLID". Zresztą podając ten przykład z UX'ami, POsami też wpadłeś w tę pułapkę (no offence), chociaż osobiście uważam, że dużo ważniejsze od tego "w jaki sposób się pracuje" jest "z kim się pracuje". Jak zbierze się parę kompetentnych osób, to szybko znajdą sobie dobry sposób na efektywne dostarczanie "value". Jak się pracuje z dzbanami, to te procesy staną się jedynie okopami dla wszystkich obiboków, którzy będą udawać pracę, wszystko zgodnie z procedurami, zmiana działania prostej formatki trwa wieki. W ostatnim projekcie miałem takiego UX'a miglanca, który albo kompletnie nie ogarniał, albo szedł w ciężki over employment i kończyło się tym, że po kilku tygodniach dostawaliśmy projekt jakiejś banalnej formatki który może i dałby się zaimplementować, ale nikt z działającym mózgiem by tego nie zrobił. Wszystko okraszone workiem buzzwordów "persona oriented design", "cognitive evaluation", "A/B testing", a guzika nie dało się nacisnąć, bo był za mały na telefon, albo zbiór list pojedynczego wyboru "zaprojektowano" na checkboxach.
A już w temacie - jeżeli jako programista mam ogólne pojęcie do czego ma służyć aplikacja, to całkowicie wystarczy mi szkic UI + notatki dotyczące zachowania "język graficzny" dla aplikacji, czyli kolorki, i np. określenie "material design". Zaimplementuję "jak mi się podoba" zgodnie z tymi wytycznymi, zgarnę UX'a na godzinę, żeby mu pokazać co zostało zrobione, dojdziemy do porozumienia co i jak trzeba zmienić i UI zrobiony. Przy okazji wyjdą mi wszystkie interface'y, których potrzebuję, żeby ten UI działał, zrobię swagger file'a do tego, dopiszę testy do mocka i dam na backend. Jako backendowiec pomarudzę swoje, ale w końcu zaimplementuję, przy okazji unikając problemów, że API, które sobie wymyśliłem dla jakiegoś tam front'u będzie wymagało od frontu wysyłania 100 żądań przy ładowaniu każdego ekranu. Nie jest to ogólnie najlepszy sposób pracy, ale sprawdza się w przypadku ~małych aplikacji mobilnych/webowych, jeżeli tylko wszystkie zaangażowane osoby są w jednym miejscu (łatwość komunikacji), chcą zrobić dobry produkt i mają minimum skilla.
Nie sprawdzi się, jeżeli design jest podstawową wartością aplikacji, został zamówiony na freelance.com i stał się zabetonowany, którakolwiek ze stron jest przekonana o swojej uber zajebistości, albo domena jest na tyle skomplikowana, że nie da się sensownie zobrazować jej głównego sensu szkicami.
Oczywiście nie wyklucza to wykorzystania elementów DDD, bo w końcu np. nie ma sensu w aplikacji nazywać klienta użytkownikiem, skoro zamawiający nazywa go klientem.
Co do łączenia UX i domeny,. konflikt trochę pozorny moim zdaniem. Jeżeli mamy jakiegoś użytkownika (aktora), to zamawiający chce na ogół pozwolić temu aktorowi na wykonywanie pewnych działań (znaleźć informację o produkcie, dodać go do koszyka, zamówić...). Taka "persona oriented app" staje się zamkniętym kawałkiem systemu, który z resztą systemu powinien się wiązać możliwie zwięzłym API. Jednocześnie jako klient sklepu, nie mam najmniejszej ochoty wiedzieć jak zorganizowana jest "domena" i w jaki sposób sklep będzie obsługiwał moje zamówienie.
a czy w ogóle koniec końców agile to coś więcej niż buzzword? no wiecie - wszyscy są Agile, ale czy faktycznie?
a, i jeszcze czym jest dla was / u was Agile?
@WeiXiao:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Tak w skrócie i na wysokim poziomie. Dla mnie, w praktyce, to "wiem w jakim kierunku mam iść i tam idę". W praktyce trochę strach pisać o tym co u mnie działa, bo jak przeczyta to jakiś "software development consultant", to opisze i kolejne pokolenie programistów będzie się męczyć z niby-zwinną metodyką, która u kogoś zadziałała, ale zaryzykujmy:
W realiach korporacji - wziąć ze schroniska kilka dużych psów i szczuć nimi wszelkiej maści agile coachy, certyfikowanych SM'ów, i inne indywidua, które biegają na około projektu i próbują zmienić jego sens z dostarczenia działającego oprogramowania spełniającego wymagania klienta, na dostarczanie wskaźników, arkuszy w excelu, metryk, raportów zgodności z referencyjną architekturą, KPI od DevOps, backlogu, velocity i innego syfu, na który przepalane jest ~80% czasu.
Riddle napisał(a):
Najpierw faza projektowania i potem faza implementacji bardzo brzmi jak nie-agile.
Być może.
Na szczęście u mnie zamiast być zgodni z jakąś tam definicją "agile" wolimy wiedzieć, co robimy.
Chodzi o minimalizację niepewności. Tylko ta niepewność może mieć różne podłoża.
Riddle napisał(a):
Ale z drugiej, Agile mówi że jak najszybciej trzeba pokazać progres userowi, a nie pokażemy go bez UI'a.
Jeśli klient coś zamawia, to chce zminimalizować niepewność odnośnie postępów. Więc "pokażcie, bo chcę wiedzieć, czy nie lecicie w ch...".
Od strony użytkownika końcowego też mogą być niepewności, bo można coś robić, czego użytkownicy i tak nie potrzebują i nie będą płacić. Stąd te wszystkie landing pejdże startupów, których nawet jeszcze nie ma, tylko jest filmik z mockupem i możliwość zapisu. Żeby sprawdzić, czy robienie danej rzeczy ma sens, czy ludzie będą zainteresowani. Albo wdraża się zmiany na małą skalę i robi test A/B.
Ale programiści też mogą być niepewni, czy coś się w ogóle uda i jak bardzo coś jest trudne. Czasem trzeba zrobić prototyp, który rozwiewa niepewność dotyczącą implementacji, nawet jeśli jest to nieużywalne przez użytkownika.
czyli:
Z drugiej strony czasem trzeba zaakceptować pewną dozę niepewności i zrobić to, co można szybko zrobić i co będzie miało już jakąś konkretną wartość dla kogoś niż robić prototypy, które nie pójdą na produkcję. Więc czasem lepiej zacząć od tych łatwiejszych rzeczy, co do których jesteśmy bardziej pewni, a w międzyczasie eksplorować możliwości.
LukeJL napisał(a):
Chodzi o minimalizację niepewności. Tylko ta niepewność może mieć różne podłoża.
Riddle napisał(a):
Ale z drugiej, Agile mówi że jak najszybciej trzeba pokazać progres userowi, a nie pokażemy go bez UI'a.
Jeśli klient coś zamawia, to chce zminimalizować niepewność odnośnie postępów. Więc "pokażcie, bo chcę wiedzieć, czy nie lecicie w ch...".
Od strony użytkownika końcowego też mogą być niepewności, bo można coś robić, czego użytkownicy i tak nie potrzebują i nie będą płacić. Stąd te wszystkie landing pejdże startupów, których nawet jeszcze nie ma, tylko jest filmik z mockupem i możliwość zapisu. Żeby sprawdzić, czy robienie danej rzeczy ma sens, czy ludzie będą zainteresowani. Albo wdraża się zmiany na małą skalę i robi test A/B.
Ale programiści też mogą być niepewni, czy coś się w ogóle uda i jak bardzo coś jest trudne. Czasem trzeba zrobić prototyp, który rozwiewa niepewność dotyczącą implementacji, nawet jeśli jest to nieużywalne przez użytkownika.
czyli:
- klient/menedżment: kiedy software będzie zrobiony? Czy wyrobimy się na jesień?
- użytkownik/UX: czy jest sens robić ten software? Jakie ficzery są ważne, a jakie nie?
- programiści: czy będziemy umieli go zrobić? W jakich technologiach?
Nigdy nie słyszałem wcześniej żeby w Agile'u chodziło o minimalizację niepewności klienta. @LukeJL Jesteś pewien że to jest faktyczna część Agile'a, czy po prostu przyjemna konsekwencja którą zauważyłeś?
W Agile chodzi o to żeby jaknajszybciej pokazać klientowi progress, żeby mógł zmienić projekt i powiedzieć nam więcej o swoich oczekiwaniach, żebyśmy my w zamian mogli lepiej dopasować projekt pod niego. Nie kojarzę żeby tam było cokolwiek o tym żeby zmniejszać jego niepewność.
LukeJL napisał(a):
Ale programiści też mogą być niepewni, czy coś się w ogóle uda i jak bardzo coś jest trudne. Czasem trzeba zrobić prototyp, który rozwiewa niepewność dotyczącą implementacji, nawet jeśli jest to nieużywalne przez użytkownika.
No i to bardziej brzmi jak agile. Wręcz powiedziałbym że każda jedna iteracja powinna być takim prototypem.
LukeJL napisał(a):
Z drugiej strony czasem trzeba zaakceptować pewną dozę niepewności i zrobić to, co można szybko zrobić i co będzie miało już jakąś konkretną wartość dla kogoś niż robić prototypy, które nie pójdą na produkcję.
No, z punktu widzenia Agile, to ja powiedziałbym że owszem - trzeba tak robić, i to nawet ciągle. Z punktu widzenia agile oczywiście. Tzn: dostarczaj najszybciej jak się da najmniejszą zmianę wnoszącą wartość (prototyp), i pozwól klientowi dać feedback, popraw się, powtórz.
LukeJL napisał(a):
Więc czasem lepiej zacząć od tych łatwiejszych rzeczy, co do których jesteśmy bardziej pewni, a w międzyczasie eksplorować możliwości.
A więc jednak odpowiedź to PHP.
Zwykle staram się mieć coś do pokazania możliwie szybko, przy czym nie musi mieć rozbudowanego UI. To może być nawet tymczasowy interfejs tekstowy (oczywiście nie w przypadku apek stricte graficznych). Jednak interfejs może być początkowo bardzo surowy / trudny w użyciu / brzydki.
W pierwszej kolejności staram się zawsze zaimplementować trzon czyli tę główną funkcję, która ma być największą wartością dla klienta + minimum wszystkich pozostałych warstw tak aby dało się to zademonstrować. Czyli odpowiadając na tytułowe pytanie - ani od dołu, ani kod góry, a po trochu tu i tam, pionowo.
Przykładowo - jeśli to miałaby być aplikacja do wyświetlania wideo, to najpierw zająłbym się - niespodzianka - wyświetlaniem wideo. Potem dodawałbym kolejne mniej istotne funkcje (przewijanie, napisy, więcej formatów, ustawianie jakości, itp).
Krolik napisał(a):
W pierwszej kolejności staram się zawsze zaimplementować trzon czyli tę główną funkcję, która ma być największą wartością dla klienta
To jest bardzo oczywiste, bardzo słuszne i bardzo rzadkie podejście.
Od tej zasady, moim zdaniem są jednak pewne odstępstwa i czasami warto przesunąć wyżej w priorytetach rzeczy trudne, które nie są same w sobie "core", ale jeżeli nie uda się ich zaimplementować, to system utraci sporo wartości. Bardziej konkretnie, jak piszemy wyszukiwarkę internetową i zakładamy, że jej główną przewagą konkurencyjną będzie oparte o jakieś zaawansowane AI ocenianie zgodności dokumentów z intencją użytkownika, to zaraz po zbudowaniu "szkieletu", który pozwoli w jakimś bieda UI wpisać zapytanie i wyświetlić listę znalezionych dokumentów zająć się tą trudną rzeczą, bo właśnie z nią jest związana największa niepewność.
Agile to nonsens, reiteracja prawideł z lat 1960 aka lightweight project development, które w 2001 zostały przemianowane na Agile.
Ruch Agile degradował do bycia fabryką certyfikatów, to-zależyzmów bez żadnych kryteriów pozwalających na ocenę czegokolwiek i konsultantów od kumbaya trzymania się za ręce i soft skills, z wachnięciem w kierunku psychologii, bezpieczeństwa psychologicznego, socjologii i innych takich.
Biznes Agile wyprodukował dokładnie 0 sensownych praktyk technologicznych & managerskich.
XP, pair, mob, swarming, inne - to już było, nie wzięło się z Agile.
Zarządzanie ryzykiem, probabilistyka, zarządzanie zmianą - to było przed Agile i jest rozwijane do dziś.
Co biznes Agile wyprodukował
Fabrykę certów dla Juleczek i Mateoszy - hej, jesteś kelnerem, budowlańcem, niańką, księgową, cokolwiek - spoko, kupta nasze szkolenia i zrobimy cię Skram Monter za 10k+ co miesiąc, legit nie ma co.
Niekończące się wojny religijne o interpretację dogmatów, świętych tekstów i apokryfów Agile - jak interpretować Agile Manifesto, jak interpretować Scrum Guice, czy Agile to Scrum czy Scrum to Agile, czy Kanban jest okej czy nie, błeeee do wyrzygu
Setki nietechnicznych ludków którzy mają parcie na wejście do IT do świętego Scrum bo oni mają ten magiczny "agile mindset" - a Ty nie
Zwłaszcza Scrum to duże G.
Stąd podsumowując - dopóki ktoś nie odnosi się do legitnych schematów czerpanych z wzorców architektonicznych, praktyk DevOps i ogólnie zarządzania projektami IT to Agile to taka wydmuszka, którą se każdy po swojemu interpretuje, ale wiadomo, że manago który ma kasę decyduje, więc nie ma to żadnego znaczenia
Stąd podsumowując - dopóki ktoś nie odnosi się do legitnych schematów czerpanych z wzorców architektonicznych, praktyk DevOps i ogólnie zarządzania projektami IT to Agile to taka wydmuszka, którą se każdy po swojemu interpretuje, ale wiadomo, że manago który ma kasę decyduje, więc nie ma to żadnego znaczenia
Czemu chcesz łączyć rzeczy związane z inżynierią oprogramowania z konceptami zarządzania projektami?
Jakby co ma wzorzec architektoniczny do tego że tam sobie robicie scruma?