Предисловие Очень часто разработчик сталкивается с задачами, предполагающими изменение существующего функционала системы или добавление нового, повторно использующего существующий функционал.
В этой статье я хочу обсудить некоторые подходы к определению объёма работы, которую нужно будет проделать разработчику, чтобы правильно планировать задачи.
Зачем планировать
Независимо от того, в какой среде вы работаете, будь то среда гибкой разработки или традиционные подходы типа водопада, существует дедлайн, в течение которого желательно завершить работу.В Scrum, например, крайним сроком будет спринт. В любом случае команда или разработчик предоставляет обязательства перед заказчиком, и эти обязательства должны быть выполнены, иначе штрафных санкций со стороны заказчика не избежать.
Планирование технических задач
В этой статье я опущу методы планирования задач для систем, написанных с нуля, и сосредоточусь на изменениях, которые необходимо внести в существующие приложения.Все подходы, которые я собираюсь описать, я в той или иной степени использовал сам.
Так:
- Анализ кода, который гипотетически необходимо изменить.
Этот подход можно применить, если вы очень хорошо разбираетесь в реализации и можете практически со стопроцентной уверенностью сказать, какие части системы будут подвержены изменениям.
- Исследование системных журналов.
Если вы не уверены в своих знаниях о реализации системы и ее поведении, вы можете обратиться к журналам.
Можно сначала попросить пользователя ввести входные данные и посмотреть, какой след система оставила в логах.
После этого можно с уверенностью сказать, какая часть реализации выполняет тот или иной бизнес-алгоритм и оценить трудозатраты на реализацию новой логики.
- Написание тестов
Нет пользователя, к которому можно было бы обратиться, чтобы воспроизвести поведение системы.
А если есть, то каждый раз связываться с ним – дело неблагодарное, да и повторять все вручную нам самим не хочется.
Почему бы не написать автоматический тест перед реализацией алгоритма? Да, мы говорим о ATDD (разработка через приемочное тестирование) и функциональных тестах.
Об этом типе тестирования необходимо позаботиться сразу после запуска проекта.
Платформа для написания и запуска таких тестов должна развиваться вместе с проектом.
Он должен быть легко расширяемым и масштабируемым.
Кроме того, запуск таких тестов должен поддерживаться в непрерывной интеграции.
Если у вас есть тест, воспроизводящий текущее поведение системы, и вы знаете, каким должен быть результат, то половина работы уже сделана.
Осталось оценить ту самую дельту, которую необходимо реализовать, чтобы: а) существующие тесты не провалились, и б) прошел и новый тест с новыми ожидаемыми выходными данными.
Возникает вполне политический вопрос.
Действительно ли необходимо писать такие тесты перед планированием задачи? Ответ может заключаться в том, насколько быстро ваша среда функционального тестирования позволяет вам писать такого рода тесты.
Если это вопрос пары часов, то ответ - да, лучше написать, если нет, то стоит подумать о Техотделе и исправить ситуацию в ближайшее время.
Если вы используете методологию итеративной разработки, перед следующей итерацией убедитесь, что пользовательская история достаточно ясна с точки зрения требований.
Требования можно легко преобразовать в приемочные испытания.
спецификация на примере (SBE), чтобы помочь вам.
SBE, кстати, хорошо интегрируется с инструментами тестирования, такими как Fitnees, реализациями BDD, такими как Spock, Easyb и т. д.
Мораль
Прежде чем углубляться в детали реализации, подумайте, как вы будете все это тестировать.Возможно, еще недостаточно требований для реализации той или иной фичи, и тогда ее следует отложить на более позднее время (спринт).
Выделите время для написания функциональных тестов, следите за регрессом в непрерывной интеграции.
Зеленые функциональные тесты — это доказательство того, что вы выполнили свою работу правильно, так, как хотел заказчик, и об этом вы узнаете сразу после очередного коммита в Source Control (ранняя обратная связь).
И писать понятные логи.
Удачи тебе.
-
Краш-Тест При Запуске Версии 2.0
19 Oct, 24 -
Польза И Вред Сроков В Программировании
19 Oct, 24 -
Какие Сайты Действительно Являются Медиа?
19 Oct, 24 -
Jvm На Opencl
19 Oct, 24 -
Сборник Бессмысленных Сайтов
19 Oct, 24
