Прим. перев.: Продолжаем публикацию серии переводов материалов, подготовленных создателями британского госпортала Gov UK. Данные материалы могут быть полезны с практической точки зрения (разумеется, не только для создания масштабных госсервисов).

Мы начали с блока, посвященного гибким методологиям проектирования, рассказали о его важной части – создания так называемого user-centered design, а сейчас переходим к гибким методологиям разработки.

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

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

Понимайте ваших пользователей

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

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

Что вы хотите сделать к следующей пятнице? Что вы узнали за прошлую неделю?

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

Это может звучать, как чрезмерное упрощение сложного процесса разработки ПО и управления проектом, но гибкие методологии разработки строятся в первую очередь вокруг вопроса: «Что вы хотите сделать к следующей пятнице?».

[Прим. перев.: мы решили обратиться к экспертам и узнать – должна ли меняться длительность итерации при работе над проектом в зависимости от его величины? Насколько критично при работе над проектом придерживаться коротких итераций (недельной длительности)?]

Комментирует Макс Десятых (креативный директор Redmadrobot):

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

Более длинные итерации снижают скорость и вредны для бизнеса, ведь в году целых 52 недели и лишь 12 месяцев. Если учесть, что не все шаги будут верными, то лучше сделать больше шагов, чем меньше.

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

Комментирует voldar Михаил Корнеев (CTO и трекер в #tceh):

Наш #tceh — большой проект, более того — многосоставной. Мы и в онлайне, и в оффлайне. Здесь много разработки, особенно бэкенда, а параллельно – управленческих и организационных вопросов.

Итерация у нас – неделя, и мы установили это опытным путем, через шишки и тернии. Объективно, не все процессы можно уложить в неделю, но и тогда их можно разбить на под-итерации. Так что теперь типичная неделя у нас начинается с собрания всей команды, где определяются ключевые задачи: это касается как разработки, так и операционных, и маркетинговых вопросов.

Это помогает: расставить приоритеты: каждый понимает, почему так, и что он должен для этого сделать; быстро тестировать или обкатывать новые гипотезы и продукты; бывает, что и раз и навсегда отказаться от «хотелки». И, как итог, укладываться в план роста и экономики, который мы определили для себя и для инвестора.

Поэтому с октября мы используем аналогичную механику при работе с проектами, которые сидят у нас в коворкинге. Это трекшн-митинги – еженедельные собрания, где я помогаю лидерам команд с постановкой целей и задач, которые позволят быстро повлиять на ключевые метрики или избавиться от основных «узких мест» в проекте. Собственно, этот подход я изучал, помогая трекерам двух предыдущих акселераторов ФРИИ.

Процесс пошагового создания продукта, с первой версии готового к распространению и использованию, позволяет вашей команде:

• Постоянно привносить в проект новую ценность для пользователей и стейкхолдеров;
• Ускорять процесс получения фидбека – он (процесс) в данном случае короче, чем при использовании каскадной модели (в рамках которой вы переходите к новой фазе разработки только после того, как все работы на текущей стадии будут завершены);
• Понимать, какие характеристики продукта являются наиболее важными на текущей стадии разработки;
• Направлять усилия на создание продукта, который действительно будут использовать.

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

Работайте небольшими, гибкими командами

Небольшие команды (от 5 до 10 человек) часто работают более продуктивно и предсказуемо, нежели более крупные коллективы. Забудьте о человекоднях (количестве работы, выполняемой за день среднестатистическим сотрудником) и начните думать о команде, как о едином целом.

Члены хорошо подобранной команды в совокупности обладают всеми навыками, необходимыми для успешного создания ПО. Представители эффективно функционирующей команды делятся на 3 основные группы:

• Менеджер продукта (эту роль, вероятнее всего, занимает сервис-менеджер) несет ответственность обеспечение возврата вложенных инвестиций путем создания продуктов, которые приобретают популярность у пользователей.
• Менеджер поставки (он же менеджер проекта или Скрам-мастер) – эксперт в области гибких методологий разработки, ответственный за устранение отвлекающих факторов, также выступает в роли фасилитатора во время командных встреч.
• Команда – самоорганизующаяся мультидисциплинарная группа, которая создает пользовательские истории («пожелания пользователя»/user story), воплощает в жизнь видение менеджера продукта и несет ответственность за оценку собственных результатов и скорости работы.

Стремитесь к тому, чтобы члены вашей команды работали парами, так как совместная работа приносит больше пользы. Двое людей, работающие над одной задачей, будут:

• Реализовывать более эффективные решения в рамках создания продукта;
• Обеспечивать лучший контроль качества;
• Быстрее передавать знания другим членам команды.

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

Ошибайтесь – чем раньше, тем лучше

Регулярно делая небольшие релизы, вы сможете:

• Улучшить качество (кода и работы в целом);
• Увеличить прозрачность всех процессов;
• Сократить затраты выхода на рынок.

Гибкие методологии не гарантируют вам успех – вы будете продолжать ошибаться! Но эти техники позволят вам находить проблемные места как можно раньше и работать над ними. Вы сможете решать проблемы или сделать так, чтобы они не возникали, если будете:

• Выпускать релизы ПО регулярно – это позволит вам собирать обратную связь быстро и знать, что думают пользователи о продукте: если продукт не нравится аудитории, вам легче будет пошагово начать работу в новом направлении.
• Показывать ценность вашей работы спонсору, используя все те же регулярные релизы – если ваше ПО обновляется редко, вы рискуете создать сервис «слишком громоздкий, чтобы работать недостаточно хорошо», который, возможно, не стоит выпускать, но релиз которого уже не может не состояться.
• Отслеживать прогресс в работе ваших команд – если между командами существует «рассинхрон» по скорости работы даже после 4-6 спринтов, значит необходимо что-то менять (будь то неизвестные ранее осложнения или неадекватная оценка требуемых временных затрат).
• Использовать принципы разработки через тестирование (TDD, написание тестов предшествует разработке блоков, которые необходимо будет тестировать), чтобы как можно раньше выявлять проблемы с недостаточным уровнем качества (находить их, определять необходимые метрики и мониторить значения по ним на протяжении проекта).

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

Постоянно работайте над планированием

Утверждение о том, что в рамках agile-проектов планировать не нужно – миф. Свобода таких проектов не дается даром: вам приходится планировать. Просто (в отличие от других подходов) делать это нужно особым образом и постоянно.

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

Ваши команды должны планировать работы совместно или, как минимум, работать вместе на двух уровнях:

• На уровне релиза – определять и расставлять в порядке приоритетности те характеристики, которыми ваш продукт должен обладать или которые желательно реализовать до дедлайна;
• На уровне итерации – планировать, какие новые характеристики реализовывать в порядке приоритетности (если обновления слишком масштабные, чтобы точно оценить объем работы по ним или «выкатить» их за одну итерацию, в дальнейшем их необходимо разбить на ряд более мелких подзадач).

Пересматривайте ваши планы после каждого спринта и актуализируйте их на основе:

• Результатов предыдущего спринта;
• Любых новых фактов и требований.

Часто встречающиеся ситуации, на которые необходимо обратить внимание

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

1. Ваша основная команда работает не полный день или участвует в нескольких проектах: ваша команда – центральный элемент в процессе поставки продукта и вам нужна ее 100%-я отдача. Сообщите об этом менеджерам и стейкхолдеам и дайте негативную оценку сложившейся ситуации.

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

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

3. У вас нет среды для непрерывной интеграции/разработки – если ваша команда не настаивала на этом с самого начала, она, возможно, не готова для подобной работы.

Итеративная разработка ПО во многих случаях независима от возможности непрерывного развертывания и проведения автоматизированных тестов.

4. У вас в компании есть независимый отдел контроля качества. Если ваша команда будет демонстрировать результаты работы независимому отделу контроля качества, его сотрудники могут неправильно истолковать результаты работы – внедряйте культуру обеспечения качества внутри собственной команды, чтобы не прибегать к услугам сторонних групп.

Это, безусловно, не полный список, но перечисленные моменты – наиболее часто встречающиеся.

Автор:

Источник