Задать вопрос
@SanchezBoy

Как реорганизовать процесс разработки и увеличить её скорость, если нету документации, куча костылей и старый код?

Всем привет!
5 лет назад создавал проект, на который был нанят один удаленно разработчик и дизайнер. Я выступал в роли ПМа.
За это время проект сильно вырос и разросся и возникла потребность в увеличении скорости разработки, нужны ещё программисты.

Но естественно никакой документации не велось, в коде разобраться сложно, первоначальная версия обросла тонной фич и костылей, фреймворк давно устарел, сам разработчик не хочет заморачиваться с рефакторингом/переписыванием, внедрением "best practice" и пр.
Скорость разработки падает, костыли дают о себе знать, всё держится на одном человеке.

Хочется привести всё в порядок: документация, тестирования, версионирование, CI и пр. красоту. Но компетенции таковые у меня отсутствуют и изучать возможности нету, деньги имеются.

Нужна помощь. Как поступить?

P.S. текущая идея. Делать хоть какую-то документацию по проекту и искать тимлида с опытом, кто возьмётся навести порядок. Или как вариант полностью на аутсорс отдать, но пугает отсутствие гибкости/оперативности.
  • Вопрос задан
  • 457 просмотров
Подписаться 2 Средний 1 комментарий
Пригласить эксперта
Ответы на вопрос 3
@jkotkot
режим сарказма
Вариант только один. Искать нормальных разработчиков, делать НОРМАЛЬНУЮ документаци, налаживать процессы, автоматизировать все что должно быть автоматизировано, рефакторить все, что должно быть отрефакторено, выкидывать костыли и заменять их нормальными решениями. Можно постепенно, если можно, а не все сразу.
Отдавать на аутсорс можно. Это довольно частая проблема, когда текущая команда не хочет изменений, или не в состоянии менять ничего. У нас приличное количество таких проектов. Отдать на аутсорс (можно и другой команде внутри) более мотивированной команде это один из выходов.
Ответ написан
@kn0ckn0ck
Продюсер
Первым делом вы должны осознать, что проект находится в глубокой Ж. Стоимость и продолжительность выхода оттуда существенны. Это значит, что сразу все сделать красиво скорее всего не получится. А это значит, что нужно выбрать что важнее и заняться этим в первую очередь.

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

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

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

Отсюда вытекает первоочередная задача - разработка автотестов, которые будут выполнять важнейшие функции:
1. фиксировать текущие требования к системе, то есть отвечать на вопрос как оно должно работать
2. страховать от ошибок, которые могут возникать из-за костылей и неопытных программистов
3. стабилизировать ветки разработчиков перед слиянием в мастер-бранч

Для создания автотестов, вам не нужен разработчик, вам нужен тестировщик с навыками создания автотестов. Только когда будут автотесты имеет смысл разгонять скорость разработки за счет привлечения новых программистов, делать CI и по ходу фиксировать технические решения, важные для дальнейшей разработки.
Ответ написан
Комментировать
Sir_Waat
@Sir_Waat
Business Analytics, Scrum Master
Дабы не повторяться хочу сказать еще одну мысль, которая помогла некоторым проектам.
Иногда кол-во "фич" и костылей зашкаливает, а технологии устаревают настолько, что единственным адекватным решением является стать "фениксом".
Иногда стоит переписать все заново используя старые наработки и перенеся необходимый функционал в новую среду. В таком случае появляется возможность начать вести все необходимые типы документации.
Конечно же этот способ работает только в случае подобном вашему. т.е. когда Вы обладаете достаточным объемом ресурсов (время и финансы) для найма профессионалов, способных на подобное действие. Максимально упростив текущую схему, перенеся её на новый функционал и обзаведшись хотя бы минимально необходимой документацией Вам будет легче сопровождать и модифицировать то, что Вы получите в итоге.
Разумеется это ОЧЕНЬ сложный и рискованный шаг, но иногда сделать заново гораздо проще чем реанимировать умирающее.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы