Автор: Майкл Болтон (Michael Bolton)
Оригинал статьи
Перевод: Ольга Алифанова

В предыдущей части мы рассмотрели, чего хочет бизнес: продукт с высокой ценностью и низкими затратами на разработку. На этот раз мы посмотрим на ситуацию под немного другим углом: как бизнес получает то, чего он хочет?

Существует некий универсальный цикл разработки. Независимо от того, какую модель разработки вы используете, она, скорее всего, выглядит примерно так:

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

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

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

Мы не хотим получить ошибки и во время тестирования, поэтому занимаемся обширным и тяжеловесным планированием тестирования, сосредотачиваясь на документации и артефактах. Мы не хотим, чтобы умы тестировщиков были «испорчены» избыточным знанием о том, чем занимаются разработчики, поэтому мы сохраняем их «независимыми» — по сути, изолируя тестировщиков и процесс тест-планирования от разработчиков.

(Напоминаю: это утрированная, карикатурная модель.)

Затем, когда почти весь продукт уже готов, тестировщики начинают его изучать — и поскольку тестирование было отложено до «фазы тестирования», которая наступает только после завершения «фазы программирования», мы с удивлением и ужасом обнаруживаем множество проблем при первом же реальном взаимодействии с продуктом.

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

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

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

Всё это — типичная, хотя и слегка карикатурная, история разработки, получившая название «водопадная» модель (Waterfall). Интересно, что в статье Уинстона Ройса “Managing the Development of Large Software Systems”, в которой впервые была описана водопадная модель, само слово «водопад» не упоминается, и сам Ройс подчёркивал, что разработка на самом деле так не происходит. Но, по-видимому, кто-то увидел наглядную диаграмму и подумал: «Прекрасно, прекрасно!» — и вот так родилась водопадная модель.

В 2001 году Манифест гибкой разработки программного обеспечения (Manifesto for Agile Software Development) предложил альтернативный подход, обозначив четыре группы ценностей:

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

• Людей и взаимодействие — больше, чем процессы и инструменты
• Работающее программное обеспечение — больше, чем исчерпывающую документацию
• Сотрудничество с заказчиком — больше, чем согласование условий контракта
• Реагирование на изменения — больше, чем следование изначальному плану

То есть, хотя мы и признаём ценность элементов справа, мы больше ценим то, что слева.

Ценности были подробнее раскрыты через двенадцать принципов:

• Наша высшая цель — удовлетворить заказчика за счёт ранней и непрерывной поставки ценного программного обеспечения.
• Приветствуйте изменяющиеся требования, даже на поздних стадиях разработки. Гибкие процессы превращают изменения в конкурентное преимущество заказчика.
• Доставляйте работающее программное обеспечение часто — от пары недель до пары месяцев, отдавая предпочтение более короткому циклу.
• Бизнес и разработчики должны работать вместе ежедневно на протяжении всего проекта.
• Стройте проекты вокруг мотивированных людей. Дайте им нужное окружение и поддержку и доверьтесь им, что они выполнят работу.
• Самый эффективный способ передачи информации в команде разработки — личное общение.
• Работоспособное программное обеспечение — основной показатель прогресса.
• Гибкие процессы поддерживают устойчивую разработку. Спонсоры, разработчики и пользователи должны быть в состоянии поддерживать постоянный темп неограниченное время.
• Постоянное внимание к техническому совершенству и хорошему дизайну увеличивает гибкость.
• Простота — искусство максимального сокращения ненужной работы — крайне важна.
• Лучшие архитектуры, требования и дизайны рождаются в самоорганизующихся командах.
• Команда должна регулярно анализировать, как стать эффективнее, и соответственно настраивать и корректировать своё поведение.

На практике в Agile было два основных принципа, контрастирующих с водопадной моделью. Первый — вместо «сначала построить почти всё» предлагалось «сначала построить почти ничего». Второй — строить не «как получится», а чисто и просто, с расчётом на будущие изменения. (Кстати, одна из первых книг, ставших классикой гибкой разработки — Extreme Programming Explained Кента Бека — имела подзаголовок «Прими изменения».)

По-моему, все эти принципы — по крайней мере на первый взгляд — вполне разумные и достойные. Манифест и Принципы предлагали гораздо более прагматичный и человекоориентированный подход, чем преобладавшие на тот момент модели разработки программного обеспечения.

Мы можем обобщить Принципы и на их основе вывести идеи, которые лежат в основе всех аспектов разработки:

• Часто поставляйте готовый продукт. Это позволяет команде и заказчику регулярно оценивать продукт и надёжно внедрять его.
• Развивайте мастерство. Как говорится в Принципах, «непрерывное внимание к техническому совершенству и хорошему дизайну увеличивает гибкость».
• Избегайте чрезмерной формализации. Манифест ценит «работающее программное обеспечение больше, чем исчерпывающую документацию». Формальные процессы дороги и часто избыточны — но когда они действительно нужны, мы их применяем. Ведь Манифест прямо признаёт ценность «правой стороны».
• Применяйте подходящие эвристики. Хотя это напрямую не сказано в Манифесте и Принципах, идея прослеживается повсюду.
• Соблюдайте устойчивый темп. Если работы слишком много — для всей команды или для отдельного участника — темп будет неустойчивым.
• Разрабатывайте и используйте инструменты. И это тоже прямо не заявлено в Манифесте, но инструментальная поддержка — нормальная и повседневная часть разработки и тестирования.
• Сотрудничайте между ролями. Это помогает использовать весь спектр экспертизы внутри команды. Как рекомендует Манифест — «цените взаимодействие между людьми больше, чем процессы и инструменты».

Вот таким образом выстраивается цикл разработки, в центре которого лежат эти общие принципы.

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

И всё же, похоже, аджилисты кое-что упустили...

А где же тестирование?

Увы, ни в Манифесте, ни в Принципах нет ни слова о тестировании; не упоминаются ошибки, критическое мышление, возможность проблем или неудач. Речь идёт лишь о ценном и работающем программном обеспечении: «Работающее ПО — главный показатель прогресса». Но… а как мы определяем, что оно работает? Хорошо, если продукт попадает к заказчику как можно скорее — но разве не стоит подумать о том, какие проблемы можно было бы выявить до поставки, чтобы не тратить время клиента зря?

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

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

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

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

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

Обсудить в форуме