Разработване на екипен проект срещу Flying Solo

Тази седмица се впускам във втория си проект за отдалечен екип като част от Chingu Cohorts. По този начин бих искал да отделя малко време за размисъл върху това, което научих в първата си кохорта „Пътуване“.

Снимка на Андрю Нийл на Unsplash

Да работя като част от екип не е нещо ново за мен. Прекарах последните 20 години в изследвания във фармацевтичната индустрия, като всички те бяха прекарани в екипи с различни размери и нива на взаимодействие. Това обаче беше първият ми опит като част от екип за разработка и ми предостави нови предизвикателства срещу разработването на проект сам.

Моята група се състоеше от трима души, всички от които имаха опит в разработването на приложения за пълен стек и двама от тях (не аз) имат опит с предишни групови проекти чрез Chingu.

Разбира се, насочвайки се към проекта, имах обичайните опасения и нервност относно кодирането като част от групата, като „Какво става, ако кодът ми не е в съответствие с останалите в групата?“ И „Какво, ако направя грешка и напълно унищожи кодовата база на групата? ”и така нататък…

Както обикновено, тези видове опасения се оправиха сами, когато започнахме да се ровим в проекта и бих искал да мисля, че се отдалечих много по-добър разработчик, защото съм бил част от него. Научих много от другите двама членове на екипа и бих искал да мисля, че те успяха да научат нещо от мен в замяна.

Като размишлявам върху опита като цяло, установявам, че има два основни елемента, които силно повлияха на напредъка и общия успех на екипния проект, които не участват в отделни проекти, комуникация и работен процес. Както ще видите по-долу, тези елементи са много преплетени, но ще адресирам всеки от тях поотделно.

общуване

Когато сами работите върху проект, имате пълна картина на обхвата и състоянието на вашия проект по всяко време. Ако не го направите, е безопасно да се каже, че вашият проект ще има някои сериозни проблеми ...

Като част от групов проект обаче вие ​​сте зависими от вашите съотборници, за да ви предоставим всички и всички промени, които са направили (и те са зависими от вас за същото).

Снимка на Джеймс Сътън на Unsplash

Тези комуникации могат да се предлагат в различни форми и ние ще разгледаме някои от тях по-долу в раздела на работния процес, но е достатъчно да кажем, че ако сте направили промяна в проекта и не сте го съобщили по някакъв начин на вашите съотборници, те не са наясно с това!

Което означава, че те ще продължат със собствените си задачи, сякаш промяната ви не се е случила. Това може да доведе до ненужно главоболие и много загубени часове по пътя ... Всичко това би могло да бъде предотвратено чрез добра комуникация между членовете на екипа.

На пръв поглед това може да звучи като очевидна концепция и да не си струва точно да напишете (или прочетете) цяла статия. Но ако сте свикнали да работите сами, като цялата комуникация се случва несъзнателно в собствената ви глава, това представлява критично важна промяна в нормалния ви процес.

Като такъв, уверете се, че се държите като добър съотборник и дръжте всички в кръга. Това не трябва да е трудно или отнема много време. Вероятно е вашият екип да е установил линии на комуникация. Задържането на всички в контура може да бъде толкова лесно, колкото актуализиране на състоянието на Trello карта или пускане на бърза линия в отпуснат канал.

Когато се съмнявате, грешете от страната на повече комуникация.

Тоест, ако не сте сигурни дали нещо е от значение за екипа, просто хвърлете бърз FYI там, на който и да е канал, който екипът използва и да продължите напред.

Съмнявам се, че има много бивши екипи, които казват „Не бих могъл да си свърша работата, просто беше прекалено много общуването!“, Но има много неща, които казват „Нашият екип се разпадна, защото никой не общуваше ...“.

Работния процес

Което ни води към работния процес.

Под работния процес имам предвид как вашият екип управлява процеса на git и дали те ефективно използват клонове, поръчки, изтегляне на заявки и т.н.

Както казах преди, това беше първият ми проект за групово развитие. Преди използвах git за моите солови проекти, но имах много да науча, когато стана дума за използването на git като част от екип.

За щастие, Франческо Агнолето написа серия ръководства, които ясно очертават как git трябва да се използва в екипна обстановка. Горещо препоръчвам да прочетете (и да запазите отметки за бъдещи справки) и трите статии. Те могат да бъдат намерени тук - част 1, част 2 и част 3.

Лично аз ги чета всеки път няколко пъти и нашата група ги използва като правило за това как нашият екип ще се справи с работния процес.

Няма да преразказвам това, което Франческо е написал в статиите си, тъй като смятам, че той обхваща много ясно материала, но искам да подчертая няколко неща, които прави, тъй като е свързан с тази статия.

Първо, когато се направи ефективно, добрият работен процес засилва комуникацията в екипа. Както казах по-рано, комуникацията и работният процес са много преплетени и всеки може да подобри другия.

Снимка на Pavan Trikutam на Unsplash

Изборът (и придържането към) добро споразумение за именуване на клоновете ясно ще уведоми съотборниците ви точно за какво работите. Това, сдвоено с ясни и прости заглавия за вашите ангажименти, не само осигурява предвидения контрол на версиите, но и карта на това, за което всеки член на екипа работи (и работи).

Посочените по-горе ръководства имат съвети за именуване на конвенции както за клонове, така и за комити. Прочетете ги!

Сега, когато всички четем статиите на Франческо и всички сме на една и съща страница, що се отнася до работния процес, има една последна точка, която бих искал да направя. Бъдете много старателни да не правите промени, които са извън обхвата на вашия клон.

Това е много важно и не може да бъде занижено! Когато работите като част от екип, не правете промени, които не са в обхвата на клона, върху който работите!

В духа на честността, това е лош навик да правя, когато работя по солови проекти. Ако работя върху една функция и си спомням нещо, което исках да променя в различна част от кодовата база, просто отивам и го променя, без да се притеснявам в кой клон се намирам.

Въпреки че това може да е лоша практика, вероятно няма да ви създаде прекалено големи проблеми, когато работите сами. Правенето на това като част от екипния проект, от друга страна, може да има много лоши последици.

Промяната в кода, върху която активно работи един от вашите съотборници (в допълнение към това, че ги пикае), има потенциал да предизвика всякакви конфликти, когато се опита да обедини промените си. Те могат да прекарат точно толкова време за решаване на конфликти за сливане, колкото и да правят промени в клона.

Не е добре за динамиката на отбора ...

резюме

Ако планирате да направите кариера извън разработването на софтуер, ще трябва да се научите да работите като част от екип. Това определено е едно от онези меки умения, които могат значително да повишат (или да попречат) на вашата ефективност като разработчик.

Не е необходимо да е трудно, но просто са необходими известни усилия. Имайте предвид, че сте част от екип и действайте като такъв. Силната комуникация и работният процес ще направят вашия екип по-голям от сбора на частите му, но обратното абсолютно ще задържи напредъка на вашия екип до стоп.

И ако работите, за да станете разработчик, направете си услуга и погледнете в Chingu Cohorts. Това е страхотна глобална общност от разработчици и амбициозни разработчици, които работят заедно, за да правят страхотни неща.