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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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