Для планирования функций профессиональные команды используют процессы с участием нескольких ролей. Они придумывают, проектируют, планируют, оценивают и расставляют приоритеты перед началом реализации. Они разбивают большие функции на небольшие фрагменты, которыми могут заниматься несколько разработчиков параллельно.
Звучит разумно. Но, не имея опыта работы, вы, вероятно, не представляете, как это выглядит в реальной жизни. Цель этой статьи — познакомить вас с типичным процессом планирования функций. С которым вы, скорее всего, столкнетесь на своей первой работе.
- Сначала мы расскажем немного теории о типичной команде разработчиков и процессе планирования.
- Позже мы применим полученные знания на двух примерах. По крайней мере, к тем, в которых вы, скорее всего, будете участвовать в качестве младшего разработчика.
Примеры основаны на пользовательских историях и проектах. Таким образом, вы сможете увидеть применение процесса в реалистичном сценарии и попрактиковаться самостоятельно.
Мой совет — прочитать хотя бы теоретическую часть на этой странице перед просмотром видео ниже. По общему признанию, объяснения здесь лучше, чем в видео.
Если вы хотите получить практические навыки в профессиональной среде, запишитесь на предстоящий React Job Simulator.
Оглавление
- Типичная команда разработчиков
- Процесс планирования функций
- Запросы на функции, истории и проекты
- Доработка
- Оценки
- Техническое планирование
- Реализация, контроль качества и развертывание
- Совет директоров
- Пример 1: Планирование простой боковой панели навигации
- История пользователя
- Доработка
- Оценка
- Техническое планирование
- Пример 2: Планирование сложной интерактивной страницы
- История пользователя
- Уточнение
- Оценка
- Техническое планирование
Примечание: Приведенные здесь описания основаны на моем опыте работы с несколькими командами. Точный процесс и обязанности отличаются от команды к команде. Но общая картина должна быть схожей во многих компаниях.
Типичная команда разработчиков продукта
Прежде чем мы погрузимся в процесс планирования, мы должны понять, как выглядит типичная команда разработчиков продукта. Какие роли в ней задействованы? Каковы их обязанности?
Это люди, с которыми фронтенд-разработчик работает ежедневно:
Примечание: это написано с точки зрения разработчика. Некоторые вещи упрощены и технически не точны (например, менеджер продукта и владелец продукта не могут быть одной и той же ролью). Могут быть задействованы и другие роли, например, QA-инженеры. Тем не менее, это должно дать представление о том, с чем сталкивается новый разработчик на своей первой работе.
Менеджер продукта (или владелец продукта в терминологии Scrum): обычно на команду разработчиков приходится один менеджер продукта. В основном они следят за тем, чтобы разработчикам было над чем работать (помимо рефакторинга кодовой базы).
- Они собирают запросы и требования к функциям.
- Они пишут задачи в форме пользовательских историй (подробнее об этом позже).
- Они определяют приоритеты функций и задач вместе с высшим руководством.
По сути, менеджеры продукта являются связующим звеном между внешним миром (например, высшим руководством или другими отделами) и разработчиками.
Дизайнер: как правило, на команду разработчиков приходится один дизайнер. Часто они даже работают с несколькими командами. В их обязанности входит создание дизайна пользовательского интерфейса (очевидно), но они также могут участвовать в исследованиях пользователей (например, как UX-дизайнеры).
Разработчики: на каждого менеджера по продукту или дизайнера обычно приходится несколько разработчиков. В большинстве случаев разработчики являются узким местом в создании продукта. В их обязанности входит внедрение новых функций, исправление ошибок, поддержка и улучшение системы, а также участие в планировании и оценке предстоящих функций.
Это подводит нас к следующей главе.
Процесс планирования функций
Вот небольшая справочная информация о том, как функция проходит путь от идеи до внедрения в производство. Это немного теоретическая информация, но позже мы увидим два практических примера.
Запросы на функции, истории и проекты
Весь процесс начинается с запроса на новую функцию. Этот запрос может исходить от команды, бизнесменов, другого отдела (например, отдела маркетинга) или пользователей компании.
Менеджер продукта собирает требования к функции, работает с дизайнером над созданием пользовательского интерфейса и пишет истории пользователей. Часто в этот процесс также вовлекается один или несколько разработчиков, чтобы понять техническую осуществимость на ранней стадии.
История пользователя — это тип задания, которое описывает (часть) функции с точки зрения пользователя. Она не содержит большого количества технической информации, но объясняет цель задания. Несколько историй могут быть сгруппированы вместе как «эпопея», которая описывает всю функцию.
Обычный шаблон для пользовательского рассказа выглядит следующим образом: «Как … я хочу …, чтобы …».
Пример: «Как пользователь я хочу использовать навигационную панель, чтобы я мог легко посетить все важные части приложения».
Доработка
После того, как менеджер продукта решит, что истории функций и пользователей находятся в презентабельном состоянии, он обсуждает их с разработчиками на так называемой доработке бэклога или груминге бэклога.
Это встреча, на которой собирается вся команда, и у каждого есть возможность задать вопросы и высказать опасения по поводу потенциальных проблем реализации. Например, часть функции может выглядеть простой, но оказаться очень сложной в реализации. Часто PM и дизайнер не знают об этом. Команда может обсудить проблему и либо найти более простое решение, либо разбить историю на более мелкие фрагменты.
После того как все вопросы сняты, можно приступать к оценке трудозатрат.
Оценки
Руководству необходимо делать прогнозы. Когда функция будет готова? Когда ее ожидают наши клиенты? Как выглядит наша дорожная карта? Обычно для составления таких прогнозов используются оценки. И самый простой и очевидный способ оценить — спросить разработчика: «Сколько времени потребуется, чтобы создать это?».
Нет ничего, что разработчик ненавидел бы больше…
Опыт показывает, что это приводит к сильно заниженным срокам. Поэтому умные люди попытались отделить смету от времени, присваивая истории баллы сложности. Разработчики в основном говорят: «Эта задача кажется сложной. Я ставлю ей 8 баллов» или «Это просто. Это 1».
Эти числа называются баллами сложности.
Они не имеют какого-либо внутреннего значения, но со временем команда обычно приходит к единому мнению о том, что представляет собой каждое число.
Идея заключается в том, что вы можете наблюдать, сколько пунктов команда может выполнить за определенный промежуток времени (часто за 2-недельный спринт). Это называется скоростью. Среднее значение скорости за несколько спринтов может быть использовано руководством для получения оценки времени работы над функцией.
Многие команды используют числа из ряда Фибоначчи (1, 2, 3, 5, 8, 13, 21…). Теория гласит, что чем сложнее задача, тем неточнее ее оценка. Увеличивающиеся промежутки между точками отсчета представляют собой эту неточность.
В теории все это звучит замечательно. Но числовая природа Storypoints часто приводит к неправильному использованию. Типичными признаками являются:
- Оценка Storypoint преобразуется в оценку времени. Пример: «Эта история имеет 1 балл, поэтому она должна занять полдня».
- Оценки по Storypoint оборачиваются против команды разработчиков: «Вы дали этой функции в общей сложности 60 баллов, поэтому у вас дедлайн 4 недели» или «Этой команде нужно увеличить скорость работы» или еще хуже «Команда А намного производительнее команды Б, потому что у нее выше скорость работы».
Но самое главное, исследования показывают, что вы можете просто посчитать количество историй вместо сторипоинтов и получить практически ту же оценку. Таким образом, все усилия по оценке могут оказаться пустой тратой времени.
Тем не менее, большинство команд используют оценки по сторипоинтам. Так что если вы хотите начать карьеру разработчика, вы, скорее всего, рано или поздно столкнетесь с ними.
Техническое планирование
Эта встреча необязательна. Она может проводиться и до оценки.
После оценки пользовательских историй разработчики собираются снова, чтобы обсудить технические детали. Помните, что история пользователя пишется с точки зрения пользователя и, как правило, не содержит большого количества технической информации.
Большая часть технических обсуждений уже должна была состояться до оценки. Поэтому при необходимости разработчики просто разбивают каждую историю пользователя на несколько технических задач, которые имеют смысл с их точки зрения. Это могут быть такие задачи, как добавление колонки в таблицу базы данных, обновление API или добавление компонента в библиотеку пользовательского интерфейса.
Реализация, QA и развертывание
На этом этапе пользовательские истории готовы к разработке. Разработчики берут их один за другим и реализуют. Кто-то тестирует реализацию. В идеале, функция покрывается автоматизированными тестами для предотвращения будущих регрессий. И наконец, функция развертывается в продакшн, чтобы пользователи могли ею воспользоваться.
Мы не будем вдаваться в подробности, поскольку эта статья посвящена процессу планирования.
Доска
Все задачи визуализируются на доске. Ниже приведен пример доски в стиле Kanban с несколькими колонками. Пользовательские истории начинаются с самого левого столбца в бэклоге. Как только они будут уточнены и оценены, их можно переместить в колонку Todo. Теперь разработчики могут выбрать задачу и переместить ее в следующие колонки в зависимости от статуса ее реализации.
Пример 1: Планирование простой боковой панели навигации
Вся эта теория может быть немного скучной и трудной для понимания. Поэтому давайте продолжим с двумя практическими примерами. Начнем с простого компонента.
Обычно я не предлагаю просматривать блог на моем сайте. Но если вы хотите попрактиковаться в этом процессе, то там у вас будет лучший опыт, поскольку решения изначально скрыты. Нажмите здесь, чтобы перейти к этому разделу на моем сайте.
История пользователя
Первая пользовательская история предстоящего React Job Simulator — это навигация по боковой панели. Вот скриншот билета с доски выше:
Вы можете увидеть фактическую историю пользователя, дизайн и список критериев приемлемости (также AC). Точный формат билета варьируется от команды к команде. КК не включают много технических деталей, но описывают функциональность с точки зрения пользователя. Здесь они в основном описывают поведение дизайна на словах.
Доработка
Во время сессии доработки команда просматривает историю пользователя, дизайн и предложенные критерии приемлемости.
Пожалуйста, посмотрите сами. Есть ли несоответствия в дизайне? Что-нибудь неясно из описания билета? Что-нибудь неправильно или отсутствует в AC? Что-нибудь, что вы хотели бы изменить?
Вот что я нашел:
…
…
…
…
Доработка этого билета выявила две более мелкие проблемы:
- Последний критерий приемки содержит ошибку: панель навигации должна выдвигаться не вправо, а влево.
- Текущая страница выделяется в меню (страница «Вопросы» в дизайне). Это отсутствует в критериях приемки.
Менеджер продукта соглашается и обновляет AC:
Оценка
История пользователя достаточно ясна, поэтому мы переходим к оценке истории пользователя. В качестве напоминания, каждый разработчик выбирает номер из ряда Фибоначчи (1, 2, 3, 5, 8, 13, 21), где 1 — это очень простая задача. Скажем, изменение текста или цвета может быть 1.
Здесь у вас есть возможность попрактиковаться: Придумайте число, которое отражает сложность этой истории пользователя, прежде чем читать дальше. Не волнуйтесь, на этом этапе нет правильного или неправильного.
Моя оценка и объяснение:
…
…
…
…
3
Как я уже сказал, в этом ответе нет правильного или неправильного. Со временем наше понимание этих оценок будет все больше и больше выравниваться.
Если предположить, что вы сказали что-то другое, мы могли бы согласиться с одной из оценок (часто с более высокой на всякий случай). Или мы обсуждаем наши причины. Это может быть очень ценно, когда есть большие различия в оценках, потому что это часто показывает необходимость уточнения пользовательской истории.
Итак, позвольте мне объяснить, почему я выбрал 3: Навигация боковой панели не выглядит слишком сложной. Это простой компонент пользовательского интерфейса без вызовов API или чего-то подобного. Но есть немного интерактивности:
- Боковая панель на рабочем столе складная, поэтому нам нужно какое-то состояние.
- Текущий элемент выделяется. Это не должно быть сложно, если использовать URL, но это добавляет некоторую сложность.
- Мобильный дизайн ведет себя иначе, чем настольная версия.
Техническое планирование
С моей точки зрения, нам не нужно разделять эту историю пользователя на несколько технических задач. Мы могли бы создать задачу для настольного и мобильного дизайна из-за разного поведения. Но я бы оставил это как единую историю пользователя.
Пример 2: Планирование сложной интерактивной страницы
Навигация по боковой панели была довольно простой. Теперь давайте посмотрим на более сложную пользовательскую историю из моего будущего симулятора React Job. Вот скриншот дизайна страницы вопросов:
Хорошо, в этом дизайне гораздо больше сложных компонентов и интерактивных элементов. Взгляд на доску показывает, что менеджер продукта создал две пользовательские истории:
В качестве примера рассмотрим «Список вопросов».
История пользователя
Вот скриншот истории пользователя:
Доработка .
И снова, пожалуйста, посмотрите сами. Есть ли несоответствия в дизайне? Что-нибудь неясно из описания тикета? Что-нибудь неправильно или отсутствует в AC? Что-нибудь, что вы хотели бы изменить?
Вот что я нашел:
…
…
…
…
Вы можете увидеть сложность этой истории пользователя только по критериям приемки. При ближайшем рассмотрении можно отметить несколько моментов:
- Название столбца «Уровень» в оригинальном дизайне — это «Статус» в пользовательской истории. Дизайн в истории пользователя — это просто скриншот реального дизайна в Figma. И он кажется устаревшим. Поэтому никогда не полагайтесь на скриншоты в описании задачи.
- Кнопки пагинации ведут себя не так, как ожидается в дизайне. На первой странице кнопка «Предыдущая» должна быть отключена. На последней странице кнопка «Следующая» должна быть отключена. Это также должно быть отражено в AC.
- Большая часть критериев приемки касается флажков и соответствующей кнопки «Решить выбранные вопросы» в верхней части таблицы. Хотя с точки зрения менеджера продукта, возможно, имеет смысл включить это в историю, мы, разработчики, знаем, что многое происходит за кулисами. Поведение флажков уже несколько усложнено. А нажатие на кнопку вызывает запрос API, который включает обработку ошибок и обновление списка проблем. Здесь предлагается перенести это в отдельную пользовательскую историю «Решение проблем».
К счастью, менеджер продукта не сопротивляется. Они создают отдельную пользовательскую историю (мы проигнорируем ее здесь) и обновляют AC в соответствии с нашей обратной связью:
Как видите, сессия доработки помогла сохранить краткость пользовательской истории и выявила некоторые случаи, которые еще не были упомянуты в критериях приемки. Особенно полезным здесь может оказаться участие нескольких разработчиков.
Оценка
Настало время для оценки. Выберите точку Storypoint (1, 2, 3, 5, 8, 13 или 21), где 1 — это простая задача, например, изменение текста или цвета.
Вот мой вариант:
…
…
…
…
8
Опять же, вполне ожидаемо, что мы выбрали разные точки повествования. Здесь нет правильного или неправильного. Но позвольте мне объяснить свое решение:
- Сама строка таблицы довольно проста (предполагается, что мы получим список проблем с необходимыми данными). Но график может стать немного сложнее. Вероятно, мы должны использовать библиотеку графиков и должны сравнить различные варианты. Всегда есть риск, что библиотека не соответствует всем требованиям, например, закругленные столбики или промежуток между столбиками.
- Пагинация добавляет некоторую сложность. Я предполагаю, что API поддерживает правильную пагинацию. В любом случае, нам нужно вызывать новые вызовы API каждый раз, когда нажимается одна из кнопок, и обрабатывать состояние кнопок в зависимости от текущей страницы.
- Помните первоначальный дизайн? На настольном компьютере у нас есть таблица. На мобильных устройствах каждый вопрос отображается в виде карточки. Я не уверен, насколько это будет сложно. Думаю, это должно быть возможно с помощью CSS-сетки или чего-то подобного. Тем не менее, с моей точки зрения, это добавляет сложности истории.
Техническое планирование
Эта история пользователя, очевидно, немного сложнее. Я бы сказал, что имеет смысл разделить ее на несколько задач для разработчиков. Есть некоторые преимущества в том, чтобы иметь несколько небольших задач:
- Pull-запросы не становятся такими большими, и поэтому их легче рассматривать.
- Несколько разработчиков могут начать реализовывать функцию параллельно (если задачи не слишком сильно зависят друг от друга).
Итак, давайте начнем разбивать пользовательскую историю на части. В качестве напоминания здесь приведены дизайн и критерии приемки из этой истории:
Подумайте о различных задачах, которые вы будете создавать. Как вы можете разделить историю на небольшие самодостаточные задачи? Как вы можете позволить нескольким разработчикам работать параллельно?
Вот задачи, которые я создал
…
…
…
…
- Задача «Create Issue Row» — это простой компонент пользовательского интерфейса, исключающий граф. Мы можем создать его с помощью Storybook. Это следует сделать в первую очередь.
- Задача «Создать таблицу» содержит вызов API и рендеринг элементов в таблице. Она зависит от задачи «Создать строку выдачи», но разработчик уже может приступить к реализации вызова API.
- Задача «Создание мобильного дизайна» может быть начата сразу после выполнения первой задачи. Честно говоря, я не уверен, стоит ли выделять это в отдельную задачу или нет. Выделение этой задачи в отдельное задание может привести к тому, что разработчик забудет о различиях между настольным и мобильным дизайном. Но это было бы отличным упражнением для React Job Simulator.
- Задание «Внедрить пагинацию» можно начать сразу после выполнения задания «Создать таблицу выдачи». В остальном она очень независима от других задач.
- Наконец, задача «Создать график» касается графа, отображающего график. Поскольку это добавляет немного сложности в историю пользователя, имеет смысл выделить ее в отдельную задачу. Таким образом, менеджер продукта сможет изменить приоритет графа, если сроки поджимают или команда приходит к выводу, что усилия не оправданы в данный момент.