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ć

Tzn? Zrób szablony

Presja czasu? Jak klient pyta ile mi coś zajmie podaję potrzebny czas +50% na ewentualny poślizg. Nawet jak mi komp zdechnie, albo pojawią się jakieś inne cyrki to potrafię zachować spokój

Dokładnie to co Spawnm napisał odnośnie czasu Domniemany czas pracy +50% to jest tak wtedy w miarę bezpiecznie
Do tego wykorzystuje jakiś system aby konkretyzować zadania i plany (Trello, Redmine).
Odnośnie wykonywania tej samej pracy od podstaw to głupota. Pisze CMS i rozbudowywuje go o nowe moduły a te co mam już napisane i sprawdzone to wykorzystuję a nie piszę na nowo

Po pierwsze analiza problemu, oszacowanie zadań oraz czasu na to przeznaczonego, oczywiście z naddatkiem na ewentualny poślizg lub ewentualne zmiany ze strony klienta. Z doświadczenia nie warto zakładać więcej niż kilka godzin na dobę, gdzie faktycznie praca daje efekt. Niby możesz klepać kod na okrągło, ale nie sądzę by wydajnie i w pełni udało Cisię więcej niż 5-6 godzin uzyskać. Zawsze stracisz czas na przełączanie się między zadaniami, odejścia od moitora by coś przekąsić, odpocząć od kodu. Po jakimś czasie pracy stwierdzam też, że tylko metodyki zwinne. Pisanie kodu 2-3 miesiące, by potem przez tydzień czy dwa czekać na feedback, nieraz w ogromnych ilościach pierdółek, to nie jest dla mnie idealne rozwiązanie. Lepiej mieć wsparcie klienta i testerów na bieżąco. Do tego więc jakiś issue tracker by mieć oko na to co poprawiać lub ogólnie jakąś tablicę, wspólną z zadaniami, gdzie ewentualnie wrzucane będą znalezione przez klienta błędy. Lepiej to zrobi Tobie pod kątem organizacji pracy (wiesz gdzie jesteś, co masz zrobić), jak i klienta, który widzi postępy, przez co nie truje Ci. No i wie, że też coś robi, ma wpływ na swój projekt

Oczywiście dobrze mieć jakieś narzędzia do wykonywania automatyzacji zadań pokroju buildy, testy jednostkowe, testy regresji. Jednym słowem Continuous Integration w praktyce, czyli Hudson lub podobne narzędzie. Zapominasz, że coś takiego jest, Ty piszesz kod, reszta dzieje się w tle. Sprawdzasz raz na jakiś czas jak wyniki. Dobrze byłoby mieć także na oku potencjalne wąskie gardła, co możemy uzyskać narzędziami pokroju Sonar, które między innymi analizują kod, wyszukując instrukcji niebezpiecznych wydajnościowo (zbytnia złożoność) czy niezgodnych z założeniami początkowymi (choćby standardy kodowania). O bezpieczeństwie kodu poprzez repozytoria kodu chyba nie muszę wspominać?

Witam.

Mi w automatyzacji pomaga phing.

na pewno warto podłapać podstawy basha (oraz grep/sed/awk itp.), czy pythona (który można również traktować jako język skryptowy), bądź perla - a potem porobić odpowiednie skrypty automatyzujące.

u mnie: bash, ant, phing, jenkins, puppet, *unit, jmeter, selenium

Ostatnio spotkałem się z opinią, że nie da się oszacować czasu trwania projektu programistycznego. Doszedliśmy do bzdur w stylu estymacja * liczba z sufitu, która zależy od naszej pewności siebie, a nie rozumnego myślenia. Pomijając już efekt spadku wydajności, zadania jakoś dziwnie zajmują tyle czasu ile się na nie przeznaczy, to i tak te przewidywania zazwyczaj są nie trafione. Jak można mówić o szacowaniu czegokolwiek, kiedy wariancja błędu jest ogromna. Zadanie, na które przewidzieliśmy 4 godziny, może się okazać zadaniem na "3 tygodnie". I to nie jest coś niezwykłego w tym zawodzie. Ja bym szedł w kierunku programowania jako usługi (PAAS? ), klient wykupuję cię na określony czas (na próbę) i można się skupić na najbardziej efektywnym wykorzystaniu tego czasu. Oczywiście wszystko pod kontrolą jakiejś zwinnej metodyki. Przynajmniej mam tu na myśli projekty większe od strony wizytówki.

Mam inne spojrzenie na ten temat. Od jakiegoś czasu pracuję w firmie, która nie narzuca mi żadnego terminu wykonania zadania.
Zadanie polega na rozwijaniu pewnego kodu. Z założenia rowijanie tego kodu ma się nigdy nie skończyć. Ja mam sie jedynie skupić na tym, aby kod był na najwyższym poziomie i raz na jakiś czas pokazywać efekty i przerzucać na produkcję.

Muszę przyznać, że nie pamiętam takiej wydajności w swojej karierze. Zero stresu, poganiania i to czego nie lubię najbardziej - szacowania. Praca idealna.

@Adi32 tylko to się sprawdza w przypadku produktu flagowego firmy. A co jak klient zażyczy sobie coś autorskiego? Przecież wtedy nie oddasz pół produktu, tylko dlatego że nadszedł dzień jego oddania.

Co do tematu, to mi wystarczy bash i php, dodatkowo lista zadań do wykonania, jakieś proste todo.

Szacowanie to zupełnie inna para kaloszy. Dziewięć kobiet nie urodzi ci dziecka w miesiąc

A co jeśli moim pracodawcą jest bezpośrednio osoba, którą Ty nazywasz klient? Buduje jeden CRM dla średniej firmy handlowej i polecam takie coś. Pracuje się lepiej i wydajniej (choć zależy od osoby, bo brak jakiejkolwiek obserwacji może pokusić).
Jest duży pozytyw odnoście własnej działalności a nawet pracy freelancersiej - zero stresu i terminów.

Panowie, słowo klucz: Agile

@Adi32, Mam podobną sytuację w pracy, jaki harmonogram by nie był robiony to i tak ZAWSZE termin się rozjeżdżał (z różnych powodów, najczęściej zmiana priorytetów zadań). Ostatecznie rozwój przechodzi na model iteracyjny który przez cały czas jest nadzorowany przez wszystkie osoby które na danym produkcie będą pracować, raz na jakiś czas jest robiona duża lista życzeń. Potem dokumentacja i prototypy, alfa, testy, beta, testy, wdrożenie.

Do tego wersja Developerska i Testowa jest dostępna dla wszystkich którzy mają również dostęp do Produkcji.

Agile to jest rozwiązanie, bo przynajmniej nie czeka się 3 lata zanim powstanie szkic dokumentacji i pełny opis funkcjonalny, 2 lata na produkt, i po 5 latach mamy aplikację która nie spełnia nawet podstawowych oczekiwań (znam takie przypadki)...

A jak ją liczysz? Wykonane zadania przez czas, czy tylko masz takie wrażenie Z takim bezterminowym programowaniem trzeba bardzo uważać bo łatwo wpaść w overengineering i poświęcać dużo czasu na rzeczy nieistotne. Jak się rozwijasz to za rok i tak byś ten kod napisał inaczej. Jednak polecałbym nakładanie terminów przez samego siebie, najlepiej takich nie prekraczających paru godzin/dnia na zadanie. Jeżeli wydaje ci się, że zadanie wymaga więcej czasu, to je podziel na mniejsze.

@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ć

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.


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?

Naprawdę sporo przed czasem by było, gdyby nie było kombinacji z liczbą devów w teamie oraz nieprzewidywalnych zmian na hostingach. Zauważ, że raczej nie przesuwa się połowy teamu do czegoś innego, ot tak Samo szacowanie odbyło się jakieś kilka miesięcy przed ruszeniem do kodu. Tylko jedna korekta w połowie kodzenia była, która wynikła ze strony klienta, bo zrobił przegląd funkcjonalności i parę dodał, a pawne wywalił. Sama zmiana na hostingu odbyła się jakiś czas po oficjalnym oddaniu projektu, który to został oddany przed terminem. Poślizg był dopiero na próbie wdrożenia i de facto w okresie utrzymania kodu już.

Tak więc nie było to deadline'owe "byle dotrzymać terminu", bo kod się obronił przed terminem zapisanym w umowie. Dopiero w czasie próby wdrożenia wyskoczyły drobne rzeczy, które je przesunęły, gdyż wymagały od nas zmian w kodzie oraz konfiguracji na hostingu, by się do nieoczekiwanych rzeczy dopasować. Nie można więc powiedzieć, by szacowania zawiodły. Wprost przeciwnie. Mimo wszystkiego aplikacja została oddana w terminie. A numery jakie tuż przed releasem wywinąło nam kilka firm o światowej marce, skutecznie nas zniechęciły do dalszej współpracy z nimi. Bądź co nie bądź, bazowaliśmy na płatnych usługach tych firm. I to nie tych z niskiej czy średniej półki. Nie każdy by strzymał, jeśli w 2-3 godziny idzie w piach kilka tysięcy, a widział że rezultat jest mniej warty niż to, co sam wie i potrafi zrobić

Co do szacunków jeszcze. Nie było to proste: "Pomnóż liczbę zadań razy określoną wartość". Wpierw podział na scenariusze testowe, w nich wydzielone zadania, szacowanie każdego i dopiero sumowanie. Z pewnym zaokrągleniem i naddatkiem na nie zawsze przewidziane rzeczy. Trzymaliśmy się tego na tyle dobrze, że w momencie "feature complete" mieliśmy jakoś miesięczny bufor na kompleksowe testy jakościowe, bezpieczeństwa, wydajnościowe. Nie sądzę by taki okres to było mało A uwierz, że w połowie projektu nagle sobie wymyślili rzeczy, które dość konkretnie uderzyły w dotychczas powstałą część.