Справиться с нескончаемым бесконечным проектом

У нас есть большой (более 1200 часов) веб-сайт, на котором много технических долгов. Это в основном обусловлено следующими (обычными) причинами.

1. Несколько программистов, которые приходят и уходят во время разработки.
2. Изменение спецификаций при разработке.
3. Добавлены многочисленные дополнительные функции (в скором времени).

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

Из-за технического долга мы тратим ОЧЕНЬ много часов на устранение или расследование проблем, которые обычно происходят из одного из следующих:

1. Бесстыдная глупая ошибка, которая заставляет людей плакать.
2. Новая функция приводит к вышесказанному, потому что мы не предусмотрели все места, где новая функция будет иметь влияние.
3. Некоторые другие проблемы, с которыми мы столкнулись (например, миграция сервера, обновления)

У нас ежедневно возникают проблемы, и мы стараемся сделать следующее, чтобы остановить это:

1. Создана техническая документация относительно импорта, оплаты и общей работы сайта.
2. Проведите встречу в начале недели - обсудите текущие проблемы или улучшения и способы их решения.
3. Есть план испытаний. Программист A тест B, B тесты C и C тесты A. Затем наш менеджер проекта добавит несколько тестов. Что касается влияния функции, мы добавляем ее в промежуточную среду и позволяем клиенту проверить себя.

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

Я предполагаю, что есть много программистов, работающих над более крупными проектами, чем этот. Вот почему я подхожу к своему вопросу:

Что мы можем сделать, или что вы делаете, чтобы избежать этих проблем в больших проектах?

Незначительное редактирование, дополнительная информация:

1. Мы используем контроль версий (SVN).
2. У нас есть процесс разработки DTAP.

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

Могу поспорить, что он слишком большой, чтобы начать писать юнит-тесты, потому что у него не было никого, кто знает, как юнит-тестировать до вас (и, к счастью, другие люди в вашей команде), и невозможно знать, с чего начать, и, возможно, даже невозможно тестирование, потому что оно опирается на точные реализации и конкретные данные, поэтому потребуется слишком много времени для того, чтобы раздеть все это до интерфейсов, макетов, заглушек и тому подобного, чтобы иметь возможность протестировать его в первую очередь. Я также держу пари, что вы не можете просто заняться рефакторингом того, что нужно реорганизовать, потому что оно слишком тесно связано, и, поскольку нет тестов, кто знает, что будет сломано исправлением плохого кода. Короче говоря, он, вероятно, стал слишком злокачественным, чтобы серьезно его исправить, но, конечно, его нельзя просто вырезать и начать заново.

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

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

Контроль источника также помогает, если вы не используете его. В частности, функции «вина» и «лог» прекрасно описывают, как / почему ошибочный кусок кода был зафиксирован.

Со стороны клиента, я обнаружил, что обсуждение цены и (длительных) задержек, как только запрашиваются изменения / дополнительные функции, работает достаточно хорошо, как и плата за время, потраченное на их обсуждение / разработку. Зачастую клиенты решают, что на секунду подумают, что подождут.

(В отличие от этого, если вы сразу же поработаете с ним о спецификациях и идеях реализации, они обычно заставят вас сказать «о, я думал, мы договорились, что вы все равно это сделаете» или (что еще хуже, после нескольких дней далее об особенностях) «но смотри, это уже разработано, и то, что мы обсуждали, звучит не так уж сложно!».)

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

Я предлагаю вам добавить тестирование на основе CI, в первую очередь в областях, которые чаще всего ломаются. Это поможет вам повысить качество, так как работа над проектом ведется.

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

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

Некоторый обзор кода хорош, но, возможно, это часть схемы тестирования A-> B-> C-> A. (Может быть, обзор кода в другом направлении?)

Позволь мне бросить в тебя басню. В начале дня вы прогуливались с человеком по улице и достигли пункта назначения. Человек, с которым вы идете, быстро обнаруживает, что он потерял свое кольцо где-то по пути, поэтому вы оба решили вернуться назад и отправиться на его поиски. Человек, с которым вы идете, быстро останавливается у фонарного столба и начинает отчаянно смотреть. Вы говорите: «Почему вы смотрите на фонарный столб, когда я думаю, что вы могли потерять его, когда мы прорезали переулок?». Он отвечает: «Я знаю, но здесь свет лучше».

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

1) Они обычно не нарушают офисную политику и баланс сил. 2) Они успешно создают иллюзию контроля со стороны руководства, а не наносят удар по сути проблемы.

Менеджмент думает, что «свет лучше здесь» обычно звучит так: «Каждая новая функция должна иметь подробную техническую спецификацию» или «Давайте проводить ежедневные ежечасные встречи, чтобы обсудить проблемы и способы их преодоления».

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

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

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

Я был в том же месте некоторое время назад. Я больше не благодаря двум простым правилам:

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

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

Кодовые обзоры. Модульные тесты. Настоящее QA Тестирование. Процесс сбора спецификаций и поэтапная разработка - вот некоторые вещи, которые должны решить большинство ваших проблем.

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

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

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

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

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

Приветствия. Иак.

Написать четкие функциональные характеристики; педантично, так что если вы можете вынести это и регулярно проверять функциональность с этими спецификациями. Чем меньше у разработчика идеи о том, что он должен развивать, тем меньше у него шансов на то, как он должен развиваться.

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

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

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

Делайте регулярные / ежедневные обзоры кода: это больше о проверке работоспособности, чтобы убедиться, что разработчик не ушел далеко от курса. Используйте эти сессии, чтобы запланировать работу на следующие дни. Могут быть дни, когда это занимает 5 минут или 1 час; Дело в том, чтобы поддерживать открытый диалог и дать разработчикам возможность обсудить свою работу с другими разработчиками и обратиться за советом. Проведите несколько сеансов сопряжения над сложными частями кода или для создания прототипа идей, но дайте людям время для работы.

Упростите создание и развертывание своего кода. Постарайтесь сократить время сборки. Чем проще построить, тем больше будет построено, тем быстрее оно будет построено.

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

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

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

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

В общем, используйте тестирование для повышения доверия к продукту, а не как инструмент, который мгновенно повысит качество. Будьте спокойны, но настойчивы :). Может быть, попытка идти быстро, но только если вы абсолютно положительно можете привлечь сертифицированного PM. Представление Agile человеком, который не знает Agile, скорее всего, убьет проект.