Привет, друзья!
На прошлом вебинаре веченей школы про Agile https://www.youtube.com/watch?v=WDinnBu6Wb8&list=PL8D2P0ruohOCoTtli71g1sw-J0k-_EixV&index=13&t=0s я обещал поделиться очень полезной статьей относительно того, как минимизировать «передачи» работы/информации между отдельными членами кросс-функциональной команды и зачем это нужно.
Вот эта статья https://www.mountaingoatsoftware.com/articles/agile-teamwork. Она правда на английском. Можно попробовать поискать подобную статью на русском, но именно эта статья мне кажется одной из самых качественных на эту тему.
Эта статья будет интересна прежде всего скрам-мастерам или тем, кто хочет эту профессию изучить.
А сейчас как и обещал, делюсь выдержками из статьи и своими мыслями на эту тему.
Что это за «передачи»?
Над любым программным продуктом всегда работает кросс-функциональная команда, состоящая из специалистов в разных областях, например, аналитики, дизайнеры, разработчики, тестеровщики и т.д. И обычно, каждый следующий специалист не может приступить к своей работе, пока другой специалист не закончил свою работу или не сделал большую ее часть. Например, программист не может приступить к работе, пока User Story не сформулирована аналитиком. Как только такая работа закончена, то она передается, говоря простым языком, на следующий этап, например, программисту, который в свою очередь передает сделанную работу дальше – тестеровщику. Вот это и есть «передачи работы» (или по англ. handoffs) от одного специалиста другому.
Почему тут вообще есть какая-то проблема?
Потому что такой подход противоречит ценностям Скрама, в частности ценности фокусировки на результате, так как передач работы от этапа к этапу:
по сути маскирует под Скрама каскадную модель разработки (aka waterfall),
заставляет «раскидывать» работу специалистов по разным спринтам: например, аналитик работает на спринт раньше, а тестирование на спринт позже, а это уже не Скрам.
А разве можно как-то по-другому?
Можно. Пониманию того, как именно, часто мешают мифы относительно разработки ПО, которые гласят:
разрабатывать и писать тест-кейсы можно начинать только после того как User Story полностью описаны,
тестировать можно начинать только после того, как код полностью готов.
Что с этим делать?
Мифы на то и мифы, что можно в них верить, а можно идти наперекор им, а именно:
Пересмотрите функции и взаимодействие специалистов внутри команды. Например, аналитики – это не просто передатчики информации между конечными клиентами и инженерами. В Скрам-команде аналитик, это фасилитатор, который стимулирует обсуждения между Владельцем Продукта и командой, чтобы выяснять как функциональность должна быть реализована.
Начните передавать «маленькие» задачи, но чаще. Вместо того, чтобы передавать от специалиста к специалисту целые User Story, начните передавать более мелкие задачи, внутри User Story. Например, Владелец продукта формулирует User Story: «Как покупатель, я могу выбрать способ доставки товаров на основе известной стоимости доставки на мой адрес, чтобы я мог принять решение, как доставлять посылку». Вместо того, чтобы «прорабатывать» эту история по очереди, в самом начале спринта все, кто будет принимать участие в ее реализации, например, аналитик, разработчик и тестеровщик, начинают ее обсуждать, задавая общие вопросы Владельцу Продукта: какие компании мы будем поддерживать (FedEx, DHL, Pony Express и др.)? Будем ли мы поддерживать доставку в тот же день, через 2 дня, 3 дня? и т.д. И тут, программист, например, может сказать, что будет легче начать с FedEx, тестеровщик соглашается, а аналитик заявляет, что займется исследованием доставки через DHL и предоставит эту информацию к тому времени, когда программист и тестеровщик закончат работу с FedEx. Таким образом, разработчик начинает работать над тем, что уже понятно, а тестеровщик начинает работать над тестами к этой задаче, обмениваясь возможными тест-кейсами с программистом, чтобы обсудит как можно раньше неочевидные пользовательские сценарии. В это время аналитик заканчивает анализировать доставку с помощью DHL, которую теперь берут в работу разработчик и тестеровщик. Такой подход приводит к тому, что не создается «лавинообразной» передачи большого количества работы от одного специалиста к другому (например, когда тестеровщику нужно за 2 дня до конца спринта протестировать недельную работу разработчика), а все специалисты работают над маленькими частями одной и тоже User Story.
Балансируйте нагрузку на команду в спринте. Конечно, не всегда такая работа над User Story возможна. Некоторые истории требуют глубокой проработки аналитиком или сложной реализации разработчиком. Просто постарайтесь брать в спринт не три сложных истории, а лучше возьмите две или одну сложную и 2-3 по проще, над которыми команда сможет работать одновременно.
Куда дальше?
Высшим проявлением минимизации передач в командной работе является Mob programming https://en.wikipedia.org/wiki/Mob_programming. Такой подход может повысить эффективность работы вашей команды в разы, но об этом – в другой раз 😊
