Workflow tools for development

@Work
, ,
1

Relates to: Ce soft de tasking/suport folositi?
and Metodologii pentru Project management

Nu e un duplicat, ce vreau să fac e o mini listă de unelte pentru echipe sau coderi de tip “lone ranger”.

Motivație: Cei mai mulți “web developeri” de care dau în ultima vreme sunt maxim de ignoranți în ceea ce privește munca organizată. Într-o minimă măsură îi înțeleg dar trebuie să fie într-un fel forțați să înceapă să se obișnuiască cu un minim de procedură. Cel puțin dacă vrei un job sau mai mult, dacă vrei un job de unde să și înveți ceva ca să progresezi.

Ca programator simplu, nu prea vezi de ce ar trebui să îți complici viața cu tot felul de unelte. Pănă începi să crești și începi să faci outsourcing că crește volumul de muncă. Moment în care începi cu pași mici dar siguri să devii ca în bancul ăla, “maimuța cu titlu de project-manager”.

Mulți văd, puțini cunosc.
Problema cu “outsourcing” ăsta e că tot tu garantezi pentru muncă, chiar dacă a făcut-o altul pentru tine.
Și trebuie să te asiguri, cu minim de efort, că ce a făcut Goguță e la calitatea pe care o vrei și pe care dai garanția.

Scopul meu în treaba asta se împarte în două. Să aflu noutăți și să încerc să dau o explicație, pentru începători și nu numai, pentru cerintele de lucru ce par a fi “draconice”.
Baby steps în a ne pregăti viitori colegi.

Majoritatea “antreprenorilor” de care dau, vor să își facă “cea mai tare echipă din lume”. Și nu că ar fi un lucru rău, doar că:

  • toți vor oameni din același oraș, ca să facă un birou mare și frumos.

    • asta din punctul meu de vedere, e primul semn că pe viitor nu se va ajunge nicăieri
      În “calculatoare” NU contează locația geografică. 90% din cei care zic că vor să fii cu ei în birou, sunt dezorganizați, împrăștiați, cum vrei să-i zici. Rare sunt cazurile de proiecte atât de complexe încât să fie necesară comunicare verbala constantă.

  • consideră că nu-i nevoie de documentație (macar a codului) și/sau de un istoric al proiectului (nu doar git log)

    • ce vrei să eviți pe cât de mult posibil e dependența de un anume programator. Din principal 3 motive:
      1- nu îți permiți să plece Goguță, 2- nu îți permiți să-l schimbi pe Goguță, 3- să-i dai un coleg să lucreze poate fi un adevărat coșmar.
    • refractoring-ul de cod devine usor un cosmar. uiți ce ai făcut, de ce ai făcut, strici alte chestii funcționale
    • cand lucrează mai mulți oameni, e vital ca toată lumea să înțeleagă ce a facut colegul și care a fost raționamentul lui, altfel vor aparea tot felul de work-arounds care îți vor transforma proiectul în spaghetti code. De aceea e absolut necesar ca toată echipa să valideze o bucată de cod înainte de a se face merge. Și bineînteles să se pună întrebări. E ok, dacă un coleg zice nu altui coleg, chiar dacă tu ca project manager zici că codul respectiv e ok.

  • unit testing. știu, e plictisitor, nimeni nu vrea să își bată capul că trece dead-line, dar ai garanția că codul merge și nu mai apar situații de genul “băi da ăsta știu că mergea”

Toate chestiile astea îți fac munca enorm de ușoară pe termen lung. Îți fac echipa flexibilă, e usor să aduci oameni noi și să se apuce repede de lucru și nu plângi dacă pleacă programatorul principal. Și chiar vei putea da dead-line-uri pe care să le și respecți :smile:

Eh, lista asta de unelte aș împărti-o în 2: free/moca și premium. Nu toată lumea scoate bani de pe proiectele la care lucrează. Nu tot timpul merită să dai bani pe ele, dar merită să încerci pe cât de mult posibil să lucrezi profesional și organizat, chiar dacă e un proiect hobby, nu se știe niciodată când va deveni ceva serios. Îți formezi tabieturile de muncă.

Free/Moca

Premium

Asteptăm sugestii.

4 Likes
2

cu un lucru nu sunt de acord:

Crede-ma ca atunci cand ai proiecte in productie si-ti tipa buza si ala care ar trebui sa stie / rezolve e la mama dracu si n-are internet sau i s-a spart o teava sau orice… been there, not fun. Also, cand ii ai pe toti la un loc economisesti o gramada de timp daca se intalnesc 3 insi si vorbesc 2 minute. Also, luatul unui status “on the fly” pentru vreo decizie e mai usor, sa nu zic “posibil”. Si muuulte alte argumente.

1 Like
3

ala care ar trebui sa stie

Păi “here’s the thing” … nu trebuie să fie un ăla care știe! Aici ai o problema. Dupa cum am zis

ce vrei să eviți pe cât de mult posibil e dependența de un anume programator. Din principal 3 motive:
1- nu îți permiți să plece Goguță, 2- nu îți permiți să-l schimbi pe Goguță…

Oricine din echipa, trebuie să cunoască cel putin 70% din proiect. Team leader sau project manager nu trebuie decat sa fie un titlu onorific pt “ala care comunica cu clientul”

Daca vorbesc 3 insi 2 minute si iau o decizie e ok, doar daca toata echipa e de 3, daca nu

… cand lucrează mai mulți oameni, e vital ca toată lumea să înțeleagă ce a
facut colegul și care a fost raționamentul lui, altfel vor aparea tot
felul de work-arounds care îți vor transforma proiectul în spaghetti
code. De aceea e absolut necesar ca toată echipa să valideze o bucată de
cod înainte de a se face merge. Și bineînteles să se pună întrebări…

si muuuuulte argumente. De cate ori n-am facut eu cod duplicat pt simplul motiv ca n-am inteles ce a facut alalalt si eram in graba si altu in spatele meu a folosit codul meu … si cateva luni mai tarziu erau 2 sisteme care faceau acelasi rahat si dai si pierzi saptamani cu refractor … pt ca ala nu mai era, code comments din parti si decizie luata la tigare

4

Am si eu o curiozitate.
Cam care este productivitatea unui programator raportata la timp? Cam cate ore pe zi? Chiar puteti sta 6-8 ore zilnic lucrand in continuu?

5

nope. cam 4-5 de lucru efectiv. restu review de cod

1 Like
6

@noah:

Sunt zile bune și zile proaste. În zilele bune scoți 4-5 ore; în zilele proaste… sunt prea proaste să le menționăm :smiley:

7

Vezi tu…se poate să lucreze în aceeași încăpere cu tine, dar dacă i se sparge o țeavă acasă tot va fi indisponibil :smiley:

Eu zic așa: cât timp sunt o mulțime de echipe ce lucrează (cu succes) nu doar de acasă, dar și din time-zone-uri mult decalate, nu oi fi eu mai special să nu reușesc asta.

Eu sunt adeptul verba volant scripta manent. Oricât de mult ai discuta pe marginea unui proiect, cel mai sigur este să scrijelești undeva deciziile luate.

În șapte-opt ani de freelancing singurele momente în care aș fi vrut să fiu în aceeași încăpere cu ceilalți au fost atunci când îmi venea să-i strâng de gât (fie clienți, fie colaboratori) :disappointed:

3 Likes
8

Să nu uităm de uneltele de comunicare:

Noi folosim următoarea combinație:

  • Slack pentru text
  • Google Hangout pentru voce/video

Am renunțat la Skype pentru că în ultimele versiuni a devenit din ce în ce mai buggy, iar căutarea prin arhivă nu e cea mai practică chestie din univers…

Și că tot vorbeam de remote: am lucrat cu succes într-o echipă împrăștiată pe trei timezones: San Francisco, România, Tokyo. :smiley:

9

aha. daca iti permiti sa tii 3 oameni redundanti pe aceeasi chestie. in practica n-ai de ce pentru ca oricum dai faliment pana apar problemele :slight_smile: sa nu mai vorbim din carti. daca te referi la ditai multinationala, da, alea nu merg fara proceduri bine stabilite si fixe.

10

Adică ar trebui ca aia 3 oameni sa nu aiba habar decat de bucatica lor?

11

n-am zis asta, dar nu poti avea 3 admini de retea de exemplu. nu renteaza. si continuand cu exemplul, ce faci daca care-l ai nu-i on the grounds si nu raspunde?

zic doar ca pana la un anumit nivel ce zici tu e frumos de avut, dar improbabil. Si vorbesc aici doar de redundanta resurselor, ca versionare tre sa faci si cand esti singur.

12

I have no idee ce ai inteles tu. Eu cu oamenii care lucrez, asa fac. toata lumea cunoaste foarte bine ce se intampla in cod chiar daca nu a scris el bucata. la sfarsitul zilei sau seara, te uiti pe pull-requests, aprobi sau pui intrebari.
Daca maine da masina peste Vasilică și moare, e doar o pierdere sufletească pt ca oricine poate sa continue task-urile lui pt ca le stie exact, nu e nimeni nelamurit, nu pune nimeni intrebari.
Daca maine vreau sa imi iau 3 luni de concediu, nu o sa ma sune nimeni sa ma intrebe, pt ca stiu ce am facut si atat timp cat seara ma uit pe commits sunt perfect up to date si cand revin ma apuc imediat de tasks fara sa pun intrebari sau sa stau cu zilele sa ma pun la curent cu ce s-a intamplat

1 Like
13

da, intradevar e greu sa faci o echipa din asta, pt ca dispare ierarhia (importanta) pt ca oricine poate fi inlocuit instant si e greu sa gasesti oameni care sunt ok cu a nu fi ei sefi sau oameni care sa fie instare sa isi asume decizii.
e un fel de masa rotunda de programare. si merge brici

3 Likes
14

Pai si e productiv ca tot tu sa si verifici codul? Si asta dupa 4-5 ore de scris cod.

De Iamntz stiu ca este liber profesionist, daca nu poate sa scrie ia o pauza se joaca cu pisica face el ceva, dar cei care sunt angajati ce fac?

1 Like
15

Pai nu, cand faci un pull-request, pui pe toata lumea la reviewers si se uita si se da approve, deny sau faci comment daca ai nelamuriri.
Prima data cand incepi in stilul asta e cam greoi, dar intr-o luna asa se cam invata toata lumea.
Scrii un commit message detaliat (gen 4-5 propozitii sau poate mai mult) + comments din cod, nu-i greu de urmarit. Ia maxim 1h

Acum am 3 proiecte simultan, cu 3, 2 si 2 programatori. 2 ale mele, unu pt client. Fiecare programator face commit pe branch-ul lui zilnic (ca sa vad ca nu freaca menta :slight_smile: ) si cand termina task (2 chiar si 3 zile) face pull-request si ala intra la review.

Ce necesita atentie e cod de php si js. Si combinat cu phpcs si jshint, mai mult te uiti ca sa-i intelegi logica.
Si daca citesc o functie de 2-3 ori si tot imi pare ciudat, ii zic sa faca refractor. Sau poate alt coleg zice asta.
Si facand fiecare asta, deja ne combinam stilurile de scris cod.

E si umpic anevoios cate odata, ca la proiectele din astea externe si de sub 1 luna, nu mai scrii unit testing. :stuck_out_tongue: sau faci minimum cat sa acoperi bdd-ul

2 Likes
16

Cât timp nu ești multinațional cu sute de oameni angajați cred că ești ok.

Pentru mine încă e greu de înțeles cum cineva se poate concentra când mai sunt cinci-zece (mai mulți?) oameni în aceeași cameră, când tot timpul se va găsi vreunul care ba vorbește la telefon, ba butonează prea tare, ba ventilatorul laptopului pornește, ba pur și simplu se uită în gol în direcția ta și ai impresia că se holbează la tine.

Eu nu pot să lucrez nici dacă stă nevasta în cameră (chiar dacă stă în spatele biroului, pe fotoliu, fără să scoată vreun sunet…) darămite cu alții :smiley:

Realistic vorbind, dacă un om nu poate fi disponibil, nu poate fi disponibil, indiferent dacă lucrează de acasă sau la firmă.

Problemele pot apărea însă în alte părți:

  • securitate (dezvolți un proiect pentru… nu știu, armată, și tot ce faci nu trebuie să iasă din firmă)
  • ceva hardware special (microcontrolere, telefoane/tablete etc)
  • oameni extrem, dar extrem de extravertiți si au nevoie de contact vizual constant cu alți semeni (de preferabil la fel de extravertiți :smiley: )

Dar pentru proiecte mici/medii? Remote ar trebui să funcționeze.

„Noi ne facem că muncim, ei se fac că ne plătesc” ? :sunglasses:

2 Likes
17

Iti spun si secretul: Important e sa fie portofelul gol inainte sa deschizi editorul! :smiley:

1393×632

3 Likes
18

10 ore? Inregistra doar editorul sau si browserul cu facebook deschis :slight_smile:

19

Pentru time tracking si timesheets eu folosesc Redbooth
Si travis nu trebuie pus neaparat la Premium pentru ca poti folosi travis-ci.org pentru proiectele open source.

20

Există produse alternative la travis, gratuite și private, indiferent de tipul proiectului (dar de obicei vin cu limite la numărul de build-uri):

Și tot așa. De fapt, dacă stau să mă gândesc, travis este printre puținii care nu au un plan gratuit :smiley: