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

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

Мы, Moroz Team, в предыдущих статьях обозначили основные проблемы бизнеса в разработке ПО и наметили пути решения проблем с компетенцией команды. Пришло время разобраться с процессом.

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

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

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

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

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

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

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

1. Начальная стадия (Inception)

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

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

2. Развитие (Elaboration)

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

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

3. Конструирование (Construction)

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

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

4. Внедрение (Transition)

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

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

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

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

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

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

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

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

Аналитик:

— анализ предметной области

— сбор и формирование требований

— документирование требований (ведение базы знаний)

Владелец продукта:

— разработка видения продукта

— управление бэклогом продукта

— планирование итераций (спринтов)

Разработчик:

— проектирование программных решений

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

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

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

Аналитик:

— модель бизнес-процессов

— модель предметной области

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

Владелец продукта:

— видение

— бэклог

— план итерации (спринта)

Разработчик:

— программное решение (как результат проектирования)

— текст программы (программный код)

— версия системы (сборка)

— релиз

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

А если хотите узнать больше о жизни и работе в айтишечке, подписывайтесь и читайте другие статьи:

— Почему в ИТ столько необразованных? Кадровые проблемы в разработке ПО и как их решить

— Как решить ваши проблемы бизнеса в разработке ПО

— Как получить ответ на вопрос «Когда будет готово?» быстро и бесплатно

За анонсами новых статей можете следить в нашем Telegram-канале.