Разработка без багов — не миф. Так и должно быть. Примените этот подход уже сегодня.
Простой вопрос, вызывающий споры: "Как работать с багами"? Можно ли полностью избавиться от багов? Должны ли мы к этому стремиться?
Мой опыт говорит: достичь состояния Ноль Багов проще, чем вы думаете.
Пример из жизни
Вспоминаю свою работу в BBC в Лондоне.
Я только что подключился к проекту как тренер по гибкому управлению разработкой. Первые две недели я внимательно наблюдал за динамикой работы команды из 22 человек.
У команды не получалось работать стабильно. Я посмотрел историю их спринтов. В одних они набирали много очков продуктивности, в других — ноль.
Я наблюдал, как команда постоянно работает над "маленькими замечаниями" в ущерб важной работе. Владелец продукта и заинтересованные лица были разочарованы отсутствием долгожданных обновлений. Разработчики показывали пальцем друг на друга.
Мне стало очевидно, что все эти "маленькие замечания" были багами трех типов. В редких случаях это были дефекты реализации. Но чаще баги были результатом некорректных или отсутствующих спецификаций.
Разработчики исправляли любые баги. Часто в срочном порядке — поскольку начальство было недовольно, или потребители не могли пользоваться системой.
Я также заметил, что хронически большое число багов стало восприниматься командой как норма.
После наблюдений я применил подход Ноль Багов.
В течение одного спринта мы перешли на новый режим. В следующие 2 спринта продуктивность увеличилась на несколько баллов. После еще 4 спринтов продуктивность стабилизировалась.
Авралов стало меньше. Продукт стал лучше. Команда стала счастливее и воспряла духом.
Как работает эта магия вуду? Расскажу подробно, почему и как применить эту систему очень просто.
Как разрабатывать ПО без багов.
Менеджмент классифицирует все задачи. Команда выполняет задачи в установленном порядке.
Есть четыре типа задач:
- Критичные проблемы
- Баги
- Фичи
- Улучшения
Рассмотрим их на примере магазина.
Критичная проблема: магазин горит.
Если не потушить пожар, вы потеряете магазин!
Критерий: потребители не могут пользоваться продуктом; деньги или время тратятся с недопустимой скоростью.
Решение: бросьте всю текущую работу и решите проблему немедленно.
Баг: трубы протекают.
Если не устранить протечки, вода зальет товар и испортит его. Это замедлит развитие бизнеса.
Критерий: система работает не так как ожидается, но потребители могут ею пользоваться; теряеются деньги или время, но в краткосрочной перспективе это допустимо.
Решение: сперва доделайте текущую задачу, затем устраните баг.
Фича: товар или сотрудник.
Товары и сотрудники необходимы, чтобы вести бизнес.
Критерий: еще не реализованные функции.
Решение: приоретизируйте и реализовывайте по порядку.
Улучшение: чистый магазин.
Довольные чистым магазином потребители заходят чаще.
Критерий: улучшение функций системы.
Решение: приоретизируйте и реализовывайте согласно приоритетам.
Других правил нет! Я же говорил, это просто.
Почему это работает
Концепция критичных проблем давно известна. Во многих командах такие проблемы называют P1. Когда вы видите пожар, вы тушите его.
Суть подхода в том, что вы всегда сначала исправляете все баги, и только потом делаете фичи и улучшения. В этой системе нет багов с приоритетами P2 или P3. Это бинарная система.
Баг либо есть, либо его нет. Баг — это проблема, которую надо решить в первую очередь. Если это не так — это не баг.
Намного чаще задачи будут классифицированы как фичи или улучшения. Приоретизируйте их и делайте по порядку.
Классифицировать задачи вам поможет картинка:
Классификация багов
Три вида багов, о которых я писал выше и в статье "Предотвращая появление багов":
- Дефекты реализации
- Некорретные спецификации
- Отсутствующие спецификации
Можно классифицировать их как критичные проблемы или переклассифицировать в фичи или улучшения.
Ниже — мои любимые правила переклассификации багов.
Можем ли мы жить с этим дефектом реализации?
Шрифт должен быть встроен в приложение, но скачивается каждый раз при его запуске.
Переклассифицируем как улучшение.
Мы теряем деньги или можем потерять их из-за некорректной спецификации?
В спецификации написано считать клики. Но следить надо за расходами.
Это критичная проблема.
Отсутствие спецификации подразумевает новые функции?
Пользователи не могут редактировать свой профиль и делиться им через социальные сети.
Переклассифицируем как фичу.
Теперь менеджеру по продукту необходимо правильно классифицировать баги. Он знает, что разработчики не будут работать над чем-либо еще до их исправления.
Строго следуя этим правилам, вы автоматически улучшаете дисциплину в команде.
Стандарты качества
При классификации багов, фич и улучшений вы опираетесь на негласные стандарты качества. Например, владелец продукта акцентирует внимание на оформлении: не принимает любые визуальные огрехи и классифицирует их как баги. Последовательное применение правил классификации неявно формирует стандарты качества.
Правила переклассификации багов в фичи и улучшения позволяют постоянно уточнять стандарты и управлять ожиданиями на ходу, адаптируя их к реальности. При этом вы сохраняете структурированный подход к поставке продукта, где качество на первом месте.
Как применить этот подход уже сегодня
Классифицируйте все задачи, пользуясь описанными выше правилами.
Подумайте о том, чтобы отправить сотни и тысячи старых задач в архив и начать с чистого листа. Не волнуйтесь, при необходимости вы достанете старые задачи из архива и классифицируете их.
Разработчики не будут ждать, пока вы классифицируете все задачи. Они начнут разбираться с багами сразу же, как только появится несколько задач данного класса.
Разработчики работают над исправлениями до полного устранения багов. НИКАКИХ ИСКЛЮЧЕНИЙ! Если нарушить это правило, подход перестанет работать. Это правило мотивирует менеджера по продукту корректно классифицировать и приоретизировать задачи.
Не позволяйте всем подряд классифицировать задачи как "баги" — получится бардак. Пусть все создают задачи, но не классифицируют их.
Классифицировать задачи должен менеджер по продукту. Возможно другие члены команды тоже захотят классифицировать задачи. В этом случае установите четкие правила и следите за порядком.
Наглядное изображение процесса работы:
Критичные проблемы решаем сразу > текущие задачи доделываем до конца > фиксим баги > делаем задачи из очереди.
Если критичных проблем или багов несколько, можете приоретизировать их, чтобы легче пережить кризис.
Команда должна постоянно и следовать правилам классификации и приоретизации. При таком подходе разработку будет идти быстро и в соответствии со стандартами качества.
Не замедлит ли это работу?
Ровно наоборот, и описанный выше случай в BBC это доказывает.
Представьте: вы едете по левой полосе скоростного шоссе. Внезапно вы вспомнили о повороте направо. Скорость 150 км/ч, и быстро перестроиться в правый ряд опасно. Вы ускоряетесь до 180 км/ч в надежде, что не пропустите следующий поворот и не попадете в пробку.
Другой вариант: вы едете со скоростью 120 км/ч. Когда вы вспомнили о повороте, еще есть время притормозить и вовремя свернуть.
В каком случае вы доедете быстрее? В каком случае больше шансов попасть в аварию и не доехать?
Подход Ноль Багов работает так же. Разработка замедляется не более чем нужно, тогда когда это нужно.
Увеличение скорости разработки может быть незаметно день ото дня, но будет очевидным в долгосрочной перспективе.
Не верьте мне на слово. Попробуйте применить этот подход на практике, замерьте результаты и убедитесь сами.
Это не новая концепция
Я был весьма горд, что придумал всё это сам.
Как выяснилось, идея не нова. Как и другие забытые мудрости "старой школы", она известна с конца 60-х!
В истинном подходе "Ноль Дефектов" нет неважных элементов. Филипп Кросби, 1926-2001
Филипп Кросби — легендарный эксперт по качеству. Ввел понятие "Ноль Дефектов" когда работал в компании Martin (сейчас известна как Lockheed Martin). Утверждалось, что "государственный аудит показал сокращение дефектов оборудования на 54%". Подход "Ноль Дефектов" был использован в космической отрасли в 60-х, и в производстве автомобилей в 90-х.
У разработки ПО и промышленного производства много общего. Популярный метод гибкого управления Канбан зародился на фабрике Toyota. Ноль Дефектов — другой вдохновляющий пример того, чему мы можем и должны научиться у промышленников.
Подход Ноль Дефектов критикуют за неоправданно дорогую цену соблюдения стандартов. Это так, если применять подход неправильно. В подходе Ноль Багов я решил эту проблему с помощью правил переклассификации багов в фичи и улучшения. Эти правила позволяют управлять затратами на основе стандартов качества.
Итоги
Баги в программах будут всегда. Писать программы без багов — невозможно.
"Ноль Багов" не означает код, в котором нет ни одного бага; это стремление устранить все известные баги.
Лучше всего итоги данной статьи подведет легендарный эксперт по качеству Эдвардс Деминг (1900-1993):
Качество создается не проверками, а улучшением производственного процесса. Уильям Деминг, 1900-1993
Сражайтесь за качество, как ниндзя!
Узнайте больше о практиках улучшения с помощью "Quality Faster". Этот цифровой продукт поможет вам улучшить качество и процессы на всех уровнях разработки, во всей команде.
Мы начинаем обучение с основных принципов поставки качественного и ценного ПО. На основе этих принципов вы создадите стратегию и процессы тестирования. Вы увидите работающие примеры на основе Node.JS, React, Chimp JS, Mocha, Meteor, и других технологий.
Кликните здесь, чтобы приобрести книгу и стать Ниндзя Качества!
Также подпишитесь на меня в Medium и Twitter. Пишите в комментариях о своих мыслях и идеях.
Я и дальше буду помогать вам быстрее поставлять ПО высокого качества.
Сэм.
Комментарии (76)
terrier
13.04.2017 21:39+17ДОСТИЧЬ СОСТОЯНИЯ НОЛЬ БАГОВ(*) ПРОЩЕ ЧЕМ ВЫ ДУМАЕТЕ! Я СМОГ И ВЫ СМОЖЕТЕ! ТОЙОТА!!! КОСМИЧЕСКАЯ ОТРАСЛЬ!!! ЗАБЫТАЯ МУДРОСТЬ СТАРОЙ ШКОЛЫ!!! ВНЕДРИТЕ НОЛЬ БАГОВ(*) СЕГОДНЯ!
(*) мелким шрифтом: Ноль Багов — маркетинговое название идеи «Ну, если бы нам не подкидывали срочные фичи, то мы бы все это багло разгребли бы ...». Компания-продавец никоим образом не подразумевает отсутствие багов, не дает никаких обещаний относительно качества ПО. Все ваши ассоциации — это ваши проблемы
zharikovpro
13.04.2017 22:47> Ну, если бы нам не подкидывали срочные фичи, то мы бы все это багло разгребли бы
Так почему же никак? Вот именно так и достичь. А по-другому никак.
lieff
13.04.2017 23:28+3А запускаете все это на голом железе и без бровзеров? Вообще то нет пока ни одной ос, ни одного браузера и ни одного процессора даже без багов. Утверждение об полном отсутствии багов в большом продукте всего лишь от введения приоритетов крайне сомнительна. В больших проектах типа chromium все эти приоритеты есть, но баги там не кончаются никогда. Тем не менее если вы небольшой группой возьмете chromium и потыкаете странички — вы ни одного бага скорее всего не найдете, это не значит что их там нет. То что вы называете «ноль багов», я бы назвал «достигнуто приемлемое качество».
zharikovpro
13.04.2017 23:44-3> Вообще то нет пока ни одной ос, ни одного браузера и ни одного процессора даже без багов.
Вот тут подробно ответил.
Если вкратце: когда вы в последний раз платили за процессов с выявленным дефектом? Да так, что вам его по гарантии не обменяли на нормальный.
> В больших проектах типа chromium все эти приоритеты есть, но баги там не кончаются никогда.
Это их право и стратегия выпускать продукт с дефектами. Хотя еще большой вопрос, сколько процентов багов являются дефектами в том смысле, что не соответствуют спецификации продукта.
> То что вы называете «ноль багов», я бы назвал «достигнуто приемлемое качество».
Если достигнуто качество, приемлемое согласно спецификации — это и называется изделие без дефектов. Т.е. производственного брака не было.
Предполагаю, что если бы в статье вместо слова баг применялось слово «дефект» с соответствующим определением, она воспринималась бы легче. Но тут уж автор как написал, так написал. Менять термин везде в статье я посчитал некорректным.lieff
14.04.2017 00:10Да, тут явно дело в терминологии. Я воспринял это именно как «чистый баг трекер», то есть все известные баги поправлены (а есть еще и пока не выявленные, от процедуры тестирования тоже зависит и прошедшего времени). Если имеется ввиду «пользоваться можно», «нет критических багов» или «есть, но проявляются на конфигурациях не из спецификации» итд, то все норм и понятно. Тот же хромиум это пример очень качественного по и хорошо вылизанного, самостоятельно вы новый баг врядли найдете, так же как врядли достигните такого же качества в своем продукте. Пользоваться им можно и миллионы людей пользуются, вот только баг трекер там далеко не пустой, а содержит 54000 багов.
Suvitruf
13.04.2017 22:04+6TL;DR: никак.
zharikovpro
13.04.2017 22:58-7Первый гонорар за программу я получил на первом курсе института. Программа складского учета грузовых контейнеров работала без сбоев каждый рабочий день в течение 5 лет. Что я сделал не так?
PkXwmpgN
13.04.2017 23:17+5Ваш пример — это единичное изделие, у одного пользователя. Которое, я так понимаю, в течение этих пяти лет, не поддерживалось и не развивалось. Вы сделали, получили вознаграждение и забыли. Или, скажем, ПО для марсахода — тоже единичное изделие.
Можете наложить концепцию "Ноль Багов", например, на IntelliJ IDEA (на ум пришло первое просто, была статья вроде недавно про десятки тысяч багов там) или любой другой большой продукт, с подобным жизненым циклом и манитизацией, который разрабатывают сотни разных специалистов из разных областей?zharikovpro
13.04.2017 23:26-1У меня есть и другие примеры. На тысячи пользователей. На сотни тысяч пользователей. На миллионы долларов оборота. Это из моего личного опыта.
Из вашего личного опыта — можете взять приложения с которыми вы и миллионы или миллиарды пользователей по всему миру работаете годами без багов.
Тут ведь важно понимать, что такое баг в данной статье. Если внимательно прочитать три вида багов видно, что там везде есть слово спецификация. И в оригинальном Zero Defects тоже говорится именно о дефектах. Дефект — это когда изделие не соответствует спецификации. Тогда это производственный брак. Соответствует — значит нет дефектов.
При этом изделие может потребителю не нравиться. Он может говорить что оно с багами. Но если оно такое как положено по спецификации — оно без дефектов, по определению. Если оно не такое как положено по спецификации — оно по определению с дефектами, даже если потребителя все устраивает.
Поэтому если мы будем говорить про IDEA например, возникнет вопрос — а какие там спецификации? Этого мы не знаем, поэтому судить о числе дефектов относительно спецификации не можем. Так же, производитель может выпускать продукцию с дефектами сознательно. Это его право.
Тут вспоминается книга Бойцовский Клуб, где главный герой как раз считал для автокомпаний, что им выгоднее — отзывать продукцию с дефектами или оплачивать страховые и судебные издержки.
lair
13.04.2017 23:42+10Дефект — это когда изделие не соответствует спецификации. Тогда это производственный брак. Соответствует — значит нет дефектов.
… а если спецификация нечеткая? А если на поведение нет спецификации?
Понимаете ли, позиция "дефект — это несоответствие спецификации" очень выгодна с точки зрения политики "ноль дефектов", но не приводит к повышению удовлетворения и клиента. И, что важнее, лишена практического смысла.
zharikovpro
13.04.2017 23:50-1> а если спецификация нечеткая?
Значит непонятно, дефект или нет.
> А если на поведение нет спецификации?
Значит не дефект.
> не приводит к повышению удовлетворения и клиента
Почему не приводит? Производители автомобилей и электроники зря отлаживают технологические процессы и стараются выпускать продукцию без дефектов? Вот счастье-то будет у нас, у клиентов, когда на заводах можно будет выпускать изделия с браком. Купит ребенок кока-колу, а внутри водка. Не по спецификации, зато счастье. Водку купит работяга, а там боярышник. Боярышник купит бабушка — а там вода. Вот это что-ли счастье?
Если без сарказма. Почему вы считаете, что соблюдать спецификации не имеет практического смысла? Зачем тогда их делают? Я-то думал, что как раз для повышения удовлетворения клиента. Который заранее гарантированно знает что он получит. И расстроен, когда получает НЕ то что ожидал.lair
13.04.2017 23:59+5Почему не приводит?
Потому что рядом могут сосуществовать "не дефект" вида "программа стирает все пользовательские данные" и "дефект" вида "текст не выделен полужирным". Согласно политике "ноль дефектов" второе важнее.
Почему вы считаете, что соблюдать спецификации не имеет практического смысла?
Нет, я считаю, что утверждение "мы во всем соответствуем спецификации" совершенно не означает довольного клиента.
Который заранее гарантированно знает что он получит. И расстроен, когда получает НЕ то что ожидал.
Это если вы каким-то чудом сделали так, чтобы спецификация соответствовала ожиданиям клиента. А в реальности регулярно бывает так, что показываешь клиенту "вот, сделано по вашей спецификации", а он тебе в ответ "но это не то, что я хотел получить".
zharikovpro
14.04.2017 00:18-3> «не дефект» вида «программа стирает все пользовательские данные»
Это дефект, т.к. теряются деньги (у клиентов, и теряются клиенты и деньги от них не поступают, зато поступают заявки на возврат и судебные иски). Если денег теряется много — это критический дефект.
> Нет, я считаю, что утверждение «мы во всем соответствуем спецификации» совершенно не означает довольного клиента.
Так тут я с вами согласен. Вроде бы в статье и комментариях нет противоположного тезиса.
> А в реальности регулярно бывает так, что показываешь клиенту «вот, сделано по вашей спецификации», а он тебе в ответ «но это не то, что я хотел получить».
Программистам дали спецификацию — они сделали. То, что клиент ожидал не того — косяк и головная боль маркетологов, продавцов и проджект менеджера. В обязанности проджекта входит, между прочим, управление рисками и ожиданиями. Маркетологи и продавцы также управляют ожиданиями.lair
14.04.2017 00:20+5Это дефект, т.к. теряются деньги (у клиентов, и теряются клиенты и деньги от них не поступают, зато поступают заявки на возврат и судебные иски)
Выше уже выясняли: на поведение нет спецификации — значит, не дефект. Или у вас уже определение дефекта поменялось?
Программистам дали спецификацию — они сделали. То, что клиент ожидал не того — косяк и головная боль маркетологов, продавцов и проджект менеджера.
Ну вот это я и не считаю продуктивным. Потому что в итоге вину просто переложили на других людей, а результат не изменился.
zharikovpro
14.04.2017 00:39> Или у вас уже определение дефекта поменялось?
Понял. У меня определение дефекта не поменялось. Я продолжаю развивать идею автора. Компания произвела ПО. По спецификации это не дефект. Но вот нашли эту багу. Начались возвраты, скандалы, акции просели, по судам таскают и требуют компенсаций. Или пока еще не таскают, но могут. Компания на этом теряет или может терять деньги? Совершенно точно, да.
На этот случай автор предлагает классифицировать этот баг как критическую ошибку. После этого, очевидно, разрабы должны выявить и устранить причину дефекта. Описав его и покрыв код соответствующими тестами, в которых будет указано, что при воспроизведении данной ситуации ожидаемое поведение программы — НЕ удалять файлы, согласно спецификации. Вроде бы здравый смысл, нет?
> Потому что в итоге вину просто переложили на других людей, а результат не изменился.
Если эти самые другие люди квалифицированно сделают свою работу — результат изменится! И конечно очень хочется узнать ваши предложения, которые лучше этого.lair
14.04.2017 11:47+3У меня определение дефекта не поменялось. Я продолжаю развивать идею автора. Компания произвела ПО. По спецификации это не дефект. Но вот нашли эту багу. [...] На этот случай автор предлагает классифицировать этот баг как критическую ошибку. После этого, очевидно, разрабы должны выявить и устранить причину дефекта.
Видите. Это все равно стал дефект. Поэтому у вас дефект — это и то, что не соответствует спецификации, и то, что на что спецификации нет, но компания теряет деньги. А если еще немного покопать, то выяснится, что и то, что соответствует спецификации, но компания теряет деньги — все равно дефект. И на этом этапе изначальное определение окончательно потеряло смысл.
Если эти самые другие люди квалифицированно сделают свою работу — результат изменится!
А вы считаете, что они сделали свою работу неквалифицированно? А почему?
И конечно очень хочется узнать ваши предложения, которые лучше этого
Ну, я вот считаю, что создание хорошего продукта — это общая ответственность, без перекидывания камней через заборы.
Suvitruf
14.04.2017 00:15Из вашего личного опыта — можете взять приложения с которыми вы и миллионы или миллиарды пользователей по всему миру работаете годами без багов.
Не припоминаю таких.
Поэтому если мы будем говорить про IDEA например, возникнет вопрос — а какие там спецификации? Этого мы не знаем, поэтому судить о числе дефектов относительно спецификации не можем.
Ну, вот та самая IDEA.zharikovpro
14.04.2017 00:20-1> Ну, вот та самая IDEA.
Осталось к этой ссылке добавить еще ссылку на спецификации продукта, и можно будет посчитать.zharikovpro
14.04.2017 00:21И опять-таки, выпускать продукт с дефектами — их право. Это никак не опровергает тезисы из статьи.
zharikovpro
13.04.2017 23:37> Ваш пример — это единичное изделие, у одного пользователя.
Компьютеры — сложные технические изделия массового потребления с миллиардами пользователей. Из этого следует, что они по определению содержат дефекты? Нет, не следует. Возможно, в спецификациях техпроцесса есть какие-то допуски по браку. Не специалист, врать не буду. В любом случае потребитель за брак не платит, а возвращает бракованное изделие по гарантии и получает нормальное.
Тут вспоминается байка про американцев, которые заказали у японцев процессоры и в контракте указали: не более 5 дефектных процессоров на тысячу. Когда вскрыли коробку, увидели записку: мы не знаем, зачем вам нужны 5 процессоров с дефектами, но вот на всякий случай отдельно их приложили.
lair
13.04.2017 23:47+1Компьютеры — сложные технические изделия массового потребления с миллиардами пользователей. Из этого следует, что они по определению содержат дефекты? Нет, не следует. Возможно, в спецификациях техпроцесса есть какие-то допуски по браку. Не специалист, врать не буду. В любом случае потребитель за брак не платит, а возвращает бракованное изделие по гарантии и получает нормальное.
Про битые пиксели слышали? Так вот, нам неоднократно говорили, что "по спецификации это не брак". Ну да, не брак, вернуть нельзя. Но монитор с битыми пикселями я покупать не буду.
zharikovpro
13.04.2017 23:56Отличный пример. Заранее известно, что у монитора может быть три битых пикселя. Честная сделка.
Да, не все это знают. Т.к. большинство не читает описание товара и гарантию перед покупкой… но незнание условий договора не освобождает от ответственности.
Как вы верно заметили, у продвинутых покупателей это не вызывает проблем. Всегда можно монитор протестировать. И в хороших магазинах квалифицированные консультанты тоже предложат вам это сделать.
С точки зрения неквалифицированного потребителя — это ошибка и беспредел. С точки зрения договора — четко обозначенные перед совершением сделки условия. Кому-то в офис и с тремя битыми пикселями монитор подойдет, кстати говоря.zharikovpro
13.04.2017 23:59P.S. Не хочу уходить в холивар на юридические темы и мелкий шрифт в договорах, и уж тем в более в рассуждения про справедливость. Это вообще другая тема.
lair
14.04.2017 00:01+3Проблема как раз в том, что это "честная сделка", но покупатель не удовлетворен. И политика "сам виноват, не прочитал описание товара" не сделает его более удовлетворенным.
zharikovpro
14.04.2017 00:08> И политика «сам виноват, не прочитал описание товара» не сделает его более удовлетворенным.
Давайте сделаем покупателя удовлетворенным.
Если я правильно все понимаю (лично не сталкивался) Мвидео обменяет вам в подобном случае монитор с битыми пикселями на монитор без битых пикселей. Хотя по закону они это делать не обязаны, они ввели такую политику чтобы сделать покупателей более удовлетворенными. Вот и решили вопрос.
Сделать покупателя удовлетворенным — вроде бы, задача отдела маркетинга и продаж, а не производства. Потому что задачу производству ставят именно на основании маркетинговых исследований. Маркетологи пусть решат, что и как нужно произвести чтобы потребитель был счастлив, а технологи организуют производство.
У технологов без маркетологов делать потребителя удовлетворенным действительно плохо получается, это не их задача.lair
14.04.2017 00:09… вот только меня не устраивает ни ценовая политика МВидео, ни их ассортимент.
И понимаете, это еще одна демонстрация того, что политика "ноль дефектов" сама по себе бессмысленна. Особенно в применении к ПО, с его спецификой написания, гм, спецификаций.
zharikovpro
14.04.2017 00:23> … вот только меня не устраивает ни ценовая политика МВидео, ни их ассортимент.
Ну так я смотрю вас любая имеющаяся политика не устраивает :) Какая политика для вас имеет смысл? Сколько дефектов должно быть в продукте, на что ориентироваться?lair
14.04.2017 11:44+1Какая политика для вас имеет смысл?
Та, при которой продукт удовлетворяет моим ожиданиям.
zharikovpro
14.04.2017 00:24> Особенно в применении к ПО, с его спецификой написания, гм, спецификаций.
Какая уж тут специфика. У автомобиля есть чертеж и критерии приемки. У дома есть чертеж и критерии приемки. И у программы тоже может быть чертеж и критерии приемки.lair
14.04.2017 11:48+1Специфика — в ожидаемой скорости выполнения. За небольшими исключениями никто и никогда не даст для программы спецификацию такой же детальности, как для автомобиля.
(вы правда никогда не читали "что если бы дома строили так же, как пишут программы"?)
Akon32
14.04.2017 10:39Что я сделал не так?
Не предусмотрели систему баг-репортов?
Другая локаль, другая ОС — и вуаля, то "1.234" не парсится, то всё окно заливается чёрным.
Бывают программы посложнее CRUD, там скрытых багов немеряно (это которые вылезают лет через 15 после внедрения).
zharikovpro
14.04.2017 11:41-1Система багрепортов была простая — мой телефон у оператора и начальника.
mrsantak
14.04.2017 12:01+2Не, ну я в студенческие годы тоже написал кучу безбажных программ для сдачи зачета по информатике. А вот сейчас какой мой продукт не взять — багтрекер так и пестрит багами. Наверное как специалист я капец как деградировал.
А уж все эти линуксы так вообще в багах утопают, наверное одни школьники пишут.
mrsantak
14.04.2017 12:07+3TL;DR: никак.
На самом деле очень просто:
Шаг первый — закройте публичный багтрекер.
Шаг второй — разгоните QA.
Шаг третий — удалите все тесты.
Шаг четвертый — назовите все уже существующие баги фичами.
Шаг пятый — PROFIT.
PapaBubaDiop
13.04.2017 22:05+1Внутри железа нет багов. Процессор идеально выпечен и исполняет все команды так, как прописано в документации. 10 лет, 100 лет, 1000 лет. В любом порядке. В любую секунду. В любой стране этой планеты. Про космос не уверен.
sshikov
13.04.2017 22:09+8Это был сарказм?
PapaBubaDiop
14.04.2017 10:57Наивно верить в безошибочность софта при наличии глючного железа и окружения.
sshikov
14.04.2017 12:15+2Да никто и не верит. Просто вы это так написали, что не сразу поймешь, всерьез это или шутка.
Да и наличие кривых спецификаций уже выше обсуждается. Я кстати, в основном сталкивался с этим. И это глобально не решается на уровне разработчика — хотя бы потому, что к моменту выявления кривизны спецификации проект уже обычно делается много месяцев, и исправлять ошибки аналитиков, или кто там их делал, обычно очень дорого. И делать это почему-то приходится именно разработчикам, как крайним.
PapaBubaDiop
14.04.2017 12:48+1Именно. Но даже при совпадении всех благоприятных факторов идеального продукта не выйдет. Скажем, люди пишут не только программы, но и строят дома. Тысячи лет опыта. Хорошие дома. Отлаженные технологии. Накопленный опыт. Филигранное мастерство. Прекрасное управление. Высокие зарплаты. А все равно! в любом новом доме, небоскребе, коттедже — куча косяков.
Хоть ты тресни.
sshikov
13.04.2017 22:08+2В моей практике было множество примеров, когда менеджмент не умел, а зачастую и не был заинтересован в том, чтобы такое проделывать. Правда, это уже совершенно другая история.
zharikovpro
13.04.2017 22:53-7Судя по минусам, данный пост станет примером того, что и сами программисты зачастую (не всегда!) не умеют и не заинтересованы выпускать ПО без багов. Потому что за исправление багов им платят. И за исправление новых багов снова платят. И нет им конца и края. Одно чинят, другое ломают. Работа всегда есть :)
PkXwmpgN
13.04.2017 23:17+2Потому что за исправление багов им платят. И за исправление новых багов снова платят
Нет, просто люди иногда ошибаются.
zharikovpro
13.04.2017 23:29-5Пусть ошибаются. Право на ошибку священнно. Сначала ошибутся и сделают баг. Потом найдут его и исправят. Будет продукт без бага. Ведь в статье нигде не говорится о том, что продукт СРАЗУ получается без багов. Как верно заметили выше, процесс написания программы это процесс создания багов. Потом начинается тестирование, отладка и баги уничтожают. Процесс разработки ведь не только из фазы написания «с листа» состоит.
sshikov
14.04.2017 12:20+1Извините, но думаю что нет. То есть я конечно видел лентяев и раздолбаев всяких, но уж поверьте — никогда не видел таких, кто любил бы выпускать плохой продукт. Никогда. Причина точно не в этом.
PkXwmpgN
13.04.2017 22:33+1У разработки ПО и промышленного производства много общего
Нецензурная брань%@&?%^&%^#%@$?!#!!!
Antelle
13.04.2017 23:37+4Не надо чинить все баги, иногда на баг нужно забить.
zharikovpro
14.04.2017 00:02-3Если можно забить — это не баг по определению автора статьи. И уж точно не дефект ;)
Antelle
14.04.2017 00:04+2Кто определяет, можно ли забить, и на основании каких показателей?
Автор как-то лихо перечеркнул все существующие способы оценки рисков, призванные ответить на вопрос, когда заняться багофичей, и предлагает заменить их одним человеком-«решителем», который видя тикет, выдаёт ответ, баг это или фича, без всякой возможности оценить это в цифрах. Протекают трубы у всех? Баг. Протекают трубы у одного человека? Ну, мы скажем, что это фича «поддержать такого человека». У половины? Как мне захочется, так и будет. И ведь не поспоришь, потому что баг назвать фичей и наоборот можно всегда. Severity? Priority? Impact factors? Не, не нужно, я сам решу, баг или нет.zharikovpro
14.04.2017 00:27> Кто определяет, можно ли забить, и на основании каких показателей?
В статье автор описал, кто и как определяет в предлагаемом подходе.
> Не, не нужно, я сам решу, баг или нет.
Если ваш продукт требует для решения комиссию — без проблем, пусть будет комиссия. Хотите циферки посчитать? Ок, считаем циферки. Есть разные подходы. У автора конечно подход простой, не всем подойдет. И все же здравое зерно тут есть. Severity, Priority, Impact factors назначает тоже человек. Который тоже «сам решит».Antelle
14.04.2017 00:29+1То есть, у этого человека внутри всё та же самая «не-бинарная» система приоритетов, по которой он оценивает тикеты, но он не хочет чтобы о ней все знали. Но зачем?
zharikovpro
14.04.2017 00:33Я не понял вашу мысль :( Может быть, смогу понять на примере.
Antelle
14.04.2017 00:41+3Вот например:
> Можем ли мы жить с этим дефектом реализации?
> Шрифт должен быть встроен в приложение, но скачивается каждый раз при его запуске.
> Переклассифицируем как улучшение.
То есть, тот человек, который классифицирует, внутри себя на самом деле подумал: так, это аффектит 70% пользователей, при этом приложение запускается медленнее в 2 раза, у конкурента в 50% случаев так же, значит, от приложения откажутся 20% пользователей. Вердикт: жить можно.
Прикол в том, что «жить можно» или «жить нельзя», так просто однозначно не определить, обычно это очень относительно. Потом по какой-то шкале из оценок, потом мы принимаем решение, нужно ли это фиксить сейчас или лучше не надо.
У автора всё то же самое: та же самая система, просто она находится в голове у «решителя», который говорит баг — не баг. Зачем это скрывать в голове одного человека и чем это лучше подхода, когда оценки видят все, мне непонятно.
Отдельные интересные проблемы, вытекающие из предложенного подхода:
— а что делать с уязвимостями?
— как сортируется вся та куча, оцененная как «не баг»zharikovpro
14.04.2017 00:48> У автора всё то же самое: та же самая система, просто она находится в голове у «решителя», который говорит баг — не баг.
Идею понял. В идеальном мире этот «решатель» — заказчик, он же спонсор разработки. По умолчанию все дефект, но есть право вето на его исправление. Если в принципе текущее поведенеие устраивает, то можно и спецификацию поправить. На практике, данные решения споносор/заказчик может делегировать менеджеру по продукту / проекту и так далее.
Мне не кажется, что автор не призывал скрывать оценки. И там, где речь идет про неявные стандарты качества, просто имелось в виду реальное положение дел. Чем очевиднее критерии оценки, тем лучше конечно. И тем более, если они публичные.Antelle
14.04.2017 00:52+1Нет, автор как раз-таки предлагает отменить приоретизацию (когда всё багофича, issue, просто они выше/ниже в списке), заменив её на несколько категорий, вот это срочные баги и их должно быть 0, а остальное — фичи или улучшения, их как-нибудь сделаем.
Я не думаю, что такой подход способен к выживанию.
maxpsyhos
14.04.2017 04:05+2Уже по своему опыту, заказчик — это последний человек, которому стоит давать право классифицировать тикеты. А иначе со временем всё становится багами, причём их критичность определяется не по ущербу от их существования, а по тому, насколько они бросаются в глаза заказчику (даже не всем пользователям).
Vkuvaev
14.04.2017 00:37+3Много лет любителям поиграть в баг или фича, вдалбливаю в мозги, что если продукт коммерческий и клиенты не довольны конкретным сомнительным поведением, разумеется, на которое нет спецификации, то это дефект. Говоря это, имел в виду хотя бы недавний случай, когда заказчик обнаружил дефект безопасности.
lair
14.04.2017 00:10+1Почему же. В спецификации написано "текст должен быть жирным". По факту — не жирный. Значит, дефект, потому что не соответствует спецификации.
Разве нет?
zharikovpro
14.04.2017 00:32-2Разве да. Надо или устранять дефект или править спецификацию. Чтобы одно соответствовало другому.
lair
14.04.2017 11:49+2А можно не устранять и не править, а просто зафиксировать и отложить до лучших времен. Экономия ресурсов.
Что от этого изменится для пользователя? Да ничего (как, впрочем, и от измененной спецификации).
Suvitruf
14.04.2017 00:17Если можно забить — это означает, как вариант, что у бага низкий приоритет, и его можно отложить. В некоторых продуктах такие баги годами живут.
zharikovpro
14.04.2017 00:31И это вариант автор статьи тоже разобрал подробно. Кстати, я бы еще добавил один вариант решения.
Допустим, в спецификации была зеленая кнопка. Программист-дальтоник сделал кнопку красной. Это не по спецификации, но красная кнопка всем очень понравилась. Формально это дефект и кнопку надо делать зеленой. Но если всем, включая закачика это нравится — можно поменять цвет в спецификации. Тогда и дефекта не будет и все довольны.
Также, если годами никто не замечал расхождения со спецификацией, то возможно спецификация была избыточна? Например, кнопка была без тени, а по спецификации должна быть тень в один пиксель. Опять-таки, если никому от этого не плохо — почему бы не поменять спецификацию?
VMichael
14.04.2017 01:40+3Как я понял из разъяснений — священная корова это соответствие спецификации и готового программного продукта.
Но зачем менять спецификацию, если годами никто не замечал расхождений? И если не замечал, то как обнаружили не соответствие спецификации?
Вообще это слишком упрощенный подход.
Мне еще никогда не попадались идеально составленные спецификации (кроме тривиальных случаев, когда и обсуждать то нечего).
Я разрабатывал и руководил разработкой.
Вот представляю как применить рекомендации в работе, получаю сферического коня в вакууме.
(Оговорюсь сразу, коробочных продуктов не выпускал, всегда работал на конкретных заказчиков, говорю только об этой сфере).
Приоритеты расставляют обычно клиенты, заказчики, спонсоры, словом те, кто платит.
Вы можете обзывать багой, можете фичей, но делать придется то, что нужно вышеперечисленным товарищам и в порядке, нужном заказчикам.
Ваши протекающие трубы могут отпугнуть ключевого клиента, который приносит основную прибыль и вы будет их чинить, а горящий складик маленького клиента, в это время, оставят гореть дотла (как вариант).
Вообще любые жесткие правила, как правило перестают работать довольно быстро, если не соответствуют реальным потребностям.zharikovpro
14.04.2017 01:50> Вообще любые жесткие правила, как правило перестают работать довольно быстро, если не соответствуют реальным потребностям.
Тогда возникает ключевой вопрос. Будет интересно узнать ваши комментарии человека с опытом руководства. Если правила перестают работать, то как заключить контракт на разработку? Чтобы с одной стороны заказчик был доволен и деньги получить. С другой — чтобы не затаскали по судам и не заниматься бесконечно бесплатными доработками.
Если есть спецификация — тут понятно. Сделали — получили деньги. Не сделали — не получили. Если нет спецификации но заказчик оплачивает часы — тоже понятно. Только все риски на заказчике, т.к. можно часы оплачивать бесконечно и безрезультатно. А это не в интересах заказчика, какой-то огромный риск, да и продуктивность тогда непонятно как учитывать и оптимизировать.VMichael
14.04.2017 02:17+2Спецификации пишут.
Обсуждают.
И в основном выполняют.
Куда же без них.
Но потом идут нюансы.
И приходится балансировать между двумя описанными вами случаями.
Что бы не уработаться за малые деньги и что бы клиенты не соскакивали.
И бывают крены и в ту и в другую сторону.
Компромиссы в ход идут.
Можно упереться в спецификацию делать четко и терять часть клиентов, оставшихся может быть хватит и быть довольным.
Можно делать часть работы «в убыток», но оставшейся части может быть хватит и быть довольным.
По поводу спецификации, меня в ваших комментариях зацепило, что она легко меняется.
Т.е. нет опоры или ориентира.
Мы сделали не по спецификации, но это здорово, сейчас мы ее подправим под наш результат быстренько и все хорошо, 0 багов.
Или мы сделали по спецификации, пусть говно, но полное соответствие, 0 багов.
И получается, что в реальности, понятие «спецификация» это такое полиморфное образование, которое пускают в ход приведя в нужную в конкретной ситуации форму.
Если вывести понятие «спецификация» за рамки, в остатке будет так:
Делаем, что бы клиенту понравилось и деньги заработать.
Что в общем то и в реальной жизни.
Договорились, написали ТЗ (спецификацию), в процессе работы увидели, что хрень выходит,
обсудили, согласовали изменение ТЗ (разной степени детализации), сроки, деньги, работаем дальше.
И система 0 багов вообще где то в стороне.
Если так просто вывести простые правила и четкую работу по спецификациям (еще любят говорить про четкие сроки и четкие бюджеты с конкретным результатом), то откуда берутся так много провальных ИТ проектов? Тут: http://foykes.com/statistika-uspeshnosti-it-proektov/, говорят что вообще мало успешных. Впрочем прошло несколько лет, может быть сейчас все по другому.
— История описанной в статье команды в общем то проста.
Команду задалбывали «срочными фичами». Пришел некто с полномочиями, ограничил входной поток. Команда стабилизировалась.
Как это обозвать (0 багов, ограничения на спринт, еще как нибудь), не суть.
Суть в том, что ограничили входной поток срочных заявок.
Такие «успешные истории» часто встречаются.
Названия и методики вроде бы разные, но суть одна, в общем то.zharikovpro
14.04.2017 11:48> По поводу спецификации, меня в ваших комментариях зацепило, что она легко меняется. Т.е. нет опоры или ориентира.
Главный ориентир явно или неявно всегда один — заказчик.
> Договорились, написали ТЗ (спецификацию), в процессе работы увидели, что хрень выходит,
обсудили, согласовали изменение ТЗ (разной степени детализации), сроки, деньги, работаем дальше.
Если согласовани изменение — значит согласовали изменение требований/спецификации? Просто не вижу противоречий.
> Суть в том, что ограничили входной поток срочных заявок. Названия и методики вроде бы разные, но суть одна, в общем то.
Все четко и понятно изложили, спасибо. Согласен.
zloyusr
14.04.2017 00:42+2Напомнило, после очередной Agile конференции в кулуарах одним из топ спикеров была высказана мысль:
Agile, как методолию, хорошо продавать, но глупо следовать. Он должен работать, но это не так.
.mrsantak
14.04.2017 02:12+2Agile похож на порно. Процесс разработки с точки зрения agile евангелистов имеет столько же общего с процессом в реальности, сколько процесс показываемый в порно имеет общего с процессом в реальности.
VMichael
14.04.2017 02:22+1Занятные у вас аналогии. :)
Из любой методологии лучше использовать фичи, которые вас зацепили, подстраивая под себя.
Если упорото следовать любой методике, можно надорваться :),
Хотя евангелисты думают иначе, но им это положено.
hamMElion
14.04.2017 00:50+1Можно написать программу без ошибок, но нельзя гарантировать безошибочную работу программы.
А перевели вы хорошо, спасибо.
vesper-bot
14.04.2017 09:42+2Статья рассчитана на идеальный мир, к сожалению. Перевод ОК имхо. Сама концепция очень похожа на "это не баг, это фича". Хотя бэкдор вида "это все-таки баг" оставлен, в реальном мире его вряд ли будут использовать правильно. В этом вся проблема.
kostus1974
14.04.2017 10:22+1применил формулу «нет-больше-слёз» и рассказал об этом в статье про верёвку, которая есть вервие простое.
похоже, он наблюдал за командой идиотов без руководителя. иначе как он мог наблюдать за тем, что команда исправляет на равных уровнях приоритета и явные баги, и простые недоработки?
статья о том, что если вы — команда идиотов, то вы должны нанять такого менеджера, как он, и менеджер разъяснит вам, что есть приоритеты, есть важность, есть ошибки и есть развитие и т.п.zharikovpro
14.04.2017 11:52> как он мог наблюдать за тем, что команда исправляет на равных уровнях приоритета и явные баги, и простые недоработки?
Не только в России работает схема справа :)
lair
14.04.2017 11:51+3Собственно, весь месседж статьи (и именно этим она мне не нравится) сводится к "Баг — это проблема, которую надо решить в первую очередь. Если это не так — это не баг.". То есть автор ввел свое определение бага, и теперь на его основании говорит, что разрабатывать программы без багов легко.
Well, WHAT?
redfs
А, как известно, «Если отладка — процесс удаления ошибок, то программирование должно быть процессом их внесения.» (с) Edsger Wybe Dijkstra
zharikovpro
Есть пусконаладочные работы. По итогу все должно работать как надо. Багов быть не должно. В этом состоянии программа может десятилетиями работать без сбоев. Это и есть Ноль Багов — когда нет ни одного выявленного бага.
redfs
Что касается самой статьи, то ваши выводы ниже о том, что она не нравится программистам, потому что программисты не заинтересованы писать программы без багов… скажем по доброму — натянуты.
Могу объяснить, почему статья не нравится лично мне.
Автор взял за основу некую банальность. Ну, к примеру — «Дети, не балуйтесь, ведите себя хорошо».
Завернул ее в стилистическую обертку «история успеха» — «Я не баловался, и вы сможете!».
Оформил в виде мантры — «Начинайте себя вести хорошо прямо сейчас!».
Себя назначил гуру — «Я расскажу вам, как вести себя хорошо!».
И даже нашел последователей
А по сути, о чём он? Да ни о чём :)