Как новичок входит в agile-команду: практики и трудности онбординга

Аннотация

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

Ключевые слова: онбординг agile-команды, адаптация, новички, Scrum, онбординг самоорганизующейся команды.

Введение

Разработка программного обеспечения — деятельность, требующая большого объема знаний и опирающаяся на людей с глубокими техническими знаниями, навыками, опытом и пониманием предметной области. Общепринятый подход к ее организации состоит в принятии мышления, процессов и практик гибкой разработки (agile). Agile применяется в проектах с совместно расположенными и распределенными командами, а также в крупномасштабной разработке систем [1, 2]. В этих условиях оптимальная гибкая разработка происходит в самоорганизующихся командах, которые автономны, кросс-функциональны и способны совершенствовать свою работу [3]. Новичкам в такой среде трудно стать полноценно интегрированными и продуктивными участниками команды. Эти трудности связаны с освоением знаний об организации, проекте, продукте, предметной области и технической среде; с пониманием и уверенным применением принятого в команде agile-подхода; а также с социализацией в самоорганизующейся команде [4].

Онбордингом называют вхождение нового сотрудника в организацию и его интеграцию. Организационная литература изучает это с 1970-х годов [5, 6]; много работ посвящено проектам с открытым исходным кодом [7, 8] и компаниям-разработчикам [9]. Однако онбординг в совместно расположенные agile-команды разработки программного обеспечения изучен мало: лишь одна статья указывает, что некоторые agile-практики способствуют онбордингу [4]. Практики назвали онбординг проблемой на международном научно-практическом семинаре 2019 года [10]. Их также волнует сохранение успешных agile-команд [11], а интеграция новичков является одним из факторов их долгосрочной устойчивости.

Мы предполагали, что онбординг в agile-проектных командах в некоторых отношениях похож на организационный онбординг вообще, но отличается от традиционного: новичкам необходимо понять agile-мышление, процесс и практики и эффективно встроиться в проекты, где нормой служит самоорганизующаяся командная работа. Поэтому мы стремились понять опыт онбординга новичков и их коллег в действующей совместно работающей agile-команде разработки программного обеспечения: как новичков интегрируют и как они осваивают уникальный agile-подход команды. Исследование отвечает на вопрос: как новички интегрируются в действующую agile-проектную команду и изучают ее agile-подход? Для ответа мы провели единичное кейс-исследование совместно работающей agile-команды в крупном IT-подразделении, которое регулярно принимает неопытных новичков. Мы обнаружили, что онбординг складывается из сочетания традиционных и специфических agile-практик, а новички и опытные участники сталкиваются с рядом трудностей.

Статья устроена следующим образом. Сначала мы рассматриваем относящуюся к теме литературу об онбординге и описываем модель Bauer [12], использованную для построения анализа. Затем излагаем метод кейс-исследования и результаты. В результаты входят описание agile-проектной команды, анализ как связанных с agile, так и традиционных практик онбординга, а также анализ ключевых проблем онбординга в этой команде. После обсуждения вклада работы следует заключение с направлениями будущих исследований.

Предпосылки

«Организационная социализация, или онбординг, представляет собой процесс перехода нового сотрудника от внешнего к внутреннему участнику организации. Онбординг помогает освоить знания, навыки и поведение, необходимые для успеха в новой организации» [5, с. 51].

Новичок может быть новым сотрудником организации либо человеком, который перешел из другого подразделения или команды. Во втором случае он уже принадлежит организации, но еще не стал своим в команде.

Литература об онбординге возникла в исследованиях организаций в 1970-х годах, когда Maanen и Schein [6] определили понятия организационной социализации, новичков, инсайдеров и аутсайдеров. Согласно их идее, организации имеют функциональные, иерархические границы и границы включенности, которые новички пересекают в ходе социализации, превращаясь из аутсайдеров в инсайдеров. Социализация включает шесть взаимосвязанных измерений [6, с. 37]; пояснения в скобках принадлежат авторам настоящей статьи:

коллективная или индивидуальная социализация, то есть вход группой или по одному;

формальная или неформальная, то есть обучение или освоение на опыте;

последовательные или случайные шаги, то есть заданная лестница достижений или ситуативные и неоднозначные требования;

фиксированный или переменный процесс, то есть заранее назначенные этапы или отсутствие расписания;

серийный или разъединенный процесс, то есть наличие или отсутствие ролевых моделей;

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

Sharma и Stol [9] изучили онбординг в коммерческих организациях по разработке ПО и по итогам обзора эмпирических работ нашли девять соответствующих исследований. Они разработали и проверили теоретическую модель связей между мероприятиями онбординга — ориентацией, обучением и поддержкой, — успешностью онбординга, соответствием организации, включающим удовлетворенность работой и качество отношений на рабочем месте, и намерением уволиться. Один из ключевых результатов состоял в том, что ориентация и поддержка тесно связаны с успешностью онбординга.

Britto, Cruzes, Smite и Sablis [13] исследовали три случая онбординга в глобально распределенной разработке унаследованных систем, используя рамку Bauer [12]. Самой сложной оказалась адаптация удаленных разработчиков в текущем agile-проекте: документации было мало, а понимание требовало постоянного диалога с наставниками.

Онбординг в совместно работающих agile-проектных командах рассматривают Buchan, MacDonell и Yang [4]. В исходном систематическом обзоре литературы они выявили в общей литературе о разработке программного обеспечения 11 целей, которые сочли применимыми и к agile-онбордингу; ниже они приведены в адаптации из [4, с. 3].

понять культуру компании и вписаться в нее;

понять нормы команды и соответствовать им;

понять ожидания других и обязанности своей роли;

понять обязанности, компетенции и полномочия коллег;

понимать, какую работу и когда выполнять;

научиться писать код и тесты в соответствии с ожиданиями команды;

понять командные стандарты качества;

понять и принять agile-мышление;

научиться пользоваться agile-артефактами и приемами команды;

понять кратко-, средне- и долгосрочную структуру работы, цели и последствия;

освоить знания и терминологию продукта, проекта и предметной области.

В этом исследовании описаны 24 метода онбординга [4]. Наряду со многими традиционными методами, например доступом к формальному обучению и интернет-сообществам, онбордингу способствовали следующие agile-практики: простая задача, парное программирование, ретроспективы и стендапы. Из-за малого числа участников — 11 интервью в разных организациях Новой Зеландии — исследователи признали, что их перечень методов онбординга, вероятно, не является исчерпывающим.

Рамка онбординга Bauer

Чтобы структурировать обсуждаемые в статье процессы онбординга, мы использовали шесть функций успешного онбординга из модели Bauer [5,12]. Эта модель является общей для любых сред и ситуаций онбординга. Мы выбрали ее, потому что она основана на эмпирических данных, широко цитируется во многих областях, а содержательной модели онбординга agile-команд разработки программного обеспечения пока нет. Шесть функций модели Bauer [12] таковы:

Подбор сотрудников. Процесс дает кандидату сведения и помогает сформировать реалистичные ожидания об организации и роли. Формально подбор может быть отдельным этапом, но эффективнее связан с онбордингом.

Ориентация — процесс, помогающий новичкам понять важные стороны своей работы и организации, включая ее культуру, ценности, цели, историю и структуру власти. Ориентация включает очные формальные программы, письменные руководства и онлайн-программы, передающие ключевую информацию новичкам. В нее входит и социализация: новичкам помогают почувствовать себя желанными, знакомя с коллегами и другими людьми в организации.

Инструменты и процессы поддержки. Письменный план онбординга новичка включает сроки, цели, обязанности, системы поддержки и способы получить помощь. Регулярные встречи с разными заинтересованными сторонами внутри организации служат механизмом поддержки новичков. Онлайн-инструменты также применяются для онбординга, но, как показали исследования, они несколько менее эффективны, чем регулярные очные вводные встречи.

Коучинг и поддержка. Наставники и ролевые модели помогают понять организацию и роль, а также ориентироваться в социальных и политических отношениях. Наставничество бывает внешним или внутренним и улучшает знание организации.

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

Инструменты обратной связи. Обратная связь и рекомендации сообщают новичку о прогрессе, сильных и слабых сторонах. Они бывают формальными, например оценка эффективности, и неформальными, когда человек сам спрашивает коллег и руководителей об ожиданиях и оценке своей работы.

Рамка Bauer [12] также описывает изменения самоэффективности, ясности роли, социальной интеграции и знания культуры. Исследование ограничено шестью функциями, поскольку оценка изменений требует продольного дизайна.

Метод

Организация обратилась к исследовательской группе за помощью в определении того, как помочь новым участникам при первом вхождении в agile-команду перейти от индивидуального взгляда на работу к командному. Для ответа на исследовательский вопрос выбрали исследование одного случая; единицей анализа стала совместно расположенная agile-команда разработчиков программного обеспечения [14]. Исследование получило этическое одобрение Университета Центрального Ланкашира.

Данные собирали прежде всего с помощью интервью. Всем участникам проектной команды предложили интервью и предоставили информационный лист об исследовании. Были опрошены более половины команды. Среди респондентов были разные новички — недавно нанятые и проработавшие в команде до года — и опытные участники, работавшие год или более. В эту вторую группу входил руководитель команды и Scrum-мастер, обладавший самым длительным опытом работы в проектной команде.

Первые встречи и наблюдения прошли в октябре 2018 года, после чего в ноябре и декабре 2018 года проводились интервью и наблюдения на рабочем месте. Интервью проводили два исследователя. Они были полуструктурированными и следовали сценарию, но интервьюеры старались оставаться открытыми новым идеям и при необходимости или соответствии теме задавали уточняющие вопросы. Все интервью расшифровали и проанализировали в NVIVO. Профиль респондентов представлен в таблице 1.

Наблюдения за ежедневной работой и отдельными встречами помогли познакомиться с участниками, увидеть практики и культуру и выявить проблемы. Полевые заметки делали во время и сразу после наблюдений.

Первый автор первоначально кодировал расшифровки интервью по темам подходов, практик и трудностей онбординга, следуя рекомендациям Saldana [15]. Данные также анализировали, чтобы понять историю команды, рабочие практики — социальные и agile, — а также культуру организации и команды. После этого первый и второй авторы сопоставили темы подходов и практик онбординга с шестью функциями модели Bauer [12], описанными в разделе 2.1. Затем второй автор дополнительно проанализировал темы, разделив связанные с agile и традиционные подходы. Все авторы проверили итоговый анализ, а черновик статьи до подачи передали участникам исследования для проверки и обсуждения.

Результаты

История и характер agile-команды

Agile-команда разработки программного обеспечения была подразделением IT-службы британского университета. За шесть лет она выросла с двух человек на момент создания до 15 во время исследования. В период кейс-исследования подразделение действовало как единая команда и следовало целостному командному подходу независимо от численности штата. Оно разрабатывало мобильные приложения для университета и исследовало идеи и технологии для будущих инноваций. Команда работала над новыми проектами и поддерживала уже развернутые приложения и системы.

Состав и размер команды менялись в зависимости от нагрузки: в нее входили сотрудники с полной и неполной занятостью, опытные и неопытные участники, студенты и ученики. На момент исследования в команде было 6 сотрудников с полной занятостью, 3 ученика и 6 сотрудников с неполной занятостью. Трое из шести частично занятых сотрудников занимали в университете другие должности с полной занятостью, а в этой команде работали неполное время. Руководитель работал полный день и совмещал роли Scrum-мастера и линейного менеджера. Ученики большую часть недель работали полный день, но проходили блочные курсы в своем учебном заведении — обычно одну неделю в месяц. Студенты обычно учились в университете и параллельно работали в проектной команде неполное время: как правило, два или три раза в неделю в первой либо второй половине дня. Большинству участников было от 20 до 29 лет; предыдущего опыта работы у них было мало или не было совсем. Исключение составляли Scrum-мастер, владелец продукта и специалист по коммуникации: им было 35–55 лет, и у них имелся разнообразный предыдущий опыт. Многие сотрудники с полной занятостью начинали как студенты с неполной занятостью, а после выпуска получали должности с полной занятостью. Текучесть была регулярной: студенты и ученики уходили после окончания учебы, а сотрудников с полной занятостью нередко привлекали вакансии за пределами высшего образования.

Команда развивала применение agile-методов постепенно. В первые годы оно не было систематическим: «Когда я только начал работать, команда была довольно маленькой, и мы не придерживались строго никакой методологии, все было почти импровизацией. Мы следовали идее спринтов и некоторым элементам agile, но не всей этой системе целиком. Лишь когда команда выросла, мы расширили использование agile» [SD1].

Команда работала в открытом офисе с соседней переговорной. Разработчики пользовались незакрепленными рабочими местами и часто меняли расстановку столов под свои нужды. Команда применяла Scrum и двухнедельные спринты; последняя пятница была днем вне спринта для завершения другой работы. Проводились ежедневные стендапы, планирование и уточнение спринта, обзоры, ретроспективы и демонстрации продукта; использовалась Scrum-доска. Руководитель еженедельно проводил индивидуальные встречи с сотрудниками, если они этого хотели. Команда работала хорошо. Общее настроение выразил сотрудник, проработавший в ней год: «Лично мне очень нравится. Здесь спокойно. То, как мы работаем, довольно динамично. Это просто хорошее место для работы» [SD1].

Практики онбординга

Далее практики организованы по рамке Bauer [12]. Все имена заменены псевдонимами.

Подбор сотрудников

Процесс найма был формальным и стандартизированным для всех новых сотрудников организации. Организация предписывала этот процесс, включавший должностную инструкцию, требования к кандидату и объявление о вакансии. Процесс различался для новичков с полной занятостью — обычно постоянных сотрудников — и с неполной занятостью — обычно временно работающих студентов и учеников. Формальный найм сотрудников с полной занятостью требовал подготовленной и сбалансированной комиссии интервьюеров: заявки оценивали по балльной системе, а на собеседованиях использовали стандартные вопросы. От всех кандидатов ожидали свидетельств творческого подхода, энтузиазма и трудолюбия. От кандидатов на полную занятость требовали опыта и технических знаний; от студентов и учеников этого не ожидали. После найма участники с полной занятостью проходили общеорганизационный вводный курс. И полностью, и частично занятых участников лично приветствовал руководитель команды; каждому назначали наставника. Новичкам также помогал Scrum-коуч.

Долгосрочный найм. Подразделение применяло долгосрочный подход: нанимало временных студентов и учеников, которые работали в команде неполный день параллельно с учебой. В некоторых случаях после получения степени они становились постоянными участниками проекта с полной занятостью. Благодаря этому команда получала постоянных сотрудников, которым требовался минимальный онбординг: они уже подходили команде и понимали организацию, цели подразделения, продукты, технологии, заинтересованные стороны и agile-подход команды.

Онбординг во время найма. Пробелы в знаниях новичка начинали выявлять уже на собеседованиях. «Во время собеседований при найме я, среди прочего, стараюсь понять, насколько человек знаком с agile, чтобы оценить величину пробела…» [TL].

Ориентация

Пакет «Новый сотрудник». Этот документ описывал то, что должны знать новые сотрудники, и выдавался всем новичкам. Один участник команды описал его так: «Здесь все, что вам нужно знать о команде» [PM]. При этом отсутствие подробностей об agile-подходе команды признавали пробелом: «…формальной части нет. А должна быть. Признаю: должна быть» [PM].

Пакет «Как работает наша команда» представлял участников, объяснял, где зарегистрироваться, как войти в Team Foundation Server и как устроена работа.

Пакет «Как наша команда работает с клиентом». Этот документ отправляют клиентам до начала работы с командой. В нем объясняется, как команда пишет пользовательские истории, какого общения она ожидает от клиента и как тестирует и принимает продукты. Документ также дают новичкам как обзор командных практик.

Пакет по agile. Руководитель отправлял новым участникам руководство с принципами Scrum и обсуждал их практику [TL].

Социализация. Проектная команда старалась общаться вне рабочих задач и узнавать друг друга, поскольку это помогало новичкам доверять команде, увереннее взаимодействовать и общаться. «Например, на встрече команды сотрудников с полной занятостью мы поощряем такую практику: говорим: „Что вы можете представить команде — что-то, что считаете ценным, или что-то о себе?“ Это помогает разрушать барьеры, тема может быть любой. Недавно один участник рассказывал об электронном сборе данных, а другой — о своей страсти к кубикам Рубика» [TL]. На социальные мероприятия приглашали всю команду: «Разные участники часто вместе ходят обедать и тому подобное. Иногда вечером мы идем выпить в город или устраиваем собственное командное Рождество…» [SD3].

Инструменты и процессы поддержки

Информационный радиатор. Проектная команда использовала физическую и виртуальную версии Scrum/Kanban-доски, хотя обычно предпочитала физическую. Опытные участники считали физическую доску полезной и для новичков: «Иногда команда взаимодействует с цифровым инструментом не так активно, как с физическим; физический кажется естественнее… Думаю, новичкам он тоже помогает, потому что можно мгновенно посмотреть и увидеть, где что находится» [SD1]. Один новичок считал доску полезной разработчикам, но не себе как архитектору: «Сейчас на доске одни задачи разработки. А моя работа поддерживает все это, и иногда мне хочется написать историю вроде: „Как архитектор, я хочу…“» [NC3].

Средства связи. Teams, Slack, TFS и почта отчасти помогали работникам на неполной ставке, но после отсутствия оставалось много пропущенного. Поэтому они также обходили комнату и разговаривали лично.

Коучинг и поддержка

Наставничество. Большинство новичков считало наставничество важной частью онбординга. Руководителя команды часто упоминали как наставника, но он признавал и наставническую роль опытных участников: «С моей точки зрения, наставничество помогает и интеграции в подразделение, и освоению технологического стека, и вхождению в agile-подход; причем почти незаметно. Сообщения исходят от участников команды, а не от меня, и я надеюсь, что благодаря этому новичок усваивает их лучше» [TL].

Ролевое моделирование. Более опытные участники отмечали, что демонстрация желательного поведения полезна и новичку, и постоянным сотрудникам: «Я стараюсь снять стигму… и показать пример, тогда остальная команда понимает, что нормально сказать: „Я не знаю, как это сделать. Я не знаю, что это такое, или мне нужна помощь“» [SD3]. Другой пример — постоянное самостоятельное изучение опытными сотрудниками новых технологий: «Сейчас я очень много учусь вне работы, особенно из-за всего нового, что мы делаем» [PM].

Церемонии. В рамках погружения церемонии объясняли новичкам при первом посещении. Например, непосредственно перед стендапом новичку рассказывали о процессе, чтобы он знал, что от него ожидают: «Они очень хорошо объясняли все, что делали: почему утром проходят стендапы, что за встречи бывают до и после спринтов. Они объясняли это до начала» [NC4].

Поощрение командной работы. Опытные участники поощряли обмен знаниями и взаимопомощь: «Все очень дружелюбны, спрашивают, не нужно ли чего-нибудь, и тебя действительно побуждают разговаривать с людьми» [NC3]. Уровень доверия между новичками и опытными сотрудниками воспринимался как высокий: «Доверия много… особенно к студентам-разработчикам: им доверяют работу… Когда они входят в команду, подходят ей и работают как часть команды, мы доверяем им задачи». «Все очень отзывчивые и дружелюбные… Чувствуешь настоящую включенность; нет разделения на разработчиков и остальных» [NC3].

Поощрение обучения. Один новичок ценил поддержку при попытках делать новое: «Руководитель очень хорошо побуждает браться за более сложные вещи… Он предложит: „Почему бы Салли это не сделать? Почему бы тебе, Салли, не сделать это?“ Сначала я кричу от растерянности и паники: „Ох!“ А потом… В хорошем смысле сотрудников полезно подталкивать, правда? Хорошо учиться новому. Да, это хорошо. Страшно, но хорошо. Хорошо страшно» [NC3].

Эмпатия. Поскольку некоторые опытные участники прежде сами были в команде студентами, они помнили свой опыт и лучше понимали проблемы новичков: «Мне хочется думать, что мы относимся к студентам как к равным, особенно с учетом моего собственного опыта студента-разработчика. У нас нет „синдрома младшего разработчика“, от которого страдают некоторые команды, когда новичкам дают второстепенные задачи… Иногда студент с неполной занятостью приходит лишь на три часа, тогда мы можем предложить ему определенные задачи, чтобы лучше использовать это время. Но это делается скорее в его интересах: я знаю, как неприятно погрузиться в работу, а затем все бросить и идти на лекции» [SD1].

Парное программирование. Руководитель команды признавал его пользу для поддержки новичков: «Когда они только приходят, я ставлю их в пару с сотрудником с полной занятостью… с одним и тем же сотрудником с полной занятостью примерно на две-три недели, а затем отпускаю работать самостоятельно в определенной области» [TL]. Пары использовали и для освоения новых технологий: «Если нам нужны навыки по конкретной технологии, мы объединяемся в пары; так же поступаем, если хотим кого-то чему-то научить» [SD1].

Переосмысление себя. Руководитель поощрял новичков заново осмыслить себя в новой роли: «Когда я нанимал студентов и они переходили на работу с полной занятостью, я старался объяснить им: нужно представить себя заново в новой роли. Например, одна сотрудница была администратором, а теперь формально занимает новую должность, хотя фактическая работа отличается от названия. Ей пришлось переосмыслить себя в новых ролях, потому что прежние обязанности она больше не выполняет» [TL].

Ежедневные стендапы. Иногда их проводили дважды в день ради сотрудников с неполной занятостью. Разработчик с годовым стажем в команде считал стендапы полезными для понимания состояния проекта и получения помощи: «Если вы на чем-то застряли, не знаете, как что-то сделать, или просто потерялись, это хорошее место, чтобы сказать об этом. Обычно кто-нибудь ответит: „О, я тебе помогу“» [SD3]. Одна новичок отметила, что пока не понимает язык команды: «Если бы я понимала их язык, то, вероятно, понимала бы больше» [NC3]. Опытные участники тоже считали, что стендапы помогают новичкам: «Большая часть общения происходит на утреннем стендапе… Иногда днем мы проводим еще один, если кто-то только пришел, чтобы ввести его в курс дела. Поэтому стендапов может быть два» [SD2].

Совместное размещение. Работа в одном месте облегчала просьбы о помощи и обмен знаниями: «…посмотреть на этот код или что-то подобное, но можно просто спросить человека рядом… Если вы чего-то не знаете, вполне вероятно, сосед это знает» [SD3]. Она также позволяла слышать разговоры других, что помогало новичкам: «Это действительно дает общее представление о том, что делают другие, пусть даже просто потому, что слышишь их разговоры между собой» [NC1].

Сигналы. Для обозначения доступности и проблем команда выработала способы общения, позволявшие понять, кого можно отвлечь, кто хочет сосредоточиться и возникла ли важная проблема, требующая внимания команды. «Иногда участники надевают наушники, когда по-настоящему сосредоточены, и тогда понятно, что к ним лучше не подходить; иногда это просто интуиция, потому что мы знаем друг друга… Думаю, при этом все мы доступны и для студентов с неполной занятостью». «Если в проекте возникает конкретное препятствие, у нас есть небольшие красные карточки для Kanban-доски… Тогда все знают о препятствии, и если у кого-то есть решение… мы можем обсудить его и попытаться устранить проблему» [SD1].

Обучение

Формальное обучение. Бюджет не позволял обучать сотрудников с полной занятостью, а нагрузка мешала посещать agile-конференции и внешние события. Формальных курсов для команды не упоминалось, хотя студенты и ученики учились по своим программам.

Погружение, или обучение через опыт. Новички начинали работать с первого дня, и значительная часть обучения и социализации происходила через продуктивное участие в команде. Два опытных участника описали процесс сходным образом: «Обычно мы стараемся сразу дать им настоящую работу, чтобы они буквально учились в процессе. Мы проводим вводную беседу о том, чего от них ожидают в команде, как получить поддержку и тому подобном, а затем отпускаем и позволяем влиться» [PM]. Восприятие новичка это подтверждало: «Меня во многом сразу бросили на глубину: „Вот несколько встреч. Да, приступаем“, — и я изо дня в день училась вместе с командой тому, как они работают». «В основном это практика, очень практический подход, с объяснениями при необходимости… Перед встречей, где мы голосовали карточками с животными, мне объяснили, что мы будем делать… Поэтому, оказавшись там, я не удивилась происходящему» [NC3].

Самостоятельное обучение. Новичков, незнакомых с agile-методами, просили почитать о них до начала работы и давали ссылки на интернет-ресурсы: «На собеседованиях мы обычно спрашиваем об опыте agile. Если человек отвечает, что опыта нет, мы говорим: „Ничего страшного, но рекомендуем изучить тему“» [PM]. Существующая команда ожидала от новичков самостоятельного обучения и прямо просила об этом: «Когда мы его взяли, то сказали: „Если хочешь продолжать работать с командой, нужно учиться и вне работы“» [TL]. Некоторые новички учились по собственной инициативе: «Я проделала большую предварительную работу… много читала об Alexa в интернете… прошла пару курсов на Udemy… Дома изучаю Python и Excel, прохожу курс по Excel. И только что записалась на курс… по пользовательским историям» [NC4].

Инструменты обратной связи

Личные встречи. Сотрудники с полной занятостью регулярно, часто еженедельно, встречались с руководителем, получали советы по техническим вопросам и осмысляли свою практику.

Немедленная обратная связь. Совместное размещение позволяло корректно сообщать о проблемах сразу после проверки работы; новичок отметил, что замечания делали доброжелательно [NC3].

Встречи. Их использовали для передачи знаний и обсуждения вопросов университета, подразделения и команды. «Там каждый может высказаться. Это работает довольно хорошо. Обстановка приятная и спокойная. Разрушаются барьеры, люди лучше понимают друг друга, а в команде появляются новые знания» [TL].

Проверка кода. Ее использовали для обратной связи: «Раз в неделю мы всей группой проверяем код, смотрим, над чем работали, и учимся друг у друга. Эта встреча в основном предназначена для программистов и учеников» [SD2]. Новичок, еще не представлявший код на такой встрече, считал проверки полезными: «Сейчас я еще не все понимаю. Но это полезно, потому что смотреть на код бывает довольно страшно, а так он становится немного знакомее» [NC1].

Тестирование. Модульные тесты воспринимали как механизм обратной связи, а элементы разработки через тестирование применяли при парном программировании, чтобы помочь новичкам: «Мы стараемся работать в парах, особенно со студентами… Когда Мартин начал, мы добавили немного разработки через тестирование, чтобы познакомить его с тем, над чем и как мы работаем» [SD2]. Новичок объяснила: «Это действительно хорошо: появляется дополнительное тестирование, и я могу увидеть, делает ли программа то, чего я ожидала, и работает ли она» [NC3].

Ретроспективы. Их использовали для корректировки и улучшения agile-процесса; опытные участники считали ретроспективы ценным инструментом обратной связи. «На ретроспективах мы даем обратную связь о том, как справились, что понравилось и что можно улучшить. Это командная обратная связь» [SD2].

Обзор спринта. Обратная связь на нем касалась технических вопросов: «Обычно обратную связь откладывают до обзора спринта. Перед ретроспективой мы проводим обзор и демонстрируем сборку. Надеемся, что она работает и можно отпраздновать; иначе прозвучит критика реализации, проектных решений и тому подобного» [SD1].

Уточнение спринта. На этих сессиях команда обсуждала и уточняла пользовательские истории до планирования: «Перед планированием мы проводим уточнение спринта, разбираем каждый рабочий элемент и задаем много вопросов» [SD3].

Небольшие задачи. По практическим причинам их давали новичкам с неполной занятостью: «Мы даем студентам задачи поменьше, потому что времени недостаточно… Например, небольшую пользовательскую историю — получить следующее событие расписания через API — вполне можно поручить студенту» [SD2]. Точкой входа для новичков часто служили мелкие исправления: «У меня есть список ошибок, которые нужно устранить, потому что обычно мы не хотим вытаскивать сотрудников с полной занятостью из спринта» [PM].

Распределение задач сочетало самостоятельный выбор и назначение руководителем; при назначении учитывали компетенции. «Для крупных задач иногда [руководитель команды] назначает исполнителя… Но обычно мы просто берем следующую задачу с доски. Если на доске нет задач, приходится просить [администратора] или [руководителя команды] добавить задачу либо связаться с владельцем продукта…» [SD2].

Демонстрация продукта. Разработчики регулярно показывали результат владельцам продукта и получали обратную связь от бизнеса [SD1].

Результаты анализа сведены в таблицу 2.

Трудности онбординга для новичков и команды

Анализ выявил трудности с полномочиями, сменой мышления, включением неполной занятости, передачей принципов agile и изменением состава команды.

Расширение полномочий. Это было постоянной проблемой команды. Руководитель отмечал трудность онбординга молодых новичков, никогда не работавших в самоорганизующейся команде с широкими полномочиями. По его мнению, им требовалась помощь: «Когда они только из университета и пришли из академической среды, которая не очень хорошо учит командной работе и не учит самостоятельности… иногда в разговоре они обращаются ко мне как к носителю власти, а я отвечаю: нет, иди и сделай сам. Поэтому я старался создавать ситуации, где они проводят собственные встречи и сами ими управляют. Я могу что-то начать, затем выйти и сказать: вот, вам больше не нужно со мной разговаривать, разберитесь сами» [TL]. Однако под давлением иногда возникал командно-административный подход: «Тогда я выдергиваю кого-нибудь из спринта и говорю: „Это нужно исправить“, либо: „Это будет исправлено в конце спринта“ — в зависимости от срочности» [PM].

Изменение мышления. Участники проектной команды склонны были полагаться на старших сотрудников в поддержании agile-процессов: «Если меня или руководителя нет в офисе, стендапы не проходят. Поэтому мы настойчиво объясняем: „Это ваша встреча, она нужна вам, чтобы помогать друг другу“» [PM]. Новичкам постоянно старались передавать полномочия: «Мы стараемся оставлять им выбор того, что они хотят делать» [SD1]. С самостоятельностью связана и проблема перфекционизма. Новичкам было трудно принять экспериментальный образ мышления: «Поскольку они совсем новые, они еще не понимают, как подступаться к проблемам. Им нужно сказать: „Просто начни, начни работу; неважно, если потом все выбросишь“… Это вопрос мышления: они пытаются с первого раза найти идеальное решение» [TL].

Учет неполной занятости. Повторяющейся темой были связь с новичками, работающими неполный день, и обмен знаниями с ними. Проблему видели и опытные сотрудники, и сами частично занятые новички: «Для сотрудников с неполной занятостью или тех, кто не может присутствовать, нужно искать способы преодолеть разрыв в общении. Почти на каждой ретроспективе все говорили, что коммуникацию нужно улучшить. Получается, вы это сказали, но на деле ничего не делаете» [TL]. Частично занятый новичок рассказал, как трудно после отсутствия выяснить, что произошло в проекте: «Они просто поговорят между собой и что-нибудь решат, а потом нигде не найдешь записи — даже в TFS» [NC3].

Передача agile-принципов. Опытные участники предъявляли к новичкам высокие требования и с трудом передавали принципы agile: «Сейчас сформировалась очень сильная и высоко мотивированная команда, поэтому ожидается, что новый человек впишется в этот дух. Это становится препятствием при наборе новых студентов: планка очень высока» [TL]. Главной проблемой онбординга руководитель считал интеграцию сравнительно молодых и неопытных новичков с неполной занятостью: «Им нужно просто погрузиться в это, а при неполной занятости трудно: до 15 часов в неделю, параллельно другая учеба, молодость, социальная жизнь и все остальное. Найти в голове место для всего этого сложно. Нужно суметь передать принципы и культуру — именно на этом я хочу сосредоточиться» [TL].

Изменение состава команды. Со временем в команде стало больше опытных участников и меньше новичков. Такой баланс улучшил способность к непрерывному совершенствованию: «Мы прошли много итераций в организации работы и, кажется, достигли удачного состояния, когда дела делаются… Поскольку участников с полной занятостью стало больше, мы увидели пользу в проведении таких сессий уточнения спринта» [SD1].

Обсуждение

Мы изучили онбординг новичков в совместно работающей agile-команде разработки программного обеспечения, поскольку тема важна практикам, стремящимся поддерживать команды в долгосрочной перспективе. Исследование отвечало на вопрос, как новички интегрируются в действующие команды и осваивают agile-подход. Анализ единичного кейса с помощью модели онбординга Bauer [12] показал, что онбординг сочетает традиционные и связанные с agile методы (таблица 2). К agile-методам относятся самостоятельное изучение основ, информационные радиаторы, объяснение церемоний до первого участия, парное программирование, погружение для обучения через опыт, проверки кода, тестирование, ретроспективы, обзоры и уточнение спринта, а также гибкое распределение задач. В кейсе выявлены и проблемы: помочь новичкам действовать самостоятельно в духе agile и экспериментально подходить к работе; проявлять гибкость ради включения частично занятых сотрудников; передавать agile-принципы; поддерживать такое соотношение опытных сотрудников и новичков, которое способствует непрерывному совершенствованию.

Наши результаты согласуются с [4,9,13], но основаны на глубоком контекстном исследовании практик онбординга в agile-команде и дают более подробную картину. Мы выявили дополнительные agile-практики, поддерживающие онбординг, и показали широкое использование коучинга и обратной связи. Кроме того, работа обнаружила конкретные трудности для новичков и команд. В предыдущих исследованиях не отмечалась проблема расширения полномочий, точнее — того, как побудить новичков действовать самостоятельно.

Практический вклад исследования состоит в рекомендациях agile-проектным командам, которые хотят лучше понимать роль конкретных agile-практик в онбординге и выбирать традиционные методы, дополняющие их до комплексной поддержки. Мы предлагаем три рекомендации: 1) включать связанные с agile практики из таблицы 2, поддерживающие онбординг; 2) применять долгосрочный найм, например привлекать студентов на практику и учеников, а затем нанимать из этой группы для лучшего соответствия сотрудников команде; 3) при онбординге уделять внимание обучению самостоятельности, ее объяснению и демонстрации на личном примере.

Теоретически работа подтверждает традиционные знания об онбординге, применяет рамку Bauer и частично расширяет ее на совместно работающие agile-команды разработчиков.

Исследование имеет ограничения. Выводы основаны на единственном кейсе и небольшом числе интервью, поэтому их переносимость на другие условия ограничена. Авторы опросили не всю команду, и потому часть взглядов отсутствует. Тем не менее данные получены от разных людей: совсем новых сотрудников, сотрудников с годом опыта и давно работающих участников, что обеспечило некоторую триангуляцию источников данных [16]. Авторы также провели проверку участниками: передали проектной команде отчет с кратким изложением результатов и запросили подтверждение и обратную связь.

Заключение

В статье мы утверждали, что онбординг новичков в agile-проектах разработки программного обеспечения с совместно расположенными командами может отличаться от онбординга вообще. Мы обнаружили, что agile-команды используют традиционные практики, а определенные agile-практики, осваиваемые через погружение, также поддерживают онбординг. Кроме того, выявлены трудности вхождения в agile-проектную команду.

Работа вносит три вклада: 1) подробно описывает онбординг в действующей совместно работающей agile-команде, определяет поддерживающие его agile- и другие практики и возникающие трудности; 2) показывает применимость модели онбординга Bauer [12] в контексте программной инженерии; 3) дает практикам рекомендации относительно agile-практик, поддерживающих онбординг.

В будущих работах мы рекомендуем разработать комплексную модель онбординга, полностью описывающую его факторы в agile. Такие исследования должны охватывать все agile-среды: совместно работающие, распределенные и крупномасштабные.

Благодарности

Авторы благодарят участников и Agile Business Consortium (ABC Ltd.) за совместное финансирование Agile Research Network.

Сведения об авторах

Viktoria Stray, электронная почта: stray@ifi.uio.no.

Rashina Hoda, электронная почта: Rashina.Hoda@monash.edu.

Maria Paasivaara, электронная почта: mpaa@itu.dk.

Philippe Kruchten, электронная почта: pbk@ece.ubc.ca.

Peggy Gregory, электронная почта: ajgregory@uclan.ac.uk.

Diane E. Strode, электронная почта: diane.strode@whitireia.ac.nz.

Raid AlQaisi, электронная почта: r.alqaisi@gmail.com.

Helen Sharp, электронная почта: helen.sharp@open.ac.uk.

Leonor Barroca, электронная почта: leonor.barroca@open.ac.uk.

Литература