Мое выступление на конференции IT Brunch “Учимся на чужих ошибках”

В эту субботу, 9 июня, состоялась третья по счету бесплатная онлайн конференция IT Brunch. В этот раз она называлась “Учимся на чужих ошибках”. Тема выбрана не случайно. Ведь больше всего в IT мы делаем именно ошибок, к нашему большому сожалению. Причем, ошибок на всех этапах разработки программных продуктов – планировании, проектировании, выборе технологий, работе с заказчиком, тестировании и т.д. Наша индустрия славится количеством проваленных проектов, но при этом мы все равно не учимся на чужих ошибках и допускаем их снова в очередном проекте. А ведь гораздо лучше слушать про ошибки других людей, учиться на них и не допускать их в своей практике.

Я выступал с докладом “Коварный tracer bullet development”, в котором поведал историю одного проекта, где мы решили попробовать новый для нас подход к разработке – Tracer Bullet Development. Пересказывать содержание доклада не буду, вот слайдкаст выступления:

Есть еще видео вариант:

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

Вопрос: Как вышли из проблемы заглушек?
Ответ: Через некоторое время от заглушек отказались. Чем больше становилось логики, тем тяжелее было поддерживать заглушки в актуальном состоянии. На это тратилось слишком много усилий.

Вопрос: А писали ли тесты на функционал с заглушками? И не сложно было их рефакторить?
Ответ: В этом была одна из идей – можно писать тесты на заглушки, а потом прозрачно использовать их для интеграционного тестирования реальных сервисов. Сейчас я понимаю, что надо было больше времени уделить провайдерам данных, чтобы сами тесты вообще не пришлось менять. А так нужно было делать достаточно много изменений, чтобы они заработали с реальными сервисами.

Вопрос: А как насчёт жизни без тестировщиков? Ошибка или нет? 😉
Ответ: Нет, это не ошибка. Я считаю, что каждой команде было бы полезно поработать без тестировщиков, чтобы приучить себя выпускать продукт нормального качества, а не рассчитывать на тестирование. Многие технические вещи начинают делаться разработчиками, когда они понимают, что тестировать кроме них некому. Они стараются сделать это как можно проще и быстрее, автоматизируя свою работу. А заказчик начинает брать на себя больше ответственности за приемку функциональности. В общем, одни плюсы. 😉

Вопрос: Как убедить заказчика в “правильности” идеи небольших функциональных команд?
Ответ: Нужно показать ему преимущества: меньше времени тратится на коммуникацию, команды работают практически независимо, можно более гибко подходить к выбору функциональности для реализации, меньше риски в случае проблем с одной из команд и т.д. Рекомендую взглянуть также на методологию FDD (Feature Driven Development).

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

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

Вопрос: Как быть если есть много маленьких проектов?
Ответ: Небольшие функциональные команды работают замечательно и в этом случае. Делается конвейер задач, каждая из которых представляет собой законченную функцию системы. Команда берет ее на реализацию и делает. Управлять этим можно с помощью Kanban (как пример).

Обсуждение (0)

Leave a Reply

Your email address will not be published. Required fields are marked *