Как спасти унаследованный проект после кораблекрушения

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

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

Для себя мы выделили основные задачи:

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

Вступление

Робинзон начал с осмотра острова и сбора выброшенных на берег предметов. С этого начали и мы. Осмотр показал:

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

Что мы смогли собрать на берегу:

Исходники проекта, правда, не все. Часть исходников, видимо, ушло на дно океана во время шторма, вместе со всей документацией.

Пару тестовых серверов, которые предоставил заказчик.

И… собственно, больше ничего.

Робинзон, проведя пару дней на пляже, соорудил себе домик. Мы тоже начали с инфраструктуры: подняли таск-трекер, вики систему и билдсервер (Jira + Confluence + Bamboo). На билдсеревере настроили деплои на тестовые сервера. И тут же столкнулись с первой проблемой.

«Мы не привыкли»

Заказчик не привык пользоваться таск-трекерами. Задачи ставились через скайп и почту. Там же шло и обсуждение деталей. Это не совсем удобно и чревато потерей информации. К тому же, не всегда договоренности из переписки были документально закреплены.

Мы старательно переносили все в Jira, но этого явно было недостаточно. Нужно было приучить представителей заказчика также пользоваться этим инструментом. Это шло через постоянные просьбы и напоминания сделать задачу в таск-трекере и добавить полную спецификацию. Признаемся, что без доли понимания и желания выстраивать процессы со стороны заказчика ничего бы не вышло.

Восстанавливаем документацию

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

Обязательное документирование нового функционала. На каждую фичу получается минимум три документа: описание функционала, статья от разработчика с деталями реализации и тестовая документация (тест-кейсы).

Взаимодействие с разработчиками в команде. Они помогали восстановить детали логики путем анализа кода. Для этого тоже лучше ставить задачи в таск-трекере. Разработчики не любят отвлекаться от работы над текущей задачей. Но если на анализ есть отдельная задача, этим можно заняться между основными. Результаты исследования обязательно документируются. Это также удобно, если заказчик просит исследовать логику, у нас уже есть готовый ответ.

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

Восстанавливаем инфраструктуру

Когда проблема с документацией стала понемногу решаться, встала проблема инфраструктуры для тестов.

Найденные Робинзоном предметы после крушения были скорее малопригодны для использования. Тестовые сервера и билдсервер оказались слабыми: сборка билда занимала около часа, деплой 15-30 минут, деплои и билды часто падали из-за инфрструктурных проблем. Половина рабочего времени тестировщика уходила на подготовку окружения для тестов. В довершение ко всему, заказчик часто использовал второй тестовый стенд для собственных тестов и демонстраций. Это минус один тестер в команде. Мы не могли увеличить количество тестовых серверов или увеличить мощность текущих. В итоге мы нашли единственное возможное на тот момент решение - развернуть проект локально у каждого тестировщика. Это в разы ускорило работу команды тестирования, а тестовые сервера стали использовать для специфичных случаев, например, тестирования установки приложения.

Хранилище документации

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

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

Наш выбор пал на Zephyr (плагин к Jira) из-за его простоты и тесной интеграцией с нашим таск-трекером. Инструмент не идеальный, но удовлетворяет наши потребности.

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

Как «попасть» в ожидания заказчика

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

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

Автоматизируем рутину

Шли годы, Робинзон неплохо устроился на острове: завел хозяйство, поля, скот. И на все времени стало не хватать. Поэтому Робинзон был рад новому помощнику - Пятнице.

Наш проект также рос. Росло тестовое покрытие и время на регрессионное тестирование. Мы работаем по двухнедельным спринтам, и в конце каждого делаем релиз и регресс. В какой-то момент время на регрессионное тестирование стало чрезмерно большим. Стало очевидно, что нужно автоматизировать. Унаследованный код не годился для покрытия юнит тестами. Интеграционные тесты также не могли покрыть все кейсы. БольшУю часть функционала нужно было автоматизировать через тестирование GUI. Наше приложение имело и web, и desktop части, поэтому нам не подходил Selenium. Нужно было искать универсальный инструмент. Нашим Пятницей стал Ranorex. Для нас и заказчика он оказался оптимальным в плане цены, функционала и интеграции с C# кодом. Сейчас у нас покрыто автотестами 30% регрессионных тестов. В планах довести покрытие до 70%.

Заключение

Сейчас нашему проекту почти 4 года. Мы постоянно улучшаем процессы и взаимодействие внутри команды и с заказчиком. Мы получаем положительный фидбек и от заказчика, и от его пользователей. Даже в непростой ситуации не стоит отчаиваться. Нужно спокойно проанализировать продукт, выделить критичные проблемы и решать их одну за другой. Тогда прогресс и развитие не заставят себя долго ждать.