Jak zorganizować zespół i poprowadzić projekt.

Odpowiedz Nowy wątek
2018-08-28 14:45
3

Zostałem niedawno koordynatorem małego, zdalnego, zespołu programistów (4 sztuki). Pierwszy projekt już prawie skończony, ogarnąłem specyfikacje i architekturę projektu, taski lecą przez Trello, pracujemy w tygodniowych sprintach, robimy wzajemnie code review itd.. Wiem jednak że dużo mi brakuje do bycia dobrym kierownikiem.

Największy problem sprawia mi odpowiedni podział projektu na taski, żeby wszyscy mogli pracować jednocześnie, bez konieczności tworzenia mocków, lub czekania aż ktoś inny skończy API innego modułu. Poza tym, często muszę uciekać się do mikrozarządzania, żeby całość ze sobą zagrała. No i finalnie, nie wiem jak podchodzić do całości od strony ludzkiej, starać się z nimi zakolegować, czy raczej trzymać chłodny dystans. Moglibyście mi polecić książki/blogi/filmy/szkolenia na temat skutecznego zarządzania zespołami, projektami i ludźmi? Podzielić się, jak wygląda workflow u was, od otrzymania specyfikacji do zdania projektu?

Pozostało 580 znaków

2018-09-13 13:44
0

Do obecnego zespołu i firmy dołączyłem (między innemi), dlatego że w zasadach mieli, robienie mocków do wszystkich zewnętrznych zależności. Dzięki temu można spokojnie pracować nad systemem będąc totalnie offline. Niektóre mocki mają całkiem skomplikowaną logike i symulują całkiem niezłe rzeczywiste systemy.

W poprzedniej firmy ilość strat generowana przez to, ze jakiś z systemów nie działał i nie mozna było nawet GUI dopalić - była kosmiczna. Całe roboczo tygodnie w p...du.


Bardzo lubie Singletony, dlatego robię po kilka instancji każdego.
edytowany 2x, ostatnio: jarekr000000, 2018-09-13 13:47
Pokaż pozostałe 8 komentarzy
Ale to codziennie zmieniacie te nagrania z Wiremocka, żeby zwracały aktualne dane potrzebne w testach? A jak sobie to radzi z obsługą danych w czasie rzeczywistym, np. opóźnieniami lotów? - somekind 2018-09-13 15:59
@somekind: Pracujesz jednocześnie nad kilkudziesięcioma mikrousługami czy jedna ma tyle zależności? - tdudzik 2018-09-13 16:07
Oczywiście, że nie pracuję nad tyloma - dlatego też nie chcę ich mieć u siebie. Pracuję nad jedną, w ciągu tygodnia zaglądam jeszcze do drugiej, czasem trzeciej. Reszta to zależności tych trzech i zależności ich zależności. - somekind 2018-09-13 16:16
@somekind: nie wszystkie dane msuza byc aktualne, szukasz np. lotow miesiac do przodu. I zakladasz ze rzeczy typu data, numer lotu itp moga sie zmieniac. Jak w rzeczywistosci. Ale to nie wplywa na funkcjonalnosc. Wazne zeby sie struktura odpowiedzi zgadzala. Opoznienia odpoiwiedzi mozna dowolnie konfigurowac + jakies automatyczne zmienianie badz generowanie wartosci. Wydajnosciowo tez jest niezle. na c5.2xlarge amazonowym spokojnie wytrzymuje 4 Gbit/s loadu. Majac jeszcze zapas. Ja nie twierdze ze top jest panaceum na wszystko, ale narzedzie jest naprawde warte poznania. - WhiteLightning 2018-09-13 19:00
Wszystkie te podejścia typu wspólna baza danych dla wszystkich developerów w zespole ,wspólne serwisy to jakaś choroba. Jak wtedy np. rozsądnie testować e2e - ja zakładam użytkownika, a CI, a lbo kolega w tym czasie kasuje? Generalnie jakiś DEV czy INT na pokazywanie binzesowi i ich testy jest OK. Ale dla mnie do pracy musze mieć wszystko wyizolowane - inaczej nie ma mowy o jakiś miarodajnych testach. - jarekr000000 2018-09-13 19:04

Pozostało 580 znaków

2018-09-14 01:53
0

@Krolik

Jak budujesz projekt bottom-up, to nie są potrzebne mocki. Jakby budowlańcy zaczynali
budowę od dachu, to w wtedy faktycznie potrzebowali by mocków ścian i fundamentów :P

to, to! Też chciałem to napisać, ale pomyślałem, że nie ma sensu, bo OP i tak pewnie nie wcieli tej zasady, ponieważ zasada budowania top-down jest wręcz dogmatem w wielu firmach (sam fakt, że OP jest "koordynatorem" - czyli w nazwie stanowiska ma wpisaną zasadę top-down). Namawianie do podejścia bottom-up to tak jakby powiedzieć koordynatorowi, żeby przestał być koordynatorem. -

Wydaje mi się, że coś jest szalenie zepsute w metodykach budowania komercyjnego softu. Dlatego właśnie w wielu firmach "agile" panuje dalej waterfall, bo te firmy dalej opierają się na zasadzie top-down (czyli: waterfall), zamiast zrobić coś takiego jak jest w open source projektach - że jeden programista tworzy moduł/bibliotek, a inni programiści używają tej biblioteki. Łączą wiele niskopoziomowych bibliotek/modułów w większe biblioteki, czy w całe aplikacje

Trochę tak jakby to były 2 inne światy, gdzie w open source budowałoby się metodą syntezy (tworzenia czegoś większego z małych elementów - budowanie jak klocków), a komercyjny soft byłby robiony metodą analizy (gdzie bierze się jeden wielki projekt i dzieli się ten projekt na wiele małych stories czy tasków). To wynika w dużej mierze ze struktury władzy (może dziwnie brzmi to słowo w tym kontekście, ale chodzi mi o to, kto podejmuje decyzje, czy idzie z góry, z duchem waterfalla, czy może samowystarczalne zespoły, i poszczególni programiści, mają autonomie piszą soft współpracując ze sobą).

Swoją drogą zamiast dzielenia tasków, ja bym zapronował coś w stylu opracowania spójnych standardów / reguł współpracy / zasad.

bez konieczności tworzenia mocków, lub czekania aż ktoś inny skończy API innego modułu.

Gdyby istniały spójne standardy, to nie trzeba byłoby czekać aż skończy API modułu, ponieważ moduły miałyby standardowy kształt API (wg jakiegoś tam dobrze znanego standardu).

O ile w ogóle nie byłyby skończone (czemu też można by zapobiec przez continous integration).

Czemu tak często w komercyjnym sofcie odkrywa się koło na nowo (NIH) i pisze się soft na zasadzie "wielkich zmian co jakiś czas" zamiast "małych zmian codziennie"?


((0b10*0b11*(0b10**0b101-0b10)**0b10+0b110)**0b10+(100-1)**0b10+0x10-1).toString(0b10**0b101+0b100);
edytowany 5x, ostatnio: LukeJL, 2018-09-14 12:59

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0