Построение процессов в мини-команде

В статье рассматривается один из вариантов планирования работы команды, состоящей из 3 человек, в контексте разработки программного обеспечения. В данном случае рассматривается планирование длиной в 1 год.

Ключевые слова: планирование, программное обеспечение, небольшой проект, Scrum-ban, процессы, Sprint Planning.

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

Пожалуй, стоит начать с исходных данных. Итак, у нас есть:

— 2 разработчика + 1 тестировщик + деливери менеджер — это весь состав проекта ;

— бесплатный инструмент с открытым исходным кодом , т. е. все, над чем и как работает команда, может изучить любой желающий;

— сайт и репозиторий — два источника непокрытых дефектов и вдохновений;

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

Таким образом, получаем интересный для сотрудников проект, который оплачивает их работодатель, а богатого клиента надо еще привлечь. То есть увеличить команду не получится на данном этапе. Отсюда вытекает ряд проблем и большое количество задач, которые нужно 3 сотрудникам порешать As Soon As Possible:

— привлечение заказчика со стороны и дальнейшее его удержание;

— исправление существующих ошибок;

— стратегия тестирования для обнаружения ошибок до релиза;

— поддержка текущих пользователей;

— оформление репозитория, официального сайта и документации.

Список выглядит небольшим, но на деле этого очень много! При всем этом нужно не обеспечить мини-команде профессионального выгорания.

Предлагаю начать с выбора методологии. Когда не знаешь, с чего начинать, стоит идти от противного — с чего начинать не стоит. Waterfall — не берем, так как не все требования известны и изменяются динамически. А значит, все схожие модели типа V-Модели уже отбрасываются. А что насчет более гибких моделей? Вариант хорош, но как правило, гибкие модели подразумевают, что есть конкретные требования от конкретных пользователей — продуманные, проанализированные и утвержденные. Наши пользователи просто «накидывают идеи». Подобное даже Use Case назвать сложно. Поэтому большинству гибких моделей придется дать отрицательный ответ.

А как же Scrum? Ему тоже стоит ответить «нет». Да, он отлично подойдет, так как требования пользователей постоянно меняются, можно безболезненно менять функционал, а для старта достаточно небольшого планирования. Есть ряд причин, почему нет: 3 человека не смогут поддерживать большое количество постоянно всплывающей документации без овертайма; Scrum подразумевает отчеты, которые сейчас не нужны; метрики будут плохими, но не достоверными. Таким образом, использовать Agile как некую философию [1] будет приемлемо, но полностью использовать Scrum — невыгодно.

Выход прост: совместить Kanban и Scrum — довольно популярное решение [3]. Таким образом, мы сможем выстраивать общение и разработку в более удобном русле, ведя при этом документацию, которая не убьет маленькую команду. От Scrum будет выгодно взять итерации где-то в 3 недели — для выпуска новой версии приложения и обновления документации. От Kanban возьмем опциональные встречи и оценки задач, а также возможность добавлять задачки в любой момент времени.

А теперь надо взять нашу итерацию Scrum-ban и впихнуть в нее ASAP проблемы, описанные в самом начале, распределив все на 3-х человек.

Прежде всего стоит провести груминг backlog: закрыть старые и не актуальные задачи, а также те, которые непонятны (над таким задачами следует посидеть и подумать, зачем это было создано и с какой целью; их лучше во время выстраивания процессов объединить с другими), выставить приоритеты и важность, выставить статусы, назначить ответственных за каждый задачку, уточнить оценку каждой задачки. Если оценку дать не получается, то стоит создать [Spike] для того, чтобы исследовать требования story. Рекомендуется также создать 2 новые story, в которые будет списываться время на встречи и на общение с пользователями. Первая нужна только для первого спринта и груминга, а вторая — тестовая и будет тянуться несколько спринтов, чтобы понять, сколько времени команда тратит на поддержку. После груминга в тестировании не останется долговременных задач. Поэтому основной задачей и довольно большой будет построение тестовой стратегии.

Каждый следующий спринт должен быть направлен на создание процесса выпуска новой версии и покрытие тестами функционала, согласно стратегии тестирования. Напомню, что есть два разработчика: 1 — занимается основным функционалом, 2 — занимается Proxy-сервером для новых платформ. Таким образом, список задач для каждого спринта получится следующим:

1 — Разработчик. Исправление дефектов, у которых Severity будет Blocker или Critical. Релиз новой версии.

2 — Разработчик. Разработка Proxy-сервера. Релиз новой версии.

3 — Тестировщик. Поддержка пользователей. Покрытие функционала тестами, согласно стратегии. Тестирование 2-х релизов.

Количество встреч со времен останется прежним, а вот их длительность уменьшится, что положительно скажется на закрытие задач в течение спринта [2]. Как ни странно, но также уменьшится время на поддержку пользователей. Потому что будет собран список возможных ошибок и скрипты ответов, а также покрыты тестами запросы пользователей. Однако, данная тенденция будет видна только после 5-го спринта, то есть где-то через 4 месяца.

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

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

Литература:

1. Деннинг, С. Эпоха Agile. Как умные компании меняются и достигают результатов / С. Деннинг. —: Манн, Иванов и Фербер, 2019. — 384 c.
2. Сазерленд, Дж Софт за 30 дней. Как Scrum делает невозможное возможным / Дж Сазерленд, К. Швабер. —: Манн, Иванов и Фербер, 2017. — 256 c.
3. Сборник Канбан и точно вовремя на Toyota: Менеджмент начинается на рабочем месте. / Сборник. — 5-е изд. —: Альпина Паблишер, 2021. — 214 c.