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

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

Начинающим на заметку: модели, методологии и всеобщая путаница

Важное уточнение для начала: есть отдельно модели разработки ПО и отдельно — методологии этой самой разработки. Модели предсказывают будущее поведение системы. Методологии нужны, чтобы система работала, причем так, как нужно. Путать модели и методологии разработки ПО — святое дело каждого ИТ-новичка, поэтому грубой ошибкой это не считается. И все же, модели – это классическая каскадная Waterfall, с ее линейностью, четкой постановкой целей для каждого этапа и строгим контролем за сроками. Модели — это Spiral, с ее фокусировкой на раннем выявлении и уменьшении проектных рисков. Разработка по Spiral начинается в небольшом масштабе, сначала решаются локальные задачи, а потом - более комплексные. И наконец, модели — это IID, в которой жизненный цикл проекта разбивается на последовательность итераций, каждая из которых напоминает «мини-проект». В общем, модель — это то, что описывает процесс разработки ПО. А вот методологии — это системы контроля, оценки и мониторинга работы над поставленными задачами. Методологии — это кнут и пряник современного разлива, которые нужны для контроля каждого звена процесса разработки. Их выбирают, исходя из направления проекта, его бюджета и сроков реализации конечного продукта. Более того, методологии могут подбирать исходя из темперамента руководителя проекта и его команды. Даже исходя из философии компании или заказчика. Давайте рассмотрим самые популярные методологии.

1. Методология «Scrum»

Scrum — гибкий метод управления проектами. В его основе лежат «спринты» — короткие итерации, строго ограниченные по времени (как правило, 2-4 недели). Продолжительность совещаний при этом сводится к минимуму, но увеличивается их частота. Каждый спринт состоит из списка задач до конца итерации, и у каждой из них свой “вес”. Во время совещаний команда обсуждает, кто что сделал, что собирается сделать и какие есть проблемы. Для планирования в Scrum используют журнал спринтов. В таком подходе в команде часто появляется Scrum-мастер, который налаживает непрерывную работу всей команды, создавая для нее комфортные условия. Также на проекте появляется роль Product Owner — руководителя разработки, человека, который следит за продуктом и выступает главным звеном между запросом клиента и результатом команды.

Плюсы:

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

Минусы:

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

Кому это подойдет:

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

2. Методология «Kanban»

Важнейшая особенность Kanban — визуализация жизненного цикла проекта. Создаются колонки выполнения задач, которые сдаются индивидуально. Колонки обозначены маркерами типа: To do, In progress, Code review, In testing, Done (название колонок, конечно же, может меняться). Цель каждого участника команды — уменьшать количество задач в первой колонке. Подход Kanban наглядный и помогает понять, где возникла проблема. Структуру по Kanban не определяют окончательно и бесповоротно: в зависимости от специфики проекта можно добавить импровизированные колонки. Например, некоторые команды используют систему, в которой нужно определить критерии готовности задачи перед ее выполнением. Тогда добавляют две колонки — specify (уточнить параметры) и execute (взяться за работу).

Плюсы:

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

Минусы:

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

Кому это подойдет:

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

3. Методология «RUP»

Методология RUP использует итеративную модель разработки. В конце каждой итерации (которая занимает от 2 до 6 недель) команда должна достичь запланированных целей и получить временную, но работающую версию проекта. RUP предполагает разделение проекта на четыре фазы, в каждой из которых ведется работа над новым поколением продукта: фазу начала проекта, уточнение, построение и внедрение. По окончании фазы вводится маркер завершения этапа (Project Milestone). Project Milestone можно считать моментом, когда команда дает оценку достигнутым результатам. В итоге методология подразумевает, что на первом этапе выпускаются основные функции, а на последующих фазах добавляются дополнения.

Плюсы:

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

Минусы:

• довольно сложный метод, который трудно внедрить при небольшой команде или компании;
• завязанность на способности экспертов ставить задачи;
• нуждается в излишнем документировании требований.

Кому это подойдет:

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

Методологий много, тренд один

Кроме бесспорно популярных Scrum и Kanban, которые основываются на принципах гибкости под общим названием «Agile», как и кроме живучей итерационной RUP, компании работают со множеством вариациями методологий. Кому-то ближе экстремальное программирование и принятие самых быстрых и простых решений, кому-то — разработка через тестирование, а кто-то отдает предпочтение быстрой разработке приложений (RAD). При этом главный и безусловный тренд — использование нескольких методологий одновременно. Или даже объединение моделей и методологий в уникальную систему контроля. Современные компании стремятся устранить бюрократические преграды, создать атмосферу общей командной работы внутри организации, не перекладывая ответственность между подразделениями и блоками. По данным отчета Scrumalliance, от 70% ИT-компаний используют Scrum. Среди них такие гиганты как Google, Amazon, Salesforce, Microsoft, Adobe. Стартапы и молодые проекты более склонны к Kanban, но ее также использует Toyota и, например, игровики из Wargaming. Более скромные СНГ-шные Prom.ua, Bigl.ua, Kabanchik.ua используют методологии Scrum и Kanban одновременно, но для разных задач. Scrum — как инструмент планирования, Kanban — для мониторинга хода работ. Что касается RUP, ее чаще всего практикуют западные компании с 50-200 сотрудниками и доходом 1-10 миллионов долларов. Но при этом IBM изменила RUP, чтобы приблизиться к принципам гибкости Agile, выпустив методологию OpenUP — «RUP, только гибкий». Та самая хваленая гибкость Agile сейчас управляет ИТ-сферой. Это не просто мода наших дней — это до сих пор инновационно, и это реально работает во многих крупных компаниях. По Agile работают в Кремниевой долине, ее использует Facebook и Uber.

В сухом остатке

Каждому проекту – своя методология разработки ПО, в зависимости от команды, финансирования, сроков и требований заказчика. Универсальной управленческой технологии нет: даже бешено популярный Agile не может обеспечить лучший подход к процессу разработки. Поэтому методологию выбирают тщательно, а иногда даже принципиально. Настолько, что по ней можно делать выводы о самой компании или о заказчиках. Методологии миксуют, дополняют моделями и адаптируют под себя. Настолько, что порождают новые подходы. Хотя в итоге управленческое царство остается в руках Scrum и Kanban, с неожиданными вкраплениями модели Waterfall или итерационной RUP.