Григорий Петров: Гибкие методологии разработки

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

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

• Нулевая цена копирования, молодость отрасли и научной дисциплины затрудняют предварительное планирование. Если какой-то код уже написан — его не пишут второй раз, основываясь на предыдущем опыте. Его просто копируют. А пишут каждый раз новое — то, что до этого никем не создавалось.
• Проблема сложности порождает скрытые риски, которые очень трудно предсказать до начала проекта. Выбранная платформа, фреймворк или библиотека могут непредсказуемо себя повести ближе к середине разработки, просто потому, что до этого никто не использовал их таким способом. Ведь если бы использовали — никто не начал бы писать код, просто взяли бы готовый.
• Молодость отрасли влияет не только на трудности предварительного технического проектирования, но и на понимание заказчиком того, что должно получиться в финале. Всплывающие по ходу разработки подробности могут полностью изменить запланированную архитектуру и функциональность, обеспечивая срыв сроков и выход за рамки бюджета разработки.

Гибкие методологии как инструмент борьбы с неизвестностью

На мой взгляд, основное назначение гибких методологий — это борьба с неизвестностью путем изменения планов. Слово «гибкость» означает, что при встрече с неведомым планы могут и будут меняться, причем заранее неизвестным образом. Именно в этом, а не в итерациях, ключевое отличие Agile от Waterfall. В случае Waterfall планы также могут меняться, но большинство таких изменений оцениваются и прорабатываются заранее, незапланированное изменение в Waterfall это форс-мажор. В случае же Agile мы ввязываемся в боевые действия как можно раньше, чтобы сориентироваться на месте, получить больше информации и адаптировать планы. Для Agile незапланированные изменения это нормальный рабочий процесс.

Agile — не «серебряная пуля». Плата за гибкость планов — их минимизация в начале разработки, невозможность точно оценить сроки и риски. Разработка программного обеспечения — большая область, и не для всех задач такой обмен принесет пользу. Для разработки типовых веб-сайтов, бизнес-автоматизации «под ключ», драйверов по спецификации и многих других задач Waterfall намного предпочтительнее. Возможность с высокой точностью оценить сроки и бюджет играет ключевую роль для многих проектов.

Зачем нужны итерации?

Частичный отказ от предварительного планирования и изменение планов по ходу работы — это очень общая концепция. Для ее воплощения в жизнь большинство Agile методологий используют «итерации», разбивая работу на изолированные промежутки от 1 до 4 недель. На самом деле это хитрый социально-психологический трюк, который сам по себе никакой пользы не несет, но позволяет удобно организовывать работу обычных команд.

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

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

Что же такого делают итерации?

• Понятная и достижимая цель в конце. Важно не просто сказать «приступаем к очередному двухнедельному этапу работы». Важно поставить достижимую цель, к которой будет стремиться команда. И результат, который в конце итерации неизбежно будут показывать внешнему или внутреннему заказчику. Наличие цели мотивирует, дисциплинирует и организует команду — начинают работать инстинкты «охота за достижениями» и «нежелание подставлять стаю».
• Защита от «рыскающего» курса разработки. Гибкость Agile не означает, что концепции должны меняться каждый день в соответствии с тем, что заказчик прочитал на хабре или услышал на конференции. Молодость отрасли провоцирует фонтанирующих идеями заказчиков постоянно менять задачи. Создается иллюзия «простоты внесения изменений». Постоянные случайные изменения увеличивают сложность продукта, что очень быстро приводит к коллапсу. Предварительная договоренность о невнесении новых требований во время итерации дисциплинирует заказчика и защищает разрабатываемый продукт.
• Фиксированная продолжительность итерации тренирует разработчиков оценивать сроки. Как показывает практика, через несколько месяцев работы у команды появляются точные ощущения «влезет» какая-то задача в итерацию или «не влезет». При принятии задачи на итерацию у разработчиков возникает ощущение ответственности перед ними самими. Достаточно нескольких неудачных демонстраций заказчику, чтобы выработать привычку вдумчиво и аккуратно оценивать сроки. Очень хорошо помогает практика в конце итерации кидать жребий, кому из разработчиков выпадет высокая честь вместе с Project Manager’ом показывать результаты работы высокому начальству. Перспектива лично рассказывать о провале благотворно влияет на оценку сроков и общую адекватность при работе с заказчиками.

Использование итераций по назначению — хороший способ применения Agile методологий. Верно и обратное: карго культ и следование букве какой-нибудь книжки «SCRUM для кофейников за 24 часа» может не улучшить, а, наоборот, ухудшить работу команды. Гибкие методологии и итерации — всего лишь инструменты. Которые подходят для одних задач и не подходят для других. Знание их сильных и слабых сторон позволяют выбирать лучший подход к организации работы в конкретной команде для конкретных задач, облегчать разработку, эффективно бороться со сложностью и делать хороший софт.