Pierwsze dwie litery nazwiska, a nie skrót od trolla.
Wyobrażam sobie dynamiczne dzielenie na mniejsze zadania w trakcie robienia i wymianę nimi między osobami, jak to jest w wielu innych branżach gdzie nie kontroluje się odgórnie przydziału zadań do osób.
10 programistów? Ha ha ha, chciałbym żeby w moim mieście były tak duże firmy IT.
0
0
Słyszałeś o czymś takim jak sub-task? A wiesz, że z subtaska też można zrobić kolejne sub-taski?
0
@jacek.tr a mógłbyś napisać konkretnie na czym polegały te taski ? Pytam z czystej ciekawości.
1
Wybitny Terrorysta napisał(a):
@jacek.tr a mógłbyś napisać konkretnie na czym polegały te taski ? Pytam z czystej ciekawości.
Najgorszy ze wszystkich pojedynczy task w tej firmie, gdzie byłem dłużej: zapoznanie się z deklaracjami (skan kartki) na podatek od nieruchomości miasta, dla którego urzędu jest projekt, zaprojektowanie w MySQL Workbenchu znormalizowanego schematu bazy pozwalającej przechowywać ich zawartość, z dziwactwami takimi jak odwołania do ID wierszy w zupełnie innych bazach które widziałem po raz pierwszy, z obsługą załączników do tych deklaracji (także bardzo skomplikowanych), stworzenie w Symfony2 aplikacji webowej pozwalającej przeglądać (z wyszukiwaniem, filtrowaniem...) dodawać, edytować i usuwać takie deklaracje w bazie, gdzie wygląd interfejsu jest taki jak w dołączonym pliku PSD, podłączyć stworzoną aplikację do centralnego systemu uwierzytelniania używanego w innych aplikacjach wchodzących w skład produktu. Maksymalny czas wykonania: 10 dni.
3
Piszecie każdy po trochę z sensem, ale hejtujecie po sobie, zamiast spróbować zrozumieć siebie nawzajem.
Moim zdaniem faktycznie czasem daje się jako taski zbyt duże funkcjonalności i rozumiem o co chodzi jackowi.tr, pomimo że niefortunnie się wyraził (bo z jego wypowiedzi można wywnioskować, że on neguje całą ideę tasków).
Jak dla mnie problem jest przede wszystkim w tym, że 1 "task" z perspektywy biznesowej/designu nie musi się równać 1 task programisty.
Dla product ownera taskiem może być "nowy widok strony głównej" którą grafik właśnie zaprojektował w Photoshopie.
A tymczasem programista sobie siada nad kodem i realizuje wizję biznesu/designu i okazuje się, że tak -
- żeby przerobić stronę główną trzeba zrefaktoryzować legacy kod w jQuery na kod w Angularze, który jest obecnie używany.
- Trzeba również dorobić integrację z 5 różnymi stronami (np. Google Maps, Facebook etc.) bo tak jest w designie.
- Trzeba zrobić własny customowy komponent slidera (bo grafik zaszalał i ciężko użyć gotowca).
- Trzeba podpiąć się do endpointów w API, żeby pociągnąć dane, które będą się wyświetlać na głównej stronie
- potem oczywiście trzeba to jakoś wystylować: najlepiej responsywnie, ale również piksel perfect (co się kłóci z responsywnością często), żeby były super animacje, ale powinno się też odtwarzać na starym Androidze czy IE.
Reasumując - z perspektywy biznesowo-designowej może to być jeden task, a w rzeczywistości programista musi wykonać wiele różnych niezwiązanych do końca ze sobą czynności, żeby wcielić tę wizję.
Słyszałeś o czymś takim jak sub-task? A wiesz, że z subtaska też można zrobić kolejne sub-taski?
I to też jest słuszna uwaga. Jednak sub-taski same się nie zrobią. Zespół musi je wydzielić. Tutaj właśnie się przydaje komunikacja w zespole, zasygnalizowanie zespołowi, że taski są zbyt duże i dyskusja, jak je podzielić na mniejsze.
Podzielenie na mniejsze taski ma też tę zaletę, że w razie czego łatwiej przerzucać taski między osobami. W podanym wyżej przykładzie - np. osoba X, może zrefaktoryzować kod z jQuery na Angulara (podpunkt 1.)., a w tym samym czasie osoba Y tworzy w Angularze serwis, który się będzie łączyć przez AJAX do endpointów w API (podpunkt 4.), bo np. pisała to API, więc wie dokładnie jak go należy używać (co prawda to rodzi niebezpieczeństwo nadmiernej specjalizacji, ale wszystko ma swoje wady).
Jak dla mnie taski powinno się dzielić trochę podobnie jak się dzieli moduły/klasy/funkcje w aplikacjach zachowując zasadę separation of concerns (nie wzystkie taski się da tak podzielić, ale wiele się da...). Jednak nie stanie się to, jeśli taski będą szły z góry, bo dla biznesu/osób nietechnicznych/pseudoseniorów:
zaprojektowanie w MySQL Workbenchu znormalizowanego schematu bazy pozwalającej przechowywać ich zawartość
oraz:
wygląd interfejsu jest taki jak w dołączonym pliku PSD
może być częścią jednego taska, nawet jeśli nie powinny (chociaż to co pisze jacek.tr to już jakaś patologia, z czymś aż takim to się nie spotkałem).
0
jacek.tr napisał(a):
W takim razie czym jest "komunikacja", jeżeli inni oczekują ciszy, której ja nienawidzę?
Poważnie pytam, czego się spodziewałeś? Ale tak szczerze?
W innych branżach np. dziennikarstwie z tego co wiem komunikacja oznacza ciągłe rozmawianie z innymi, robienie wszystkiego razem.
Znam kilku ludzi z tej branży i - uwaga - pracują dosyć podobnie. Kiedy masz wyklepać tekst, to zakładasz słuchawki na uszy i klepiesz.
Dokumentacja do projektu z informacjami dla programisty, a nie końcowego użytkownika? Chyba sobie żartujesz, nikt w Polsce poza megakorporacjami nie ma na to czasu.
Zależy od firmy, coraz częściej czytelny kod + jakiś np. Javadoc do tego to jeden z punktów w kryterium odbioru.
"Taski" to dla mnie największa głupota i nie zmienię zdania.
Skoro postawiłeś sprawę w następujący sposób: "choćby przyszedł ktoś, kto by dał mi niepodważalny dowód to i tak nie zmienię zdania" to rzeczywiście jest mało do dyskusji.
Optymalnie byłoby: nieskończenie wiele nieskończenie małych "tasków", wtedy problem który opisałem nie istnieje, można znaleźć optymalny przydział do osób.
Zakładając zerowy overhead na task może i masz rację. Ale task trzeba stworzyć, podjąć i zamknąć - to zabiera czas. Im mniejszy task tym większy procentowy udział takiego okładu. Ot i tyle.
Szczerze to moim zdaniem idąc do pracy miałeś jakieś swoje wyobrażenie dotyczące pracy w zawodzie programisty - że to jakieś non-stop spotkania, mitingi, briefingi, wspólne zastanawianie się czy prostokąt jest szczególnym przypadkiem kwadratu itp. itd. - i rzeczywistość zweryfikowała Twoje poglądy. Zgodzę się, że cały proces taskowy może być zrealizowany źle. Zgodzę się, że junior pracuje mniej wydajnie od seniora i trzeba to uwzględnić.
Ale z Twoich postów widzę, że masz tendencję do szafowania wyrokami i zamiast szukać rozwiązań po prostu głośno narzekasz.
0
jacek.tr napisał(a):
W takim razie czym jest "komunikacja", jeżeli inni oczekują ciszy, której ja nienawidzę?
No to masz, to Ci może coś wyjaśni:
https://pl.wikipedia.org/wiki/Introwersja
W innych branżach np. dziennikarstwie z tego co wiem komunikacja oznacza ciągłe rozmawianie z innymi, robienie wszystkiego razem.
https://pl.wikipedia.org/wiki/Ekstrawersja
Rozumiem że Ty się łapiesz pod to drugie a oni pod to pierwsze?
Widzisz, wystarczyło napisać że nie radzisz sobie z tymi taskami a już masz tutaj zarzuty, że jesteś słaby albo co gorsze trollujesz, nie powiedziałbym też żeby to dobrze wyglądało w oczach rekruterów, dlatego zastanawiam się czy w ogóle szczerość popłaca?
Dokumentacja do projektu z informacjami dla programisty, a nie końcowego użytkownika? Chyba sobie żartujesz, nikt w Polsce poza megakorporacjami nie ma na to czasu.
A nawet gdyby taka była to też może być pisana takim językiem że trudno to zrozumieć, więc tu bym się aż tak nie podniecał. Sądzisz że miałbyś w tym przypadku lepiej?
2
Tak jest oczywiście najłatwiej, zwalać na kogoś winę, nie zwracając jednocześnie uwagi na niewygodne fakty. Za co programiści zatrudnieni w tej firmie do diabła biorą pieniądze? Za samo tylko kodowanie? Realizacja tego tasku w jednym z postów wyżej na Symfony jest realna w 10 dni, niestety dla wymiataczy i to przy założeniu że dobrze znają projekt. W jaki sposób ktoś kto dostanie dla przykładu rozbudowę jakiejś kobyły której nie widział nawet na oczy więc dopiero musi się z tym zapoznać (a to zajmuje czas) może sobie dać radę w tak krótkim terminie? Symfony jest niestety stosunkowo skomplikowany, to nie jest CodeIgnither czy tam Kohana, frameworki które wydaje mi się że są jednymi z najprostszych jakie istnieją i stosunkowo łatwe do opanowania.
Co do niewygodnych faktów, fakty są takie że jak się wejdzie na serwisy aukcyjne to mnóstwo firm walczy nie koniecznie najniższą ceną ale często krótkimi terminami realizacji. Jak w tej sytuacji oczekiwać realizacji tego typu wymagań od tych mniej doświadczonych?
0
@drorat1
O czym Ty piszesz? Przecież napisałem, że bycie słabym nie jest niczym zlym. I napisałem, że moje "jechanie" jest raczej związane z tonem wypowiedzi, niż z tym, że ktoś dopiero zaczyna.
Przykładowo:
W takim razie czym jest "komunikacja", jeżeli inni oczekują ciszy, której ja nienawidzę?
Praca programisty w dużej części - w większości nawet - składa się z stukania w klawiaturę nie mówiąc nic. Jeśli ktoś "nienawidzi" ciszy, to nie jest praca dla niego. Ale wiadomo - skoro pan @jacek.tr oczekuje rozmów, to cały zespół musi się spiąć i jego oczekiwaniom sprostać, prawda?
Inna sprawa to to, co dało się wyczytać między wierszami. Jeśli w dwóch różnych firmach narzekano na niego, że jest niesamodzielny i że dużo pyta to być może coś jest na rzeczy. Dodatkowo człowiek ten wyrokował o całym rynku ("na testy mogą sobie pozwolić tylko megakorporacje") na podstawie znajomości dwóch firm, w dodatku takich z mniejszego miasta.