Операция «Ы»: просто о процессе разработки ПО на примере строительства

Строительство и разработка ПО очень сильно похожи между собой. У каждого из них есть цель по созданию некоторого результата. Есть ограничения по срокам и бюджету. И в каждом случае для достижения результата применяется некоторый подход.

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

И в разработке, и в строительстве присутствуют следующие части-кирпичики процесса:

• стадии (крупные этапы)
• направления деятельности (или умным словом дисциплины)
• роли исполнителей, специалистов
• задачи, которые выполняют исполнители
• результаты деятельности (или ещё одним умным словом артефакты)

Смешаем все кирпичи в кучу, чтобы понять, как они работают вместе.

Наша цель — создать продукт, который работает. В заданном объёме, в заданный срок и выделенный бюджет. Чтобы это сделать, нам нужно:

1. разбить весь процесс на несколько стадий;
2. понять, какие направления деятельности нам нужны на этом проекте и на каждом из его этапов;
3. определить, каких специалистов для каждого направления нужно привлечь для выполнения всей необходимой работы;
4. на каждом этапе определить набор задач, выполняемых разными специалистами;
5. какие результаты мы должны получить от выполнения каждой задачи, чтобы двигаться дальше и достичь цели.

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

Стадиями или фазами являются значительные периоды проекта. Каждый период заканчивается контрольной точкой для принятия важных решений. Расскажу о стадиях жизненного цикла проекта на примере методологии UP (Unified Process).

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

Т.е. заказчик и исполнитель должны определить, для кого они делают дом, каким он должен быть, и каким способом будут его строить. Например, будут ли его строить с нуля или распечатают готовые блоки на 3D-принтере. Если договорились — проект запущен.

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

В терминах стройки исполнитель на этой стадии согласует с заказчиком смету расходов (какие потребуются материалы, какие будут задействованы специалисты), архитектуру самого дома и примерный график строительства.

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

Здесь начинается непосредственное строительство: от фундамента до отделочных работ. В итоге должен получиться готовый дом.

Стадия внедрения — последний шаг, необходимый для поставки готового решения конечному пользователю. Здесь выполняются последние исправления ошибок, происходит развёртывание системы и др. подготовительные работы для демонстрации готового решения. Результатом этой стадии будет подтверждение, что ожидания пользователей оправданы, продукт принят клиентом. Или произойдёт возврат на стадию конструирования.

В терминах строительства это момент приёмки готового дома заказчиком. Он проверяет, что все работы выполнены, смета соблюдена и сам он удовлетворён тем, что получилось.

Основные направления в разработке ПО:

• Бизнес-моделирование
• Требования
• Проектирование
• Реализация
• Тестирование
• Развёртывание
• Управление проектом
• Окружение
• Маркетинг и сопровождение

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

В строительстве существуют не только строители. Также и в разработке есть не только разработчики. Вот некоторые из основных ролей, которые есть в процессе разработки:

• Аналитик
• Архитектор
• Владелец продукта (product manager или product owner)
• Дизайнер пользовательского интерфейса (UI) или пользовательского опыта (UX)
• Инженер DevOps
• Маркетолог
• Методист процесса (например, scrum-мастер)
• Разработчик
• Руководитель проекта (project manager)
• Сотрудник поддержки
• Тестировщик (QA-инженер)
• Технический писатель

Отличие роли от должности — один человек может играть несколько ролей. Например, если на вашем проекте единственный исполнитель, он просто играет сразу все роли. Также существуют кроссфункциональные команды. Это значит, что роли между ними не определены конкретно — все умеют заниматься всем и занимаются этим.

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

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

Аналитик:
— анализ предметной области
— сбор и формирование требований
— документирование требований (ведение базы знаний)

Владелец продукта:
— разработка видения продукта
— управление бэклогом продукта
— планирование итераций (спринтов)

Разработчик:
— проектирование программных решений
— их реализация и отладка (преобразование в программный код)

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

Результатом каждой задачи является некоторый артефакт. Вот несколько примеров артефактов, которые создают и за которые отвечают уже привычные нам роли:

Аналитик:
— модель бизнес-процессов
— модель предметной области
— спецификация требований (например, в виде технического задания)

Владелец продукта:
— видение
— бэклог
— план итерации (спринта)

Разработчик:
— программное решение (как результат проектирования)
— текст программы (программный код)
— версия системы (сборка)
— релиз

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

Отсутствие процесса — значит отсутствие правил и порядка. Чаще это связано с хаосом и анархией, с отсутствием понимания «зачем мы это делаем». В любой деятельности это не приведёт к достижению результатов.

Вот несколько примеров, когда отсутствие процесса ни к чему хорошему не приводит:

1. Пропуск важных стадий разработки — упущение деталей на первоначальных этапах приводит к многократному преумножению проблем на следующих этапах. Часто приводит к превышению ресурсов, бюджета и к срыву сроков
2. Нечётко определены обязанности и распределены роли — неадекватное распределение кадровых ресурсов, дублирование одной и той же работы, выгорание и снижение мотивации («меня не ценят, я же всё делаю»)
3. Отсутствие работ по одному или нескольким направлениям портит работу всем остальным. Например, при отсутствии тестирования страдает качество продукта, повышается количество ошибок, снижается возвращаемость пользователей, а за ним и выручка

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

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

Чтобы понять, насколько вы способны изобретать велосипед и делать свой процесс, обратимся к понятию «сю-ха-ри».

Если вы находитесь на стадии «Сю» в разработке и пока не знаете нюансов, стоит пока повторять за профессионалами. Благо, существует уже почти вековая история развития индустрии.

На стадии «Ха» вы можете поэкспериментировать с инструментами, методиками и адаптировать процесс под себя. Применить новое для себя наиболее выгодным способом и отбросить ненужное, что не работает на ваши показатели успеха.

На стадии «Ри» вы уже можете делать процесс по своим правилам и обучать ему других.

Важно не перескакивать эти стадии. Совершенствоваться постепенно и осознанно. И не останавливаться.

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

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

Не старайтесь сразу же сделать ваш процесс идеальным. Начните с малого и постоянно совершенствуйтесь. Следуйте по ступенькам СЮ-ХА-РИ. Адаптируйте процесс под себя и создавайте новые правила, которым станут подражать другие.

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

Если вам не терпится опробовать внедрение или устранение узких мест в вашем процессе разработки на практике, приходите к нам в Moroz Team. Поможем, чем сможем)