Инкрементальный дизайн и архитектура

Перевод оригинальной статьи Рона Джеффриза «Incremental Development»

Суть подхода Big Design (детальное проектирование до начала разработки, англ. Big Design Up Front, BUFD) заключается в том, что у нас есть тщательно отобранный набор идеальных требований, и при помощи нескольких достаточно формализованных практик мы создаем красивую архитектуру для воплощения этих требований. Этот дизайн подобно солнцу освещает мир программирования, позволяя программистам без каких-либо глубоких раздумий идеально воплощать идеальную архитектуру для выполнения этих идеальных требований.

Даже если бы это было правдой (спойлер: это не правда), в большинстве случаев Big Design не смог бы удовлетворить наши потребности. Я бы сказал, он никогда не удовлетворяет наши потребности, и уж точно не в случае, который волнует меня больше всего —

В случае работающего продукта

За свою полувековую карьеру в разработке ПО я узнал многое — и самостоятельно, и работая с командами. Если бы я мог вернуться в прошлое и вынести только одну мысль, она была бы такой:

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

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

Поэтому для меня главный вопрос в разработке звучит так: как мы можем поставлять программный продукт каждую неделю? И в свете этого становится ясно, что концепция Big Design, как я его определяю, просто не позволит с этим справиться. Мы не можем создать хороший дизайн и выполнить все требования за две недели. Поэтому Big Design в этом варианте не подойдет.

Так как же мы можем это сделать?

Нам нужен детально проработанная архитектура

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

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

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

Впрочем, кое-что из того, что говорят эти люди — чистая правда:

Нам абсолютно необходима хорошо проработанная архитектура для большой и сложной проблемы и решения.

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

Инкрементальная разработка и дизайн

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

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

В ходе второй итерации мы делаем так, чтобы фичи, как бы мало их ни было, действительно работали — по крайней мере, большинство фич.

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

Что может пойти не так?

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

Очевидно, что изображенный выше проект обречен. Его дизайн все менее и менее работоспособен, и в конце выглядит совершенно размытым. Мы определенно провалили проект.

Сделайте все правильно!

Фокус вот в чем.

  1. Легко иметь хороший дизайн, когда еще нет фич;
  2. Когда мы разработаем следующую фичу, мы портим наш хороший дизайн:
  3. Но поскольку мы добавили всего одну фичу, мы не слишком сильно его испортили;
  4. Прежде чем объявлять фичу готовой, мы исправляем дизайн;
  5. И все сначала.

Продукт развивается. Дизайн и архитектура развиваются. И дизайн остается хорошим.

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

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

Но не будем ли мы продвигаться слишком медленно в таком случае? Не быстрее ли будет с Big Design?

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

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

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

Вы сами выбираете, сколько кода поставлять и когда. Вы сами определяете, какой анализ и какой дизайн должны быть сделаны перед стартом разработки и далее на каждом этапе. Это все решаете вы.

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

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

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *