Красные флаги в Agile-разработке

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

Об авторе

Фронтендер. Прошёл школу мидл-бойца в Яндексе, после уехал в Германию, где работал в Каяке — поиск по авиабилетам и всякое — американской организации среднего размера. И довольно долго в Дикониуме — довольно крупном агенстве, делающем e-commerce для больших клиентов. В мою бытность в этой компании она была куплена Фольксвагеном. В Дикониуме часть моих обязанностей были лидовскими и организационными. В связи с этим я посещал много воркшопов по аджайлу и повидал много команд, которые довольно строго пытались следовать Cкраму.

Интро

Содержательная цель — поделиться паттернами и практиками, которые указывают на нездоровые процессы в разработке.

Заметки по презентации

Принципы Agile

  1. Люди и взаимодействие важнее процессов и инструментов
  2. Работающий продукт важнее исчерпывающей документации
  3. Сотрудничество с заказчиком важнее согласования условий контракта
  4. Готовность к изменениям важнее следования первоначальному плану

How it started, how it goes

На конференции в Сноуберде в 2001 году, где был написан Agile-манифест, Кент Бек сказал, что одной из наших целей было преодолеть разрыв между программистами и менеджментом.

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

The Tragedy of Craftsmanship

Примеры

SAFe® 6.0 big picture
Subway Map to Agile Practices

Противоречия

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

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

Scrum Guide

Нездоровые паттерны коммуникации

Это негативные и непродуктивные способы общения, которые могут привести к конфликтам, раздражению и непониманию.

Пять дисфункций команды

По книге Патрика Ленсиони

  1. Отсутствие доверия
  2. Боязнь конфликтов
  3. Отсутствие вовлеченности
  4. Уклонение от ответственности
  5. Невнимание к результатам

Откладывание разговора до Sprint Review

Хороший способ замять конфликт, чтобы потерялись контекст и актуальность.

Отсутствие связи команды с заказчиком

Если это только Sprint Review, то это может привести к непониманию и непродуктивности. Вообще, это нарушение одного из принципов Agile.

Жёсткое модерирование встреч

Когда отлонение от темы ведёт к созданию новой встречи. Когда модератор не даёт команде свободы и сам становится источником конфликта. Когда команде не даёт возможность выразить свои мнения и мнения команды не слышны.

Назойливое использование айсбрейкеров

И других а ля весёлых мелочей, например, названия спринтов.

Отношение ко встречам и времени

Makers' vs. Managers' schedule

Рабочий день состоит из встреч vs. встречи прерывают работу

Встречи длиннее полутора часов

Период устойчивого внимания — около сорока минут.

После встреч нужно восстанавливаться

И для входа в рабочий режим нужно время.

Убеждённость в том, что должны присутствовать все

Особенно на рефайнментах, где нужно обсуждать и уточнять детали.

Утренние стендапы

Всегда начинайте день с хорошего настроения и планирования.

Когда стендап — это отчёт о тикетах

А не обсуждение того, над чем идёт работа

Разработчики вымучивают, что говорить

И нет свободы говорить, что думается

На встрече народу больше, чем нужно

Встреча для членов Dev-команды, все остальные опциональны.

Ранне-утренние стендапы

Ориентированные на жаворонков

Нарушения в планировании

Нежелание выделять время на рефакторинг

Точнее, чаще реструктуризации кода.

Игнорирование усилий на code review

Когда это не закладывается в оценку времени на тикеты и трудозатрат разработчиков.

Silent commitment

Молчаливое согласие на нереалистичные ожидания.

Стресс от искусственных дедлайнов

Самый быстрый путь к выгоранию. Это приводит к ухудшению качества кода и снижению продуктивности.

Постоянное изменение скоупа

Если при этом команду ругают за невыполнение целей спринтов.

Грязные лайфхаки программистов

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

Размазывание сторипойнтов во времени

1 пойнт — полдня, 2 пойнта — полтора дня, 3 пойнта — три дня, 5 пойнтов — неделя, 8 пойнтов — спринт.

Разбиение на простейшие подзадачи

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

Жонглирование статусом тикетов

In progress -> Code Review -> In Progress -> Code Review -> Testing

Разработка в стиле 90/10

Перенесение багов на другой спринт

Спасибо за внимание,
приглашаю к обсуждению