Кто такие “девелоперы” в парадигме Scrum? Почему всех участников скрам-команды называют “девелоперами”? В чем разница между девелоперами скрам-фреймворка и остальными?
Слава Москаленко, первый тренер от scrum.org в Украине, соучредитель Agile.Live, практик с мировым опытом внедрения Scrum (Сингапур, США, Великобритания, Австралия и др.) объясняет разницу.
ОДИН ТЕРМИН, РАЗНЫЕ ЗНАЧЕНИЯ
Одна из проблем, с которой сталкиваются команды, переходящие на скрам (или считающие, что его практикуют), заключается в непонимании или ином трактовании значения, которое вкладывает Scrum в понятие “девелопер”.
Если приходить в скрам с сегментированным, фрагментарным или даже индивидуалистским пониманием понятия “разработчик”, то вряд команда будет целостной и по-настоящему автономной, самоуправляемой, гибкой (agile) и скоростной (последнее крайне важно для Джеффа Сазерленда, который уверяет, что благодаря скрам-подходу мы сможем выполнять “вдвое больше за меньшее время”).
Определения терминов
Вообще девелоперами называют многих – строителей, специалистов по развитию бизнеса или организаций. В нашем контексте речь идет об отрасли информационных технологий и отрасли, которые интегрируют их в свои бизнес-процессы.
Сам термин “девелопер” приобрел популярность в Украине довольно давно. Еще в мои студенческие времена бытовал термин Software Developer (разработчик программного обеспечения), мог касаться различных языков программирования, в то время как Software Engineer предусматривал более узкую специализацию, так же как:
- Net-Developer;
- Java-Developer;
- Full Stack-Developer и др.
В широком или узком смысле – речь идет о “разработчиков”.
Специфика SCRUM
В Scrum “девелоперами” считают всех причастных к разработке продукта и повышению его ценности для конечных потребителей и стейкхолдеров.
Спецификой скрам-команды также является кросфункциональность – каждый ее участник обладает набором навыков разработки и готов подставить плечо коллеге – заменить его, взять часть работы на себя или наоборот – делегировать где нужно. Все это возможно только тогда, когда даже при высокой концентрации на цели продукта (product goal) команда умеет работать не в одном узком направлении, а имеет спектр компетенций и умеет адаптироваться под требования бизнеса по новому продукту, а в случае необходимости способна быстро получить новые знания.
Сложности
Практика показывает, что автоматизация бизнес-процесса или же разработки может проходить сквозь десятки различных систем, созданных на разных языках программирования. В таком случае, представьте на минутку, насколько ценной будет команда, если среди ее участников будут знатоки различных языков, а не одного?
Когда речь идет о, скажем, модернизации, то интеграция новых технологий невозможна без понимания старых, что уже свидетельствует о высоком уровне сложности (complexity) таких задач.
Вот почему высоко ценятся скрам-команды, имеющие высокий уровень экспертности не в одной, а в нескольких сферах, которые непосредственно касаются разработки продукта.
Учитывая постоянное появление новых технологий и довольно большого перечня старых, в Scrum принципиально ценят такую характеристику специалиста, как желание и открытость учиться, профессионально развиваться, расти, быстро приобретать новые знания, в целом выяснять нюансы, интересоваться сутью продукта, искать лучшие способы его реализации, быть проактивным.
ПРОБЛЕМЫ
Неизвестно почему, но существует определенная сакрализация “узкой специализации”. Конечно, лучшим можно быть в чем-то одном. Но разве это означает остановку профессионального развития? Ведь “интеграция” априори предполагает взаимодействия различных систем.
Такая сакрализация вызывает ненужную зависимость от специалистов узкой специализации. Это может касаться и устаревших систем (не во всех командах есть специалисты, способные менять старые системы, чтобы интегрировать в нее новые).
Кроме искусственной сакрализации узкой квалификации, довольно распространенная проблема непонимания роли каждого участника Scrum-команды. Подробно о командах в парадигме Scrum см. в других моих публикациях на Agile.Live.
РЕШЕНИЕ
Продукт необязательно является новой технологией. В то же время новая технология не будет ценной, если не будет удачно интегрирована в существующий продукт. Другими словами, технология – не панацея.
Я подчеркиваю, что:
- Скрам нужно создавать вокруг бизнес-процесса, а не технологии (которая может устареть!);
- Стоит продвигаться в сторону продукта и повышения его ценности (а не “технологии”).
Компонентные и кроскомпотентные команды
Чтобы лучше понять понятие “разработчики” в Scrum, подумаем о компонентных и кроскомпонентных командах.
Например, в разработке участвуют инженеры программного обеспечения. Их немного, они все время заняты и перегружены, а потому создают bottle-neck – “закупоривают”, замедляют процесс на входе или выходе.
Рассмотрим два примера.
Кейс 1 – Решение в пользу кроскомпонентности
Компания поставила задачу разработать две новые технологии и модифицировать шесть уже существующих. Проект был чрезвычайно сложен.
Вместе с коллегами мы решили привлечь двадцать разных специалистов, в определенной степени перегружали скрам-команду. Мы чуть сузили ее до пятнадцати человек вместе с нами.
Конечно, наша команда работала медленнее, чем обычно, но это было гораздо лучше, чем если бы мы соблазнились на “недоскрам”.
Иначе, в случае недоскрама, нам пришлось бы запустить несколько отдельных векторов разработки и потратить целую вечность на согласование всех взаимосвязей и интеграции между ними.
Дело в том, что в реальном бизнесе немало процессов проходят через все его уровни, все команды, все технологии (и старые, и новые). Здесь и возникает соблазн создавать компонентные команды.
Напротив, кроскомпонентная команда отвечает за реализацию не одной узконаправленного системы, а всего бизнес-процесса.
Соответственно, в кроскомпонентной команде должны быть представители и старой, и новой (и какой угодно) системы, чтобы реализовывать целостный бизнес-процесс, охватывающий все уровни продукта. В таком случае, эффективно создавать инкремент можно в пределах одной (кроскомпонентной) команды.
Компонентные также разрабатывают инкремент, но только в пределах своей узкой специализации, не затрагивая весь бизнес-процесс. Возникает сложный дискурс об изменениях, которые необходимо внести каждой команде, выяснении взаимозависимостей (как от инкремента компонентной команды зависит работа других команд, работающих над разработкой), существенное увеличение продолжительности реализации сложного продукта.
Кроскомпонентная не имеет такой проблемы, потому что все изменения и взаимозависимости вносятся одновременно в пределах одной команды и одного спринта. За один спринт вносятся незначительные изменения в две или более систем, а инкремент касается всего бизнес-процесса и сразу учитывает специфику других систем.
Кейс 2 – Инвестиционный банк
Расскажу еще один кейс с моего профессионального опыта. По заказу одного из мировых инвестиционных банков наша команда должна была создать новую технологию на базе уже существующей.
Наш опыт и квалификация покрывали 80% требований. Одна из главных проблем заключалась в устаревших технологиях (Сobol, Microsoft.Net т.п.), и большая проблема заключалась в том, что мы не имели опыта работы со старыми технологиями.
Так мы попали в зависимость от редких экспертов, график которых был перегружен и расписан на несколько месяцев вперед! Однако мы не могли сидеть, сложа ручки.
Не сговариваясь, мы, как один, решили самостоятельно изучить эти технологии, еще и убедили менеджмент в том, чтобы получить мандат на такой “ход конем”.
С большим упорством мы реализовали весь бизнес-процесс, независимо от графика работы редких специалистов.
У нас было 4 разработчики, один тестировщик (который за несколько месяцев научился хорошо программировать), мы создали dream-team! “Дайте нам любую задачу, мы решим ее – самостоятельно!” – вот было наш лозунг. Это был настоящий IТ-спецназ, элитный дивизион.
Результат был феноменальным. За короткое время (полтора месяца) мы изучили все, что нам было нужно и реализовали проект раньше предыдущих прогнозов руководства. (Обычно на такие задачи шло 4-5 месяцев). Топ-менеджеры были в восторге. Как только мы завершили этот проект, нас пригласили в другие – на таких условиях, отказаться от которых было невозможно.
ВЫВОДЫ
Что значит иметь команду “девелоперов” в Scrum? Поделюсь своими соображениями:
- Лучше иметь пятерых настоящих девелоперов (без сужения в сторону “только” – только JavaScript, только FrontEnd, только BackEnd и т.д.), которые образуют целостную кросфункциональную и автономную команду.
- Стоит убрать титулы (“старших”, “высших”, гениальных и т.п.) из команды разработчиков.
- Классный девелопер первым приоритетом ставит задачу бизнеса (а не амбиции кодировать любимым языком программирования – и только им).
- Крутой девелопер интересуется развитием IT-сферы – изучает новые подходы, новые технологии, расширяет свою компетентность.
- Умелый девелопер углубляется в задачи бизнеса, ставит вопрос и коммуницирует (даже если он интроверт!) c представителем бизнеса или специалистом.
- Настоящий девелопер способен попросить о помощи, когда в ней нуждается. Это не ущемляет величие его персоны.
- Особы, которые не хотят расширять свой профессиональный горизонт (например, изучать другие языки программирования), вряд подойдут для скрам-команды.
- Стоит помнить о другой ловушке – “нагреть океан” (Boil the Ocean) – не утонуть в океане знаний, а наоборот – взять только ту частицу, которая действительно нужна для решения задачи.
- Настоящий девелопер в парадигме Scrum обладает такими чертами, как лидерство и инициативность. Ведь именно такие люди способны изменить всю организацию! Заметьте: я говорю не о “менеджменте”, а о чертах характера, личности. Менеджмент (руководители) мыслит категориями ресурсов, расходов, доходов и тому подобное. Настоящие девелоперы (лидеры, инициаторы) создают гораздо более благоприятные условия для менеджмента (распределения ресурсов, понятные процессы и т.д.). Например: “Дайте мне еще одного проактивного специалиста, и мы вместе сделаем больше, чем привлекать многих различных пассивных специалистов …” – это тема для отдельного разговора.
- Agile – черта настоящих девелоперов в Scrum.
ПРИСОЕДИНЯЙТЕСЬ К AGILE.LIVE
Ближайшие сертификационные тренинги Agile.Live: Advanced Scrum Master with PSM II Certification, Professional Scrum Product Owner (PSPO), Professional Agile Leadership Essentials (PAL-E)
Подписаться на страницу в LinkedIn
Подписаться на Telegram-канал Agile.Live
Подписаться на YouTube-канал Agile.Live