Lean №9 - Принятие решение в самый последний момент

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

Что предлагается для того чтобы это было возможно:

1. Не делайте дизайн системы в самом начале. Дизайн системы должен развиваться по мере того как мы больше узнаем про систему и требования к ней. 
2. Оптимизируйте процесс взаимодействия между теми что знает бизнес и тем кто знает код чтобы упростить внесение изменений в дизайн системы.
3. Любители пытаются сделать все правильно с первого раза. Эксперты выявляют ошибки до того как они приведут к проблемам.
4. Используйте объект-ориентированный дизайн и компонентную разработку. Например:
1. Используйте модули. Прячьте поведение внутри модуля, откладывайте дизайн модуля как можно дольше.
2. Используйте интерфейсы. Отделите интерфейсы от реализации.
3. Используйте параметры.
4. Используйте абстракции.    
5. Декларативное программирование, а не процедурное. Алгоритмы не должны зависеть от окружения.
6. Избегайте повторений кода - DRY. 
7. Модуль имеет одну, простую функцию. Поэтому метод по валидации объекта не должен менять содержимое этого объекта (чтобы оптимизировать лишний SQL запрос), Марат.
8. Инкапсуляция. Изменения не должны приводить к каскадными изменениям в других модулях.
5. Реализуйте максимально простое решение сейчас вместо того чтобы делать решение которое будет удовлетворять "будущим" потребностям. Завтра вы будете знать больше, потому завтра вы сделаете более крутое решение.
6. Избегайте лишних фич, добавляйте их лишь just-in-case. Любая фича - это потери на понимание, реализацию, тестирование, подддержку. НЕ бывает бесплатных фич.
7. Исследуйте то что критически важно бизнесу. Малое время формирования ответа. Когда тратить на него силы? В самом начале и потом поддерживать его до конца проекта, или оставить на завершение работ и сэкономить время? Это не ваше решение - это приоритет бизнеса. Если ему это критически важно - сделайте в самом начале, чтобы снизить риски изменения архитектуры в конце работ.
8. Чем медленнее ваша реакция на изменения, тем раньше вам нужно принимать решения. Чем быстрее вы можете менять код системы, тем больше вы сможете отложить решение.