Менеджер проекта просит о полной 100% уверенности каждый раз, когда я фиксирую код

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

Менеджер проекта не понимает программного обеспечения достаточно хорошо, и, конечно, не понимает тестирование достаточно хорошо. Возможно, ему необходимо обучение.

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

Вы можете получить копию отличной книги Джеральда Вайнберга “* Идеальное ПО и другие иллюзии о тестировании **”. В главе 3 (“Почему бы просто не протестировать все?”), у Вайнберга есть раздел под названием “Есть бесконечное количество возможных тестов”.

Он говорит о черном ходу, помещенном в высокозащищенную программу, где обычную парольную защиту можно обойти, набрав W, затем три пробела, затем M, затем три пробела, затем J, затем ровно 168 нажатий клавиш, ни разу не используя букву L.

Тогда он пишет: “Ты уже понял суть? Если вы не догадались, что количество тестов, необходимых для исчерпывающего тестирования программного обеспечения, бесконечно, или, по крайней мере, "число больше, чем я могу запустить за свою жизнь”, то вы не поняли смысла этой главы. Теперь понимаете"

Объясните Вашему менеджеру проекта, что каждый день дополнительного тестирования несколько повысит Вашу уверенность в коде, но она никогда не может достичь 100%. Скажите ему, что вы будете рады продолжить тестирование за счет другой продуктивной работы. Тогда спросите его, сколько еще дней он хотел бы, чтобы вы потратили на тестирование, и какая из ваших других работ должна быть отложена.

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

Boss: Вы на 100% уверены, что это исправление не нарушит существующие функции или не вызовет никаких негативных последствий для работы пользователей?

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

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

• Я создал юнит-тесты, чтобы проверить добавленную функциональность, и устаревшие тесты больше не актуальны в связи с изменением

• Хотя я не могу дать вам 100% гарантию, я предоставил как можно больше гарантий в сроки, которые я считаю разумными для реализации этой функциональности. На самом деле я уже достиг точки снижения доходности. Я могу потратить еще 5 часов, чтобы дать вам еще 0.1% гарантии, но шансы, что такие усилия не оправдаются, уже настолько малы. Однако, вы отвечаете за проект и таймфрейм, так что дайте мне знать, сколько еще времени я должен потратить на эту функцию.

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

Если он будет продолжать неприятно себя вести, то я поговорю с ним и “владельцем” проекта по электронной почте об этом “100% протестированном” требовании и о том, какие ресурсы, как я считаю, необходимы для его выполнения.

Как разработчик, вы являетесь представителем ЮНИТа и тестируете изменения в вашем коде. По моему мнению (как разработчик), то есть проверить, что нет явных ошибок, все компилируется, все ошибки попадают в ловушку. У вас нет возможности узнать, какие сценарии будут встречаться после того, как код запустится (плохие данные, неожиданный ввод, изменения в клиентском программном обеспечении, список бесконечен)

Чтобы иметь 100% уверенность в том, что изменения ни на что не повлияют, вам понадобится тестовая среда, которая отражает реальную среду EXACTLY (данные, аппаратное обеспечение, разрешения, подключение) и набор тестовых сценариев, которые охватывают каждый отдельный сценарий. Это, как хорошо известно, практически невозможно создать среду по разным причинам

Если он ожидает 100% уверенности, то он должен предоставить среду и рабочую силу, чтобы поддержать его ожидания

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

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

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

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

Это то, где искусство этого бизнеса вступает в игру. Не только “работает”, но и радует клиента.

В конце концов, это деловые отношения. Если договоренность о контракте удобна и выгодна для вас, то мириться с этой причудой стоит. Не похоже, что он настолько серьезен, просто настойчив. Как я уже сказал, у него выработалась раздражающая привычка. Если он начнет негативно реагировать, и тон станет более враждебным, то баланс делового соглашения может сделать его нецелесообразным для вас. Но из вашего краткого описания мне кажется, что вы всё ещё можете эффективно управлять отношениями" (Л. Рон Хаббард).

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

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

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

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

Это может означать, например, предоставление примеров ошибок, которые решаются по разумной цене и без всякой вины летать вокруг. Это может означать, что нужно посмотреть на его собственную культуру компании, есть ли в компании кто-то ещё, кто готов возложить на него несправедливую вину, если что-то пойдёт не так. Это также может означать введение процедур для устранения будущих ошибок как можно быстрее и дешевле. Если бы компания действительно была на 100% уверена в коде, то такие процедуры были бы бессмысленны, потому что она была бы готова поставить произвольно большие суммы денег на отсутствие будущих ошибок!

В качестве окончательного разрешения, если он (работодатель) просит вас (подрядчика) продать ему уверенность в том, что вы не можете дать о своей работе, и ничто не изменит его мнение на этот счет, то все, что вы можете сделать, это четко заявить, что вы не в состоянии обеспечить эту уверенность, и что он может нанять кого-то другого, если он думает, что есть кто-то, кто может. Конечно, это долгий путь, но вы, возможно, с таким же успехом знаете вашу БАТНУ, прежде чем вы начнете.

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

Даже при всевозможных видах тестирования (тестирование модулей, интеграция, компонент, система, руководство, пользовательский интерфейс, нечеткость, безопасность, проникновение… вы называете это). Это связано с Halting problem . Соответствующая выдержка из Википедии приведена ниже:

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

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

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

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

Я бы попробовал объяснить, что цель в 100% является труднодостижимой. Она не может быть достигнута. Никогда. Во всей вселенной. История видела много таких примеров, например, демонстрация выпуска Windows 95 . Давно? Ну, посмотрите, сколько красных сборок на публичном CI сервере для проектов с открытым исходным кодом; войдите в систему как гость, если у вас там нет аккаунта. Итак, результат - программное обеспечение провалится.

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

В-третьих, это должно быть определение сделано. Что-то, что приходит в голову команде разработчиков. Это может включать: документацию, реализацию, тестирование, ворота качества и т.д. Это очень важно, так как теперь вы можете сдвинуть subjectivity (то есть “вы на 100% уверены?”) на objectivity (то есть все пункты определения готовой работы завершены).

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

Обычным ответом на этот вопрос является рецензирование и регрессионное тестирование.

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

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

3) Альфа- и бета-тестирование на ранней стадии и часто с реальными сценариями клиента. Клиенты будут делать с вашим кодом вещи, которые вы никогда не ожидали.

Ни один из них не является 100%, как и их комбинация. Но они значительно сближают вас. Они действительно требуют нетривиального вложения дополнительных ресурсов. Они действительно замедляют разработку по сравнению со скунсворком “просто сделай это, и мы исправим это, когда он сломается”. Но если вы действительно хотите безошибочный код, признавая, что люди поддаются падению, и внедряя практику, помогающую поймать неудачу до того, как она достигнет клиентов, это может стоить больше, чем эти затраты.

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

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

Да, это сводит с ума хороших программистов. До тех пор, пока это не спасет их задницы.

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

Даже QA команда не может гарантировать, что все возможности проверены, потому что возможные пути через сложную программу в основном бесконечны. Тем не менее, они приблизят вас намного ближе, чем вы есть сейчас. Одна из причин заключается в том, что разработчик не может адекватно протестировать свой собственный код. Они знают, что он делает, и поэтому склонны проектировать тесты, исходя из того, что, по их мнению, он должен делать. Они скучают по крайним случаям, они скучают по глупостям, которые пользователи делают так, как никогда бы не сделали, потому что они знают, как это работает, иногда они неправильно интерпретируют требование, но все их тесты будут отражать их изначальную неправильную интерпретацию. Они часто упускают ошибки в требовании и делают то, что от них просят не делать то, что они должны были бы делать (это является причиной огромного количества ошибок, которые обнаруживаются только после того, как фактические пользователи [с которыми слишком часто не советуются при определении требования] пытаются воспользоваться программой). Они упускают влияние на части приложения, в которых у них никогда не было причин работать, особенно в тех частях, которые выполняются специалистами (например, изменение таблицы, которое имеет смысл для приложения, но нарушает автоматизированный процесс импорта или отчет)

Если он хочет более высокого качества, он должен будет заплатить за это и временем, и деньгами. Даже при полном контроле качества вы не сможете достичь 100%, хотя, безусловно, НАСА и ее подрядчики подойдут к этому вопросу близко. Они также тратят великая сделка больше денег, чем ваша компания тратит. Даже тогда им удалось полностью пропустить MARS один раз.

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

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

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

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

Если он на самом деле микро-управляет вами и оглядывается через плечо на протяжении всего процесса создания проекта, есть простой способ убедиться, что вы можете “гарантировать” 100% уверенность без того, чтобы он потом вас об этом ястребил.

Пусть он сам это одобрит

Чтобы быть ясным, вы должны сделать это не как требование, а скорее как предложение, что если он действительно хочет 100% идеального кода, то он должен смотреть на то, что вы делаете сам, и одобрять каждое изменение, которое вы делаете на этом пути. Это не для того, чтобы сказать, что он должен буквально читать код, а для того, чтобы увидеть его в действии и подтвердить “да, вот как он должен действовать”.

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

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

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

К сожалению, вы можете быть в положении “босса”, чье понимание вашей работы ограничено, что всегда больно, когда пытаешься объяснить, как исправление ошибок невозможно поддерживать со 100% уверенностью. Таким образом, чтобы подвести итог, ваша лучшая ставка может быть просто сделать все, что вы можете, записывать все, и сделать его понять, что вы делаете то, что вы можете в пределах ваших собственных возможностей.

Довольно много хороших ответов здесь, PM определенно нуждается в обучении и узнать немного о том, что значит писать программное обеспечение.

Я не хочу повторять ничего из этого, но бросьте другую, довольно необычную идею. Этот метод довольно рискованен и во многом зависит от того, насколько высока ваша репутация, насколько хороши ваши навыки (или более того, как они воспринимаются), и какова ваша личность, и какова личность вашего Премьера. Я предполагаю, что вы его не неправильно поняли, и он на самом деле означает 100% (я часто вижу, что люди говорят 100%, но на самом деле имеют в виду “делай все, что можешь”)

Это сработало у меня однажды, и это единственная реплика, о которой я упоминаю здесь. Вас предупредили. В основном, это возможный способ обучить PM, если все остальные средства проваливаются.

Иногда, PM (или любой другой менеджер) просто не хочет слушать, так что вы должны где-то заставить его (или команду) удариться об стену, чтобы остановиться на мгновение и подумать. В этом сценарии это означает: Работать как можно лучше, стараться тестировать как можно лучше. Передайте свои лучшие пожелания, а затем скажите: “Да, я на 100% уверен, что это сработает”.

Если вам очень повезло, то никакой ошибки не произойдет, и все будут счастливы; но на самом деле, что произойдет, так это то, что есть ошибка. Что вы теперь будете делать? Вы признаете, что совершили ошибку. Установите связь с ошибками и ошибкой в том, что вы уверены на 100%. Люди несовершенны и могут создавать ошибки в программном обеспечении. Люди несовершенны и могут создавать ошибки в тестах. Следовательно, люди несовершенны и могут “создавать ошибки” в своем восприятии 100% уверенности в отсутствии ошибок.

Представьте этот колодец, и 100% водонепроницаемость (хаха, j/k, 100% опять). Убедитесь, что после всего этого, сообщение, которое прозвучало: “Я не могу быть на 100% уверен в своих тестах”. Если PM тогда не может сделать логичный шаг “Это будет одинаково для всех разработчиков”, то вся надежда, вероятно, потеряна, хотя…

Но, пожалуйста, попробуйте сначала другие вещи!

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

Если вы можете заставить РМ рассказать вам его историю (возможно, из-за его напитка по выбору), то вы можете сочувствовать, и он может стать восприимчивым к “инновациям”, так же как и к звуковой программно-инженерной практике.

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

Говорить на его языке: Используйте метафору, чтобы проиллюстрировать размер проблемы. Это 40 000 строк кода? Скажите ему, что это как 600-страничная загадка убийства на иностранном языке. Если вы хотите что-то изменить в середине главы 12, как сделать так, чтобы это не вызвало перерыва в преемственности с остальной частью истории?

Ищите способы повысить доверие к приемлемой цели в пределах разумных экономических границ. Вам не удастся внедрить SEI Capability Maturity Model 5 уровня за одну ночь. Но вы, возможно, сможете перейти от текущего вопроса к “проходит ли автоматизированный набор регрессионных тестов?” и “как выразить это новое требование в системе регрессионных тестов?”.

Я бы ответил ему самым математическим способом, учитывая, что он просит о вероятности со 100%-ой уверенностью, и полностью игнорируя то влияние, которое статистические распределения окажут на такое число: Вы должны дать ему 2 или 3 числа, с соответствующей уверенностью: 1 неделя на 90%, 2 недели на 95%, 6 месяцев на 100%. Последнее число было преувеличением, но я уверен, что вы поняли суть.

См. статью Википедии о интервалах доверия ](https://en.wikipedia.org/wiki/Confidence_interval) для более подробного прочтения.