Комментарии 25
То есть, вы утверждаете, что баг, пропущенный при разработке по водопаду, после релиза, гораздо дешевле бага, который нашли во время тестирования?
Не утверждаю, а можете на материале статьи пояснить как у вас сформировался этот вывод?! Свою логику.
«Водопад» предполагает и включает в себя этап «тестирования». Поэтому когда вы сравниваете ошибку сделанную в разработке ПО по «водопадной» модели, с «нашли во время тестирования» не понимаю о чем вы.
Возможно, вы хотели спросить стоит ли ошибка допущенная по «водопадной» модели разработки дешевле чем ошибка допущенная по какому-либо фреймворку «гибкой» разработки?
Если об этом речь, то сравнивать стоимость устранения ошибок в обоих случаях не возьмусь, скажу что сейчас во фреймворках «гибкой» разработки допускается больше структурных ошибок, так как упор делается на ту выгоду которую можно получить в ближайшей перспективе против долгосрочных целей. Так формируется «технический долг», который потом вылезает в виде новых ошибок.
Вот статья которая это иллюстрирует — Пьеса «Технический долг».
Как это лечить описано в статье «будущее гибкой разработки».
Я выступаю за использование фреймворков гибкой разработки, которые требует от работающих в них более высокой «инженерной культуры», повышением которой мы, пишущие и читающие на Хабре, и занимаемся.
Да заказчикам нужно быстро и дешево, о каком качестве может идти речь)
Видите ли, конечно быстро и дешево. Ведь это такие понятные слова. А если сайт будет подтормаживать, иметь дыры в безопасности, будет сложно добавить новые фичи, а старые будут работать некорректно — это уже вопрос не к менеджерам, а к низкой квалификации разработчиков.
Заказчику нужно быстро и дешево, а если будут проблемы то в этом виноваты конечно же мы, команда разработки, что плохо сделали свою работу. А если мы делаем свою работу плохо, то логично же что нам недостает квалификации. Настоящие же профессионалы работают хорошо, быстро и дешево. — скажет Менеджер / Заказчик.
Только и остается, что наращивать экспертизу, учиться продавать себя и становится Менеджерами-Профессионалами, чтобы быстро и дешево обеспечивать засчёт применения современных технологий и связи с реальностью.
«Чтобы мы были теми переменами которых ищем».
Кстати, в статье этот момент хорошо описан. В самом деле «накосячить» можно в любой момент. Причем если говорить о квалификации, то она влияет лишь на вероятность появления дефектов, но не на их принципиальную невозможность. Собственно из это и появляется вся эта история с задачами контроля качества и вовлечением в процесс персонала разного уровня. Отсюда и возникает мысль, что качество это командная responsibility, начиная от первых контактов с заказчиком и до закрытия проекта.
Хотя в общем направление мысли адекватное, но в статье всё настолько идеализировано и упрощено, что описанное скорее напоминает модель для настольной игры в разработку качественного ПО для детей среднего школьного возраста, нежели реалии нашей работы.
но в статье всё настолько идеализировано и упрощено
Это даётся не просто, через постоянные тренировки.
Тем кто раньше не задумывался о качестве надо с чего-то начинать / раскапывать эту тему, с этими знаниями не рождаются, а вот с темой всё чаще сталкиваются по мере роста компании и разбираться нужно.
И начинать стоит с простого и прагматичного. Затем посмотреть на историях гуру менеджмента качества как эволюционировали идеи про качество и уже отсюда двигаться в ITIL, COBIT, CMMI, SWEBOK и серию ISO.
Внедрять информационные системы типа Atlassian JIRA, чтобы построить учет ошибок и дефектов в разрезе версий выпущенного ПО, планировать их устранения по будущим версиям, автоматически собирать данные о затратах на их устранение, типизировать, по правилу «20 на 80» устранять самые тяжелые.
Осваивать технологии Test Driven Development, Behavior Driven Development, Continuos Integration, Интерактивного прототипирования без разработки.
Наши реалии таковы, что прихожу я в большой банк познакомится с ИТ-директором и он просит меня помочь им продать CI бизнесу (бизнес-подразделениям) при этом говорит что всё что мы можем сказать — сколько это будет стоить (сколько и какого железа и софта нужно будет купить, сколько человек ещё нанять), а вот какой эффект банк и его бизнес от этого получит нет. Также есть серьезная проблема с наличием актуальной документации на текущие эксплуатируемые системы.
В итоге все выглядят как папуасы на острове, увешанные бусами и всякими другими модными штуками, где микроскопом колют кокосы.
Для меня статья немного сумбурная и с немного непонятными выводами.
Вам просто надо по горизонтали отложить этапы разработки ПО начиная от требований, спецификации, кодинга, и заканчивая релизом и передаче пользователю. И для каждого этапа поставить столбик, показывающий сколько стоит устранить ошибку, найденную на данном этапе. Получится интересная кривая, обычно стремительно возрастающая к конечным этапам. Т.е чем раньше в процессе разработки будет обнаружена и устранена ошибка, тем меньше последствия.
Именно поэтому в настоящее время становятся популярны Model-driven-development или Model-Based Design — это когда на этапе требований строится модель ПО, которая уже на этом этапе дает возможность проверить множество требований и устранить множество ошибок путем упрощенного моделирования происходящих процессов, например вычислений, обмена данными между модулями, пользовательских интерфейсов и т.д.
Хуже, что не учтено другое: затраты этого времени есть штука вероятностная; какой-то баг фиксится за 15 минут, а какой-то может и на пару недель потянуть, если скрывает существенный рефакторинг (например, если баг не устраним без смены нижележащей либы).
Хуже, что не учтено другое: затраты этого времени есть штука вероятностная; какой-то баг фиксится за 15 минут, а какой-то может и на пару недель потянуть, если скрывает существенный рефакторинг (например, если баг не устраним без смены нижележащей либы).
ИМХО затраты времени на каждом этапе разработки тем более предсказуемы, чем ближе продукт к финальной стадии. На самом деле, если какой-то баг найден в момент, когда продукт уже зарелизен, то основное время потратится не на его фикс программистом, а на бюрократию — принять баг от пользователя службой поддержки, воспроизведение, документирование и передача разработчикам, фикс(15минут- неделя), пререлиз, тестирование всего продукта по новой, релиз.
Также следует учесть, что такие серьезные баги, как смена либы, должны отсеиваться и фикситься на ранних стадиях разработки, а не в конце. Что опять же ведет к тому, что затраты времени на фикс одного бага ближе к концу проекта составляют примерно константу.
Стоимость качества в разработке программного обеспечения