automatyzacja pracy Opcje

[jarmiar]

cześć

chciałbym sie was zapytać jak radzicie sobie z presją czasu i oczywiscie jak automatyzujecie swoją pracę

od dłuższego czasu wiele prac wykonuję od podstaw, dzięki czemu tracę cenny czas i wydajność spada ;/, a chciałbym jakoś to przyspieszyć

[thek]

@Theqos: kwestia otrzaskania z kodem. Masz rację pisząc, że są to tylko oszacowania, ale osoba będąca praktykiem może w miarę dokładnie oszacować ile zajmie jej dana funkcjonalność, gdyż zna zaplecze, wie czego użyć, czy jest zamiennik, który pozwoli jej skrócić czas kodzenia, ile musi mniej więcej własnego czasu wnieść do zadania. Tutaj właśnie objawia się całą potęga agile. Trzeba znać siebie i swoje możliwości. Jeśli coś oszacuję na 5 godzin pracy, to mniej więcej tyle to może zająć BEZ ingerencji z zewnątrz. Ale zawsze zakłada się sytuacje wyjątkowe, w stylu zmiany zdania, specyfikacji przez klienta czy coś w tym stylu, więc dodajesz X% czasu dodatkowo na to. Jeśli jesteś nowy w projekcie dokładasz bonusem kolejne X% jako przegrzebanie się przez nieznany Ci kod i tak dalej. Ja mam na głowie w sumie projekt, w którym siedzę od początku, będący wersją 2.0 i przez miesiąc byłem na utrzymaniu wersji 1.X, a jestem w sprawach wersji 1.X o konsultacje pytany przez... osoby które wersję 1.0 pisały Czemu? Bo przez miesiąc przeorałem go z każdej możliwej strony i nawet wprowadzałem poprawki funkcjonalne oraz wydajnościowe do najbardziej core'owych fragmentów aplikacji, które zostały wchłonięte przez nowszą wersję. Przez kilka miesięcy obie żyły niezależnie i trzeba było je synchronizować. Długi czas robił to mój poprzednik, a potem ja przejąłem jego obowiązki. Tuż przed releasem, gdy jeszcze wiele rzeczy się nie zgrało i musiałem dość szybko to ogarnąć oraz łatać.

Masz też rację z czasem. Dla mnie krytyczny czas to góra 2-3 dni. Jeśli szacowany czas go przekracza, to znaczy że, funkcjonalność po prostu została albo źle zaimplementowana, albo wręcz wcale i najlepiej napisać ją od nowa oraz porządnie. Coś jak brzytwa Okhama. Powyżej pewnej wartości nie ma co się bawić w refactor, ale lepiej napisać od nowa. To po prostu bardziej ekonomiczne, wydajniejsze niż oranie w starym kodzie. Uważam też, że wiele zależy od strony "klienta". Zrzuć na niego określenie priorytetów ważności określonych zadań. Dzięki temu wiesz czym się zająć w pierwszej kolejności. Zdejmujesz zadanie ze szczytu i określasz czy jest trudne, czy nie zawiera podzadań, ile może zając dla Ciebie. Czemu? Bo każdy oszacuje je inaczej. Dziś miałem tego świetny przykład. Kumpel wziął jedno i oszacował na określoną liczbę godzin. Ja zerknąłem i powiedziałem mu gdzie ma szukać odpowiedzialnych za to elementów kodu. Zrobił to w około połowę czasu jaki oszacował. Kilka moich odpowiedzi oraz wskazówek znacząco zredukowało mu czas potrzebny na "research" nieznanego wcześniej kodu, a po chwili rozmowy gdy słuchałem jego pomysłów, podejść i znając architekturę kodu, wybrałem jedno z proponowanych przez niego jako najodpowiedniejsze. Wystarczyło by ruszył dalej samodzielnie z kopyta. Zrobiłem mu za bazę wiedzy i eksperta od danej części kodu. Do pewnego stopnia więc jest to wypadkowa własnej wiedzy, znajomości kodu i... pewności siebie

@hind: znam to sam. Kod, zanim pójdzie na produkcję, ma wersję dev oraz wersję stage dla testów wewnętrznych. Testy są podwójne. Każda poprawka czy nowość przechodzi testy wewnętrzne przez osobę z teamu inną niż zajmująca się taskiem. Dopiero po pozytywnym przejściu tego etapu idzie do testerów klienta. To oni decydują czy zmiana wejdzie na produkcję czywróci do poprawki. Byle literówka wystarczy do cofki. Efekt? Oszacowany na pół roku projekt miał poważne zmiany w mniej więcej połowie. Oszacowano ponownie i okazało się, że należy dodać mniej więcej miesiąc. Na półtora miesiąca przed przesunięto jednego członka do innego projektu. Miesiąc przed terminem oddania przesunięto mnie do innego. Na tydzień przed zakończył się okres wynajęcia podwykonawcy i... projekt zaliczył pomyłkę o zaledwie kilka dni od oszacowanego, mimo zredukowania teamu o około połowę. Na dodatek nie z racji stricte kodu, ale zmian u providera, które musieliśmy kodem łatać

Powód edycji: [Spawnm]: TL;DR :D

[Theqos]

@Theqos: kwestia otrzaskania z kodem. Masz rację pisząc, że są to tylko oszacowania, ale osoba będąca praktykiem może w miarę dokładnie oszacować ile zajmie jej dana funkcjonalność

Oczywiście się zgadzam. Jak pracujemy w agile i mamy funkcjonalności "paro godzinne" to taką umiejętność możemy sobie wyrobić. Problem, o którym ja mówiłem jest taki, że nie możemy po prostu podzielić naszego projektu na 1000 takich zadań, zrobić mnożenie, dodać 20% na "sytuacje nieprzewidziane" i mieć realistyczny termin. Nawet jakby nam się udało podzielić nasz projekt tak szczegółowo i nic by się nie zmieniło (powodzenia) to parę z tych zadań może okazać się potęrznymi krowami i "otrzaskanie z kodem" nic tu nie da. Jeżeli te funkcjonalności nie są z kategorii "must have" to pół biedy, bo klient może z nich zrezygnować, w przeciwnym wypadku jest lipa. Znam takie przypadki, gdzie takie "funkcjonalności" potrafią przekształcać się w osobne projekty. Nie można przewidzieć, czy w zadaniu nr 357 pomyliliśmy się w szacunkach o 20 minut, czy 20 dni.

projekt zaliczył pomyłkę o zaledwie kilka dni od oszacowanego, mimo zredukowania teamu o około połowę. Na dodatek nie z racji stricte kodu, ale zmian u providera, które musieliśmy kodem łatać

Co tylko potwierdza fakt bezsensowności tych szacunków. To jest doskonały przykład czego to się nie robi, żeby dotrzymać terminu. Masz jakieś historie o zakończeniu projektu sporo przed czasem?