Как да изградим солидни екипни взаимоотношения в ИТ компания

Избери работата, която обичаш, и тогава няма да бъдеш принуден да работиш и един ден през живота си.
Конфуций

Софтуерните компании са сложни структури, които се нуждаят от новаторски идеи, продукт, който да се харесва на потребителите и силни в областта си специалисти, които да разработят продуктите и да поддържат качеството при новите версии на софтуера.

Всички сме чували за компаниите Стартъп (Startup), които имат малко на брой служители и малък бюджет, но голям потенциал, тъй като самите основатели са водени от идеята, че техният продукт ще бъде много полезен за обществoто. Тази идея ги кара да работят неуморно за обработването на обратната връзка от потребителите и предоставяне на нови версии с повече функционалности. Компаниите често пъти се нуждаят от инвеститори, които вярват в идеята и се доверяват на начина на разработката на основателите. С новите функционалности на разработваното приложение се увеличава и потребността от нови служители и установяването на процеси за работа.

Не е учудващо, че в средите на информационните технологии разработчиците биха избрали уеб приложение за управление на проектите си. Jirа (Джира) е точно такова уеб-приложение, което се налага на пазара като удобно и лесно за управление на задачи (таскове/tasks), дефекти, разпределение и планиране на задачите по работни седмици (спринтове, итерации) спрямо наличността на служителите.

Чрез използването на Jira отпада необходимостта от микромениджмънт. Служителите имат възможност да следят цялостното развитието на проекта сами, да актуализират статуса на задачите си своевременно и така мениджърите да са информирани в реално време за напредъка или евентуалните проблеми при разработката на софтуера без да прекъсват работата на служителите си с допълнителни въпроси.

Тъй като всяка компания определя свои правила за използване на Jira и разпределение на задачите, понякога се случва така, че програмисти и софтуерни тестери работят по една и съща задача в Jira, която на практика са две различни задачи. Например developer-ът разработва функционалност за „регистриране в системата“ и неговата задача преминава в статус „готова за тестване“. Тогава софтуерният тестер започва да сравнява разработенето и спецификацията. Ако забележи разминаване със спецификацията, специалистът по тестване отваря дефект отново в Jira, който е „закачен“ към задачата за разработка. След приключване на тестването, софтуерният тестер може да насочи задачата отново към програмиста, за да отстрани откритите дефекти. По време на тестването програмистите не си почиват, а разучават, как да бъде имплементирана новата им задача или директно работят по нея. Когато видят преотворена задача или такава с много дефекти, това нарушава работния им ритъм, тъй като вече мислят за две задачи. Преди години, когато изгря професията на софтуерния тестер, се смяташе че програмист и тестер са врагове. За щастие с времето се установиха добри работни практики и това недоразумение се изчисти, тъй като главната цел на един екип е да предостави на клиентите работещ софтуерен продукт. Честото преотваряне на тикети без причина или като заяждане не е добра практика, лесно може да бъде избегнато с един разговор с product owner или project manager, които да преценят дали е важно дефектът да бъде отстранен, дали е нужно да бъде отстранен и дали поправката му е с по-голяма важност от разработката на нова функционалност.

Друг подход за управление на задачите в Jira е всеки developer да има отделни таскове за разработка, а всеки QA (quality assurance engineer) да има таск за тестване. Така developer-ите няма да имат усещането, че тасковете им непрекъснато се преотварят, а ще работят по новоткритите дефекти, които сами по себе си са нов таск.
Основните статуси през които може да премине задача в Jira обикновено са: нов, възложен, отворен, дублиран, не е дефект, отказан, преотворен, поправен, тестван повторно, верифициран и затворен. Администратор на Jira може да промени статусите, ако са прекалено много и утежняват процеса на работа при текущите нужди и натовареност на екипа. За да се предотвратят недоразумения и излишни дискусии, добра практика е при смяна на статуса на тикет-а да се остави коментар, който да изясни какво е наложило смяната на статуса.

Източник на изображение: pixabay.com

Понякога програмистите оставят като коментар само препратка към кода, който са написали. Този подход е полезен, но разбираем само за останалите програмисти от екипа, които проверяват кода за грешки и възможни дефекти или регресии. Разбира се всеки QA се стреми с напредването на кариерата си да разбира все повече от писане на код, но да прави ревю на кода, не е сред основните задачи на специалистите по manual testing (ръчно тестване), затова тяхната работа би била улеснена, ако програмистите оставят и коментар, как би се отразила направената промяна в кода на ползването на софтуерния продукт. На база на такъв коментар, тестерите създават тестови сценарии и задачата им може да бъде завършена по-бързо и без допълнителни въпроси към developer-ите дали тестването е било извършено правилно.

За да работи пълноценно екипът е важно всеки един специалист да описва подробно резултата от работата си. При добре дефинирани изисквания в началото на проекта, всеки developer и QA може да прецени в какви срокове би завършил задачите си. Ако QA-ите описват добре дефектите, които откриват, след това програмистите ще отделят по-малко време да разберат дефекта и да го възпроизведат, което от своя страна ще улесни поправката на дефекта.

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

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

Автор на статията: Ина Бунова –  Quality assurance engineer и дългогодишен преподавател в компютърно образователен център Progress.

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