“Тошнит уже от ваших Скрамов и Канбанов…”

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

Итак, началось все вот с такого комментария. Вот самая интересная часть, из-за которой разгорелась дискуссия:

Правда вот я что понял: Николай всегда всё про интернеты и интернеты, но кроме «интернет-софта» есть ещё много другого разного и не везде ваши подходы (да и ваще эджайл) применим. А от повальной увлечённости Скрамом и Канбаном просто тошнит уже.

Впрочем я тоже считаю, что чистый Quality Control не нужен, Quality Assurance – то есть когда происходит реальное тестирование до написания первой строчки кода и убирается любая двусмысленность в том что и как нужно реализовывать и в каком порядке – это идеальный вариант. А потом тестирование чисто юнит-тестами и «автоматизацией» + небольшой QC перед релизом и всё ок.

Вообще у программистов должно быть минимум свободы и минимум вариантов для выбора как реализовывать. Свобода – это рабство, жаль, что всякие ратующие за «полёт творчества» в ИТ этого не понимают.

И тут мы оставили тестирование и пустились в разбор процессов. 🙂 Вот мой ответ:

Много другого-разного конечно существует, но давайте посмотрим реалиям в лицо. Какая разница с какого типа проектами использовать Scrum или Kanban? Это процессы, которые позволяют организовать работу над любого рода проектом (даже не IT). У вас есть свой процесс, который лучше и помогает вам делать быстро и качественно проекты? Расскажите о нем, напишите.

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

Вот такой последовал ответ:

«По поводу свободы и вариантов реализации вы заблуждаетесь. » – да ладно, хотите поспорить с Оруэллом? Вы ж не забывайте, что «незнание – сила» в дополнение к «свобода – это рабство». То есть правильный подход – это когда те, кто разрабатывают – делают всё в жёстких рамках, а те, кто пользуются – максимально ограничены в возможности выбора и всё закрыто защитой от дурака и нет никакой информации о возможности что-то как-то менять. Шикарный пример – продукция компании Эппл.

«И тут тестирование – это не банальщина, потому что надо оценить насколько решение справляется с поставленной задачей.» – если обрезать все двусмысленности, нечёткие трактовки и детализировать принципы работы системы, жёстко формализовать дизайн по всем аспектам, то реально если не 90, то минимум 80% тестирования, которое требует внешнего контроля (мануальное или полуавтоматическое, всё таки человеческий фактор убрать хрен получится, автотест не скажет «не удобно») можно перевести в процессы до написания первой строчки кода, причём первая имплементация потребует больше тестирования, но чем дальше в лес – тем меньше будет требоваться прямого тестирования, при этом при планировании нового функционала или обновлений будет намного проще убрать лишние риски и уточнить реально важные детали.

Становится интереснее и я принял вызов:

Тут есть одно весьма строгое допущение – «жёстко формализовать дизайн по всем аспектам». Если вы про дизайн и архитектуру кода, то сделать это практически невозможно. В современных проектах они никогда не зафиксированы и всегда находятся в состоянии развития. Вы по-моему пытаетесь применить немного старомодное мышление: зафиксируем требования, зафиксируем дизайн, статически это протестируем, а уже потом за код сядем. Не работает! Доказано практикой многих лет многими проектами…

Но получил вот такой ответ, который задел за живое (именно поэтому решил перенести в отдельную статью эту дискуссию):

Как раз строго наоборот, практика многих лет разработок чего бы то ни было говорит обратное: чем жёстче стандартизация и чем выше требования соблюдать изначальный дизайн от А до Я – тем выше качество результата. То есть если к разработке ПО применить методики разработки, к примеру, марсоходов или ядерных бомб – качество ПО возрастёт.

«В современных проектах они никогда не зафиксированы и всегда находятся в состоянии развития.» – и это адовая проблема, отсутствие жёсткого контроля за происходящим порождает беспредел. То есть не просто «контроля» – контроль как бы есть, но есть отличное мнение, что если раз дать откусить палец, то в следующий раз отгрызут руку, поэтому контроль быть жёстким, а отношение таким: налажал – отгребаешь. Я не ошибусь, если скажу, что сча весь код всего десктопного и мобильного софта состоит из говна и заплаток. Из всего софта, что я пользовал за последний год единственным решением, которое не содержало явных и очевидных глюков – это Вин8, причём чисто сама ось+вин эксплорер, без учёта метро-софта и родного десктопного софта – там ещё тот адок. И то – официально уже вроде 20 апдейтов или даже больше встало, но это всё таки ОСь – многкомпонентная система. А так то релизы один глюкавее другого, все соревнуются не в качестве, а в скорости выпуска, в результате софт превратился в бесконечный поток ширпотребного поноса, который вылетает, глючит и обновляется каждый день, потому что «нафига тестировщики нужны?» или потому что «мы всё сделаем по ХР и со Скрамом». Мир сходит с ума, одни слушают Адель, Бибера и Леди Гагу, другие релизят каждый день новую версию продукта, потому что отладить, отдебажить и месяц-два потестить – нет времени. А о нормальном планировании я вообще молчу. Эхх, нет сча эффективного менеджмента, Ден Кеннеди абсолютно прав.

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

  • Это проекты повышенного риска, поэтому ошибка стоит слишком дорого. Все прорабатывается на детальнейшем уровне именно поэтому.
  • Это проекты с гигантскими бюджетами, причем часто именно из госсектора. Денег просто немеряно и поэтому они могут себе позволить такую роскошь как делать медленно и до мельчайших деталей все продумывать.
  • Туда нанимают очень и очень толковых товарищей. Маловероятно, что кто-то экономит на таких проектах, отдавая их в Украину на аутсорсинг, причем в наши известные большие компании. Работа недавних студентов просто убила бы пару миллионов человек в итоге. 🙂
  • Эти проекты никуда не торопятся. Есть сроки, но их очень часто пропускают и идут дальше. И это никого не волнует. Важен результат. В коммерческих продуктах это почти невозможно – всех интересует результат и в кратчайшие сроки (или хотя бы в назначенные).
  • Доменные задачи в таких проектах решаются уникальные, которые никто до этого не делал. В подавляющем большинстве проектов коммерческих это не так. Даже если бизнес идея и отличается, то архитектурно решения подобные существуют.

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

Вдобавок, уменьшается стоимость дефектов. Многие проекты четко контролируют работоспособность основного критического для бизнеса функционала. Если нашелся дефект где-то еще, то это не беда. Оно никак не повлияет на бизнес и дешевле быстро починить и накатить обновление. Поэтому, частые релизы – это не от глупости менеджеров или их неграмотности. IT очень быстро меняется и требования к разработке растут с каждым днем. Кто-то может их удовлетворить, а кто-то может пенять на отсутствие “эффективного менеджмента”…

Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!

Обсуждение (9)

вспомнил об этом треде:
“- Firefox и Chrome обновляются раз в месяц как минимум” – и они бажны, Опера после перехода на такую модель – глюк на глюке.
“Многие SaaS платформы обновляются по несколько раз в день:” – это багофиксы, “обновляются” – ну не нужно так, а? вы реально считаете, что там обновляют всю платформу целиком каждый день?
“- Сейчас даже некоторые «неповоротливые» приложения стараются хотя бы раз в пару недель выпускать версию (программы для онлайн оплат, банковский софт)” – увольте, не версию, а набор багофиксов и новые глючные недотестированные фичи с новым номером, например 1.2.4.45334

“Там по линке рассказ в том числе о том как ребята тестировавшие софт для управления марсоходом Curiosity реверс инжинирили из логов его спеки.” – то есть вы отрицаете, что модули марсохода были жёстко утверждены и тестировались много лет, чтобы убедиться, что марсоход не умрёт и выдаст качественные резалты и вовремя? хм

Не знаю за кем вы следите, но:

– Firefox и Chrome обновляются раз в месяц как минимум
– Многие SaaS платформы обновляются по несколько раз в день: Flickr, Twitter, Amazon и т.д.
– Сейчас даже некоторые “неповоротливые” приложения стараются хотя бы раз в пару недель выпускать версию (программы для онлайн оплат, банковский софт)

Причину этого я вам уже описывал. Но вы отказываетесь ей внимать. 🙂

я последние лет 10 очень внимательно мониторю рынок софта и чото я не заметил, чтобы “частые релизы” (то есть чаще, чем раз в квартал были чем-то иным, чем длиннющие списки багофиксов.
У всех производителей под все платформы. А реально допиленные по функционалу продукты как выходили раз в полгода/раз в год – так и выходят. То есть во всём мире процесс и квалификация людей – говно? Увольте. Я говорю не о “теоретическом смысле”, а о практической реализации. Частые релизы нужны, чтобы а) не иметь команды тестирования, б) фиксить баги найденные конечными пользователями, в) тестировать новый функционал прям на конечных юзерах и иметь возможность быстро допилить его/выпилить, если не юзается, опять же на основе отзывов пользователей.

Могу сказать, что обновление софта чаще, чем раз в полгода меня, как пользователя, бесит неимоверно и хочется выжигать напалмом придурков, которые не могут тупо допилить нормально одну версию, а потом нормально запилить вторую. Не, ну там какое-то накопительное обновление с багофиксами не помешает, но внедрять бажный функционал в каждом релизе каждые 2-4 недели – да просто жесть же, Аушвиц по таким девелоперам плачет.

Основная задача частых релизов это снижение рисков “выпустить не тот продукт”, например. Есть еще несколько “основных задач” и фикс дыр там отсутствует. Он наоборот местами становится в разы сложнее.

Там по линке рассказ в том числе о том как ребята тестировавшие софт для управления марсоходом Curiosity реверс инжинирили из логов его спеки.

Основная задача частых выпусков – не держать уже готовый функционал “на полке”, а тут же выпускать его в жизнь и заставлять приносить деньги. У кого это только фикс дыр, стоит серьезно задуматься над процессом и квалификацией команды. 🙂

“ЗЗЫ: Частота релизов и уменьшение стоимости дефектов это не очень кореллирующие вещи.” – вообще не коррелирующие )), но основная задача “частых выпусков” – это как раз фикс дыр, найденный в предыдущих версиях
“Вы не поверите, но у марсохода небыло жестких спецификаций и часть они фактически реверс инжинирили из логов работающего прототипа: http://compass.informatik.rwth-aachen.de/ws-slides/havelund.pdf” – эммм, какого марсохода, кто что конкретно реверс инжинирил?

я, кстати, отлично отношусь к Agile и пытался популяризировать его у нас ещё в 2006-м, а в 2008-м даже читал внутренние тренинги по процессам с упором на принципы ХР и Agile в целом. Дискуссию поддержу, только чуть позже – пятница, атчиоты ))))

Сам вчера участвовал в теме, где хейтили принципы agile и так далее. Все чаще такие споры происходят из-за ЧСВ автора, а не из-за желания найти истину. А жаль. Картинка в тему http://img.playground.ru/images/2/5/tolstokvashino.jpg

Повторю еще раз:
Вы не поверите, но у марсохода небыло жестких спецификаций и часть они фактически реверс инжинирили из логов работающего прототипа: http://compass.informatik.rwth-aachen.de/ws-slides/havelund.pdf

ЗЫ: А что за сказки про бесконечный бюджет проектов госпроектов? Той же NASA его вообще-то активно режут последние много лет.
ЗЗЫ: Частота релизов и уменьшение стоимости дефектов это не очень кореллирующие вещи.

Leave a Reply

Your email address will not be published. Required fields are marked *