Изображение сайта tricentis.com
Существующие реалии буквально требуют от разработки программного обеспечения еще больше сокращать время выполнения проекта: от возникновения идеи до выпуска готового продукта. С завидной периодичностью заказчики просят реализовать проект «вчера», чтобы его не скопировал «сегодня» кто-то другой. И, конечно же, бюджет на то, чтобы сделать невозможное, как всегда, ограничен.
Разработчикам ничего не остается, как вновь и вновь заниматься оптимизацией техпроцесса, экспериментировать, пробовать новые методологии. В особо «запущенных» случаях временные резервы ищут буквально в каждом отделе, а не только заставляют разработчиков печатать быстрее.
Оказывается, быстрее могут работать и тестировщики, и менеджеры, и аналитики, и отдел внедрения. Остается всего ничего – придумать, как этого добиться.
На помощь приходят методологии гибкой и стремительной, а иногда и экстремальной, разработки. Это действительно позволяет частично решить указанную проблему.
Изображение сайта quora.com
Модель Agile предусматривает плодотворное взаимодействие отделов разработки и тестирования, осуществляемое в соответствии с общими целями, общими правилами и общими критериями эффективности.
Agile стал достоянием широкой общественности в 2001 году.
Гибкая разработка сводится к серии коротких циклов, называемых итерациями, которые обычно длятся две-три недели. Каждая итерация сама по себе выглядит как программный проект в миниатюре и включает все задачи, необходимые для выдачи мини-прироста по функциональности: планирование, анализ требований, проектирование, программирование, тестирование и документирование. По окончании каждой итерации команда выполняет переоценку приоритетов разработки.
Подразумевается, что «гибкий» программный проект готов к выпуску в конце каждой итерации. Однако на практике это происходит далеко не всегда и не так быстро, как теперь хочется клиентам.
Кроме того, разработка замедляется из-за того, что у различных подразделений, участвующих в создании программного обеспечения, нет общих инструментов и отсутствует возможность делиться полученными знаниями.
Каждое из подразделений выполняет собственные задачи и пользуется разными критериями оценки эффективности своей работы. Для разработчиков — это скорость написания и количество реализованных в программном коде функций, для тестировщиков — число выявленных ошибок, для отдела эксплуатации — стабильность функционирования систем и минимальное количество инцидентов. Подобная модель работы нередко приводит к конфликту интересов: первые стараются как можно быстрее написать код и отдать его на проверку, вторые готовы проверять и тестировать сколь угодно долго, чтобы выявить все баги, а третий с трудом принимает код, поскольку любые изменения влекут за собой потенциальные риски для всей ИТ-инфраструктуры.
Выяснилось также, что отдел эксплуатации – это еще одно слабое звено, которое остается «за рамками» модели Agile.
В 2009 создатели DevOps вселили в широкую общественность надежду на светлое будущее.
Вот так формулируются благородные цели DevOps:
DevOps (development и operations) — методология разработки программного обеспечения, нацеленная на активное взаимодействие и интеграцию специалистов по разработке и специалистов по информационно-технологическому обслуживанию. Базируется на идее о тесной взаимозависимости разработки и эксплуатации программного обеспечения, и нацелена на то, чтобы помогать организациям быстрее создавать и обновлять программные продукты и сервисы.
Стоит отметить, что Agile – не является непременным условием для реализации DevOps.
Clyde Logue, основатель StreamStep, говорит об этом так: «Agile сыграл важную роль в разработке для восстановлению доверия у бизнеса, но он нечаянно оставил IT Operations позади. DevOps это способ восстановления доверия ко всей ИТ-организации в целом».
В DevOps Cookbook и The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win, описаны лежащие в основе принципы, с помощью которых все DevOps паттерны могут быть получены с помощью подхода «Три пути»:
Первый Путь подчеркивает производительность всей системы в целом, в отличие от производительности отдельного звена или отдела.
В центре внимания находится все бизнес-потоки по созданию ценности, которые включены в IT.
Второй Путь заключается в создании петли обратной связи идущей справа налево. Целью практически любой инициативы по совершенствованию процесса является сокращение и усиление обратной связь, чтобы необходимые поправки могли внедряться постоянно.
Третий путь заключается в создании культуры, которая влияет на две вещи: постоянное экспериментирование, которое требует принятия рисков и извлечение уроков из успехов и неудач, а также понимание того, что повторения и практики являются предпосылкой к мастерству.
По словам многих заказчиков, ценность описанного подхода состоит в том, что он позволяет получить полную картину модели разработки — с участием абсолютно всех заинтересованных сторон, с четко обозначенными процессами и интеграционными механизмами.
Мы попросили экспертов ответить на несколько вопросов, чтобы узнать, как обстоят дела с DevOps в русскоговорящем мире.
Евгений Оглоблин, DevOps компании из крупнейшей российской тройки:
1. Каким компаниям подходит DevOps?
Мне кажется, что в достаточной степени любым. Крупным – потому что это позволит ускорить разработку, тестирование и релизы продуктов, маленьким – потому что все будут вовлечены в процесс, появится некоторое подобие взаимозаменяемости сотрудников.
2. Насколько глубоко понимание DevOps в русскоговорящем сообществе?
У нас еще очень много «классических админов», которым про продукт вообще не интересно. У них FreeBSD 8 или CentOS 5, все работает и кушать не просит. Значит, и изобретать ничего не нужно.
Плюс сопутствующая DevOps'у автоматизация подразумевает достаточно много работы, зачастую — с новыми технологиями, иногда вообще не известными людям.
Внятно объяснить, что же такое DevOps, по-моему, до сих пор никто не смог — в любой компании есть свои тонкости, наследие и тому подобное. В общем случае все сходятся на мнении, что это автоматизация, стандартизация и более активное участие отдела эксплуатации в разработке, но этих «всех» не так много, если считать в процентах от общего количества IT-людей.
3. Каковы преимущества DevOps?
В случае успешного внедрения DevOps компании могут в перспективе рассчитывать на:
- автоматизацию (снижение рисков человеческой ошибки)
- ускорение и упрощение процессов разработки и релиза
- получение быстрой обратной связи от пользователей (метрики, мониторинг)
- PROFIT!!!
4. Каковы недостатки DevOps?
Нужно очень много поработать.
Нужно не забывать про до сих пор актуальные best practices предыдущих поколений – в море новых технологий сделать это легко.
DevOps по разным причинам может не подойти коллективу, пытающемуся внедрить сабж.
DevOps — не серебряная пуля (а жаль).
5. Насколько широко распространился DevOps в СНГ / России?
В компаниях-лидерах IT-рынка — широко распространился. Хотя, как водится, есть исключения. Но живые компании все чаще понимают необходимость современных методологий.
Евгений Потапов, генеральный директор ITSumma:
1 Каким компаниям подходит DevOps?
Существует несколько значений термина, несколько пластов понимания, что же такое DevOps.
Если мы говорим о культуре взаимодействия разработки и эксплуатации, где программисты понимают, как работают системы, и обладают навыками системного администрирования, а администраторы понимают принципы разработки, то это несомненно надо любой компании, поскольку такой плотный контакт обеспечивает простоту взаимодействия и скорость решения задач, которые часто лежат на границе этих областей.
Если же мы говорим о наборе конкретных практик, связанных с виртуализацией, контейнеризацией, автоматизацией управления инфраструктуры, то здесь самое главное, что компания (а главное сам проект), должна достичь такого размера, при котором накладные расходы на организацию этих практик будут ниже, чем накладные расходы на управление инфраструктурой без них.
2 Насколько глубоко понимание DevOps в русскоговорящем сообществе?
В наш 21-й век различия между сообществами разных стран не настолько сильны, как можно подумать. Да, мы несколько отстаем по времени начала применения новых технологий по сравнению, прежде всего с компаниями Долины, однако это вопрос месяцев, не лет.
3 Каковы преимущества DevOps?
Упрощение коммуникации между специалистами ведет к ускорению взаимодействия.
Пропадает классическая проблема, где программисты винят во всем работу серверов, а администраторы отвечают, что проблемы создает код.
Ускоряется как создание новой функциональности, так и решение старых проблем.
Автоматизация же позволяет избавить от извечной рутины и хаоса в ИТ-проектах.
4 Каковы недостатки DevOps?
Самая главная проблема, которую мы сейчас видим связана не столько с самой методологией DevOps, сколько с повышенным вниманием и ажиотажем вокруг любой новой технологии или практики, когда они применяются не по необходимости, а из интереса к самой технологии.
Зачастую накладные расходы на внедрение и поддержку практик автоматизации, таковы, что даже не ускоряют, а замедляют процессы внутри компании.
Да — иметь возможность часто обновлять код проекта — действительно важно, но как часто небольшому проекту надо иметь возможность выкладывать код ежедневно, десятки раз на дню?
При этом человеческие и денежные затраты на поддержание этой возможности довольно велики.
5 Насколько широко распространился DevOps в СНГ / России?
Существуют развитые сообщества DevOps-специалистов, проходят митапы, выходят отличные книги:
- www.facebook.com/groups/feedme.ru
- www.facebook.com/groups/1418742661718580
- devopsdeflope.ru
- telegram.me/devops_deflope
- eksmo.ru/book/proekt-feniks-roman-o-tom-kak-devops-menyaet-biznes-k-luchshemu-ITD583259
Авторы книги DevOps Cookbook и The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win выделяют следующие бизнес-преимущества DevOps:
- быстрый выход на рынок (сокращение времени цикла и более высокие темпы развертывания);
- повышение качества (повышение доступности, меньше сбоев и так далее);
- увеличение организационной эффективности (больше времени тратится на деятельность, связанную с увеличением ценности продукта и количества функционала).
P.S.
Возможно следующим этапом оптимизации командной разработки будет введение телепатической связи между сотрудниками всех отделов и даже с заказчиками.
Комментарии (32)
ZaEzzz
22.07.2016 23:10+6Прочел статью и ничего не понял. Начал искать блог какой компании и не нашел. Странно.
Я знаю зачем и кому нужен DevOps, но из статьи это совсем не понятно. Вроде и круто, но не понятно зачем.
JediPhilosopher
22.07.2016 23:51+4Внятно объяснить, что же такое DevOps, по-моему, до сих пор никто не смог
Мне одному кажется странным такое количество статей по предмету, который никто даже не может внятно определить?
grossws
23.07.2016 02:48+2На помощь приходят методологии гибкой и стремительной, а иногда и экстремальной, разработки. Это действительно позволяет частично решить указанную проблему.
Хороший ряд. Прекрасно иллюстрирует непонимание термина XP. Ставлю за него заслуженный минус.
В продолжение ряда стоит добавить PP:
Есть экстремальное программирование (XP), а есть психопатическое (PP). Основные приемы и методы его:
- Проект всегда начинается в пятницу вечером и должен быть закончен к понедельнику
- Изменения в проект вносят тестировщики и админы
- Иногда еще уборщица и генеральный директор
- ТЗ отсутствует
- Выбор архитектуры происходит после написания кода
- И меняется не менее двух раз
- В день
- На продакшен-сервере стоит ПО пятилетней давности, а на тестировочном — последние версии
- День сдачи проекта — вчера и не может быть изменен
- Команда меняется каждую неделю
- Руководитель команды меняется каждый день
- Документация ведется на бумажках, приклеенных к монитору
khanid
23.07.2016 11:29На продакшен-сервере стоит ПО пятилетней давности, а на тестировочном — последние версии.
Бывали случаи, когда всё было наоборот. Производитель софта работает с окружением пятилетней давности, хотя могла уже поменяться даже не одна мажорная версия компонентов этого самого окружения.
lostpassword
23.07.2016 16:45+3Документация ведется на бумажках, приклеенных к монитору
Ага, так она всё-таки ведётся!
khanid
23.07.2016 11:27+1На помощь приходят методологии гибкой и стремительной, а иногда и экстремальной, разработки. Это действительно позволяет частично решить указанную проблему.
Но это же ненормально! Самим загонять себя в рамки постоянного экстрима. Работа должна быть планомерной и постоянной.
Состояние экстрима, как по мне, это не решение проблемы. Это латание дыр. И на позиции постоянной методологии будет приводить к тому, что где-то у нас что-то прохудится, и опять понадобятся костыли. Тем более что внятно объяснить, что же такое DevOps, опять мало кто может. Получается эдакая многорукая шива. Эникей 80го лвла. Если эникеи занимались всем простым и плюс некоторым администрированием, то тут получается смесь занимается администрированием и плюс программированием и разработкой продукта на постоянной основе. Ну если я правильно понимаю суть этого самого DevOps. Тогда ошибки неизбежны.
Экстрим на то и экстрим, и, опять же, по моему разумению, не надо возводить его в практику, используемую на постоянной основе.
VolCh
23.07.2016 13:38Каждое из подразделений выполняет собственные задачи и пользуется разными критериями оценки эффективности своей работы. Для разработчиков — это скорость написания и количество реализованных в программном коде функций, для тестировщиков — число выявленных ошибок, для отдела эксплуатации — стабильность функционирования систем и минимальное количество инцидентов.
Странные оценки. Для разработчиков разве что более-менее адекватно, если считать, что реализованной является функциональность не содержащая критических ошибок. Для чего нужно определение критических ошибок, скажем, непрохождение основных юзкейсов реальным пользователем
Для тестировщиков критерий эффективности должен быть: число багов, которые они не заметили, а заказчик/пользователи заметили. Меньше — лучше
Для эксплуатации: число инцидентов в их зоне ответственности (меньше — лучше) и точное распределение остальных инцидентов по другим подразделениям и(или) специалистам, когда назначенный на инцидент специалист решает проблему самостоятельно или переадресует её по иерархии или отбрасывает, а не тратит время на изучение, а потом понимает что это не его зона отвественности (меньше неверных назначений — лучше)
VolCh
23.07.2016 13:48А вообще наблюдаю не в ИТ-компаниях со своими подразделениями разработки (пускай даже из одного человека) в странах бывшего СССР, что обычно эксплуатация не заинтересована во вникание в разработку, часто максимум взаимодействия «скажи какие пакеты поставить, а дальше сам настраивай и деплой» и «место на диске скоро кончится, разберись почему и лучше сам исправь». Грубо говоря, эксплуатация без разработчика не способна ни развернуть разработанное приложение, ни точно локализовать проблему — хотя бы в коде она, в железе, или в конфигах. А разработчики занимаются этим по принципу «если не я, то кто?» не сказать, что с большой мотивацией обычно, особенно когда общее руководство критикует что разработке мало времени в итоге уделяется.
o_serega
24.07.2016 20:15Я видел и обратную картину, точнее часто наблюдаю, когда на 30 разработчиков 5 — 6 которые не то, что понимают как сие дело будет работать в боевых условиях, хотя бы могут сами себе развернуть dev окружение. Зачастую картина, когда есть виртуалка, которую сделал тимлид или кто-то из тех 5 — 6 разрабов, кто может, а остальные ее тупо себе тырят, сейчас дело ушло в сторону dockerfile)))
Вот классика DevOps инженера которую я наблюдаю: был когда-то он админом, потом надоело скучно даминить — ушел в разработчики, через пяток лет надоело скучно писать код — тут появился devops, ушел в него, ибо имеет опыт как со стороны эксплуатации так и со стороны разработки, да и о тестировании тоже. Теперь он сидит пилит «инфраструктуру как код» (кстати именно пилит, процесс затяжной и нифига не законченный, да и конца и края этому не видно) и тыкает горе разрабов носом в их «код»)
AlexLeonov
23.07.2016 21:28+2Я ничего не понял.
Вот честное слово — руковожу немалой (по количеству человек-и-часов) разработкой — и не понял, о чем эта статья.
Причем тут вообще Agile? Как методика разработки относится к тому, что «админы должны быть частью команды» (а это и есть суть термина dev-ops)?
Виртуализация и контейнеризация — это dev-ops? Странно, а я всегда думал, что это просто полезные инструменты для администрирования и управления инфраструктурой…
Да — иметь возможность часто обновлять код проекта — действительно важно, но как часто небольшому проекту надо иметь возможность выкладывать код ежедневно, десятки раз на дню?
Да всегда, блин. Всегда. Человек, отрицающий необходимость CI — эксперт?
Статья больше вводит в заблуждение, нежели рассказывает о действительном предназначении dev-ops: уменьшать себестоимость процесса разработки путем автоматизации, интеграции «сисдадминов» в общий флоу и избавления программистов от функций, несвязанных с программированием.VolCh
24.07.2016 14:55действительном предназначении dev-ops: уменьшать себестоимость процесса разработки путем автоматизации, интеграции «сисдадминов» в общий флоу и избавления программистов от функций, несвязанных с программированием.
Разве такое предназначение девопса? Мне казалось, что уменьшение срока реализации бизнес-требований (для многих бизнесов лучше внедрить фичу, увеличивающую входящий денежный поток, или исправить баг его уменьшающий, дороже, но быстрее, нормальный бизнес мало интересует себестоимость фичи или багфикса (в разумных пределах), если её реализация обеспечивает прибыль больше нормальной)
Всё остальное это средство. Причём избавление программистов от функций не связанных с программированием, это и ни необходимое, и ни недостаточное условие. Часто бизнесу выгоднее наложить именно на программистов как минимум часть ответственности, не связанной непосредственно с программированием, чем на других имеющихся специалистов, не говоря о найме новых.AlexLeonov
24.07.2016 16:49+1Я считаю, что да, именно такое.
То, что вы пишете, про сокращение срока реализации — это и есть себестоимость. Себестоимость = рейт * время.
Любое управление производством в IT — это, имхо, управление себестоимостью. А для этого надо или резать косты (средний админ дешевле среднего разработчика, поэтому пусть именно он занимается задачами типа «обновить PHP на всех инстансах» и даже задачами «протестируй, что отвалится про обновлении PHP?»), либо резать время (и опять же мы приходим к тому же самому — программист должен только программировать, всё остальное либо автоматизируется, либо исполняется более дешевыми исполнителями)VolCh
25.07.2016 13:20Да, себестоимость есть рейт * время, но бизнес часто согласен на больший рейт ради минимального времени. Бизнес минимизирует время, а рейт служит стоп-фактором. Грубо, бизнесу не нужна клевая фича через год бесплатно, не нужна через день за сто штук баксов, а между через месяц за десять и через два за пять выберет через месяц за десять. При условии, конечно, что по оценкам внедрении фичи на месяц раньше принесёт как минимум на 5 штук больше. И при условии, что есть эти десять штук, которые более выгодно вложить возможности нет.
Нет, имхо, главное — управление сроками (не человеко-часами, а календарными) при приемлемой для заказчика (внутреннего или внешнего) себестоимости. Практика качественного уменьшения себестоимости часто приводит к полному фейлу проекта, причём не только по срокам, но и вообще по функциональным и нефункциональным требованиям бизнеса.AlexLeonov
25.07.2016 13:38бизнес часто согласен на больший рейт ради минимального времени
Это и есть управление себестоимостью.
Нет, имхо, главное — управление сроками
Сроками управлять невозможно, потому что любая фича нужна до того, как потребность в ней вербализуется. Любой поставленный срок — уже факап.
Практика качественного уменьшения себестоимости часто приводит к полному фейлу проекта
Не наблюдал такого. А вот полный фейл по причине «мы не заметили, как кончилось бабло» — видел и не раз.VolCh
25.07.2016 13:50Это и есть управление себестоимостью.
Нет, это управление временем. Крайне редко ставится задача «вписаться в фиксированный бюджет и не важно сколько времени займёт».Сроками управлять невозможно
Очень спорно
Не наблюдал такого
«Зачем платить сеньору N денег, возьмём 5 джунов за N/10 денег каждому денег и получим тот же результат» — не знакомо?AlexLeonov
25.07.2016 13:56+1Задача «вписаться в бюджет» не имеет никакого отношения к управлению проектом по себестоимости, о которой я говорю. Это вы что-то себе на ходу придумываете и на ходу же опровергаете.
Повторю еще раз.
Любая фича нужна вчера. Любые сроки срываются. Эти два утверждения делают управление по календарным срокам чем-то сродни шаманству или SEO — невозможно всерьез разговаривать со специалистом, который уверяет, что кнопка будет в понедельник и НИКОГДА не держит свои обещания.
Единственный приемлемый (имхо) способ управления разработкой — это управление от себестоимости. Сколько нам будет стоить эта фича? Ответ на этот вопрос отрезвляет бизнес, позволяет сразу и легко определить приоритеты, сформировать производственный план и управлять ресурсами в непрерывном режиме.
Задача же руководителя проекта — минимизировать себестоимость бизнес-value. В том числе и путем ускорения их разработки и внедрения.
Каждый час проведенный фичей в стеке задач — это чистый убыток. Как только приходит понимание этой простой истины — всё начинает вертеться со страшной скоростью, любители воткнуть везде mongodb, потому что «это модно и писали на хабре» с треском увольняются, а бизнес начинает видеть простой и понятный результат каждый день.
«Зачем платить сеньору N денег, возьмём 5 джунов за N/10 денег каждому денег и получим тот же результат» — не знакомо?
Я обычно с идиотами не работаю )))VolCh
25.07.2016 14:58Так в том-то и дело, что на вопрос «сколько нам будет стоить фича» ответить можно только после уточнения «а за какой (календарный) срок?». Себестоимость — функция от календарных сроков, в том числе определяющая каких специалистов и какой квалификации нужно привлекать, чтобы уложиться в нужный срок. Фича нужна вчера — будет завтра за 100 000, согласны подождать месяц — будет стоить 10 000, согласны подождать два месяца — будет стоить 5000, согласны подождать год — будет бесплатно.
AlexLeonov
25.07.2016 15:17Себестоимость — функция от календарных сроков
Именно в этом месте вы кардинально неправы.
Всё в реальности обстоит строго наоборот.
Срок — функция от себестоимости. Причем нелинейная. Есть предел, после которого увеличение рейта не приведет к сокращению времени, ровно как и есть предел, после которого увеличение времени на разработку не даст нового business-value.
Всё это
Фича нужна вчера — будет завтра за 100 000
— обычно фантастика, в которую верят начинающие PM-ы. Если индексирование базы длится трое суток, никто вам ни за какие деньги его за сутки не сделает ))
vyatsek
24.07.2016 20:14+2В моем понимании DevOps — это такой Software Any key, который знает как работает софт и знает как работает окружение и поддерживает работоспособность сервера.
Если брать по-старинке, то это отдел эксплуатации. В маленьких компаниях этим занимаются как правило админы+разработчики.
«Методология DevOps» — маркетинговый булшит.AlexLeonov
24.07.2016 21:19+1Добавьте к вашему определению еще «знает, чем занимаются разработчики и что им нужно». И тогда будет почти идеально.
varnav
24.07.2016 22:45DevOps — это, упрощённо, «сисадмины разработки». В противопоставление классическим «сисадминам эксплуатации» Что, кстати, чётко следует из названия.
VolCh
25.07.2016 13:29-1«Методология DevOps» означает декларирование отсутствия чёткой границы между зонами ответственности эксплуатации и разработки. Или путём создания «выделенных» ролей «девопсов», либо постоянной совместной работы эксплуатации и разработки.
it4lpr
25.07.2016 10:22непонятна четкая сфера… 20 лет в ИТ и не понимаю, какой % и какую нишу закрывает этот devops. Что нужно бизнесу? И какому бизнесу? Есть биз, который потребляет ПО — тут один devops — весь спрос с эксплуатантов, они точка контакта с бизом (работающим, а не заказывающим).
Есть биз по созданию ПО под заказчика. Второй вариант. Есть биз по созданию ПО, которое и есть суть твоего бизнеса (пример — Танки).
раз это слитно написали, то смысл в уменьшении издержек на коммуникации (всех видов: и косты и время и нервы и риски) между dev и ops. То есть это методология, которая увеличивает стоимость привносимую разными ИТ-подразделениями. В пределе это методолгия должна развиться в лучшие практики организации взаимодействия ВСЕХ тех.подразделений, таким образом, чтобы для биза — это было единым целым(во-первых), а во-вторых — не монстрообразным ит-департаментом с «неповоротливыми» процессами, а подобием настраиваемого (в идеале в любой момент) автомата.
amarao
Заменяем слово devops на «сепульки», а agile на «сепуление» и смысл статьи не меняется.
Shapelez
Так можно всё что угодно поменять без риска для смысла — язык, он такой. Да и люди не глупые.
amarao
Нет. Если мы возьмём фразу «При написании юнит-тестов использование адаптеров к внешним зависимостям вместо мока самих зависимостей позволяет использовать стабы для фиксации внутреннего стабильного интерфейса, выделяя проверку соответствия внутреннего интерфейса внешнему в интеграционные тесты», и в этой фразе заменим любое непонятное слово на «сепулька», то фраза перестанет быть осмысленной.
А в этой статье если в фразе «Модель Agile предусматривает плодотворное взаимодействие отделов разработки и тестирования, осуществляемое в соответствии с общими целями, общими правилами и общими критериями эффективности.» если мы напишем «Модель сепулек предусматривает плодотворное взаимодействие отделов разработки и тестирования, осуществляемое в соответствии с общими целями, общими правилами и общими критериями эффективности.», то ничего не поменяется, потому что взаимодействие «плодотворное», имеет «общие цели и правила» и следует «общим критериям эффективности».
Shapelez
Стабы = сепулька. Юнит-тесты = сепуления. Не вижу разницы, совершенно одинаковые риторические упражнения.