Aktywne Wpisy
Kordianyt +51
Krotka pilka do graczy PC - jaka gra z ostatnich 3 lat wywarla dla was najwieksze wrazenie i polecilibyscie dalej? Kupilem tlustego kompa i ogralbym cos nowego i ciekawego, pozdrawiam #gry #pcmasterrace #komputery
BlackBlack +66
Dzisiaj w nocy zmarła moja dziewczyna. Miała wypadek samochodowy. Pogotowie przyjechało bardzo szybko. Reanimowali ją 40 minut, ale nie udało się. Nie umiem sobie z tym poradzić. Umarłem razem z nią.
Jak sobie myślę, że ona teraz jest gdzieś tam sama, że już nie będę mógł jej pomóc, że już nigdy nie zasnę obok niej, że już nigdy nie obudzi mnie całusem w czoło, że już nigdy nie zrobię jej tostów z
Jak sobie myślę, że ona teraz jest gdzieś tam sama, że już nie będę mógł jej pomóc, że już nigdy nie zasnę obok niej, że już nigdy nie obudzi mnie całusem w czoło, że już nigdy nie zrobię jej tostów z
Czy ktoś z was też odczuł że w pewnych typach projektów gdzie nie ma jako takiego użytkownika i interfejsu (GUI bądź API), jak np. jakiś ETL, Scrum wydaje się po prostu "nie pasować"?
W projekcie gdzie tworzymy dość dużego ETL-a który z racji swojej specyfiki działania jest dość "binarny" (tj. albo wszystko zaimplementowałeś i jest dobrze albo nie i wynik nie ma sensu) i nie ma miejsca na płynny przyrost funkcjonalności zauważam że ta metodyka się nie sprawdza pod kilkoma względami. Tj.:
1. Dema - stakeholder'a interesuje czy wynik wypluwany jest poprawny i zgadza się z baseline, demo to albo suchy status report w takim wypadku albo pokazanie tabelek i gadanie osobie nietechnicznej dlaczego te wartości w danej kolumnie teraz są ok a nie były
2. Ciężko przy takiej aplikacji rozumować w kontekście user stories i features więc te features przestają być features a user stories user stories - ta hierarchia przestaje działać i mutuje w jakiegoś dziwoląga
Chyba fundamentalny problem jest taki że Scrum zadaje pytanie "jaką wartość to co robisz przynosi użytkownikowi" a w przypadku takiego ETL-a czy innych aplikacji "bezuserowych" nie ma jasnej odpowiedzi na to pytanie
Pracuje obecnie w Data Engineering, wcześniej różne projekty w tym user-facing jak strony/serwisy internetowe i z tej perspektywy patrzę na Scruma którego tu wcisnęli, u mnie dochodzi fakt że team jest mieszany (devowie, testerzy, analitycy) co też w Scrumie nie ma chyba sensu
Ale czasem wyłapuje cfaniakow nierobów i to chyba jedyna jego zaleta.
@Parmenides69: No ale to włąśnie w tej sytuacji chodzi o podzielenie tego na mniejsze kawałki - mimo, że z punktu widzenia biznesowego nie ma sensu to w sytuacji pokazania dema jesteś w stanie "udowodnić", że działa.
Np. jak już masz ETL.
Sprint 1 - wczytanie danych z plików/baz źródłowych - i pokazujesz, że masz idealnie wszystko zaczytane
@mccloud: Ale o to chodzi że to jest dużo bardziej skomplikowane, do tego często opóźnienia wymagań i analiz, problemy z danymi. Zrobienie tego co opisałeś jako "Sprint 2" to może wyjść tak naprawdę z miesiąc jak nie więcej.
Można się bawić w jakieś sztuczne dzielenie pracy czy
Sprint 1 - wczytałeś dane - zademowane, że jest idealnie to co idzie ze źródła.
Sprint 2 - pierwsze kilka klocków ETL... demujesz wynikj, potwierdzasz poprawność obliczeń
Soprint.... tu masz kolejne klocki ETL
Na koniec demujesz wszystko od A do Z. Czyli wczytanie i odpowiedni wynik.
Z perespektywy developera, jak coś to wiesz po
Do meritum to iteracyjny proces wytwarzania jest wręcz idealny do takich rzeczy bo dzielisz duże zadanie w twoim przypadku proces ETL na mniejsze, które dostarczasz partiami w ramach iteracji. Czyli jeżeli proces ETL składa