jak wygląda praca w zespole programistów?, (młodszy programista Symfony2, PHP) Opcje

[koszykarze]

Czego może spodziewać się początkujący programista (Symfony2) w pierwszej pracy w zespole?

Załóżmy zaczynam pracę wg ogłoszenia, gdzie w wymaganiach mówi się o 2 letnim doświadczeniu z:
-Symfony2
-Git
-Doctrine
-(twig, html, css, mysql)


Czego mam się spodziewać w kwestii organizacji pracy, podziału obowiązków.

Jakie przykładowe zadania daje się takim nowicjuszom w pierwszych tygodniach, miesiącach? Oddzielny mały projekt do samodzielnej pracy, czy małe zadania w dużych projektach? Nie bardzo widzę, by starzy programiści mieli dzielić się swoimi obowiązkami z nowicjuszem, którego styl i umiejętności są zagadką.

Czy to jest zwykle jedno pomieszczenie, dla całego zespołu z fruwającymi pytaniami, pomysłami czy odizolowane pomieszczenia, a może praca w domu i spotykanie się z zespołem 2 razy w tygodniu?


Wiadomo, że to zależy od tego i owego, że wszędzie inaczej.

Wiem, że aż prosi się, by ponabijać z autora tematu, ale mimo wszystko proszę o w miarę poważne i łagodne potraktowanie.


Może jakieś blogi o tym, artykuły, książki? Workflow, to jest to słowo do google?

[Dejmien_85]

Drogi przyjacielu,

Jako osoba, która pracowała w różnych firmach o różnej organizacji, powiadam Ci - wszystko zależy od firmy.

Ale na 99% wszystko zależy od projektu. Gdy firma ma duży projekt, wtedy wcielają Cię po prostu do zespołu. Jeśli projekt jest malutki, wtedy mogą dać Ci cały projekt - choć na starcie to raczej mało prawdopodobne, bo firma nie zleci nowemu materiałowi, którego jeszcze nie poznali, wykonania zadania od A do Z, stawiając swoją reputację na szali.

W większych firmach przeważnie pracuje się w metodykach zwinnych, poczytaj sobie o Agile, Scrum, Kanbanie, Sprintach, Standupach, Retrospekcjach itd.

I pamiętaj - nawet gdyby projekt miał być ogromniaście ogromny, wtedy i tak robi się go wdrażając jedną funkcjonalność po drugiej, małymi kroczkami. Więc jako nowicjusz na początku pewnie byś dostawał jakieś proste zadania, później coraz trudniejsze - choć wcale nie musi tak być. Ktoś może Cię po prostu zapytać - "Kolego, zajmiesz się tym?".

I pamiętaj - jeśli masz z czymś problemy, to od razu idź po pomoc, nie bój się pytać innych, odbierz to jako konsultacje z profesjonalistami.

Najgorsze co możesz zrobić to... powiedzieć, że poradzisz sobie z jakimś zagadnieniem, gdy wiesz, że tego aktualnie nie jesteś w stanie zrobić, a następnie mówić wszystkim, że jest OKAY, kiedy tak naprawdę siedzisz cicho przy kompie i szukasz na google rozwiązania. To najgorsze co możesz zrobić. W zespole liczy się komunikacja, jeśli widzisz w czymś problem, to od razu gadasz o tym z kolegami i informujesz kierownika projektu/managera/przełożonego/osobę odpowiedzialną za projekt, że jest problem i że coś zajmie sporo dłużej.

Co do work-flowu.

Pracując według "Agile'a".

1. Przed projektem jest planowanie. Wtedy cały zespół się zbiera, przychodzi Analityk Biznesowy (osoba, która gadała z klientem i wyciągnęła czego klient chce), a następnie mówi co będzie trzeba zrobić. Tutaj wyznacza się rzeczy do zrobienia w określonym czasie. Np. Ustala się, że w ciągu tygodnia zrobi się rzecz X, Y, Z. Następnie ten okres czasu nazywa się "sprintem".
Później rzeczy X, Y, Z rozpisuje się na pojedyncze taski, typu: "przygotować schemat bazy danych", "stworzenie widoku dla strony głównej", itd. Głównie tworzy się "zadania", które nie powinny zajać dłużej niż 1 dnia. Na planowaniu ustala się także, kto ma się czym zająć.
2. Po planowaniu programiści zbierają swoje tyłki z sali konferencyjnej (tam przeważnie się planuje), następnie idą do swoich stanowisk i zaczynają pracować. Każdy wie co ma zrobić w danym dniu i to robi, aż do końca dnia.
3. Następnego dnia, rano, są tak zwane "stand upy", "daily", kiedy to zespół spotyka się rano i każdy na szybko streszcza co zrobił poprzedniego dnia, jakie spotkał problemy i co planuje zrobić dalej. Wszyscy na "stand upie" informują się nawzajem co zrobili itd. I tak sobie mijają dni, aż do końca sprintu, kiedy to następuje "code freeze" (wtedy wszyscy przestają wdrażać nowe funkcjonalności i jedynie poprawiają bugi).
4. Następnie jest "demo", czyli kontaktuje się z klientem, przedstawia mu to co zostało zrobione (prezentacja jest przeważnie zdalnie prowadzona).
5. Po spotkaniu z klientem następuje retrospekcja, czyli zespół spotyka się w sali i każdy mówi co poszło dobrze, co źle, jak można to poprawić. Każdy przedstawia swoje propozycje, następnie jest głosowanie, najlepsze propozycje są spisywane i próbuje się ich trzymać w następnym sprincie.

I znów... następnego tygodnia jest Planowanie, kodowanie, codziennie "stand upy", później code freeze, demo i retrospekcja.

Co do samej pracy - są różne oprogramowania do zarządzania projektami, bardzo popularna jest Jira i Confulence. Tam przechowuje się informacje dotyczące projektu, a także zapisuje wszystkie taski i aktualizuje dane kto pracuje nad czym (masz tabelkę typu "to do", "doing", "in testing", "done" i przeciągasz sobie swoje taski odpowiednio).

Co do kontroli wersji - teraz prym wiedzie GIT oraz GitFlow (jeden ze sposobów korzystania z Gita). Wystarczy, że poczytasz o "GitFlow" i będziesz wiedział wszystko o tym, jak się zarządza kodem).

Mam nadzieję, że te informacje coś Ci powiedzą.

Przy okazji - z powyższego sytemu nie korzystają wszystkie firmy, są takie, które mają swoje prawa, lub swoje "bezprawie". Pracowałem w kilku firmach (na początku mojej kariery), gdzie tak naprawdę była kompletna samowolka, po prostu zebrali grupę programistów, którzy nie mieli ani doświadczenia, ani pojęcia o pracy zespołowej i przekazywali im projekty - i każdy ORAŁ jak MÓGŁ (i było zabawnie). (IMG:style_emoticons/default/biggrin.gif)

Także wszystko zależy od tego gdzie trafisz. ; )

Ten post edytował Dejmien_85 28.01.2016, 22:15:39