Роберт Мартин - Чистый Agile. Основы гибкости

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

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

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

Возможно ли такое, что программа технически готова к развертыванию в конце каждой недели или двух?

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

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

Стабильная производительность

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

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

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

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

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

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

Отчаявшись, менеджеры спросят разработчиков, что можно сделать для повышения производительности. У разработчиков уже готов ответ. Уж они-то понимают, что делать. Они только и ждут того, чтобы их спросили.

И они отвечают: «Надо все переделывать».

Представьте, в какой ужас приходят менеджеры. Сколько денег и времени было вложено в проект! И что мы видим? Разработчики советуют выбросить все наработки и начать проект с чистого листа!

И как считаете, верит ли руководство разработчикам, когда те обещают, что «в этот раз будет все по-другому»? Конечно, нет! Они ж не дураки, чтобы поверить этому. Но что же им теперь делать? Производительность уже и так ниже плинтуса. Такими темпами работа не может продолжаться. Поэтому после многочисленных стенаний они соглашаются на рефакторинг.