Менеджер проекта требует полной 100% уверенности каждый раз при фиксации кода

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

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

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

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

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

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

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

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

Босс: Вы на 100 % уверены, что это исправление не сломает какие-либо существующие функции и не повлияет на работу пользователей?

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

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

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

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

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

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

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

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

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

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

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

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

Вот где искусство этого бизнеса вступает в игру. Не только «работает ли это», но и нравится ли это покупателю.

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

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

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

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

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

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

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

Строго говоря, никогда нельзя быть на 100% уверенным, что коммит не сломает программу.

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

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

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

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

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

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

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

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

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

Обычный ответ для такого рода целей — рецензирование и регрессионное тестирование.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Это ваша проблема, но до сих пор это не ваша вина. Если вы не исправите это, в какой-то момент вам придется взять на себя ответственность. Обсудите со своим боссом, что, пока это не будет исправлено, вы никогда не будете на 100%. Предложите рефакторинг. Кроме того, 100% в уме нетехнических людей — это не то же самое, что у программиста. Возможно, вам следует указать, что вы «на 100% уверены, что клиент, вероятно, не заметит».

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

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

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

Заставьте его одобрить это самостоятельно

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

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

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

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

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

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

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

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

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

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

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

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

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

Если вы сможете уговорить менеджера проекта рассказать вам свою историю (возможно, за любимым напитком), тогда вы сможете посочувствовать, и он может стать восприимчивым к «инновациям», иначе говоря, к надежной практике разработки программного обеспечения.

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

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

Ищите поддержку способов повышения уверенности в достижении приемлемой цели в разумных экономических пределах. Вы не сможете внедрить Модель зрелости возможностей SEI уровня 5 за одну ночь. Но вы могли бы перейти от текущего вопроса к «проходит ли набор автоматизированных регрессионных тестов?» и «как мы выражаем это новое требование в системе регрессионного тестирования?»

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

Дополнительную информацию см . в статье Википедии о доверительных интервалах .