Как мы делаем проекты: управление разработкой и code review

Если вы пропустили

Знакомство

Проектирование и прототипирование

Дизайн

Разработка вебсайтов

Разработка мобильных приложений

Управление разработкой

В зависимости от целей проекта разработка может управляться двумя способами: по  agile-методологии или «водопадом».

Agile

Наиболее популярная agile-методология — Scrum. Разработка по ней идёт итерациями, или спринтами. Их длительность составляет от полутора до двух недель. На проекте есть общий пул задач, который называется бэклогом (Backlog). В начале каждого спринта руководитель проекта вместе с вами формирует список задач — sprint backlog, который остаётся неизменным на весь период итерации. Если новое пожелание возникло посреди спринта, его заносят в бэклог и назначают приоритет, чтобы сформулировать задачу на следующий спринт. В конце итерации её участники собираются, чтобы увидеть итоги и сформировать список задач для нового рабочего периода.

По ходу проекта проводятся регулярные standup-митинги. На них команда постоянно синхронизируется друг с другом, разбирается ближайший план и проблемы на проекте. Так мы держим вас в курсе процесса.

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

Ни один спринт не обходится без тестирования с обязательным исправлением большинства найденных багов. Подробнее о тестировании читайте в следующей части цикла.

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

«Водопад»

В этой методологии каждый этап работы над проектом идёт строго один за другим: от формирования ТЗ к проектированию, затем к дизайну, разработке, тестированию и поддержке. Возможность вернуться к  какому-то этапу не предполагается. Эта парадигма самая стабильная в плане стоимости, но не самая удобная для проектной работы. Чтобы внести какие-то изменения, придётся ждать, пока проект пройдёт все этапы и будет завершён. Но можно разбивать крупные этапы на более мелкие (например, этап в шесть месяцев на три этапа по два месяца) и тем самым раньше повлиять на процесс разработки. Набор функциональных возможностей при таком стиле ведения проекта останется неизменным на весь период. Эта методология лучше применима к проектам, которые невыгодно делать в виде MVP.

Хотя команда Лайв Тайпинг умеет работать по любой из вышеописанных методологий, мы обнаружили, что большинству наших клиентов выгоден некий гибридный вариант. При таком варианте сохраняются гибкость разработки и возможность вносить изменения в проект, но также остаётся понимание о сроках и бюджете всего проекта. В итоге в большинстве случаев мы работаем по водопаду, разделенному на этапы в  один-два месяца; внутри каждого из этих этапов мы используем основы Scrum, разделяя разработку на спринты. Мы показываем вам состояние проекта по прошествии спринта, поэтому вы всегда в курсе того, как идут дела. Если у команды возникнут какие-то проблемы, вы узнаете об этом сразу же, а не на релизе. Подход не требует с вашей стороны такого вовлечения, как в Scrum, и отлично подходит, если вы привлекаете специалистов по модели аутстаффинга с оплатой не за часы, а за отработанный месяц (ретейнер).

Канбан

Ни один наш проект не обходится без канбан-доски задач, с которой в течение спринтов работает вся команда. Обычно мы используем такие инструменты, как Trello, Youtrack и Asana и часто приглашаем наших клиентов на доски, чтобы глубже погружать их в контекст процесса разработки.

Code Review

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

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

Проверяющие разработчики «причёсывают» код в соответствии с принятым в Лайв Тайпинг стандартом. Наличие стандарта гарантирует, что все разработчики будут писать базовые вещи одинаково. Это позволяет новому разработчику разобраться с кодом быстрее, чем с кодом автора-одиночки. Этот процесс «причёсывания» называется code review. Вносить изменения и передавать другой команде проект, прошедший эту процедуру, быстрее и дешевле, чем без неё.

С объяснения того, что такое code review, начал свою жизнь влог Лайв Тайпинг. Подписывайтесь.

Рассказ о тестировании — в следующей части.