Методологии разработки ПО

Здравствуйте. На последних двух собеседованиях меня спрашивали про методологии. Это не самый важный или сложный вопрос, но иметь шпаргалку-ответ будет неплохо. В этой статье я попытаюсь дать понятие, что такое методология разработки и сравнить те, с которыми встречался лично или о которых спрашивали. Методология разработки ПО – это процесс описания того, как определенный продукт будет разрабатываться, то есть один из способов организации коллективной разработки. Существует множество разных моделей такого процесса, каждая из которых описывает свой подход и нельзя сказать, что среди них выделяется одна, которую нужно использовать в каждом проекте, всё сугубо ситуативно. Предлагаю рассмотреть подробнее три из них.

Waterfal

Waterfall (каскадная, водопадная) – одна из самых старых методологий и подразумевает строгое последовательное выполнение всех этапов, каждый из которых должен завершиться перед началом следующего. То есть переход на следующий этап означает полное завершение работ на предыдущем. На картинке показано, что сначала мы анализируем задачу (документируем задания, обговариваем сложности), потом происходит дизайн (на этом этапе формируется структура проекта), дальше кодинг и тестирование. Возвраты на следующие этапы не предусмотрены. Использовать такую систему рекомендуется в небольших проектах, где известны заранее требования и мала вероятность, что они будут меняться. Преимущества:

• Полная и согласованная документация на каждом этапе;
• Простота использования;
• Стабильные требования.
• Бюджет и дедлайны заранее определены

Недостатки:

• Большое количество документации;
• Не очень гибкая система;
• Клиент не может ознакомиться с демо-версией продукта;
• Нет возможности вернуться на шаг назад.

Scrum

Scrum – система разработки ПО, основана на делении всего процесса на итерации, где в конце каждой из них команда готова предоставить демо-версию продукта. На картинке видно, что команда проходит все этапы разработки параллельно, что позволяет в конце каждой итерации иметь готовую часть проекта. Постараюсь коротко объяснить простыми словами суть методологии, но тут очень много терминов. Думаю, самое важное понять суть, а термины уже запомнятся с опытом. Вся разработка делится на спринты (зачастую 2-3 недели). Есть backlog(список задач) для всего периода разработки и для каждого спринта отдельно. Каждая задача имеет свой story point(оценку сложности). У каждого участника процесса есть своя роль:

• Scrum-команда – это команда работающая над проектом(разработчики, тестеры, дизайнеры).
• Scrum-мастер – человек, который следит, чтобы соблюдались принципы скрама.
• Product owner – заказчик.

Так как в этой системе ставка сделана на общение, то присутствует большое количество митингов:

• Stand-up – короткий митинг, проводится каждый день, принимают участие все члены команды и каждый участник отвечает на 3 вопроса: что делал? Что будет делать? И какие есть блокеры?
• Плэннинг – проводится в начале спринта и на этом собрании определяют какие задачи должны быть выполнены за следующий спринт.
• Ретроспектива – проводится в конце спринта и её суть – выяснить, что было сделано хорошо и что можно было улучшить.

Преимущества:

• Заказчик может наблюдать результат в процессе разработки.
• Ежедневный контроль над процессом разработки.
• Возможность вносить коррективы во время разработки.
• Налаженные коммуникации со всеми членами команды.
• Малое количество документации.

Недостатки:

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

Kanban

Канбан – система, построенная на визуализации процесса выполнения задач команды. Основная идея в этой системе уменьшать количество задач выполняющихся в данный момент (в колонке «in progress»).В скраме ориентация команды на успешное выполнение спринтов, в Канбане на первом месте задачи. Хорош для проектов которые в стадии поддержки где основной функционал уже разработан и остались минимальные доработки и багофиксинг. В канбане задачи сдаются индивидуально. Задача независимо от других задач проходит по всем этапам на доске и как только она выполнена её можно показать заказчику. Канбан доска состоит из колонок, каждая из которых это отдельный процесс разработки. На некоторые столбцы(например, in progress) вводят ограничения по количеству тасок, которые там могут находиться. Это помогает легко и быстро находить проблемные места в распределении задач. На картинке пример самой просто такой доски. Количество колонок и названия могут меняться, назову самые распространенные:

• To do – список задач, которые надо сделать
• In progress – задачи над которыми ведется работа в данный момент
• Code review – задачи, которые сделаны и отправлены на ревью
• In testing – задачи, готовые к тестированию
• Done – сделанные задачи.

Преимущества:

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

Недостатки:

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

В заключение о методологии разработки ПО

По моему мнению, основательно разбираться в методологиях разработки ПО нужно людям, которые занимают управленческие должности или стремятся к ним, но понимать хотя бы основы желательно всем. Это неотъемлемая часть процесса разработки и используется не только в IT-сфере. Спасибо, что уделили время чтению моей статьи, надеюсь она была вам полезной. Я старался описать только ключевые моменты максимально доступно и коротко, так что статья не является исчерпывающей. Буду рад услышать ваше мнение о ней и ответить на ваши вопросы. Всем добра!