Не оставляй никаких предположений

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

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

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

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

Предположения смертельно опасны

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

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

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

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

Опасность

Вы думаете, что это чересчур, какой вред от нескольких непроясненных предположений?

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

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

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

Изменять

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

Предположения – это невыясненные факты. Это вещи, о которых мы догадывались, не подтверждая их. Чем больше вещей построено на основе этих предположений, тем сильнее влияние изменений.

Наихудший сценарий ошибочного предположения

  • Обновление требований и выход
  • Код необходимо обновить — это может привести к поломке зависимого кода.
  • Интеграции обновлены
  • Данные обновлены
  • Развертывание/DevOps обновлено
  • Перенос данных обновлен
  • Тестирование обновлено
  • Документация обновлена
  • Обучение обновлено
  • Новый выпуск в течение жизненного цикла программного обеспечения

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

Уточнение фундаментального предположения может вызвать невероятное количество изменений и затрат.

Какие предположения существуют?

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

  • Мы предполагаем, что программное обеспечение должно работать во всех сценариях.
  • У нас есть все требования
  • Мы можем построить текущий код
  • Текущая кодовая база делает именно то, что указано в требованиях.
  • Код построен в соответствии с текущими стандартами, указанными
  • Доставим по текущему плану
  • Программное обеспечение будет делать то, что нужно бизнесу
  • Все будет на месте, когда мы развернемся, чтобы жить
  • У нас есть навыки для создания программного обеспечения
  • Программное обеспечение будет работать с заявленной производительностью/нагрузкой в ​​​​производстве.
  • Текущее программное обеспечение соответствует нормативным стандартам
  • Если сервер выйдет из строя, у нас есть резервная копия, которая все восстановит (кто-нибудь практиковал аварийное восстановление на проекте?)
  • Если сервер разработки взорвется, у нас будет весь код в системе контроля версий и плейбук для воссоздания всего.
  • Если команда разработчиков умерла на вечеринке на лодке, другая команда могла бы взяться за дело на основе системы контроля версий и документации.

Отзывы и вопросы

Лучший инструмент для борьбы с предположениями — командная работа, вопросы и обратная связь.

  • Ночные сборки будут собирать и развертывать код каждый день.
  • Модульные тесты проверят, что код делает то, что мы ожидаем после его изменения.
  • Разработчики, тестировщики и бизнес-пользователи проверяют недостающие требования.
  • Тестирование производительности показывает, что ваше программное обеспечение работает при ожидаемых нагрузках

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

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

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