Desenvolupant un projecte d'equip vs volador sol

Aquesta setmana em vaig embarcar en el meu segon projecte d’equip remot com a part de les cohorts de Chingu. En fer-ho, voldria prendre un minut per reflexionar sobre el que vaig aprendre a la meva primera cohort de "Voyage".

Foto d'Andrew Neel a Unsplash

Treballar com a part d’un equip no és una cosa nova per a mi. He passat els últims vint anys fent recerca a la indústria farmacèutica, tot gastant-se en equips de diverses mides i nivells d’interacció. Aquesta va ser, però, la meva primera experiència com a part d’un equip de desenvolupament i va proporcionar alguns nous reptes respecte al desenvolupament d’un projecte pel meu compte.

El meu grup estava format per tres persones, totes elles amb experiència desenvolupant aplicacions de pila completa i dues de les quals (no jo) tenien experiència amb projectes de grups anteriors a través de Chingu.

Per descomptat, dirigint-me al projecte, vaig tenir les habituals inquietuds i el nerviosisme sobre la codificació com a part d’un grup, com ara "Què passa si el meu codi no està a l’altura dels altres del grup?" I "Què passa si faig una equivocar-se i destruir completament la base de codis del grup? ”, etc.

Com de costum, aquest tipus d’aprensions van funcionar a mesura que vam començar a excavar el projecte i voldria pensar que em vaig allunyar d’un desenvolupador molt millor per haver-ne format part. Vaig aprendre moltes coses dels altres dos membres de l’equip i voldria pensar que, a canvi, van poder aprendre alguna cosa de mi.

Al reflexionar sobre l’experiència en general, trobo que hi havia dos elements clau que van impactar molt els avenços i l’èxit global del projecte d’equip que no entraran en joc en projectes, comunicació i flux de treball individual. Com veuràs a continuació, aquests elements estan molt entrellaçats, però els abordaré de manera individual.

Comunicació

Quan treballeu en un projecte per vosaltres mateixos, teniu sempre una imatge completa de l’abast i l’estat del vostre projecte. Si no ho és, és bastant segur dir que el vostre projecte tindrà problemes seriosos ...

Com a part d’un projecte de grup, però, depenen dels companys d’equip per proporcionar-vos tots els canvis que hagin fet (i depenen del vostre mateix).

Foto de James Sutton a Unsplash

Aquestes comunicacions es poden fer de diferents formes, i en tindrem algunes de les que es mostren a continuació, a la secció de flux de treball, però n'hi ha prou amb dir que si heu fet un canvi al projecte i no ho heu comunicat d'alguna manera als vostres companys d'equip, no en són conscients!

El que significa que continuaran amb les seves pròpies tasques com si el vostre canvi no hagués passat. Això pot provocar mals de cap innecessaris i moltes hores perdudes al llarg del camí ... Tot això es podria haver evitat mitjançant una bona comunicació entre els membres de l'equip.

A la superfície, això pot semblar un concepte evident i no val la pena escriure (o llegir) un article sencer sobre. Però si estàs acostumat a treballar sol, amb tota la comunicació passant inconscientment al teu propi cap, això suposa un canvi important en el teu procés normal.

Com a tal, assegureu-vos que actuïu com un bon company d'equip i que tothom estigui al corrent. Això no ha de ser difícil ni fer temps. És probable que el vostre equip hagi establert línies de comunicació. Mantenir tothom al bucle pot ser tan senzill com actualitzar l'estat en una targeta Trello o deixar anar una línia ràpida en un canal fluix.

Quan tingueu dubte, comenceu-vos a equivocar-vos pel costat de més comunicació.

Això vol dir, si no esteu segur d’alguna cosa rellevant per a l’equip, només heu de llançar una FYI ràpida cap allà a qualsevol canal que l’equip estigui fent servir i seguir endavant.

Tinc dubtes que hi ha molts antics equips que deien "No podia fer la meva feina, hi havia massa comunicació!", Però hi ha molts que diuen que "El nostre equip es va separar perquè ningú es va comunicar ...".

Flux de treball

El que ens porta al flux de treball.

Per flux de treball, vull dir com el vostre equip gestiona el procés de git i si utilitzen efectivament sucursals, commits, pull request, etc.

Com he dit abans, aquest va ser el meu primer projecte de desenvolupament de grups. Abans havia utilitzat git per als meus projectes en solitari, però em quedava molt per aprendre a l’hora d’utilitzar git com a part d’un equip.

Afortunadament, Francesco Agnoletto ha escrit una sèrie de guies que expliquen clarament com s’ha d’utilitzar git en un equipament. Recomano que llegiu els tres articles (i marqueu-les per a futures referències). Es poden trobar aquí: part 1, part 2 i part 3.

Personalment, les he llegit diverses vegades i el grup el va utilitzar com a regla per manejar el nostre equip de treball.

No faré cap comentari sobre el que ha escrit Francesco en els seus articles, ja que crec que cobreix el material amb molta claredat, però vull ressaltar diversos punts que planteja pel que fa a aquest article.

Primer, quan es fa de manera eficaç, un bon flux de treball millora la comunicació en equip. Com he dit anteriorment, la comunicació i el flux de treball estan molt entrellaçats, i cadascun pot millorar l’altra.

Foto de Pavan Trikutam a Unsplash

Si escolliu (i s’adhereixen a) una bona convenció d’anomenament de les sucursals, els vostres companys sabrien exactament el que esteu treballant. Aquesta, aparellada amb títols clars i senzills per als vostres compromisos, no només proporciona el control de versions previst, sinó també un mapa del que treballa (i estava) treballant cada membre de l’equip.

Les guies esmentades tenen consells sobre convencions de denominació tant per a sucursals com per a compromisos. Llegiu-les!

Ara que tots hem llegit els articles de Francesco i estem tots a la mateixa pàgina pel que fa al flux de treball, hi ha un últim punt que voldria fer. Sigui molt diligent en no fer canvis que estiguin fora de l’àmbit de la vostra oficina.

Això és molt important i no es pot subratllar. Quan treballeu com a part d’un equip, no feu canvis que no siguin de l’àmbit de la branca on treballeu.

En l’esperit d’honestedat, això és un mal costum de fer quan treballo en projectes en solitari. Si treballo en una característica i recordo alguna cosa que volia canviar en una altra part de la base del codi, només vull canviar-la sense preocupar-me de quina branca estic.

Tot i que això sigui una mala pràctica, probablement no us portarà massa problemes quan treballeu sol. Si ho fas com a part d’un projecte d’equip, d’altra banda, pot tenir conseqüències molt dolentes.

Fer un canvi per codificar en què un dels vostres companys està treballant activament (a més de fer-los enfadar) té el potencial de provocar tot tipus de conflictes quan intenten combinar els seus canvis. Podrien dedicar el mateix temps a resoldre conflictes de combinació, i fer primer canvis a la sucursal.

No és bo per a la dinàmica d'equips ...

Resum

Si teniu previst fer una carrera professional en el desenvolupament de programari, haureu d’aprendre a treballar com a part d’un equip. Sens dubte, aquesta és una d'aquestes habilitats suaus que poden millorar (o dificultar) la vostra eficàcia com a desenvolupador.

No ha de ser difícil, però cal fer un esforç conscient. Mantingueu en compte que formeu part d’un equip i actueu com a tal. La comunicació forta i el flux de treball faran que el vostre equip sigui més gran que la suma de parts, però tot el contrari arrossegarà absolutament els progressos del vostre equip.

I si treballeu per convertir-vos en desenvolupador, feu-vos un favor i consulteu les cohorts de Chingu. És una increïble comunitat mundial de desenvolupadors i desenvolupadors aspirants que treballen junts per fer grans coses.