Aktywne Wpisy
Zawiera treści 18+
Ta treść została oznaczona jako materiał kontrowersyjny lub dla dorosłych.
![AlienFromWenus](https://wykop.pl/cdn/c3397992/AlienFromWenus_d0SsQNbamP,q60.jpg)
Dlaczego faceci muszą być tacy agresywni, bez emocji, empatii i człowieczeństwa? Zero ludzkich odruchów, tylko maszyny, którym nadrzędnym celem jest zarabiać hajs, bo nie liczy się dla nich być, tylko mieć, i to nie dla siebie, ale by pokazać się innym, że jest lepszy. Pieprzony wyścig szczurów. Na co to komu? Rywalizacja w imię czego? Tylko coraz lepszy telewizor, samochód, zamiast skupić się na budowaniu szczęścia na rzeczach niematerialnych.
Trudno dziś przez
Trudno dziś przez
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