Как да въведете нов Developer в Scrum екип
Научете как да въведете нов Developer в Scrum екип чрез програмиране по двойки, Definition of Done и самоуправление, вместо чрез остарели уики страници.
Повечето процеси по въвеждане на нови кадри в инженерните екипи се провалят, защото третират хората като компютри, очакващи първоначално прехвърляне на данни. Компаниите дават на новия служител двадесет линка към остаряла документация, настройват правата за достъп в продължение на дни и очакват чист код още през втората седмица. В един Scrum екип този подход е особено неефективен. Scrum разчита на самоуправление, споделена отговорност и бързи цикли за обратна връзка. Ако искате новият Developer да навлезе бързо в ритъм, трябва да го въведете чрез активно сътрудничество, а не чрез изолирано четене.
Фокусирайте се върху Sprint Goal вместо върху уики документацията
Документацията обикновено вече е остаряла по времето, когато новият колега стигне до нея. Вместо да карате новия Developer да смила сложни архитектурни спецификации, запознайте го директно с текущия Sprint Goal. Именно Sprint Goal обяснява защо екипът изгражда съответния Increment точно в този момент. Той дава незабавен бизнес контекст, който никоя статична архитектурна диаграма не може да осигури.
Нека Product Owner отдели двадесет минути, за да разясни цялостната продуктова визия и текущия Product Goal. След това останалите Developers могат да покажат как настоящият Sprint Backlog служи за постигането на тази непосредствена цел. Това дава на новия колега ясна представа за смисъла на работата още преди да напише и един ред код.
Работете по двойки още от първия следобед
Конфигурирането на локална среда за разработка често е изключително фрустриращо. Липсващи системни променливи, остарели скриптове и скрити права в хранилищата отнемат дни, когато човек се опитва да се справи сам. Програмирането по двойки решава този проблем незабавно. Осигурете съвместна работа на новия Developer с опитен колега още през първия му ден.
Първоначалната цел е съвсем проста. Напишете, тествайте и качете малка промяна в тестова среда в рамките на четиридесет и осем часа. Достигането до продукционна или тестова среда веднага демистифицира процеса на внедряване и премахва притеснението. Ето как програмирането по двойки ускорява въвеждането на нови кадри в Scrum:
- Разкрива неписаните екипни правила, които документацията никога не споменава.
- Премахва страха от счупване на софтуерния билд или внедряване на дефектен код.
- Затвърждава разбирането, че Developers носят колективна отговорност за създадения Increment.
- Осигурява естествен начин за задаване на въпроси, без новият колега да се чувства така, сякаш прекъсва някого.
Използвайте Definition of Done като компас
Според Scrum Guide дефиницията Definition of Done представлява официално описание на състоянието на даден Increment, когато той покрива изискваните стандарти за качество на продукта. За новодошлия това споразумение е далеч по-полезно от фирмения наръчник, тъй като определя какво всъщност означава завършена работа.
Прегледайте Definition of Done заедно. Обяснете защо съществува всеки отделен критерий. Ако автоматизираните регресионни тестове, прегледите на код или проверките за сигурност са задължителни, демонстрирайте как те работят на практика. Ясните стандарти спестяват на новите Developers необходимостта да гадаят колко тестване или документация очаква екипът.
Включете ги в събитията на Scrum незабавно
Събитията в Scrum могат да изглеждат непривични за човек, свикнал с традиционните срещи за отчет на статуса. Scrum Master трябва да обясни целта на всяко събитие, преди то да започне. По време на Daily Scrum се уверете, че новият колега разбира същността на събитието, а именно сесия за инспекция и планиране, в която Developers координират напредъка към Sprint Goal, а не отчет пред мениджър.
Насърчете новия Developer да участва в Sprint Retrospective още от първата седмица. Новият поглед забелязва спънки, които опитните членове на екипа приемат за даденост. Въпросът на нов колега защо даден билд отнема четиридесет минути или защо дадена стъпка при внедряване се прави ръчно често дава повод за ценни подобрения в екипа.
Инспектирайте и адаптирайте процеса по въвеждане
Тъй като един Scrum екип е самоуправляващ се, самите Developers управляват работния процес по въвеждане на нови хора. Централните отдели осигуряват оборудване, но екипът определя как колегата да се интегрира в ежедневната практика. Отнасяйте се към въвеждането като към развиващ се процес, а не като към статичен списък за отмятане.
В края на първия Sprint на новия служител отделете десет минути по време на Retrospective, за да обсъдите как е протекло въвеждането му. Попитайте какво го е забавило, какво го е объркало и какво е било полезно. Използвайте тези отзиви, за да усъвършенствате подхода си за следващия човек.