Сейчас много говорят о гибких подходах к разработке программного обеспечения. И даже пытаются внедрить для выполнения гос. контрактов. С другой стороны, много компаний спотыкаются на этих подходах. И хотя в компаниях делают что нужно, и даже Scrum-мастер в них есть, программный Продукт почему-то перестает развиваться, и появляется много задач на исправление дефектов. Давайте разберемся почему так происходит.

Как дошли до жизни такой

Гибкие подходы к разработке программного обеспечения, начали применяться в России с 2002 года, после выхода книжек Кента Бека «Экстремальное программирование» (XP). Но, настоящую популярность принес Scrum, во главе со Scrum Alliance и сертификацией Scrum-мастеров. Всем понравилась простота применения, игры в планирование, геймификация ретроспектив, и очевидные ежедневные планерки, которые ранее применялись на заводах и в конструкторских бюро. И все уверовали в то, что можно меньше писать документации и больше общаться, а код сам по себе создастся качественным.

В результате, получилась интересная штука. Благодаря хорошей пропаганде (сертификация Scrum-мастера стоит не маленьких денег) под Agile-процессом разработки ПО начали понимать Scrum и наоборот. Но, зачастую при внедрении Scrum, и практик улучшающих общение, забыли об инженерных техниках обеспечивающих качественную разработку ПО.

В итоге, Agile превратился в карго-культ в который верят. А программный продукт, как не разрабатывался хорошим, так и не разрабатывается.

Взгляд назад

Давайте посмотрим внимательней на историю движения Agility применительно к разработке ПО.

Основным конфликтом который решался был следующий:

Для того чтобы Заказчик был доволен, нужно создать качественное и полезное программное обеспечение. Для создания качественного Продукта, нужно не менять требования в процессе разработки ПО. И одновременно с этим, чтобы создать полезный Продукт, нужно корректировать требования к Продукту, адаптировать под потребности. Нельзя одновременно менять требования и не менять требования.

Но как же тогда быть? Когда нельзя, но очень хочется, то можно. И авторы XP задумались: как бы сделать так, чтобы требования можно было менять (корректировать), а продукт был качественным?

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

Таким образом, все инженерные техники XP увязывались в единую систему:

• чтобы реализовать новые требования нужен рефакторинг существующего кода;
• чтобы рефакторинг ничего не сломал — нужны модульные тесты;
• чтобы модульные тесты всегда срабатывали — одни должны запускаться каждый день на интеграционном сервере;
• Чтобы тесты не забывали писать — их нужно писать ДО кода (техника Test Driven Develpment (TDD));
• Чтобы тесты было не лень писать — нужно это делать вдвоем.

С другой стороны, необходимо не забывать и о Заказчике, и о том чтобы вовремя знать что он задумал и держать его в курсе. А также держать в курсе и всю команду:

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

Как следствие, если мы из всей системы практик вынем хоть один кирпич, то система рухнет и похоронит Продукт. Что впрочем и получается.

Что имеем

Как результат неполного применения всех техник лежащих в основе появились мифы описанные в статье Hayim Makabee. Конец Agile: смерть от примитивизма. //Практика проектирования систем.-2015.

• Миф 1. Хорошие проектные решения рождаются при реализации User Stories.
• Миф 2. Технический долг всегда можно оплатить в будущем
• Миф 3. Постоянный рефакторинг — это эффективный способ создания кода
• Миф 4. Гибкость может быть обеспечена за счет следования Agile процессу.

Но я думаю, что и эти мифы возникли не на пустом месте. Корневая причина этих мифов в том что, вместо применения полноценного процесса XP, который и был базой для Agile-подхода, все пользуются Scrum- коммуникационным фреймворком, который просто не покрывает всех потребностей разработки программного обеспечения.

Итог

Никакую практику нельзя применять бездумно, просто потому, что это модно или так сказал ОН. Всегда! Всегда нужно думать наперед.

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

Хорошая техника «Парное программирование», обеспечивает думание стратегически на лету. При парном программировании один ВСЕГДА будет «навигатором» — стратегом (без клавиатуры), а второй «пилотом» за клавиатурой. Это позволяет охватывать сразу весь код в общем, и принимать решения по месту.

В Методологии XP нигде не написано «Не пишите документацию». Коммуникации важнее документации, но если документация является способом коммуникации, то система Wiki обеспечивает создание этой документации ровно в том объеме в котором надо. Что, в свою очередь, улучшает синхронизацию пары (пилот-навигатор) и создание качественного кода за счет проработки и обсуждения архитектуры.

Также, в практиках Экстремального Программирования нигде не написано «делайте технический долг и сделаете заказчика счастливым», там написано «делайте непрерывный рефакторинг, тесты защитят вас. да прибудет с вами Сила». Это значит что при завершении КАЖДОЙ задачи не должно оставаться технического долга. Совсем.

В Методологии XP, также, не написано «Не проектируйте всю систему наперед». Там написано «Будьте готовы к изменениям», это значит, что необходимо делать архитектуру в меру гибкой, и одновременно с этим в меру достаточной для реализации известного объема работ и демонстрации частого результата Заказчику.

Заключение

1. Поклонение карго-культу и механистическое выполнение действий не даст нужного эффекта. А может сделать еще хуже.
2. Если вы не применяете хоть одну из техник XP — вы не построите продукт с Agile. Он разрушится по пути.
3. У каждого участника команды должно быть понимание зачем нужна та или иная техника. ибо смотри п.1
4. Никогда не останавливайтесь на достигнутом, всегда можно что-то улучшить. Не поддавайтесь инерции.

Литература

1. Экстремальное программирование. Кент Бек
2. Мифический человеко — месяц или Как создаются программные системы. Фредерик Брукс
3. Профессиональная разработка программного обеспечения. Макконнелл С.
4. Цель. Элия М.Голдратт, Джефф Кокс

Послесловие

Q: А бывают ли проекты по Scrum успешными?
A: Только если они делаются с применением практик XP. Или в случае если весь проект выполняется менее чем за 1 месяц под ключ.