3) Можно ли отложить поставку программного обеспечения, чтобы исправить ошибку?
4) Самое главное: что вы ожидаете от своего программного обеспечения? Пора торговать? Качество? Хотите узнать, используют ли ваши клиенты программное обеспечение достаточно долго, чтобы найти ошибку?
но похоже, что он знает об ошибке ... поэтому в этот момент может показаться, что программисту просто лень не исправлять это, зная об этом ...
Кеннет
7
@Kenneth: Вы могли бы видеть это так, но продукты должны быть отправлены, и они всегда будут иметь ошибки. Это будет зависеть от серьезности ошибки в отношении того, задерживаетесь ли вы в срок.
Мэтт Эллен
1
@ Матт, это правда. Однако мне кажется, что в большинстве случаев вы не захотите отправлять продукт с серьезными ошибками. Это будет означать, что оставшиеся ошибки, о которых вы знаете, будут незначительными, и в большинстве случаев их легко исправить или, по крайней мере, обойти. Вы не можете обрабатывать ошибки, о которых вы не знаете, но если процесс тестирования выполняется правильно, большинство ошибок должно быть обнаружено ...
Кеннет
1
Может быть, мой сарказм не был ясен ... но говорить, что "всегда нормально" отправлять программное обеспечение с ошибками, это своего рода безответственно. Это все равно, что сказать: «В мире всегда будут убийцы, поэтому не имеет значения, пойду ли я и убью несколько человек».
Рассерженный Гоат
7
@DisgruntledGoat Не все ошибки одинаковы: некоторые из них легко исправить, а некоторые разрушают проект. Очевидно, что они должны быть исправлены. Некоторые из них - очень редкие ошибки, которые трудно найти, основанные на необычных обстоятельствах, и, как правило, их трудно исправить без серьезного переписывания. Иногда им просто нужно остаться, потому что их исправление предлагает слишком мало пользы, а программное обеспечение должно появиться вчера. Все дело в анализе затрат / рисков / выгод.
CodexArcanum
33
Это решение суда. Помните, что ошибка может быть много вещей. Если это основной функционал, который не работает, то вы сначала исправите это. Если это что-то незначительное, что имеет минимальное влияние или не оказывает реального влияния на полезность программы, вы можете позволить этому скользить.
Так что посмотрите на это с точки зрения затрат / выгод.
Вы отправляете продукты с известными ошибками, когда общая стоимость и риск исправления ошибки перевешивают любые проблемы и негативное влияние, которое может возникнуть из-за существующей ошибки.
Таким образом, если у вас есть 2-недельный период тестирования перед выпуском, и обнаружена небольшая ошибка, вопрос состоит в том, чтобы ... исправить эту ошибку, стоящую за 2 дополнительные недели, которые команда может теперь потратить, чтобы повторно протестировать приложение и установку (часто забывают о шаге в создании программного обеспечения)? Сколько стоит репутация или продажи, если программное обеспечение запаздывает? Люди собираются злиться? Они могут быть очень рады жить с незначительной ошибкой, если основные функции могут быть доставлены вовремя.
Риски включают в себя риск появления новой проблемы, не только в исправлении ошибки, но также и в том, что может возникнуть при создании новой установки.
Негативное влияние - это и время, и усилия на работу с клиентами, сообщающими об ошибке, и такие вещи, как ущерб репутации.
Опечатка в поле 'about' - это то, что вы действительно должны исправить. Это займет около 0,7 секунд (при условии, что мы оба печатаем с одинаковой скоростью). Однако, если вы оставите эту опечатку, люди увидят ее . Это мгновенная смерть для уверенности ваших пользователей в вашем программном обеспечении, если есть видимые ошибки в пользовательском интерфейсе.
Это кажется правильным для меня. В большинстве случаев в продукте есть несколько незначительных ошибок, даже когда он выходит в релиз. Это, как правило, очень необычные вещи, которые оказывают незначительное влияние на фактическую работу и использование программного обеспечения или вещей, которые большинство пользователей никогда не видят.
Гленатрон
3
Действительно, опечатки в вашем пользовательском интерфейсе разрушают веру в качество продукта (ошибочно, так как многие великие программисты просто не говорят на хорошем английском языке), однако я понимаю вашу точку зрения - тривиальные ошибки, которые не причиняют реального вреда и, вероятно, никогда не появятся вверх не стоит хлопот сдерживать выпуск. Оставьте это для пункта пули в 1.01.
Фоши
Не допускайте орфографических ошибок в вашем приложении. Откровенно говоря, я более смущен ими, чем фактической ошибкой.
ChaosPandion
1
Понятия не имею, о чем вы говорите ...;)
Андреас Йоханссон
6
Ошибки бывают разной степени тяжести. В любой софтверной компании, в которой я работал, мы классифицировали ошибки в порядке Приоритета от P0 до P4.
P0 Это программное обеспечение не работает / дает сбой и может нанести ущерб бизнесу клиентов. P1 Он работает не так, как задумано, и постоянно падает в основной функциональности. P2 Иногда происходит сбой, и часть побочной функциональности может не работать. P3 Некоторые элементы программного обеспечения не работают так, как задумано / ожидается. P4 Косметическая проблема.
Я работал в местах, где P4 просто не исправляются, потому что они так мало влияют на программное обеспечение.
Я бы сказал, что все в порядке, если у вашего программного обеспечения есть проблемы с P3 / P4, я бы добавил это в примечания к выпуску и отметил, что над ними ведется работа.
Я бы никогда не выпустил программное обеспечение с проблемой P0, P1 или P2, о которой я знал.
Это называется « Известная проблема ». Google, Microsoft, Apple и т. Д. Поставляют продукты с ошибками, как известными, так и неизвестными. Попробуйте свести их к минимуму, но не ждите совершенства. Корабль быстро, грузим часто.
Вы не можете отправить программное обеспечение без ошибок. Совет, который я могу дать, заключается в том, что лучше всегда говорить своему клиенту: «Эта версия не может делать то и это, но мы собираемся это исправить», чем ситуация, когда клиент говорит ВАМ, что у вас есть ошибка.
Если серьезно, если вы не являетесь идеальным программистом с идеальной тестовой установкой, чтобы идеально тестировать каждый отдельный путь к коду и, в конечном итоге, он может существовать, маловероятно, что вы отправите продукт без ошибок.
Поэтому будьте прагматичны: если все, с чем вы сталкивались в своем тестировании, исправлено, все, что нужно, следует исправлять по мере необходимости.
Пока вы честны со своими клиентами, вы можете отправлять с ошибками. Сообщение им обо всех существующих ошибках показывает, что у вас есть хорошие знания о вашем программном обеспечении, и это действительно хорошо проверено (если оно есть ..). :)
Очевидно, что лучше всего избегать доставки с ошибками.
С точки зрения потребителей ... Никогда. Я хочу сказать, что если вы знаете, что в программном обеспечении есть серьезная ошибка, вы никогда не должны его отправлять. Однако силы природы (бизнеса) преодолевают это, если производственный цикл программного обеспечения сейчас находится на стадии, когда это может нанести ущерб бизнес-модели, и они представляют собой незначительные ошибки, которые не будут: (i) ставить под угрозу безопасность программного обеспечения (ii) влиять на удобство использования
Как говорили люди, это очень широкий вопрос. На самом деле это подводит меня к интересной перспективе: так называемые «ошибки», о которых вы заявляете, - это только ошибки, обнаруженные вашими тестерами. Там может быть бесконечно больше лазеек. Просто напомнил интересную историю, которую я услышал от одного уважаемого профессора на одном семинаре для выпускников: когда люди в одной из скандинавских стран использовали машину для голосования типа «распознаваемый от руки», некоторые люди взламывали всю систему, написав вредоносный код SQL (который система взяла как нормальный ввод).
Другим решающим фактором может быть то, как дефект относится к вашему последнему выпуску. Если ошибка является частью новой, но неработающей функции, то отсутствие функциональности не означает регресс функциональности. Идите и отправьте.
С другой стороны, если дефект приводит к потере существующей функциональности, которая, как известно, полезна для существующих клиентов, он должен заблокировать выпуск. Такой выпуск был бы понижением для ваших клиентов и не служил бы ни вашим интересам, ни их интересам.
В этом могут быть оттенки серого. Регресс в функциональности ядра никогда не должен выходить за рамки. Некоторая регрессия в периферийных функциях может привести к тому, что пользователи получат новую версию, если она также содержит новые функциональные возможности, к которым они проявили интерес. Незаметный дефект, который вряд ли затронет многих клиентов, может быть включен в выпуск, если в случае это влияет на тех клиентов. Дефекты в экспериментальных функциях, которые в любом случае отключены по умолчанию, никогда не должны приводить к задержке выпуска.
Ответы:
Я предполагаю, что вы говорите об «известной» ошибке (в противном случае вопрос не имеет смысла). Ну, ответ зависит от этих факторов:
1) Кто пользователь и как он / она примет ошибку в случае ее обнаружения?
2) Каково потенциальное воздействие (повреждение) ошибки?
3) Можно ли отложить поставку программного обеспечения, чтобы исправить ошибку?
4) Самое главное: что вы ожидаете от своего программного обеспечения? Пора торговать? Качество? Хотите узнать, используют ли ваши клиенты программное обеспечение достаточно долго, чтобы найти ошибку?
источник
Это всегда должно быть хорошо, потому что не существует такого понятия, как программное обеспечение без ошибок.
источник
Это решение суда. Помните, что ошибка может быть много вещей. Если это основной функционал, который не работает, то вы сначала исправите это. Если это что-то незначительное, что имеет минимальное влияние или не оказывает реального влияния на полезность программы, вы можете позволить этому скользить.
Так что посмотрите на это с точки зрения затрат / выгод.
Вы отправляете продукты с известными ошибками, когда общая стоимость и риск исправления ошибки перевешивают любые проблемы и негативное влияние, которое может возникнуть из-за существующей ошибки.
Таким образом, если у вас есть 2-недельный период тестирования перед выпуском, и обнаружена небольшая ошибка, вопрос состоит в том, чтобы ... исправить эту ошибку, стоящую за 2 дополнительные недели, которые команда может теперь потратить, чтобы повторно протестировать приложение и установку (часто забывают о шаге в создании программного обеспечения)? Сколько стоит репутация или продажи, если программное обеспечение запаздывает? Люди собираются злиться? Они могут быть очень рады жить с незначительной ошибкой, если основные функции могут быть доставлены вовремя.
Риски включают в себя риск появления новой проблемы, не только в исправлении ошибки, но также и в том, что может возникнуть при создании новой установки.
Негативное влияние - это и время, и усилия на работу с клиентами, сообщающими об ошибке, и такие вещи, как ущерб репутации.
источник
Ошибки бывают разной степени тяжести. В любой софтверной компании, в которой я работал, мы классифицировали ошибки в порядке Приоритета от P0 до P4.
P0 Это программное обеспечение не работает / дает сбой и может нанести ущерб бизнесу клиентов. P1 Он работает не так, как задумано, и постоянно падает в основной функциональности. P2 Иногда происходит сбой, и часть побочной функциональности может не работать. P3 Некоторые элементы программного обеспечения не работают так, как задумано / ожидается. P4 Косметическая проблема.
Я работал в местах, где P4 просто не исправляются, потому что они так мало влияют на программное обеспечение.
Я бы сказал, что все в порядке, если у вашего программного обеспечения есть проблемы с P3 / P4, я бы добавил это в примечания к выпуску и отметил, что над ними ведется работа.
Я бы никогда не выпустил программное обеспечение с проблемой P0, P1 или P2, о которой я знал.
источник
Это называется « Известная проблема ». Google, Microsoft, Apple и т. Д. Поставляют продукты с ошибками, как известными, так и неизвестными. Попробуйте свести их к минимуму, но не ждите совершенства. Корабль быстро, грузим часто.
источник
Вы не можете отправить программное обеспечение без ошибок. Совет, который я могу дать, заключается в том, что лучше всегда говорить своему клиенту: «Эта версия не может делать то и это, но мы собираемся это исправить», чем ситуация, когда клиент говорит ВАМ, что у вас есть ошибка.
источник
когда это «фича»! ;)
Если серьезно, если вы не являетесь идеальным программистом с идеальной тестовой установкой, чтобы идеально тестировать каждый отдельный путь к коду и, в конечном итоге, он может существовать, маловероятно, что вы отправите продукт без ошибок.
Поэтому будьте прагматичны: если все, с чем вы сталкивались в своем тестировании, исправлено, все, что нужно, следует исправлять по мере необходимости.
источник
Пока вы честны со своими клиентами, вы можете отправлять с ошибками. Сообщение им обо всех существующих ошибках показывает, что у вас есть хорошие знания о вашем программном обеспечении, и это действительно хорошо проверено (если оно есть ..). :)
Очевидно, что лучше всего избегать доставки с ошибками.
источник
Часто лучше иметь продукт вовремя, со списком известных проблем, чем не отправлять его вообще.
Одна из вещей в мире программирования , который дает людям уверенность в проекте , были ли они релиз запланирован и является ли график имеет .
Вот почему Ubuntu выпускает релизы каждые полгода, даже если есть открытые выпуски.
источник
Я бы сказал, что хорошее эмпирическое правило гласит: «Является ли эта ошибка бестселлером?»
Если ошибка приводит к сбою «сценария счастливого пути», то абсолютно не поставляется с этой ошибкой.
Если ошибка приводит к сбою «сценария касательного к счастливому пути» и обходного пути нет, то не отправляйте с этой ошибкой.
Если ошибка задокументирована и есть известный обходной путь, то, вероятно, все в порядке с такой ошибкой.
источник
С точки зрения потребителей ... Никогда. Я хочу сказать, что если вы знаете, что в программном обеспечении есть серьезная ошибка, вы никогда не должны его отправлять. Однако силы природы (бизнеса) преодолевают это, если производственный цикл программного обеспечения сейчас находится на стадии, когда это может нанести ущерб бизнес-модели, и они представляют собой незначительные ошибки, которые не будут: (i) ставить под угрозу безопасность программного обеспечения (ii) влиять на удобство использования
источник
Как говорили люди, это очень широкий вопрос. На самом деле это подводит меня к интересной перспективе: так называемые «ошибки», о которых вы заявляете, - это только ошибки, обнаруженные вашими тестерами. Там может быть бесконечно больше лазеек. Просто напомнил интересную историю, которую я услышал от одного уважаемого профессора на одном семинаре для выпускников: когда люди в одной из скандинавских стран использовали машину для голосования типа «распознаваемый от руки», некоторые люди взламывали всю систему, написав вредоносный код SQL (который система взяла как нормальный ввод).
источник
Есть то, что называется FMEA (режим отказа и анализ эффектов), очень полезно решить, когда известная ошибка важна или нет на основе:
источник
Другим решающим фактором может быть то, как дефект относится к вашему последнему выпуску. Если ошибка является частью новой, но неработающей функции, то отсутствие функциональности не означает регресс функциональности. Идите и отправьте.
С другой стороны, если дефект приводит к потере существующей функциональности, которая, как известно, полезна для существующих клиентов, он должен заблокировать выпуск. Такой выпуск был бы понижением для ваших клиентов и не служил бы ни вашим интересам, ни их интересам.
В этом могут быть оттенки серого. Регресс в функциональности ядра никогда не должен выходить за рамки. Некоторая регрессия в периферийных функциях может привести к тому, что пользователи получат новую версию, если она также содержит новые функциональные возможности, к которым они проявили интерес. Незаметный дефект, который вряд ли затронет многих клиентов, может быть включен в выпуск, если в случае это влияет на тех клиентов. Дефекты в экспериментальных функциях, которые в любом случае отключены по умолчанию, никогда не должны приводить к задержке выпуска.
источник