Скрам стал стандартом в софтверной разработке, многие компании вводят практику утренних планёрок и называют это «скрамом». Нужен ли скрам аналитикам, необходимо ли аналитикам знать, чем занимаются сейчас разработчики?
Каждый знает, что скрам – это фреймворк гибкой разработки. С практической точки зрения, скрам - это способ организация работы софтверной команды, включающая выделение ролей (владелец продукта, скрам-мастер, команда разработки), распределение функций и выполнение процессов (планирование спринта, ежедневные скрам-митинги, демо спринта, ретроспектива).
Везде можно прочитать принципы скрам, но мало кто говорит об идеях в основе.
Позвольте их изложить с несколько непривычной точки зрения.
Термин «скрам» происходит из регби и означает разыгрывание мяча, при котором игроки стоят в кругу, плечом к плечу, мяч – в центре, каждый готов наброситься на мяч первым. В этом суть скрама: все игроки унифицированы. В скраме нет аналитиков, разработчиков, тестировщиков. В скраме есть универсальные члены команды – разработчики, каждый из которых может выполнить задачу, а также скрам-мастер – который отвечает за методологию.
Скрам эффективно использует ресурс любого свободного участника команды. Вот почему скрам – это магия для современной разработки.
Конечно, аналитик – не разработчик, но разработчик – может быть системным аналитиком, может и тестировать. Тестировщик и аналитик взаимозаменяемы. Тоже не уникальны.
Более того, теперь не надо никого мотивировать. Людям промыли мозги так, что они мотивирует себя сами, бросаясь на любую свободную работу, как на мяч в бейсболе. Более того, они и сами себя контролируют, подхлёстывают и делают виноватыми (на скрам-митингах и ретроспективе), а также сами улучшают процесс (ретроспектива).
Магия скрама имеет и обратную сторону
1. Скрам – это мекка неорганизованной разработки, закрепляет agile
Agile - это концепция гибкой разработки, при которой заказчик не знает точно, что хочет, требования постоянно меняются, работа идёт в режиме постоянной корректировки, задачи разработки и поддержки смешиваются. Скрам закрепляет эту неорганизованность в конкретные действия, ритуалы.
Признанными недостатками agile являются:
1. «Слив» бюджета на разработку, поскольку принципы гибкой разработки увековечивают бесконечность финансовых ресурсов спонсора проекта. Давайте не думать, не продумывать решение, давайте не ставить тщательно задачу. Будем работать итеративно. Делать и переделывать. Только за ваш счёт – за счёт заказчика.
2. Снижение качества разработки с точки зрения данных, поскольку разработка становится управляемой ИТ-инженерами, а не аналитиками данных. Инженеры размещают и использует данные как это им удобно и быстро, в этом случае никто не заботится о модели данных. Это приводит к «мешанине данных»: данные плохо понимаются конечными пользователями (значение, состав, взаимосвязи, возможности использования), сложно и сложнее с каждым разом проверяется их корректность и тестируются изменения.
3. Снижение качества разработки с точки зрения кода. Инкрементально сделанный функционал приводит к тому, что периодически необходим рефакторинг кода (т.е. из состряпанного в спешке кода необходимо сделать более организованный код – т.е. переписать код). Однако переписывание кода не приносит инкремент ценности. Будет ли з это платить заказчик – ведь он нанимал на работу команду профессионалов, которая и так должна была создавать профессиональный код? В большинстве случаев с этим как раз и возникают проблемы – в результате мы получаем код плохого качества, который с каждой итерацией становится всё запутаннее. А это – проблемы тестирования, сложности исправления существующих ошибок и появления новых из-за запутанности кода.
2. Что высасывает из людей энергию? Концентрация!
Не все обращают на это внимание. Если в команде 10 человек, то на ежедневном скрам-митинге каждый должен слушать каждого, стараться вникнуть, что они говорят. Это совсем не нейтральная процедура и дело совсем не в 10-30 минутах времени. Это – активное усилие, на которое тратится энергия человека.
Это значит, что после траты этого усилия необходимо восстановление. Восстановление занимает примерно столько же, если не больше, времени. Ели реальный скрам - полчаса, то это значит, что столько же времени человек приходит в себя, он может формально вернуться на рабочее место, но ему нужно ещё время, чтобы всё переварить.
3. Cкрам "съедает" самое продуктивное время
Время разработчиков нелинейно. Существуют разные оценки, но разработчик продуктивен не более 3 часов. Причём это самое продуктивное время у людей именно утром. И это время убивает скрам.
8 часовой рабочий день – это для фабричных рабочих, из эпохи рабского труда. У мыслительной работы совершенно другие свойства. Конечно, не надо думать, что все работы в ИТ – мыслительные. Техподдержка – это индустриальный процесс. Сейчас как раз сводят творческие процессы - к рутинным, чтобы можно было нанять дешёвых исполнителей и заставить из трудиться как роботов.
4. Cкрам разрывает непрерывное время.
Серам митинги отъедают даже больше времени, чм вы думаете. Представьте, что у вас скрам в 10-00. Начнёте ли вы что-то важное за 15 мин до начала? Скорее всего нет, и не только потому, что надо собраться, продумать, что вы будете говорить. Просто не хочется прерываться. Перерывы, переключения – это траты умственной энергии. Кто говорит о мультизадачности как норме бизнеса – скорее просто не понимают тему, либо что много хуже – работают как корпоративные красные комиссары.
Конечно, всю эти проблемы использования времени можно пытаться компенсировать безумной мотивацией (если она есть), дисциплиной, силой воли, борьбой со страхом. Но любые усилия приводят к истощению человека – то не гений, а обычный «подельщик» средних ИТ- продуктов.
А что если у вас не один скрам в день, а два?
Теперь профессионально о бизнес анализе - в Телеграмм https://t.me/IntelligentBA и более острые видео - в тикток www.tiktok.com/@yarosl_b