Не оставляй никаких предположений
Разработчики программного обеспечения должны относиться к предположениям так же, как они относятся к своему боссу, работающему в нижнем белье — продолжать задавать вопросы, пока они не уйдут?
Какое самое смертоносное оружие для взлома кода, дизайна, архитектуры и планов проекта? Изменение есть.
Изменения разрушают планы, разрушают код, уничтожают требования и приносят хаос. Изменения опасны. Все находятся в состоянии повышенной готовности, чтобы не дать изменениям нарушить их проект.
Великое изменение, которое когда-либо применялось, заключалось в том, чтобы убедить разработчиков предположить, что они знают, как все работает, и создать код поверх этого.
Предположения смертельно опасны
Предположения подобны большому злому волку, замаскированному под бабушку, который готов съесть ваш проект на ужин. Предположения — это непроясненные изменения требований, которые все упускают из виду.
Предположения — это изменение, которое разработчики создали сами и еще не знают, что оно существует. Предположения — это невысказанные факты, о которых все знают, они настолько уверены в них, что никому не нужно документировать их как требования.
Предположения не подписаны, не согласованы и, что хуже всего, могут быть совершенно и совершенно неверными.
Сила предположений в том, что у них есть технология скрытности, которая используется, чтобы скрыться, пока пользователи не увидят демонстрацию или не воспользуются системой и не укажут, что они неправы.
Опасность
Вы думаете, что это чересчур, какой вред от нескольких непроясненных предположений?
Опасность для разработчиков заключается в том, что если вы сделали предположение, вы несете ответственность. Команда разработчиков может нести ответственность за срыв проекта и дорогостоящее расширение для всей проектной группы.
Предположения — это неразорвавшиеся мины, ожидающие, что кто-то наступит на них и взорвет код, проекты, требования или планы проекта.
Один проект купил маркетинговый инструмент, который не мог справиться с объемом необходимого маркетинга или каналов. Кто-то предположил, что маркетинговое программное обеспечение справится с этой задачей.
Изменять
Изменения — разрушительный разрушитель разработки программного обеспечения. Это разрушает код, проекты для планов. Как только вы измените код или дизайн в программном обеспечении, вы не знаете, что может сломаться, и вам может потребоваться изменить все, что построено поверх этого.
Предположения – это невыясненные факты. Это вещи, о которых мы догадывались, не подтверждая их. Чем больше вещей построено на основе этих предположений, тем сильнее влияние изменений.
Наихудший сценарий ошибочного предположения
- Обновление требований и выход
- Код необходимо обновить — это может привести к поломке зависимого кода.
- Интеграции обновлены
- Данные обновлены
- Развертывание/DevOps обновлено
- Перенос данных обновлен
- Тестирование обновлено
- Документация обновлена
- Обучение обновлено
- Новый выпуск в течение жизненного цикла программного обеспечения
Наиболее значительным изменением является продление сроков и обновление плана, чтобы включить всю работу, необходимую для внесения вышеуказанных изменений. Когда планы меняются, эмоции нарастают, а давление возрастает.
Уточнение фундаментального предположения может вызвать невероятное количество изменений и затрат.
Какие предположения существуют?
Процессы разработки программного обеспечения генерируют обратную связь и исключают предположения. Вы предполагаете, что предположения связаны только с требованиями, но в разработке программного обеспечения существует множество предположений.
- Мы предполагаем, что программное обеспечение должно работать во всех сценариях.
- У нас есть все требования
- Мы можем построить текущий код
- Текущая кодовая база делает именно то, что указано в требованиях.
- Код построен в соответствии с текущими стандартами, указанными
- Доставим по текущему плану
- Программное обеспечение будет делать то, что нужно бизнесу
- Все будет на месте, когда мы развернемся, чтобы жить
- У нас есть навыки для создания программного обеспечения
- Программное обеспечение будет работать с заявленной производительностью/нагрузкой в производстве.
- Текущее программное обеспечение соответствует нормативным стандартам
- Если сервер выйдет из строя, у нас есть резервная копия, которая все восстановит (кто-нибудь практиковал аварийное восстановление на проекте?)
- Если сервер разработки взорвется, у нас будет весь код в системе контроля версий и плейбук для воссоздания всего.
- Если команда разработчиков умерла на вечеринке на лодке, другая команда могла бы взяться за дело на основе системы контроля версий и документации.
Отзывы и вопросы
Лучший инструмент для борьбы с предположениями — командная работа, вопросы и обратная связь.
- Ночные сборки будут собирать и развертывать код каждый день.
- Модульные тесты проверят, что код делает то, что мы ожидаем после его изменения.
- Разработчики, тестировщики и бизнес-пользователи проверяют недостающие требования.
- Тестирование производительности показывает, что ваше программное обеспечение работает при ожидаемых нагрузках
Разработчики, бизнес-аналитики, тестировщики должны задавать бизнес-пользователям множество вопросов, чтобы понять их бизнес, найти недостающие требования и уточнить существующие требования, отвечающие потребностям их бизнеса.
Вы должны прояснить каждое предположение, потому что предположение с большим количеством зависимостей от него похоже на вытаскивание блока дженги со дна: оно может обрушить всю башню.
Обратная связь — это фундаментальный инструмент в разработке программного обеспечения, гибкая разработка основана на ранней обратной связи. Обнаружение проблем, предположений и других потенциальных изменений как можно скорее там, где их проще и быстрее исправить.