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

9 апр. 2019 г. 4 min read

Перевод оригинальной статьи Рона Джеффриза «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, на старте у нас есть огромное преимущество по времени, часто целые месяцы.

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

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

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

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

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

Great! Next, complete checkout for full access to Scrum.ru Consulting.
Welcome back! You've successfully signed in.
You've successfully subscribed to Scrum.ru Consulting.
Success! Your account is fully activated, you now have access to all content.
Success! Your billing info has been updated.
Your billing was not updated.