Особенности гибкого процесса производства в студии
В чем гибкость то?
Походу, в образе мышления :) Вот раньше разрабатывали сразу целиком и вполне успешно работала цепочка:
идея → техническое задание → дизайн → программирование → тестирование → релиз
Если ближе к релизу появлялись новые идеи, приходилось игнорировать их или переделывать готовое. Страдал продукт,
или выбивались из ресурсов.
Стали пробовать новые подходы, за основу взяли Scrum, из Kanban понравилась визуализация. Теперь стараемся тестировать и реагировать на изменения в процессе разработки, поэтому → гибкость.
Определите, какая у вас задача
В 1999 году Дэйв Сноуден из IBM создал фреймворк Cynefin (дословный перевод — «устройство для осмысления»). Благодаря нему группа людей может совместными усилиями соотнести задачу (или ситуацию) с определенной областью фреймворка.
Там не существует наилучших практик решения задач, а у нескольких экспертов могут быть разные взгляды на одну и ту же проблему. Поэтому, движемся строя гипотезы и проводя эксперименты, чтобы подтвердить или опровергнуть их.
Именно гибкие методологии эффективнее всего позволяют работать
в таких условиях.
Подходы у всех разные, но идеи совпадают. Обновленный флоу в студии
Осмысленность при разработке важнее сроков и бюджетов. Это путь, который ведет к повышению истинной ценности продукта — счастью пользователя.
Мы не верим в существование идеального процесса разработки, который бы еще и подходил разным командам. Еще думаем,
что использование популярных языков программирования, инструментов и технологий разработки не гарантируют успешность проекта. Ключевым фактором, обеспечивающим успех, являются человеческие качества.
Поэтому наш обновленный флоу разработки проектов не готовый мануал, а фреймворк с набором принципов, возможных инструментов и действий. В основе самообразование и переосмысление приобретенного опыта всех участников Molinos.dev
Мы осознанно разделяем разработку на концептуальную и детальную часть. На старте, выясняем, что должно происходить в приложении
и как оно будет устроено внутри и только потом переходим
к производству.
Поверьте, намного сложнее и дороже переписывать код приложения, когда выяснится, что сервис оплаты не поддерживает нужный функционал
Большой риск начать программировать не зная:
- возможностей, ограничений и особенностей среды, в которой будет работать приложение,
- возможностей, ограничений и особенностей сервисов с которыми предстоит интегрироваться,
- потенциальной архитектуры приложения,
- флоу всех пользовательских историй, их критериев работоспособности и приемки.
Предоставьте эти данные вашим разработчикам и они не будут топтаться на месте, ожидая документацию на интеграции, перестанут задавать общие вопросы, например откуда получить данные для какой-нибудь формы, что происходит по нажатию на такую-то кнопку или что должно произойти в случае ошибки какого-то сценария.
Такой подход выглядит сложнее и дороже. На практике, уделяя время критическим рискам на старте, мы стабилизируем всю дальнейшую разработку.
Поверьте, намного сложнее и дороже переписывать код приложения, когда выяснится, что сторонний сервис оплаты не поддерживает нужный функционал или важный сценарий работы невозможно реализовать из-за технологических особенностей.
«Под капотом» управления проектом
Концептуальный уровень и визуализация
Следуя одному из принципов Kanban— каждый участник команды
работает не сам по себе, он — часть Команды, поэтому мы уделяем особое внимание тому, чтобы у всех участников было единое представление о проекте.
На старте, каждый проект получает свое пространство для коллаборации между командой заказчика и разработки. Там проходит концептуальная часть разработки: строится карта с целями, приоритетами и участниками проекта, карта с пользовательскими путями, карта пользовательских историй с критериями работоспособности и приемки, формируется потенциальная архитектура проекта.
От анализа к синтезу или проектный план
Когда понимаем, что предстоит делать и чего мы хотим достичь
в результате проекта, то переходим от концептуальных артефактов
к проектному плану в таск-трекере.
Строим стратегический план на диаграмме Ганта с составом работ, взаимосвязями между ними и прогнозируемой длительностью. Кстати, благодаря интеграции между Mira и Jira карточки пользовательских историй генерируют соответствующие эпики, стори или задачи в таск-трекере.
Верхнеуровневый взгляд помогает нам зафиксировать, как мы планируем сделать проект.
Во время спринта команда разработки использует канбан-доску
с визуализацией эпиков, стори и конкретных задач на спринт.
На ней:
- следим за движением задач по статусам выполнения,
- контролируем нашу загрузку, чтобы выполнять задачи, а не только переключаться между ними,
- контролируем проблемные места (мы стремимся
к взаимозаменяемой команде, поэтому каждый можем расширить зону своей ответственности и помочь товарищу, если проблема стопорит команду) - анализируем результаты в конце спринта (с доской удобнее
на ежедневных стендапах, обзорах спринтов)
«Пульс проекта» или детальный уровень
В конце каждого спринта планируем следующий и проводим обзор прошедшего с учетом цикла Деминга. Раз в несколько спринтов проводим демонстрацию результатов клиенту.
Детальный уровень — короткий период в один спринт. Каждый пункт состоит только из одного предложения, команда может быстро оценить успешность прошедшего спринта и здоровье проекта.
Так каждый участник команды видит, что нужно сделать прямо сейчас, чтобы приблизить общий результат к цели. Если детальный план
не выполнен, то мы дали конкретные обещания и не сдержали их :(
Резюмируя
- Не существует идеального процесса разработки, подходящего всем. Подбирайте методологию и состав работ в зависимости от степени неопределенности проекта.
- Сложные и запутанные проекты начинайте с концептуальной
и стратегической части, ответьте на вопросы «что планируется сделать?» и, главное, «зачем?» - У нас такие проекты проходят через трехуровневое «сито»: концептуальный, верхнеуровневый и детальный.
- Каждый раз, когда накопился некий объем отклонений — мы не пытаемся вернуться на заранее рассчитанную траекторию,
а смотрим, как нам лучше попасть в нашу цель из той точки,
в которой мы уже находимся.
Эта заметка является частью цикла заметок по разработке проектов
с высокой долей неопределенности в Molinos Studio.
