@WujekAlien - dashboard sam się powinien tworzyć z danych z Jiry

Tworzysz kilka ticketów w Epicu i umiejętnie zmieniasz ich status tak by wykazać postępy

@koszotorobur a kto by tam Jiry używał ;)

@WujekAlien

@koszotorobur no chyba nie xD W moim korpo ździra jest w czasach słusznie minionych, bo to gówno robiło wszystko poza sensownym działaniem.

@NiebieskiSzpadelNihilizmu - a coś używane w zamian czy korpo całkiem porzuciło tego typu software?

@WujekAlien Jira miała bardzo wiele zalet i jedną wadę - nie zawsze, a właściwie czesto nie wysyłała powiadomień i zmianach/przypisaniu zadań xD

@Yes_Man - byłem adminem dwóch wersji serwerowych i dużo zależy od konfiguracji.

W ogóle jak się Jirę dobrze skonfiguruje to działa jak złoto.

Oczywiście config aplikacji tak by działała na serwerze to jedno a konfiguracja projektów już w działającej istancji to drugie - to też można spierdolić po całości i zrobić niedziałające gówno

Nie powiem, że najwygodniej było mi administrować trzecią instancją Jiry bo to była wersja Cloud - czyli managed service - tam głównie pomagałem nieogarom konfigurować projekty tak by odpowiadały potrzebom zespołów i automatyzować co się dało (a odkąd plugin Automation for Jira stał się częścią wersji Cloud to właściciele projektów sami sobie mogli już wiele zautomatyzować).

@koszotorobur AzDo, gdzie mamy wszystko do robienia deweloperki (i patodeweloperki :P)

@LondoMollari - skądże - a co to?

@LondoMollari legendy mówią że byli śmiałkowie którzy ją widzieli i przekazali tę historię dalej. Do dziś są śmiałkowie którzy skuszeni opowieściami szukają jej, niestety bez skutku

@bojowonastawionaowca no i wykrakałeś 🤣 a już było dobrze

@bojowonastawionaowca

Community

Communi

Commu

@bojowonastawionaowca

@cebulaZrosolu tylko to skomplikowany przypadek, trzeba opierdalać się udając, że ciężko zapierdala się, to może być katorżnicza praca

@cebulaZrosolu @A_Inot only that Pamiętaj- wieczne zapierdalanie ponad swój limit i jebanie 130% tylko po to, żeby "pokazać" nigdy nie kończy się dobrze, nieważne czy to jest januszex czy megakorpo. Jasne- możesz na chwilę zacisnąć zęby i coś dowieźć, jak masz na to parcie, albo jest ciśnienie, ale ciągły taki zapierdol jest z góry skazany na porażkę. Firma zawsze będzie dążyć w stronę "więcej", więc jak w jednym roku zrobisz X roboty, to w następnym narzucą ci jakiegoś z dupy kejpiaja, że masz wyrobić 1,1X. Do tego firma zawsze, ale to zawsze widzi twoją robotę jako 100%, nawet jak będziesz jebał roboty efektywnie na 2 etaty "no bo przecież wyrabiasz". Żaden menago nie da o to nawet sekundy jebania, nie mówiąc już o jakimś bonusie czy podwyżce. Co najwyżej usłyszysz, że "tak trzymaj". Na efekty długo nie trzeba czekać- prędzej czy później się wypalisz, a nawet jeśli jakimś magicznym cudem nie, to tak samo prędzej czy później zdarzy się jakiś jeden gorszy miesiąc- ot choroba, jakieś nieprzewidziane sytuacje, wypadek, problemy w domu, gdzie nie będziesz w stanie tak performować i chuj- nagle się okaże, że twój wcześniejszy rok zajobu na 200% nie znaczy absolutnie nic, bo liczy się to, że w danej chwili nie wyrobiłeś jakiejś magicznej normy i trzeba cię jebać.

@A_I nie ma po co się żyłować. Najlepiej na co dzień robić na 70% swoich możliwości max- jak przyjdzie jakiś trudniejszy okres, to będziesz przynajmniej miał bufor, dzięki któremu nie będziesz musiał łazić po suficie. Robota będzie zrobiona, ty się nie zajebiesz, góra będzie zadowolona, a ty sobie będziesz mógł wrócić do robienia swoich 70% jako 100%.

@lokurva opierdalanie sie w pracy przez dluzszy czas, np. 3-4 tygodnie z rzędu sprawiły, ze uzależniłem sie od smartfona, chodzę zmulony i wycienczony psychicznie i fizycznie, do tego frustracja. Na początku robilem jakies kursy online, pisałem wrzutki na Hejto o przyprawach, ale kurde ile można.....z czasem i to mi zbrzydło. mam nadzieję, ze w kolejnej pracy aż tak czesto nie bede nie mial co robić.

@Poji Dokładnie, byle jak proof of concept można napisać w 1-2 dni, który obejmie właśnie 80% założonych funkcjonalności jako tako. Te pozostałe 20% przypadków, może zająć kilka miesięcy, bo będą dochodzić nowe wymagania, albo zmiany w istniejących wymaganiach.

Porównałbym to do tworzenia samochodu. Wymaganie jest "no to chcemy takie COŚ, co przewiezie ludzi z miejsca na miejsce, szybciej niż chodziliby na piechotę".

Ale w trakcie wychodzi, że powinno również chronić ludzi w razie wypadku, chronić ludzi przed deszczem/śniegiem, w zimie fajnie jakby grzało, w lecie fajnie jakby chłodziło, powinno pokazywać ile paliwa zostało, powinno pokazywać z jaką prędkością się porusza, do tego jakieś światła, żeby dało się jechać w nocy. Na końcu po dorzuceniu tych wszystkich rzeczy, okazuje się, że waga zwiększyła się o tyle, że auto słabo przyśpiesza, więc trzeba ogarnąć większą moc wracając do silnika. Git udało się, ale teraz wychodzi, że hamulce są za słabe. Aby zrobić lepsze, trzeba przemyśleć konstrukcję kół, bo większe hamulce się nie mieszczą do obecnych. A aby dorzucić większe koła, trzeba zmienić konstrukcję samochodu. A na końcu klient jeszcze wpada i mówi, że chciałby jakiś prosty ficzer, który nazwał "kierownicą", żeby dało się zmienić kierunek jazdy, bez potrzeby wychodzenia z samochodu i go przestawiania ręcznie XD.

@HmmJakiWybracNick systems engineering się kłania, żeby uniknąć takich sytuacji.

I tak się będą zdarzać xD

@WujekAlien zawsze mnie to rozwala jak inżynier twierdzi na spotkaniu, że coś można zrobić w 2 dni a nie np miesiąc a jak później dopytujesz o szczegóły to wychodzi na to, że większość jest nie przemyślana a resztę "dorobi się na szybko" xD

@zboinek tak, albo oszacował, przy 100% szans powodzenia i 0 problemach po drodze

@Dzemik_Skrytozerca gorzej- przyszło edżajl i nagle się okazało, że wszyscy mają być principa-senior-ekspert-ruchacz-analny-devami i napierdalać kod, kod i tylko kod. I mają napierdalać kod kodem. Na nic innego nie ma czasu, nic innego nie ma prawa bytu, nic innego nie istnieje, bo nagle okazało się, że jedyną metryką zespołową na wszystko stała się ilość commitów w ciągu sprintu. Że tak złośliwie dodam- nie pytaj jak to się u nas skończyło po tym, jak jedna mądra głowa to wymyśliła. Powiem tylko, że odpowiedzią było makro wyzwalające git commita przy każdym zapisie pliku w IDE, co wygenerowało nam na koniec sprintu taką wartość, że przebijaliśmy w słupku całą resztę firmy razem wziętą. Trzykrotnie. Głupie gry, głupie nagrody i tak dalej ¯\_( ͡° ͜ʖ ͡°)_/¯

@NiebieskiSzpadelNihilizmu

U nas religia jest tzw. DevOps, admin zarządzający za pomocą yamla i skryptokodu. Nie byłoby to źle, gdyby ludzie nie popełniali błędów.

No i można zapomnieć o UX, czy też o bardziej dalekowzrocznym zarządzaniu.

@Dzemik_Skrytozerca no to widzę klasyka gatunku- my przerabialiśmy edżajla, potem skrama, którego przez jego gównianą implementację nazywałem sramem, no i teraz devopsa, który koniec końców ani nie jest dev, ani ops. Też wszystko wciskane tak bardzo religijno-dogmatycznie jak to tylko możliwe, razem z jakimiś -masterami, którzy łazili na początku jak nawiedzeni po wszystkich naszych spotkaniach i próbowali na siłę udowodnić, że całe te nasze spotkanie to to są ich spotkania i oni tam są najważniejsi ze swoim pierdoleniem. Cywilizowany dostęp do systemów wycięty, a nawet niecywilizowany utrudniony tak bardzo jak to tylko możliwe, UI złe, wszystko tylko przez API, hype driven development robi ładny creep out zewsząd, bo wszyscy mają parcie i nacisk na dewelopowanie, narzut procesowy już dawno temu przekroczył jakieś cywilizowane normy. I tak się to kręci.