Меньше задачи, быстрее разработка и быстрее выход на рынок

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

Теоретически мы можем доставить двигатель клиентам и сказать – вот видите какую крутую фигню мы строим. 

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

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

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

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

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

Разбитие проекта на составляющие и тестирование каждого шага позволит выявить ошибки раньше и исправить их раньше. 

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

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

---

Понравилось? Кликни Лайк, чтобы я знал, какой контент более интересен читателям. Заметку уже лайкнули 1 человек

---