Разпределените екипи имат нужда от повече от канал в Slack и ежедневна среща. Ефективното сътрудничество изисква съзнателен избор на инструменти и ясни правила за комуникация, които намаляват триенето и държат всички в синхрон.
Нива на комуникация
Структурирайте комуникацията в три нива: синхронна (видеоразговори, програмиране по двойки), асинхронна (писмени актуализации, записани демонстрации) и пасивна (табла, страници за състоянието). Не всеки разговор изисква среща и не всяка актуализация изисква нишка. Изберете правилното ниво за всеки вид информация.
Едно просто правило помага на екипите да изберат:
- Синхронно за решения с голяма неяснота или емоционална тежест: дизайнерски спорове, реакция при инциденти, трудна обратна връзка.
- Асинхронно за статус, предложения и всичко, което някой може да поиска да препрочете по-късно.
- Пасивно за факти, които се променят сами: състоянието на компилациите, статуса на внедряванията, графика на дежурствата, напредъка на спринта.
Запишете правилата по подразбиране. „Въпросите се задават в канала на екипа, а не в лични съобщения“ и „решенията, взети на разговор, получават писмено обобщение до един ден“ звучат очевидно, но неписаните норми са първото, което се разпада, когато екипът расте или се разпростира в различни часови зони.
Сътрудничество по кода
Прегледът на кода е една от най-важните съвместни практики в инженерството. Поставете ясни очаквания за времето за преглед — стремете се прегледите да се правят до четири часа в работно време. Използвайте чернови на pull request-и за ранна обратна връзка и съобщения по конвенцията conventional commits, за да предадете намерението си.
feat(billing): add proration to plan upgrades
fix(auth): refresh session before token expiry
docs(adr): record decision to adopt event sourcingИнструменти като GitHub, GitLab и Bitbucket предлагат работни процеси за преглед, но процесът е по-важен от платформата. Създайте контролен списък за преглед на кода, който обхваща коректност, четимост, тестове и документация.
Няколко практики правят прегледите по-бързи и по-приятни:
- Поддържайте pull request-ите малки. Фокусираната промяна получава внимателен преглед, а голямата — бегъл поглед.
- Пишете описанието за рецензента. Обяснете защо съществува промяната, какво е обмислено и отхвърлено и как да се провери.
- Отбелязвайте сериозността на коментарите. Разграничаването на блокиращ проблем от предложение или дребна забележка спестява един кръг комуникация.
- Автоматизирайте скучните части. Форматирането, линтването и проверката на типовете са работа за инструментите, за да могат хората рецензенти да се съсредоточат върху дизайна и поведението.
Управление на проекти
Изберете подход към управлението на проекти, който отговаря на размера и работния процес на екипа ви. Kanban таблата работят добре за поддръжка и непрекъсната доставка, докато спринтовете дават структура при разработката на функционалности. Ключът е последователността — изберете подход и се придържайте към него достатъчно дълго, за да оцените ефективността му.
Какъвто и да е методът, добрият тракер отговаря с един поглед на три въпроса: върху какво се работи, кой отговаря за него и какво е блокирано. Ако хората продължават да задават тези въпроси в чата, таблото не си върши работата. Поддържайте задачите достатъчно малки, за да се завършат за няколко дни, свързвайте ги с pull request-ите, които ги затварят, и архивирайте остарялата работа, вместо да оставяте backlog-а да се превърне в гробище.
Култура на документиране
Екипът, който документира добре, си сътрудничи по-добре. Поддържайте жива документация за архитектурните решения (ADR), процесите по въвеждане на нови хора и runbook-овете. Инвестирайте във вътрешни инструменти, които улесняват намирането и обновяването на документацията.
Записът за архитектурно решение не е нужно да е дълъг:
## ADR-012: Use server-side sessions
Status: Accepted
Context: Token refresh logic caused repeated auth bugs on mobile.
Decision: Store sessions server-side with an httpOnly cookie.
Consequences: Simpler clients; requires a shared session store.Дръжте документацията близо до работата. Документацията в същото хранилище като кода се обновява в същия pull request; документацията в отделно уики обикновено изостава.
По-малко инструменти, по-добре интегрирани
Разрастването на инструментите е отделен проблем за сътрудничеството. Всяко допълнително приложение е още едно място, където информацията може да се скрие, и още един поток от известия, които се борят за вниманието. Преди да въведете нещо ново, попитайте кой съществуващ инструмент заменя то и кой ще отговаря за конфигурацията му. Предпочитайте инструменти, които се интегрират със системата за контрол на версиите и тракера ви, така че pull request да обновява задачата си, а внедряване да публикува съобщение в правилния канал, без някой да копира връзки на ръка.
В заключение
Най-добрата стратегия за сътрудничество е тази, която екипът ви наистина използва. Започнете просто, подобрявайте въз основа на обратната връзка и непрекъснато усъвършенствайте работните си процеси. Преразглеждайте нормите си приблизително веднъж на тримесечие, премахвайте инструментите, които никой не отваря, и приемайте триенето, за което съобщават новите колеги, като най-честния сигнал, който ще получите.