Несмотря на то, что Agile появился около 20 лет назад, более-менее активно применять его начали только в течение последних восьми лет. Гибкие принципы возникли как альтернатива традиционным методам разработки с целью уменьшения затрат на производство ПО, готового для отправки заказчику (potentially shippable software), за счёт повышения эффективности совместной работы и клиентоориентированности. То есть набор принципов формировался под решение задач бизнеса – для ускорения процесса разработки и достижения максимального результата от команды без увеличения затрат на производство.
Да, гибкая методология позволяет выжать из команды максимальный КПД, но есть два нюанса, которые при сложившихся обстоятельствах снижают Agile-эффект. Во-первых, принципы действительно работают только в небольших командах. Кроме того, если в команде все специалисты очень сильные, то совершенно не факт, что получится существенно увеличить их производительность.
Как это работает?
Сегодняшний процесс разработки можно разделить на три этапа: написание кода, подготовка его к запуску и продакшен.
Традиционно целью Agile был первый этап разработки – написание кода. В конце далёких 90-х именно этот этап рассматривался как требующий улучшения и серьёзных изменений. Тогда же получила известность одна из наиболее распространённых имплементаций Agile — Scrum. Справедливости ради стоит отметить, что Scrum вышел в свет в 1986 году, за 15 лет до того, как был адаптирован для Agile в 2001 году.
Scrum приносит выборку того, что нужно писать, позволяет отследить процесс разработки, выявить недостачи и противоречия на начальных этапах. Без технического задания программист не знает, какой именно продукт должен получиться в результате. Например, если речь идет о Google или Facebook, то у разработчиков того или иного сервиса вопросов не возникает. Они делают продукт для себя — сами являются его заядлыми пользователями и понимают, что и как должно выглядеть и что нужно сделать, чтобы новый функционал был удобным. Другое дело, например, система биллингa. Программист не знает того огромного количества нюансов, которые необходимо учесть для корректной работы сервиса как регуляционных, так и маркетинговых, как, например, различные модели расчётных операций.
Пионерами Agile были маленькие компании, которые не боялись применять передовые технологии – им нечего было ещё терять! По понятным причинам написание кода в подобных организациях составляет основную часть процесса (процессы подготовки и запуска практически отсутствуют). Эффект был потрясающий! Однако через несколько лет применения традиционного Agile в более развитых организациях стали замечать, что проблемы, связанные с сокращением выпуска на рынок новых продуктов, не исчезли. Agile передвинул затор на следующий этап – на подготовку нового продукта к выпуску. Тогда же, в середине первого десятилетия 2000-х, понятие Agile было расширено и стало собирательным, в отличие от первоначального значения, ориентированного только на первый этап разработки.
С целью подготовки написанного кода для потенциального выпуска появился Continuous Delivery. Стоит обратить внимание, что выпуск не обязательно происходит сразу, а может быть задержан, например, для привязки к определённой дате в соответствии с бизнес-задачами. Такой подход позволяет добиться слаженной работы команды, автоматизировать все процессы и повысить скорость потенциальной отправки кода в продакшен. Однако качество продукта гарантируется только за счет автоматических тестов, так как приемочные проверки не справляются со скоростью поставки кода и зачастую используются как формальный этап. Конечно, сегодня такие автоматические тесты отдельных компонент, написанные зачастую самими разработчиками, обеспечивают правильное исполнение кода. Но ни сама методология, ни какие-либо существующие сегодня инструменты не обеспечивают корректную работу кода в более сложной среде – продакшене. Кроме того, не факт, что код будет выполнять необходимые заказчику функции и решать поставленные задачи.
Например, в июле 2015 после очередного обновления ПО были остановлены торги на Нью-Йоркской фондовой бирже. Этот сбой сотряс мировую экономику, в частности, снизил на 1% фондовый индекс США на весь день, а также затормозил переговоры Греции с ее кредиторами на целую неделю! Ещё один яркий пример – обновление системы продажи авиабилетов в компании «Дельта». После выпуска нового ПО в продакшен информация вообще перестала поступать в диспетчерскую службу. В результате авиакомпания отменила все рейсы и понесла существенные финансовые и репутационные потери. Несомненно, в обоих случаях многие проверки перед запуском были пройдены и, тем не менее, ещё многие были бы сделаны, если бы занимали меньше ресурсов и времени.
Пробел с обеспечением качества кода сегодня очень актуален и он будет постепенно заполняться. По оценкам Gartner, в ближайшие три года по крайней мере 75% IT–корпораций будут вынуждены развить автоматическое тестирование, интегрирующее бизнес-процессы. Определенные надежды на решение проблемы качества возлагаются на такие технологии и методологии, как контейнеры и BDD (behavior driven development) – Docker, Cucumber и прочие.
У кого это работает?
На сегодняшний момент принципы Agile имплементированы в большинстве компаний, где это было возможно сделать без особых рисков для бизнеса. И все, кто смог выстроить новые процессы, в целом довольны результатами, например: Google, Zara, Ikea. Однако стоит обратить внимание, что эти компании действуют по принципу «разделяй и властвуй» — то есть работа разделена на проекты, которыми занимаются относительно небольшие самостоятельные команды. Кроме того, по Agile в этих компаниях работает в первую очередь бизнес-подразделение (особенно это касается Zara и Ikea), а не только отдел разработки. Они изменили не только организацию процесса, но и бизнес, поэтому естественным образом соответствуют Agile-модели.
Но есть часть компаний, где полноценно адаптировать гибкие методологии пока не удаётся – результатов либо нет вообще, либо они не соответствуют ожиданиям бизнеса. Например, ING и Citibank считаются самыми продвинутыми в банковской сфере по части адаптации Agile. Однако далеко не все отделы этих финансовых гигантов работают по гибким методологиям. На Agile перешли, в основном, те подразделения, которые занимаются поверхностными оболочками, мобильными приложениями или другими передовыми разработками. Иными словами, отделы, не связанные с основными бизнес-процессами, сбой которых может поставить под удар годовые доходы и привести к краху всей корпорации.
То есть в тех областях, где цена ошибки очень высока, компании пока опасаются что-то менять. Да, они понимают, что Waterfall себя изжил и, работая по-старому, можно в какой-то момент остаться далеко позади от конкурентов и всё потерять. Они бы и рады перейти на новые методы работы, но пока риски гораздо выше, чем потенциальная выгода от нововведений. Кроме того, зачастую необходимы большие вложения, чтобы перевести бизнес на гибкие методологии и далеко не факт, что всё сразу заработает хорошо. Это касается в первую очередь тех компаний, где большинство бизнес-процессов построено на ПО, написанном десятки лет назад на языках программирования, не столь модулярных, как Java, Scala, GO и пр.
Но те компании, которые пытались внедрить Agile и не получили ожидаемых результатов, всё больше и больше проявляют недовольство. Им обещали, что после имплементации гибкой методологии КПД увеличится, а time-to-market и вместе с ним затраты на производство сократятся. Однако ожидаемого эффекта не возникает, так как код выходит быстрее и всё больше и больше проблем появляется на продвинутых этапах разработки. КПД в некоторых случаях повышается, однако заметного сокращения затрат не происходит. Но чаще всего случаются откаты из продакшена, которые бьют по времени достижения целей, бьют по time-to-market и стоят очень дорого, так как исправление багов в продакшене требует гораздо больших затрат ресурсов разработчиков. Цена ошибки возрастает не только из-за позднего обнаружения, но и из-за высокой скорости разработки. Этот эффект можно сравнить с турбулентностью в потоках, когда скорость потока превышает максимально допустимую для данной среды.
Всё это привело к тому, что в последнее время появился большой спрос на инструменты, позволяющие решить эти проблемы и всё-таки добиться Agile-эффекта.
Как повысить эффективность?
Облака очень активно развивались в последнее десятилетие и частично открыли шлюзы для проведения тестирования в больших масштабах. Однако проблема полностью не была решена – несмотря на все преимущества, облачные технологии относительно дороги. Кроме того, не всегда просто построить необходимые среды проверок в cloud. Сегодня, в среднем, каждому разработчику необходимо 10 сред — таким образом цена среды может сравниться с бюджетом оплаты труда самого разработчика.
Как результат, начали появляться и другие технологии — контейнеризация, виртуализация данных и сервисов. Их использование в интегральных средах раскрывает шлюзы ещё больше. Используя эти технологии на одном сервере, можно за считанные секунды поднять сотни сред, имитирующих реальные, и сбои работы тех или иных сервисов.
Однако всё равно существует дисбаланс между частотой изменений и частотой тестов, которые позволяют проверять эти изменения. Таким образом «бутылочное горлышко» переместилось от команд разработчиков и упрощенных сред проверок в интегральные среды проверок. Кстати, этот процесс подтверждается появлением большого количества стартапов, которые занимаются решением проблемы организации среды программного обеспечения.
На чем стоит и куда движется Agile
Одним из центральных понятий гибких и непрерывных методологий — это так называемый сдвиг влево, который означает перенос ответственности как можно ближе к разработчику. И это действительно так – сейчас мы видим, что очень многие процессы сместились в сторону написания кода. Так, например, обсуждение технического задания, первая проверка кода и даже презентация работающего приложения зачастую выполняются в присутствии или даже непосредственно самим разработчиком.
В дальнейшем это смещение будет сдвигаться ещё дальше влево, ещё ближе к программистам – то есть все проверки, включая интегральные и стрессовые, будут производиться предельно близко к источнику изменений и к моменту изменения. Это обусловлено необходимостью баланса между частотой изменений и частотой тестов.
Кроме того, этот сдвиг позволяет избежать эффекта турбулентности, который можно обнаружить при работе нескольких сотен человек, подающих код несколько раз в день. Эффект турбулентности заключается в том, что сотни изменений скапливаются в ожидании сред и дефицит сред влияет на скорость их поставки. Он возникает по двум причинам. Во-первых, из-за недостатка ресурсов (в попытке все успеть люди создают много лишних действий и это ещё больше замедляет общий процесс). А во-вторых, если из сотни изменений несколько десятков «падают» на тестах, то это приводит еще к большему дефициту сред, так как после исправления нужно проверять снова все, а не только те, которые правили. Так, например, изменения в модуле конфигурации могут привести к сбою в модуле оплаты и сбою работы всего приложения.
Таким образом, чтобы повысить Agile-эффект, необходимо в первую очередь реализовать два условия:
1. Появление возможности для запуска бизнес-тестов без особых затрат,
2. сдвиг интегрального и бизнес-тестирования как можно ближе к источнику изменений.
И, конечно же, нужны эффективные решения для мониторинга качества работы приложений в реальных условиях.
Когда наступит «золотой век» Agile?
С начала своего существования Agile перевоплотился из набора принципов в ассортимент методологий, процессов и даже стандартов. Сегодня поле деятельности этих методологий не ограничено командами разработчиков. Гибкие процессы успешно внедряются практически во все отделы IT и даже бизнес руководствуется стандартами Agile. Среди наиболее известных можно отметить Scrum, Scrumban, SAFe, ScaleAgile@Spotify, Continuous Delivery, Lean, Prince2 Agile и многие другие.
Несмотря на многие фреймворки и методологии, которые в рамках Agile претендуют на лидерство и заявляют о решении всех проблем и снятии всех барьеров, качество остаётся главным шлюзом перед беспрекословным переводом на Agile всех отделов и этапов разработки IT-корпораций. Существование этого шлюза является причиной недоверия к Agile и попыткой оправдать сохранение принципов каскадной модели или Waterfall. Также происходят попытки изменить Agile при помощи внедрения традиционных этапов тестирования.
Это позволит сдержать на время поток ошибок, заливающий бизнес-процессы, сайты и приложения корпораций. Однако в условиях плотной конкуренции бизнес не будет долго терпеть такую модель. Только при переводе всего механизма на гибкие методологии возможно добиться работы бизнеса, гибкой и адаптированной к требованиям рынка, с высокими параметрами качества и скорости.
Итак, одной из ключевых проблем в работе Agile сегодня является проблема качества. И ее решение – дело уже совсем ближайшего будущего. Так, уже появился целый ряд инструментов, которые помогают быстро и точно предсказать степень удовлетворения бизнеса новыми изменениями в приложениях. Внедрение подобных инструментов позволяет добиться хороших результатов в осуществлении проверок.
Решив эту проблему, в последующие 5 лет гибкие методологии откроют себе путь в оставшуюся треть корпораций, которые до тех пор не осмелятся переводить разработку на более современный, но рискованный лад.
Комментарии (88)
staticlab
30.01.2017 13:15+7Waterfall себя изжил
Почему все евангелисты Аджайла помнят только каскадную модель?
damat
30.01.2017 16:28+1есть даже более сложный вопрос: а где была описана и реально применялась «каскадная» модель? =) поищите, удивитесь
corri
30.01.2017 21:15Может больше не знают ничего?(
RUP — сложна
accera
31.01.2017 10:02Кстати, RUP не противоречит Agile — http://www.agilemodeling.com/essays/agileModelingRUP.htm
staticlab
31.01.2017 10:16+1Вообще говоря, в основе и RUP, и Agile лежат итеративная методология и инкрементальная модель разработки.
http3
31.01.2017 10:54А в водопаде итерации не возможны разве? :)
staticlab
31.01.2017 11:05+1Судя по рассказам евангелистов, Водопад — это такая древняя модель разработки прямиком из каменного века, и такая же монолитно-каменная, когда приходит заказчик, отдаёт ТЗ, оплачивает счёт и забывает о проекте до тех пор, пока его окончательно не сделают. При этом не трогает разработчиков всякими "Ну как там у вас дела", "Покажите, что сделали", "Тут мы решили немного поменять концепцию", "А давайте вот тут поиграем шрифтами".
И, в отличие от этого, Аджайл рисуется как дивный волшебный мир, где разработчики-хипстеры радостно проводят ежедневные 15-минутные планёрки, регулярно демонстрируют заказчику наработки, проводят разбор полётов и планируют задачи на очередную итерацию. Постойте, это же как будто бы делали и до Скрама? Да ну, бред какой-то.
gricom
30.01.2017 22:23Более того, то, что сейчас называется waterfall (на самом деле автор этой методологии мамой клянется, что имел ввиду итеративность), отнюдь себя не изжило, т.к. реализовать средства защиты информации или спец.софт для авиации, космоса и медицины по аджайлу не получится
sentyaev
30.01.2017 22:39т.к. реализовать средства защиты информации или спец.софт для авиации, космоса и медицины по аджайлу не получится
Это некое расхожее мнение, что невозможно.
Вы же знаете, что даже софт на Opportunity обновляли, да и не только для него.
В одной компании разрабатывали железо + софт к нему, так там был очень даже agile и итеративная разработка. Там лишь разница в длительности итерации и их стоимости.gricom
31.01.2017 11:40то, что софт можно обновлять — это не значит, что идет работа по аджайлу. Разница в том, что в водопаде сначала аналитики до мельчайших подробностей прорабатывают требования и фиксируют их, после этого разработчики пишут код, а когда написание кода закончено, то никаких изменений, кроме багфиксов, быть в принципе не может. После этого куа куачат, а девелоперы фиксят и только потом в продакшн.
Здесь нет гибкого скоупа итерации, изменений требований, деплоя каждой рабочей сборки в продакшн и тому подобных практик из аджайла.sentyaev
31.01.2017 12:57в водопаде сначала аналитики до мельчайших подробностей прорабатывают требования и фиксируют их, после этого разработчики пишут код, а когда написание кода закончено, то никаких изменений, кроме багфиксов, быть в принципе не может. После этого куа куачат, а девелоперы фиксят и только потом в продакшн.
С определением я согласен.
Но, вы хоть раз видели идеальный водопад?
Да и по сути, водопад от итеративной разработки отличается только длительностью итерации.
У меня был проект, где первоначальная разработка заняла 3 года. Классический водопад.
А потом пошли ежегодные итерации (это назввалось — модернизацией).
Bimawa
31.01.2017 11:27Изучая ООП, с этими всякими наследованиями, могу предположить, что каскадная модель живет до первого изменения базовой структуры (требований) :)
staticlab
31.01.2017 12:20Что, простите?
Bimawa
31.01.2017 12:21Говорю, что каскадная модель не уживается потому, что требования заказчика меняются быстрее чем заканчивается цикл разработки :-)
staticlab
31.01.2017 12:23С этим никто и не спорит. Но причём тут евангелисты и ООП?
Bimawa
31.01.2017 12:26>Почему все евангелисты Аджайла помнят только каскадную модель?
IMHO, но мне кажется Аджаил придумали взамен каскадной модели. Поэтому другие модели может и рассматривались, но для большинства стартапов, они были, не применимы, в той или иной мере.staticlab
31.01.2017 12:49+1Вам действительно кажется.
Incremental software development methods can be traced back to 1957. Evolutionary project management and adaptive software development emerged in the early 1970s. During the 1990s, a number of lightweight software development methods evolved in reaction to the prevailing heavyweight methods that critics described as heavily regulated, regimented, and micro-managed. These included: from 1991, rapid application development; from 1994, unified process and dynamic systems development method (DSDM); from 1995, Scrum; from 1996, Crystal Clear and extreme programming (XP); and from 1997, feature-driven development. Although these originated before the publication of the Agile Manifesto in 2001, they are now collectively referred to as agile methods.
Понимаете, авторы гибких методологий не с каскадной моделью боролись. Они боролись со сложностью существовавших на тот момент итеративных методологий. Но евангелисты сравнивают Аджайл исключительно с железобетонным Водопадом, как будто бы никакой полувековой истории изысканий в области управления процессом разработки ПО не существовало.
К слову, каскадная модель разработки была заимствована из "классических" индустрий, таких как машиностроение и строительство, просто потому что никаких других на тот момент не существовало. А в строительстве домов особо не поаджайлишь.
Понимаете, если не знать эволюционный путь методологий разработки и реальные предпосылки появления гибких методологий, то очень легко при внедрении испортить Аджайл, превратив его в некий итеративный процесс с управленческой бюрократией, деспотизмом менеджеров и примесью аджайлового карго-культа, что можно наблюдать на многих реальных примерах.
По моему мнению, настоящий скрам-мастер должен знать и понимать, чем на самом деле отличается гибкая методология от классических (и это не итеративность).
FedjaNew
02.02.2017 12:15staticlab> Почему все евангелисты Аджайла помнят только каскадную модель?
Потому что, как правило, они очень слабо разбираются в других моделях разработки.
Правильнее было бы противопоставлять Agile и Plan?driven projects.
НО!
Как уже где-то отмечено в комментариях, тот же Sprint — это чистейший Plan?driven MICRO-project.
И наоборот, в Plan?driven projects исправление ошибок часто осуществляется в стиле Agile/XP.staticlab
02.02.2017 12:46+1Потому что, как правило, они очень слабо разбираются в других моделях разработки.
А можно ли тогда гарантировать, что они в Аджайле и Скраме разбираются хорошо? :)
FedjaNew
02.02.2017 13:04staticlab> А можно ли тогда гарантировать, что они в Аджайле и Скраме разбираются хорошо? :)
Можно проверить.
На данный момент у меня зарегистрированы следующие разновидности Agile:
1. Scrum
2. Extreme Programming (XP)
3. Kanban
4. Crystal
5. Dynamic Systems Development Method (DSDM)
6. Agile Unified Process (AUP)
7. Feature Driven Development
8. Adaptive Software Development
9. Scaled Agile Framework (SAFe)
10. Lean Software Development
11. Large Scale Scrum (LeSS)
12. Disciplined Agile Delivery (DAD)
Если очередной проповедник знает (расскажет) хотя бы о половине, то ему можно будет поставить троечку :)FedjaNew
02.02.2017 13:24А можно «засыпать» вопросом попроще:
«Какие основополагающие принципы объединяют Software Requirements (SR), Use Cases (UC) и User Stories (US)?».
Напоминаю, что SR и UC традиционно относят к «Waterfall», а US — к Agile.
sentyaev
30.01.2017 14:59Традиционно целью Agile был первый этап разработки – написание кода.
С написанием кода проблем нет и небыло. Основная проблема разработки (и раньше, и сейчас) сделать то, что нужно заказчику (решить его задачу/проблему).
Давайте приведу agile manifesto (http://agilemanifesto.org/iso/ru/manifesto.html):
Мы постоянно открываем для себя более совершенные методы разработки
программного обеспечения, занимаясь разработкой непосредственно и помогая
в этом другим. Благодаря проделанной работе мы смогли осознать, что:
Люди и взаимодействие важнее процессов и инструментов
Работающий продукт важнее исчерпывающей документации
Сотрудничество с заказчиком важнее согласования условий контракта
Готовность к изменениям важнее следования первоначальному плану
То есть, не отрицая важности того, что справа,
мы всё-таки больше ценим то, что слева.
Итак, одной из ключевых проблем в работе Agile сегодня является проблема качества.
Agile не должен решать проблему качества. Agile это даже не методология, это всего лишь подход к разработке.
А для повышения качества есть другие техники — unit/integration/acceptance tests, tdd, bdd и т.д.rmpl
30.01.2017 15:23Agile это даже не подход к разработке, это просто набор принципов и ценностей :)
accera
30.01.2017 21:21Действительно, 15 лет назад Agile был набором принципов, однако сегодня он объединяет многие дисциплины производства. Даже такие компании как Zara и Ikea работают по Agile, и речь не идет об их отделе разработки ПО. Прошу прощения за ссылку на английском: http://www.forbes.com/sites/stevedenning/2016/08/13/what-is-agile/#2d5433b4b926
sentyaev
30.01.2017 22:53Действительно, 15 лет назад Agile был набором принципов, однако сегодня он объединяет многие дисциплины производства.
Как и какие дисциплины он объеденяет?
Вас читать очень сложно, т.к. вы делаете некое заключение, но не приводите никаких данных на которых ваше заключение основано.
ПС: Прочитал статью на которую вы ссылаетесь, она только подтверждает то, что я сказал.
pixelcube
30.01.2017 15:00… написанном десятки лет назад на языках программирования: ..., GO и пр.
Ему еще нет десятка )
dmitriyabr
30.01.2017 16:20+3Традиционно целью Agile был первый этап разработки – написание кода.
Нонсенс.
Целью Agile никогда не было написание кода, целью Agile является удовлетворение клиента, а для этого, Agile-фреймворки (тот же Scrum) работают над тем, чтобы НЕ разделять те три этапа разработки, про которые пишет автор.
Основой Scrum-a является тот факт, что ВЕСЬ продукт с учетом тестирования, выкладки на продакшн, делает Scrum-команда, в течении спринта. А в команду эту входят ВСЕ необходимые для этого специалисты.
Кроме того, сами авторы Scrum настоятельно рекомендуют использовать техники XP и DevOps для обеспечения быстрой выкладки результатов на прод в надлежащем качестве.
P.S.
Это уже вторая статья от автора и я снова убеждаюсь, что присутствует явное непонимание, что Agile это не только Scrum.
Во-первых, Agile – это всего лишь манифест из ценностей и принципов.
Во-вторых, если говорить про техники под зонтиком Agile, то есть XP, DevOps и другие, которые как раз заточены, под выпуск КАЧЕСТВЕННОГО ПО. Их всего-лишь надо с умом применять. А говорить, что проблема Agile в качестве – как минимум не корректно. Проблема сегодняшнего внедрения Agile во многих компаниях, в том что его внедряют не разобравшись в сути.accera
30.01.2017 21:10Спасибо! Я рад что вы мой постоянный читатель! Речь действительно о «зонтике» Agile, который развернулся намного шире и покрывает не только отделы разработок, а уже всей компании. Проблема именно в том, что результат действительно зависит от того как внедряют Agile. Необходимо новое дополнение к «зонтику», которое будет сопровождать внедрение Agile, и позволит четко определить, что сделано не по правилам и как это исправить. Именно этим и занимаются сегодня разработчики Agile.
dmitriyabr
30.01.2017 22:58+2Сложно вас не читать, если ваши коллеги спамят этими статьями в профессиональных сообществах.
А потом новички думают, что это аджайл не работает, после внедрения такими "экспертами".
Рекомендую, сначала разобраться в сфере, прежде чем писать статьи
podluzny
30.01.2017 16:28+2Итак, одной из ключевых проблем в работе Agile сегодня является проблема качества. И ее решение – дело уже совсем ближайшего будущего.
В будущем вообще все будет хорошо, но так-то аргумент слабый и даже немного комичный.
sentyaev
30.01.2017 17:07Сегодня, в среднем, каждому разработчику необходимо 10 сред — таким образом цена среды может сравниться с бюджетом оплаты труда самого разработчика.
Откуда эта цифра? Что за ней стоит?accera
30.01.2017 20:50-1Количество параллельных веток кода, с которыми одновременно работает один разработчик: починка багов, нынешняя версия, новая версия, версия для определенного заказчика, экспериментальная версия и т.д.
sentyaev
30.01.2017 22:34+11. Я имелл ввиду какова методика подсчета и как вы получили данные.
2. Какое отношение «ветки» имеют к «средам»? Если вы считаете, что соотношение 1 к 1, то это довольно спорно.accera
31.01.2017 10:11Как минимум 1 к 1, и даже иногда, на каждую ветку необходимо 3-4 среды: поверхностные проверки, разные вариации данных, разные вариации поддерживающих сервисных приложений и т.д. Допустим ТЗ добавить оплату картой покупки книги. Необходимо проверить новый код на стабильность, безопасность и функциональность. Таким образом уже три среды на одно ТЗ, каждая со своими инструментами, заточенными на тип проверки.
sentyaev
31.01.2017 10:35Как минимум 1 к 1, и даже иногда, на каждую ветку необходимо 3-4 среды
Вот вы приводите цифры, объясните пожалуйста на каких данных они основаны.
Вот например у меня есть опыт в 7и проектах, если говорить про количество «сред», то было так:
1. local, dev, stage, prod
2. local, dev, prod
3. local, dev01-dev10 (было 10 окружений для параллельной разработки и независимого тестирования фич, несколько разработчиков могли использовать одно окружение), qa, rc, prod
4. local, dev, prod_vN (N — номер версии), prod_vNextaccera
31.01.2017 16:54Это то, что происходит обычно:
dev
stage
prod
несколько сред для тестеров, а у разработчиков только одна, да и та хромает.
Это я говорю про то, как работает сегодня.
А вот представьте себе вариант, когда Вы открываете eclipse или другой IDE, и, нажимая на кнопку, получаете новую среду. Ваш новый код туда закачан, есть все данные для тестов, которые QA, Ops и анналисты согласовали и подготовили, более того, даже acceptance тест можете запускать нажатием кнопки и можно подключаться с дебагером.
В таком случае в течении дня у Вас будет как минимум одна “локальная” среда для каждого набора тестовых данных или может даже для каждого теста. Такая имплементация на уровне виртуализации слишком дорогая, а вот контейнеры более подходят для этого.sentyaev
31.01.2017 17:13Я ничего не пытаюсь «представить», если я хочу проверить некую теорию — я ставлю эксперимент.
Попробую спросить вас снова. Вот ваше высказывание:
«Как минимум 1 к 1, и даже иногда, на каждую ветку необходимо 3-4 среды».
Вопросы:
1. Как вы определили эти числа? Это ваше мнение или практика?
2. В каком количестве проектов вы участвовали с таким подходом?
2. В какое количество проектов вы внедрили такой подход?
3. Как вы оценивали положительный/отрицательный эффект от такой практики?
Заранее спасибо.accera
01.02.2017 19:11На каждую ветку, с которой работает программист есть как минимум одно изменение. Желательно каждое изменение проверить перед выкладыванием кода в ветку и лучше, конечно, с как можно большим разнообразием тестовых данных. Полагаю, это не только мое мнение. Единственное препятствие для такого подхода — время и усилия, затраченные на поднятие сред, закачку тестовых данных и запуск тестов. Это как раз та область, которая будет развиваться в следующие 5-10 лет под “зонтиком” Agile.
Дополнительно к инструментам типа Docker, Cucumber & Service Virtualization будут появляться новые, цель которых будет ускорить, упростить и удешевить подъем сред, закачку данных и запуск тестов приема.staticlab
01.02.2017 20:48Согласен, что отдельные тесты можно провести перед коммитом, но зачем прогонять все тесты на машине разработчика? Тем более, что изменения делаются в собственной ветке разработчика. А для полного прогона тестов пусть CI-сервер разворачивает виртуальное окружение и тестирует там сколько понадобится. И какое отношение к реализации тестирования имеет аджайл?
sentyaev
01.02.2017 20:52Полагаю, это не только мое мнение.
Спасибо, другими словами вы получается не внедряли такой подход.
Я почему так спрашиваю. У меня любой коммит в любую публичную ветку, любой пулл реквест проходит такой процесс: 1. проверяем кодстайлы, 2. прогоняем тесты, 3. билдим. Это не выкладывается никуда, т.е. это все происходит на билд сервере.
Все что попадает в develop/master проходит тот-же процесс но и еще деплоятся на правильный энвайромент dev/pre-prod.
Когда pre-prod стабилен, просто меняем prod/pre-prod местами (проблем с базами нет, т.к. они тоже разные).
Вот мне и не понятно, зачем вам такая куча этих сред. Опятьже Докер, подняли себе окружение, провели тесты и грохнули.
Я к тому, что это уже несколько лет как есть.accera
02.02.2017 01:11Если работает один человек, то можно и на билд сервер загружать. Правда тесты, наверняка, тесты компоненты, а не тесты приема. А вот если 200 человек работает, то билд будет падать раз за разом. Это и есть эффект турбулентности, когда проводная способность билда меньше, чем поток изменений проходящий через него.
Вот статистика с настоящего, не самого перегруженного сервера:
120 модулей в проекте
450 разработчиков
приблизительно 100 изменений в день (как вы видите еще не все работают с одной веткой)
12 билдов в день
в среднем, каждый билд длится 30 минут
в среднем, каждый билд строит 8 новых изменений
обычно 2 билда успешные, первый и последний (в конце дня все работают над стабильностью)
Сегодня, основная сложность — построить среду быстро (меньше минуты) и создать набор правильных тестов, которые проверяют работу бизнес процессов в целом, в дополнение к тестированию отдельных компонент.
Проверка на билд сервере это первый этап так называемого «сдвига влево», т.е. подальше от prod. На сложных проектах этого тоже не достаточно.sentyaev
02.02.2017 02:08У нас в 10 раз меньше людей. А у меня в команде в 100 раз)
Тесты у нас все запускаются. Их более 2000 и примерно четверть приемочные.
Сегодня только из-за одного меня запустились более 10 билдов и 4 деплоймента.
При этом у нас всего 3 билд сервера. Если будет не хватать, просто добавим еще.
Я это к тому, что в современном мире это уже не проблема давно.
Ну и 30 мин на билд это перебор конечно. У нас всего один проект есть у которого весь пайплайн занимает более 15 минут, но мы его растягиваем на отдельные части.
Вот буквально неделю назад оторвали кусок который практически не менятся (т.е. измененя вносятся примерно раз в 3-4 месяца). И потихоньку, думаю за год-другой растащим.
BalinTomsk
30.01.2017 17:24+2----по принципам Agile сейчас работают две трети IT-компаний.
Давайте будем честными, никто из первой десятки, и мало кто из сотни, Agile не использует.http3
30.01.2017 21:14Не заметил этого утверждения.
Я бы сказал, что те, кто и работает, на самом деле «работает».
Достаточно поискать прошлые топики об Agile, которыми хабр завален, и описанием проблем.
Ощущение, что пытаются впихнуть свой Agile куда только можно.
zenkz
30.01.2017 21:44Давайте будем честными и не будем измерять «компаниями». Потому что в рамках одной компании каждый проект сам для себя решает что использовать. Это может быть Скрам, Канбан или обычный водопад. Не видел ни одной компании, которая бы запрещала использовать Agile. (Ведь даже документацию и ТЗ можно писать по Agile). Я очень сильно сомневаюсь, что ни одна команда в Microsoft, Apple или Google не использует Agile методологии.
accera
31.01.2017 10:14Парадокс именно в том что в первом десятке находятся корпорации, для которых изменение может обойтись слишком дорого. Пионерами Agile были компании, которые не были включены в лидеры рынка.
9zloy
30.01.2017 17:58Автор не прав и НЕ рубит фишку. Главная проблема внедрения agile не качество, а недоверие и нежеление людей меняться в целом. Новое любит 10% населения, остальные любят старое и привычное. Проблема качества в agile проектах стоит ничуть не более остро, чем во всех остальных проектах. Автоматизация используется во всех типах проектов и нормально помогает.
Хватит уже поминать agile. У нас уже post-agile тут на острие. Scrum и иже с ними выходят из моды и завоевывают non-software deveopment команды. Сейчас модно говорить о трансформации всей компании, холократия там, плоские структуры, доверие, вот это вот все.accera
30.01.2017 20:35Статья именно об этом. Agile уже давно перерос из набора принципов для команд разработчиков в собирательное понятие:… Тогда же, в середине первого десятилетия 2000-х, понятие Agile было расширено и стало собирательным, в отличие от первоначального значения, ориентированного только на первый этап разработки.…
elenaelena
30.01.2017 18:56Сейчас у меня закончился проект и меря переводят на проект с полноценным Agile. То есть моим начальником становится скрум мастер и product owner, первая недавна работала официонткой, второй тоже какой то управленец-гуманитарий.
То есть они меня будут микроменеджерить и любой технический вопрос надо будет согласовывать с ними. Так по идее не должно быть в аджайле, но так устроена психология человека, если человек- мелкий начальник, то есть он может распределять задания и планировать сприн, он с 99,99% будет лезть в технические вопросы и микроменеджерить. Производительность в аджайле снижается минимум в 5 раз, а работы с выпучинными глазами и огромной усталостью от бесконечных 15 минуток, которые растягиваются минимум на 40 мин, прибавляется в разы.
Предыдущий проект был с Jira и вроде как был спринт, но все, за исключением утренних 15 минуток (на 40 минут), было очень неформально. Смогла переписать большую часть легаси (1998г.) приложения, как франт энд так и бэк энд. Приложение сейчас выглядить конфеткой.
Сейчас начнется аджайл, поэтому главная установка у меня — не напрягаться, главное — быть максимально активным на митингах и отчетах о своих результатах.
Это о рациональном подходе к аджайл с точки зрения опытного разработчика с опытом работы с аджайл на 8 разных проектах.
Aingis
30.01.2017 19:17если человек- мелкий начальник, то есть он может распределять задания и планировать сприн
Это ересь какая-то. Оценивают задачи и набирает на спринт команда, и никто другой. Скрам-мастер их должен прикрывать, а PO может только сказать, что вот эти задачи важнее. Всё. Если это не так, то это не аджайл.elenaelena
30.01.2017 20:33— это в теории, на практике на 8 проектах распределяет задачи тим лид или скрум мастер, а никак не команда.
accera
30.01.2017 20:43-1Это к сожалению происходит сплошь и рядом. Как вы и говорите — «так устроена психология человека». По Agile никто из «куриц» не должен контролировать технические решения: если тесты прошли — значит работает.
JDay
30.01.2017 19:15Все намного проще: Итак, одной из ключевых проблем в работе
Agileсегодня является проблема качества.sand14
30.01.2017 21:17+3Естественно.
Вся статья про то, что Agile заточен под команды из слабых разрабов, и про то, как при назначении качеству нулевого приоритета, абсолютный приоритет отдается быстрой поспринтовой разработке прототипов, а далее в статье описывается, что — внезапно! — прототипы в продакшене не работают.
И далее описываются попытки доработать методологию, чтобы на выходе выдавался и качественный код, и работающий в продакшене продукт.
Но тогда это что-то другое, а не аджайл в общепринятом и рекламируемом виде.
Представляется, что если придать водопаду человеческое лицо, и доработать аджайл, то они встретятся в одной точке.
mad_nazgul
31.01.2017 11:39+1ИМХО проблема всех, кто «внедряет» Agile отдать ответственность за качество кода и время проекта в одни руки — программиста.
А это в свою очередь дает программисту полную безответственность.
Т.к. обычно время берется в займы у качества кода.
Потом за это придется платить, но всегда можно «уйти» от ответственности. И платить будет кто-нибудь другой.
Грубо говоря:
Мы тут быстро наговнокодили, т.к. нам спринт закрыть надо. А потом кто-нибудь когда-нибудь наш говнокод, наверное, отрефакторит.
<:o)
MacIn
30.01.2017 19:40+2То чувство, когда мысли, хорошо выражаемые через схемы и графики, оформелны в виде стены текста с типовыми фоографиями и превращаются просто в нечитаемую портянку без разбивки…
http3
30.01.2017 23:03+2Например, если речь идет о Google или Facebook, то у разработчиков того или иного сервиса вопросов не возникает. Они делают продукт для себя — сами являются его заядлыми пользователями и понимают, что и как должно выглядеть и что нужно сделать, чтобы новый функционал был удобным.
Действительно? :)accera
31.01.2017 10:19Я не знаю разработчиков, которые после (или даже во время) работы регистрируются в приложении для диспетчеров поездов или системы биллинга. :-)
incogn1too
30.01.2017 23:20+1Пересели на agile, чтобы увеличить скорость разработки, в ущерб качеству, теперь удивляемся куда делось качество. Ну-ну.
sentyaev
31.01.2017 04:26+1Гибкие принципы возникли как альтернатива традиционным методам разработки с целью уменьшения затрат на производство ПО, готового для отправки заказчику (potentially shippable software), за счёт повышения эффективности совместной работы и клиентоориентированности.
Основная цель гибких методологий — не уменьшение затрат, а уменьшение рисков.
То есть набор принципов формировался под решение задач бизнеса – для ускорения процесса разработки и достижения максимального результата от команды без увеличения затрат на производство.
Гибкие методологии не ускоряют разработку. Задача — получить работающий продукт в конце каждой итерации. Другими словами вместо того чтобы ждать свои 12 фич год, с гибкими методологиями бизнез будет ждать эти 12 фич тоже год, но получать по одной фиче каждый месяц.
Гибкость в том, что во первых мы можем завершить проект когда у нас готовы только 2 фичи, т.к. решим что больше не нужно. Либо после того как получили теже самые 2 фичи, можем поменять приоритеты выпуска остальных. Либо вообще отменить пару и добавить другие.
Сегодняшний процесс разработки можно разделить на три этапа: написание кода, подготовка его к запуску и продакшен.
Нужно добавить как минимум планирование, проектирование и тестирование.
Не совсем понятно, что такое «подготовка к запуску».
Традиционно целью Agile был первый этап разработки – написание кода.
Как я уже говорил выше, никакого отношения к написанию кода гибкие методологии не имеют. Главное — минимизация рисков.
Например, если речь идет о Google или Facebook…
Другое дело, например, система биллингa…
Очень спорное высказывание. Хотелось бы больше конкретики и почему вы так решили?
Тогда же, в середине первого десятилетия 2000-х, понятие Agile было расширено и стало собирательным, в отличие от первоначального значения, ориентированного только на первый этап разработки.
Действительно Agile сейчас это собирательное понятие для гибких методологий. Но как я уже писал, оно не имеет никакого отношения к написанию кода.
Однако качество продукта гарантируется только за счет автоматических тестов, так как приемочные проверки не справляются со скоростью поставки кода и зачастую используются как формальный этап.
…
Кроме того, не факт, что код будет выполнять необходимые заказчику функции и решать поставленные задачи.
Для этого существует QA, и если он не справляется значит процесс настроен не верно. Тут уж agile ни причем.
Определенные надежды на решение проблемы качества возлагаются на такие технологии и методологии, как контейнеры и BDD (behavior driven development) – Docker, Cucumber и прочие.
Тут вы смешали тесты и инфраструктуру. Могли бы вы раскрыть как Docker поможет с качеством?
Им обещали, что после имплементации гибкой методологии КПД увеличится, а time-to-market и вместе с ним затраты на производство сократятся.
Видимо обещали те, кто не понимает для чего были придуманы гибкие методологии. Повторю еще раз — риски, а не КПД.
Облака очень активно развивались в последнее десятилетие и частично открыли шлюзы для проведения тестирования в больших масштабах.
Вы имеете ввиду нагрузочное тестирование или количество тестовых сред? Если про количество, то что нам раньше мешало докупить железа?
Сегодня, в среднем, каждому разработчику необходимо 10 сред — таким образом цена среды может сравниться с бюджетом оплаты труда самого разработчика.
Про это я уже спрашивал, хотелось бы понять откуда вы взяли данные для такого вывода.
Как результат, начали появляться и другие технологии — контейнеризация, виртуализация данных и сервисов. Их использование в интегральных средах раскрывает шлюзы ещё больше.
1. Что такое «интегральная среда»? Впервые встречаю такое понятие.
2. Что вы имеете ввиду под словом «шлюзы»?
Таким образом, чтобы повысить Agile-эффект, необходимо в первую очередь реализовать два условия:
1. Появление возможности для запуска бизнес-тестов без особых затрат,
2. сдвиг интегрального и бизнес-тестирования как можно ближе к источнику изменений.
И, конечно же, нужны эффективные решения для мониторинга качества работы приложений в реальных условиях.
Тесты и мониторинг не имеют отношения к Agile, соответственно не могут повысить его эффект. Они могут повысить качество и время обнаружения проблем.
С начала своего существования Agile перевоплотился из набора принципов в ассортимент методологий, процессов и даже стандартов.
Agile не перевоплощался, это просто зонтичный термин для гибких методологий.
Несмотря на многие фреймворки и методологии, которые в рамках Agile претендуют на лидерство и заявляют о решении всех проблем и снятии всех барьеров, качество остаётся главным шлюзом перед беспрекословным переводом на Agile всех отделов и этапов разработки IT-корпораций
…
Итак, одной из ключевых проблем в работе Agile сегодня является проблема качества. И ее решение – дело уже совсем ближайшего будущего. Так, уже появился целый ряд инструментов, которые помогают быстро и точно предсказать степень удовлетворения бизнеса новыми изменениями в приложениях. Внедрение подобных инструментов позволяет добиться хороших результатов в осуществлении проверок.
Я уже писал, Agile не про качество, а про риски.
Могли бы вы привести пример этих инструментов?accera
31.01.2017 10:24-1Риск во многом зависит от качества, если убрать конечно элемент везения! Я с вами согласен, качество это способ уменьшения риска. А инструменты для предсказания степени удовлетворения — https://cucumber.io и https://www-01.ibm.com/software/rational/servicevirtualization/
sentyaev
31.01.2017 11:46Риск во многом зависит от качества, если убрать конечно элемент везения! Я с вами согласен, качество это способ уменьшения риска.
Гибкие методологии не повышают/уменьшают качество. Требования к качеству есть в любом проекте. Для повышения качества мы используем тестирование например (unit testing, integration testing, acceptance testing и даже manual и regression testing).
А инструменты для предсказания степени удовлетворения — https://cucumber.io и https://www-01.ibm.com/software/rational/servicevirtualization/
Cucumber — это обыкновенный BDD инструмент, он не умеет «предсказывать степень удовлетворения».
Про второй я не знаю, так что тут сказать нечего.accera
31.01.2017 19:46-1Именно так!
Как повысить качество? Это и есть следующий этап развития Agile
Правильно построенные тесты в Cucumber позволяют однозначно определить соответствие критериям приема. Ну а последнее позволяет запустить сложную систему до того как все куски кода написаны. Например, в приложении для покупки книг, правило написанный тест позволит проверить, насколько система отвечает требованиям, если книга не найдена а виртуализация сервисных приложений сократит время до проверок и демонстрации — можно будет запускать приложение до того, как база данных готова.
vanatka
31.01.2017 09:49Пробовали ли вы когда-нибудь DSDM Atern?
accera
31.01.2017 10:33Спасибо за очень хороший вопрос! Естественно, однако я не видел что бы DSDM действительно работал на практике, тем более на больших проектах — он слишком общий. В жизни все значительно сложнее. Например, один из принципов — согласие о критерии сдачи проекта до начала разработки. На практике бизнес не согласится принять что-то, до того как видел как оно работает в деле.
vanatka
31.01.2017 14:34Мы в нашем компании работаем по DSDM, экономим деньги, свои и заказчика.
По факту получается достаточно хорошо использовать условие работы по этому процессу, как воронку для фильтрации «наших» клиентов. Те кто согласны — эволюционным путем двигаться к продукту — остаются с нами, с ними мы и продолжаем успешно работать. И должен признаться dsdm очень хорошо помогает как presale сделать так и дальше спокойным быть account'у.
Относительно вашего point'a относительно критерия сдачи — в DSDM 4 этапа, и заказчик в праве отказаться от продолжения работы на любом из этапов.
Вы работаете по предоплате? Что входит в предоплату? Проектирование?
Если научиться продавать DSDM тогда у вас вероятнее всего не будет fix price на весь проект, у вас будет возможность варьировать бюджет в виду обратной связи бизнеса.
Вопрос качества как правило связан либо с проектированием либо с обработкой Change request'ов… Как вы работаете с change request'aми?accera
31.01.2017 18:24Именно так, качество связано с определением критериев сдачи, в данном случае проектированием на начальном этапе или обработкой CR.
Самая распространенная модель работы с CR — через backlog. Недостаток заключается в возможном несоответствии критериев сдачи с имплементацией ТЗ. Этот недостаток должен быть устранен за счет показа результата заказчику. Это не сложно для простых проектов. Однако для более сложных вопрос среды и тестов приема критичен. В идеале все тесты приема работают и заказчик доволен работой после ручных проверок. Это работает, когда CR не очень много или они могут быть проверены одновременно. На деле все упирается в недостаток сред проверок и автоматических тестов, которые проверяют критерии приема. Именно здесь и пригодятся контейнеры, виртуализация сервисов и автоматизация проверок приема.
powercfg
31.01.2017 14:31Коллеги, можете посоветовать толковую книгу по Agile? Желательно на русском.
dmitriyabr
31.01.2017 16:40Для начала:
Манифест
Скрам Гайд
Канбан
А потом можно уже думать о других книжках =)
jetcar
31.01.2017 14:48вот бы ещё придумать способ работать с ПО которые и сами не знают что им надо или тех кто генерит идеи и не думает как они повлияют на всё остальное, а то аджайл как-то не особо помогает, а с толковыми ПО почему-то и без аджайла всё отлично работает
accera
31.01.2017 18:26Это точно! С толковыми ПО и без аджайла всё отлично работает :-)
Один из способов — дать попользоваться результатом на ранних этапах, задолго до того, как он окончательно готов. Опять же все упирается в недостаток сред проверок и автоматических тестов, которые проверяют критерии приема. Именно здесь и пригодятся контейнеры, виртуализация сервисов и автоматизация проверок приема.
FedjaNew
01.02.2017 19:12Давно установлено, что при эмиграции быстрее всего общаться с аборигенами на бытовом уровне начинают женщины. При этом они не могут объяснить, почему надо говорить именно так, ибо не углубляются в грамматику.
Мужчины же наоборот, сначала скрупулезно изучают грамматику и зубрят слова, и общаться начинают много позже.
Так вот, Agile — это явно женское начало в процессе разработки. Waterfall, V-model и т.д. — мужское.
В человеке и в человеческом обществе эти два начала являются типичным примером единства и борьбы противоположностей. Что мы наблюдаем и в процессах разработки.
http3
В течение спринта можно менять ТЗ? :)
mad_nazgul
Можно!
Но изменения переносятся на следующие спринты. <:o)
http3
Так какая же она тогда гибкая методология? :)
sentyaev
Если требования меняются в течении спринта, возможно нужно сократить длительность спринта (например с месяца до двух недель, или даже до недели).
Либо уделять больше времени на планирование вначале спринта.
unet900
Либо закладывать в спринте время для решения незапланированных задач. Например срочная починка багов на проде или прочая текучка, которая может вылезти в спринте. Примерно через 3-4 спринта (у нас были короткие по неделе) уже известно на что и сколько в уходит времени. ИМХО не на всех производствах ПО agile будет эффективен. Так же не везде его реально внедрить по «политическим» мотивам.
sentyaev
Это само собой. У вас же есть «velocity», он должен это учитывать (тут мы говорим о спринтах, и я подразумеваю, что имеем ввиду Скрам).
Тут правильно говорят, что Agile это не методология и даже не подход. Поэтому сложно что-либо говорить об эффективности.