Перевод оригинальной статьи Рона Джеффриза «Incremental Development»
Суть подхода Big Design (детальное проектирование до начала разработки, англ. Big Design Up Front, BUFD) заключается в том, что у нас есть тщательно отобранный набор идеальных требований, и при помощи нескольких достаточно формализованных практик мы создаем красивую архитектуру для воплощения этих требований. Этот дизайн подобно солнцу освещает мир программирования, позволяя программистам без каких-либо глубоких раздумий идеально воплощать идеальную архитектуру для выполнения этих идеальных требований.
Даже если бы это было правдой (спойлер: это не правда), в большинстве случаев Big Design не смог бы удовлетворить наши потребности. Я бы сказал, он никогда не удовлетворяет наши потребности, и уж точно не в случае, который волнует меня больше всего —
В случае работающего продукта
За свою полувековую карьеру в разработке ПО я узнал многое — и самостоятельно, и работая с командами. Если бы я мог вернуться в прошлое и вынести только одну мысль, она была бы такой:
Какой бы продукт вы ни разрабатывали, поставляйте реально работающий продукт каждые две недели, а если возможно, то каждый день.
Почти каждую проблему, с которой я сталкивался за свои полвека в разработке ПО, можно было бы решить, имея на руках работающую версию продукта, пусть и с усеченной функциональностью. Мы можем отдельно обсудить причины этого, но простое объяснение заключается в том, что это позволило бы мне демонстрировать прогресс и перевести разговор с «делай больше» на «вот… что дальше?». Мы бы тогда быстрее поставляли хорошие идей и быстрее отсеивали плохие.
Поэтому для меня главный вопрос в разработке звучит так: как мы можем поставлять программный продукт каждую неделю? И в свете этого становится ясно, что концепция Big Design, как я его определяю, просто не позволит с этим справиться. Мы не можем создать хороший дизайн и выполнить все требования за две недели. Поэтому Big Design в этом варианте не подойдет.
Так как же мы можем это сделать?
Нам нужен детально проработанная архитектура
Тут видимое противоречие, и оно мешает большинству людей принимать инкрементальную разработку всерьез. Я постоянно слышу: «Наша проблема и решение настолько велики и сложны, что нам абсолютно необходим детально проработанная архитектура. Поэтому мы не можем поставить работающий программный продукт каждую неделю».
Тогда они могли бы сказать: «Наша проблема и решение настолько велики и сложны, что нам абсолютно необходим хорошо проработанная архитектура. Но мы не знаем, как это сделать, поставляя работающий продукт каждую неделю. Думаем, это вообще невозможно».
Однако, исходя из моего опыта, это возможно. А раз это возможно, и мне нужен работающий продукт каждую неделю, значит я должен придумать, как это делать.
Впрочем, кое-что из того, что говорят эти люди — чистая правда:
Нам абсолютно необходима хорошо проработанная архитектура для большой и сложной проблемы и решения.
Так как же мы можем объединить одно с другим, начав с чистого листа, поставляя продукт каждую неделю — и при это прийти к хорошему дизайну и архитектуре? Хорошо, что вы спросили. Вот примерный план того, как это можно сделать.
Инкрементальная разработка и дизайн
Мы выбираем подход, когда наша разработка определяет наш дизайн, а дизайн определяет разработку. Мы одновременно занимаемся разработкой и дизайном. Это происходит так:
Сформулировав свое видение требований — не полностью, а только ту часть, которую мы хорошо себе представляем — мы создаем маленький кусочек продукта, какой мы можем построить примерно за неделю. Как первый маленький кусочек рисунка. Фичи могут даже не полностью работать.
В ходе второй итерации мы делаем так, чтобы фичи, как бы мало их ни было, действительно работали — по крайней мере, большинство фич.
В ходе третьей итерации добавляем ключевые фичи и заставляем работать весь продукт. И дальше в том же духе. Мы добавляем следующие важные фичи, в том варианте, в котором мы их понимаем, и все время поддерживаем продукт в рабочем состоянии.
Что может пойти не так?
Мы знаем, что нам необходим хорошо проработанная архитектура, и если у нас его не будет, прогресс остановится, а количество дефектов и багов взлетит до небес, потому что именно так все и происходит при плохом дизайне. Это выглядит так:
Очевидно, что изображенный выше проект обречен. Его дизайн все менее и менее работоспособен, и в конце выглядит совершенно размытым. Мы определенно провалили проект.
Сделайте все правильно!
Фокус вот в чем.
- Легко иметь хороший дизайн, когда еще нет фич;
- Когда мы разработаем следующую фичу, мы портим наш хороший дизайн:
- Но поскольку мы добавили всего одну фичу, мы не слишком сильно его испортили;
- Прежде чем объявлять фичу готовой, мы исправляем дизайн;
- И все сначала.
Продукт развивается. Дизайн и архитектура развиваются. И дизайн остается хорошим.
В результате у нас получится хороший проработанный дизайн. Прогресс выглядит так:
Как вы знаете, процесс перехода от неработоспособного дизайна к хорошему называется рефакторинг или перепроектирование. Все модели и практики подробно описаны.
Но не будем ли мы продвигаться слишком медленно в таком случае? Не быстрее ли будет с Big Design?
В рамках подхода Big Design продукт не поставляются, пока не прописаны все требования и не проработана детально архитектура. Мы поставляем пригодный к использованию программный продукт небольшими порциями каждую неделю или две. В сравнении с Big Design, на старте у нас есть огромное преимущество по времени, часто целые месяцы.
И еще одно наше преимущество заключается в том, что стейкхолдеры и клиенты видят, как постепенно формируется реальный продукт. Они выбирают фичи, которые считают важными, и могут их тестировать. Поэтому если они вдруг выберут не ту фичу, то сразу получат обратную связь и могут изменить направление.
По-моему, это и есть гибкая разработка в стиле Аджайл. Это непросто, но это наилучший способ с самым высоким рейтингом выживания (поверьте, я изучил их все и многие испытал на практике).
Вы сами выбираете, сколько кода поставлять и когда. Вы сами определяете, какой анализ и какой дизайн должны быть сделаны перед стартом разработки и далее на каждом этапе. Это все решаете вы.
Я бы поступил так: нашел бы способ поставлять работающий продукт каждые несколько недель. Благодаря своему двадцатилетнему опыту гибкой разработки, я убежден в том, что это возможно.
И раз это возможно, то я бы делал именно так. Ну а вы… делайте как считаете нужным, но догадайтесь, что бы я посоветовал.
