x

Добро пожаловать в IT Leader Assistant.
Please Войти!

Создать аккаунт

Как добиться самоорганизации от технической команды. Инструкция для ПО.

Александра Шаламова
07-27-2021 14:40

Видео-тезисы статьи

Введение

Нередко можно услышать в адрес команды: “а давайте вы самоорганизуетесь”. В этой статье я хочу поговорим о том, как работает самоорганизация команды и какие необходимы условия и действия от ПО, чтобы самоорганизация действительно работала. Здесь речь пойдет о классической Agile-команде, в которую не входит ПО, как часть команды.

Что такое самоорганизация и для чего она нужна

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

Что команда может делать в рамках самоорганизации

В рамках самоорганизации Agile-команда может:
  • принимать технические решения по реализации задач;
  • планировать бэклог спринта в соответствии с приоритетами бэклога продукта;
  • корректировать решение в рамкам критериев приемки;
  • самостоятельно решать спорные моменты между собой;
  • вносить запрос на увеличение ресурсов как связанных, так и не связанных с функционированием проекта;
  • вносить задачи в бэклог продукта на обсуждение с ПО.

Что команда не должна делать в рамках самоорганизации

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

Что должен делать ПО для самоорганизации команды

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

Четко описывать задачи с критериями приемки

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

Позитивный сценарий работы ПО с описанием задачи

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

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

Негативный сценарий работы ПО с описанием задачи

ПО создает задачу со следующим описанием:
Сделать, чтобы пользователи могли выбирать свой город.
У команды при прочтении этой задачи нет четкого понимания, что нужно реализовать. На груминге половина встречи уходит на то, чтобы обсудить с ПО эту задачу и выяснить, что в ней подразумевается. При этом все спорят о том, нужно ли реализовывать каждую деталь и как ее нужно реализовывать. В результате к планированию в бэклоге продукта нет достаточного количества задач готовых к разработке для составления спринта.

Разъяснять все вопросы по задачам на грумингах

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

Позитивный сценарий присутствия ПО на груминге

Команда рассматривает на груминге User Story, созданную в прошлом пункте и возникает вопрос “Должен ли сохраняться город для пользователя и автоматически выбираться на всех его устройствах?”. Они обсуждают этот вопрос с ПО и приходят к заключению, что адрес должен сохранятся в профиле пользователя и быть одинаковым везде. После этого один дописывают в задачу новый критерий приемки:
после выбора город должен сохраняться и быть выбранным автоматически на всех устройствах, где авторизуется пользователь

Негативный сценарий отсутсвия ПО на груминге

Команда рассматривает на груминге User Story, созданную в прошлом пункте и возникает вопрос “Должен ли сохраняться город для пользователя и автоматически выбираться на всех его устройствах?”. Но ПО в этот раз нет на груминге, поэтому команда не может выяснить свой вопрос и дополнить критерии приемки задачи. Поэтому задача остается в бэклоге продукта до выяснения деталей и не может попасть в ближайший спринт.

Четко расставлять приоритеты задач

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

Позитивный сценарий расстановки приоритетов

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

Негативный сценарий расстановки приоритетов

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

Быть доступным в экстренных ситуациях

ПО должен быть доступным для команды на случай экстренных ситуаций. Даже если ПО идеально описал задачу и решил все вопросы на груминге, может возникнуть такая ситуация, что в процессе реализации выяснились новые данные, которые все меняют и могут сделать невозможным или более дорогим, чем ожидалось, выполнение задачи. В этот момент команда должна призвать ПО, чтобы донести ему новую информацию и узнать как он будет менять приоритеты задач (готов ли он, например, оставить задаче ставшей в разы сложнее и дольше в реализации оставить тот же приоритет или ее ценность в таком случае понижается). Здесь может показаться, что команда слишком зависит от ПО. Однако, на деле все совсем наоборот. Во-первых, команда не имеет нужной квалификации и не должна менять приоритеты задач, это может сделать только владелец продукта. Это та задача, которую нельзя переложить на команду, ее может решить лишь человек, имеющий полноценное видение по продукту. Во-вторых, чем быстрее ПО ответит команде и поможет ей определить измененные приоритеты, тем быстрее команда сможет продолжить работать самостоятельно. Если ПО нет в доступе долгое время, то это мешает команде продолжить независимо работать над спринтом.

Позитивный сценарий доступности ПО для команды

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

Негативный сценарий доступности ПО для команды

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

Своевременно находить бюджет на блокирующие ресурсы

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

Позитивный сценарий работы ПО с ресурсами для команды

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

Негативный сценарий работы ПО с ресурсами для команды

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

Доверять команде

Доверие очень важный пункт для самоорганизации команды. Если команда решила проблему в рамках, описанных ПО критериев приемки и расставленных им приоритетов, а ПО будет выражать свое недовольство, что что-то решили без него, или даже поведет себя агрессивно, то об самоорганизации можно будет забыть. Только при условии, что ПО описывает все что для него важно и дает команде достаточную свободу действий, он может ожидать избавления себя от траты времени на решение каждого мелкого вопроса по задаче.

Позитивный сценарий доверия ПО к команде

В User Story описанной в первом пункте ПО описал, что пользователь должен иметь возможность выбрать свой город. Команда перебрала возможные варианты реализации и выбрала готовое решение, уже используемое в продукте в другом месте, где город выбирается из списка с возможностью поиска. На демо команда показала готовую задачу. ПО оценил, что все критерии приемки выполнены и весь необходимый функционал работает, как он заказывал. При этом ПО отмечает, что команда выбрала удачное решение, в котором есть поиск по списку. Хотя в критериях приемки такого требования не было, поиск не только не противоречит требованиям задачи, но и улучшает пользовательский опыт при выборе города. Таким образом команда внесла свой вклад в улучшение продукта, за счет свободы и доверия, предоставленной им ПО. При этом команда не отвлекала ПО лишними уточнениями и вопросами о выборе реализации, а ориентировалась только на уже готовые критерии приемки.

Негативный сценарий недоверия ПО к команде

ПО описал в задаче, что выбор города должен осуществляться с помощью элемента Select с запросом сразу всего списка городов с бэкенда. Команда в процессе реализации поняла, что без поиска выбирать город очень неудобно и использовала выпадающий список с поиском. На демо ПО был очень возмущен, что решение было принято без него и запретил команде делать так впредь, настояв на переделке задачи. Через какое-то время после выкатки пользователи начали жаловаться, что пользоваться выбором города невозможно. А команда больше никогда не проявляла инициативу, когда видела, что что-то можно сделать лучше.

Какие преимущества получает ПО и продукт

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

Комментарии

Чтобы оставить комментарий, пожалуйста, авторизуйтесь

Подписывайтесь на обновления

Последние статьи из нашего блога