Критика agile: почему гибкая методология разработки губит крупный бизнес и помогает малому — Офтоп на vc.ru – Дорогой Agile, мне надоело притворяться / Habr

Содержание

Дорогой Agile, мне надоело притворяться / Habr

«Agile мёртв». Люди всё время так говорят. Но обязательно добавляют: «Мы просто шутим». Они типа имели в виду, что это у тебя такие неправильные и глупые практики, что это для тебя Agile мёртв. Но «настоящий» Agile не мёртв. Просто все его делают неправильно. Так что я понял: настоящий Agile — это, знаете ли, Agile в теории. Даже я его внедрял. И знаете что? Мне надоело.

Недавно я видел в статьях ту же самую старую защиту: «Но-но-но, проблема в водопаде, скраме и неправильной реализации Agile, несоблюдении Манифеста… бла-бла-бла». Тогда Боб Маршалл сказал мне правду. Он сказал: «Заткнись, Чарльз. Манифест Agile — это кувшин, который мы наполняем». Он сделал несколько замечаний, с которыми мне пришлось согласиться. Я задумался. Результатом стала эта статья.

Вот вам тест. Как начинается первая строка манифеста Agile? Не подглядывать. Не знаете? Всё в порядке. Это не имеет значения. Там говорится: «Мы открываем более совершенные методы разработки программного обеспечения…» Стоп. Заметьте, написано: «разработка программного обеспечения». Там не говорится: «вытягивание вашей организации», «погашение долга за трансформацию», «выкраивание его с помощью этого командно-контрольного дерьма», «сосредоточение на результатах и улучшение работы по открытию», «исправление вашей средневековой системы бюджетирования» или любой ещё более продвинутой добавленной ценности, которую люди пытались в него вложить. Но дело в том, что когда люди говорят, что Agile относится ко всей организации, это ревизионизм. Это нечестно.

Заметьте также, что он начинается «Мы открываем…» Он не говорит: «Мы получили свыше…» Вам не кажется, что с 2001 года мы кое-чему научились? Я имею в виду, да, большинство крупных организаций всё ещё застряли в 1987 году, но ладно вам. Вопреки распространённому мнению, фотография ниже на самом деле не из акта подписания Манифеста. Можем мы наконец перестать притворяться?

Манифест служил определённой цели, но он не приведёт вас туда, куда вам нужно. Так что приступайте к учёбе. У наших знаний есть срок годности, и не такой большой, как мы думаем. У всех есть коллеги (обычно начальники), которые утверждают, что у них «нет времени учиться». Вы сами знаете, что они слишком самоуверенны в своих знаниях. Так что найдите хороший список книг. Следите за хорошими блогами. Вот для начала: если вы не читали

Sense & Respond, Lean Enterprise, A Seat at the Table и Everyone Is a Change Agent, предлагаю сделать это немедленно. И вашим начальникам.

Начните читать посты Джона Катлера, Мелиссы Перри, Боба Маршалла, Аллена Холуба, Лоры Кляйн, Эрики Холл, Нила Киллика и тех, на кого они ссылаются. Они все согласны друг с другом (или со мной)? Нет, но они умны и вас тоже сделают умнее. Приступайте к чтению и поощряйте других. Fast Company говорит, что средний генеральный директор читает 60 книг в год. Сколько книг читают ваши руководители? И что они читают? (Статьи HBR, репортажи Gartner и романы Мейв Бинчи не в счёт). Потому что давайте посмотрим правде в глаза: если ваши руководители мастера Scrum, то вы прочно застряли в 80-х и 90-х годах.

Давайте перейдём к непрерывному обучению и перестанем притворяться, что Agile — какое-то лекарство. Это нужно сказать: Agile есть и всегда был локальной оптимизацией для небольшого повышения эффективности системы. Только Agile несправедливо вынес под микроскоп команды разработчиков программного обеспечения. Это никак не повышает организационную гибкость. НИКАК. Интересно, что, по словам Кена Швабера (см. его «Небезопасно на любой скорости»), Agile был попыткой «компенсировать ущерб, нанесённый водопадом», и всё же никогда не давал организациям целостную, жизнеспособную альтернативу водопаду. Потому что есть разница между теорией и практикой. Работа над продуктом — это скорее практика. Когда мы жалуемся на AINO (Agile In Name Only), мы не честны с самими собой.

Теория против практики, помните? Мы должны быть прагматичными. Agile на практике почти всегда AINO. Похоже, проблема с самим движением, не так ли? В любом случае, есть более важные вещи, о которых нужно узнать, включая (но не ограничиваясь) Lean UX, Lean Enterprise, Beyond Budget, Theory of Constraints, Throughput Accounting, Design Thinking, DevOps, организационная терапия Маршалла и т. д.

Вы спросите, почему Lean UX возглавляет список? Из-за того, что по своей сути Lean UX популяризует концепцию ориентированности на результат. Подумайте: если вы не знаете, какое изменение поведения пытаетесь создать, то не будете понимать свои действия. Если у вас нет однозначной сигнализации «поворота» (pivoting), то вы уже не можете быть гибким. Вот что такое Agile, в конце концов, это pivoting. Некоторые могут возразить: «Но-но-но, проверять и адаптироваться!» Конечно. Теория против практики, помните? Я не вижу гибких команд, которые проверяют и адаптируются. Я вижу, как команды Agile пытаются наверстать отставание, возятся с Jira и Rally и работают так, будто строят кирпичную стену по приказу.

Agile на самом деле имеет тенденцию маскировать основную проблему — это системное, двунаправленное отсутствие вертикального доверия. Коачи Agile уходят, ухудшив ситуацию: они оставляют после себя менеджеров, говорящих на поросячьей латыни, и команды разработчиков, которые перешли на эсперанто. Команды считают, что управление сломано, а руководство считает, что основное внимание по-прежнему надо уделять объёму, срокам и эффективности, игнорируя, что сроки являются произвольными, а оценки времени являются формой отходов. (Знаете ли вы, что стори-поинты на самом деле изобрели, чтобы скрыть время и помочь решить саму проблему? Здесь тоже появились неприятные последствия, не так ли? Теория и практика).

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

это команда. Кончайте уже с локальными оптимизациями и осознайте, что доверие — это проблема №1. Перестаньте несправедливо помещать разработчиков под микроскоп, позволяя остальным прятаться в чёрном ящике. (Почему нас не интересует, как работают команды стратегического развития? Или как архитекторы легаси являются ограничениями в системе?)

И пока мы этим занимаемся, следует перестать относиться к командам разработчиков так, будто они работают на заводе. Мы не штампуем пластиковую посуду. Мы создаём программное обеспечение. Нужно перестать вести себя так, будто мы заправляем пиццерией. Здесь другие правила. Мы не используем один и тот же проверенный рецепт. Мы разрабатываем рецепты. Если вы ещё не поняли, это работа по открытию, а не просто доставка. Пренебрежение открытием приводит к массовым потерям: неиспользуемые функции и другая работа, которая не достигает результатов. Это обнажает ещё один глубокий недостаток Agile. Он предполагает, что пользователей можно воспринимать как морских свинок: «Эй, просто используйте этот дерьмовый продукт, тогда мы улучшим его». За исключением того, что дерьмовый продукт обычно таким и остаётся, не так ли? Будущие улучшения становятся ненужными «затратами».

Но-но-но, Agile действительно нацелен на исследования! Правда? Будем честными. Теория против практики, помните? Если вы зарабатываете на жизнь проектированием или исследованиями, то ответьте на этот вопрос. Как вы обычно относитесь к работе с гибкими командами? Вас изначально рассматривают как ценность и просят помочь «проверить и адаптировать»? Или вас просят «доказать свою ценность»? Как сказал Алан Купер, когда вас просят «доказать свою ценность», вам ясно дают понять, что вы находитесь в системе, которая вас не ценит. Обратите внимание, что они просят отдельного участника доказать свою ценность — они не спрашивают, какая часть их кода на самом деле смещает показатели в правильном направлении. Другими словами, они по-прежнему фокусируются на людях,

а не на самой работе. Вероятно, они всё ещё сосредоточены на костах, а не на ценности, игнорируя те области, где значительная часть ценности фактически утекает.

Если вы работаете с гибкими командами, в следующий раз, когда вас попросят «показать свою ценность», попробуйте это. Начните задавать им вопросы. Знают ли они, какова цена задержки? Какие упражнения они используют для оценки этого параметра? Каких конкретных результатов они пытаются достичь? Какая доля их продукта фактически достигает своих показателей? Они не знают? Если есть более быстрые и дешёвые способы узнать, что разрабатывать, кроме как просто выпускать код, заинтересованы ли они в обучении? Какова их эффективность потока? Насколько всё плохо? Сколько времени они проводят на собраниях? Если есть дизайнерские игры и упрощённые действия, которые приведут к лучшим решениям за гораздо меньшее время, они заинтересованы в обучении? Потому что я не просто покажу вам свою ценность — я научу вас создавать больше ценности

во всём, что вы делаете.

Это другой способ мышления. Это мета. Это стратегически. Как отмечает Остин Говелла, и Agile, и водопад сосредоточены на разработке. Дизайн — это проверка. Если они не заинтересованы, можно уходить. Если они просто опустив головы выпускают продукт, фокусируясь на издержках, то никогда даже не узнают достаточно, чтобы понять, что вы, как правило, получаете больше того, на чём фокусируетесь (гм, косты). Это фабрика по производству функций. Круговая порука. Они притворяются, что создают пластиковую посуду. У вас есть дела поважнее. Потому что реальная ценность обеспечивается опциями, которые генерируются путём исследования. Чем больше опций вы создаёте и чем более гибок ваш подход, тем больше возможных путей и лучше результат. Чего они пытаются достичь? Исследовали ли они три-пять способов достижения этой цели? Это приведёт к лучшему принятию решений на перспективу. Одна опция — это не выбор. Два — это дилемма. Три — теперь вы кое-чего добились.

Когда-нибудь слышали о Законе необходимого разнообразия? Компонент с наибольшим количеством опций управляет системой. Примените это к тупой борьбе за власть «Agile против водопада». У вас были руководители, которые пытались сохранить контроль над системой сверху, и гибкие команды, которые пытаются приблизить ценность к источнику (реальные пользователи и клиенты). Выход из бессмысленной гражданской войны — научить людей генерировать варианты на всех уровнях. Путь вперёд — не «Agile против водопада». Это умная стратегическая работа сверху вниз (водопад) с эмпирически-ориентированными тактиками снизу вверх. Дизайн и открытие помогают в обоих случаях.

Так… каков выход? Это разумный фокус на чётких результатах, а не на выдаче, с запланированными результатами вместо запланированных отметок, не с проектными, а с надёжными продуктовыми командами, уполномоченными проверять предположения и находить кратчайший путь к ценности.

Теперь к обучению (адаптировано на базе диаграммы Джона Катлера).

Так… значит, Agile уходит? Конечно, нет. Это просто глупое сообщение в блоге. У меня нет никакой власти. И если бы даже была, Agile всё равно не исчез бы. Движение Agile сделало возможным появление многих из упомянутых концепций. Кроме того, вопреки распространённому мнению, гибкие практики не были изобретены движением Agile. Они появились на десятилетия раньше.

Так что нет, я не хочу, чтобы Agile уходил.

Я просто хочу, чтобы мы стали честнее.

что такое Agile и где его применять — Офтоп на vc.ru

Вы, наверное, уже сталкивались с дискуссиями по теме Agile в интернете. То рассказывают про Scrum — революционный метод управления проектами, то говорят, что Agile у нас не завелся. Со стороны всё это выглядит как минимум непонятно. Поэтому давайте разбираться вместе, о чём говорят все эти люди вокруг.

Agile — прилагательное

В переводе с английского языка, Agile («эджайл») — гибкий. Поэтому все эти фразы, которые я встречал за последнее время в интернете:

управление проектами в стиле Agile;

Agile-манифест;

Agile у нас не заработал;

стань первым Agile-маркетологом в России;

можно перевести, как:

управление проектами в стиле гибкий»;

«гибкий-манифест»;

«гибкий у нас не заработал».

Ну и очевидно, что йоги-маркетологи — новый тренд, который только-только идет в Россию. А гибкий-манифест, — вы можете себе такое представить? Наверное, это кусочек пергамента, который умеет танцевать на столе. Понимаете к чему я? Люди вокруг говорят странные фразы, при этом у них горят глаза и они спешат внедрить Scrum. Страшно!

Так, а что же там за манифест

Более 15 лет назад группа профессионалов, разрабатывающих программное обеспечение, собралась на горном курорте обсудить методики и практики, которые позволяют им создавать программные продукты, востребованные конечными пользователями.

Они описали ценности и принципы, которые лежат в основе создания программных продуктов, в документе под названием «Манифест гибкого подхода к разработке программных продуктов». Да, они сами используют сокращенный вариант Agile Manifesto, но за этой фразой скрывается именно набор ценностей и принципов, которые являются фундаментальными для большого количества методик и практик, помогающих создавать качественные и востребованные программные продукты.

Перевод — ответственная работа. Потеря контекста при переводе иностранной литературы — это серьезная проблема, которая формирует неверное представление о сути у читателя.

Простой пример: «Agile-манифест разработки программного обеспечения». Что вы запомните из этой фразы? Наверное, «Agile-манифест», а вспомните ли вы, что это про разработку программных продуктов? Надеюсь. А вот призёр — первое место, золотая медаль на конкурсе по потере контекста в процессе перевода.

В оригинале книга называется «Scrum — the art of doing twice the work in half the time», что практический любой бесплатный электронный переводчик переведёт как «Scrum — искусство делать вдвое больше работы в два раза быстрее». Ни слова о проекте. Scrum вообще не про проекты. Увы и ах.

Люди и взаимодействие важнее процессов и инструментов. Работающий продукт важнее исчерпывающей документации. Сотрудничество с заказчиком важнее согласования условий контракта. Готовность к изменениям важнее следования первоначальному плану. То есть, не отрицая того, что справа, мы всё-таки ценим то, что слева.

— из Agile-манифеста

На самом первом месте, конечно же — человечность. Чтобы создавать востребованные и качественные продукты, нужны в первую очередь знания из гуманитарных областей. Потому что создают продукты живые люди.

Кстати, позвольте придерусь к первой ценности в русскоязычном манифесте.

Гибкая методология разработки (Agile)

Описание гибкой методологии разработки

Гибкая методология разработки (от англ. — Agile software development) — манифест, определяющий способ мышления и содержащий основные ценности и принципы, на которых базируется несколько подходов (фреймворков, от англ. framework — каркас, структура) к разработке программного обеспечения (хотя в последнее время идет тенденция и попытки применения гибкой методологии разработки к иным направлениям деятельности, не только в части информационных технологий), подразумевающих под собой интерактивную разработку, периодического (динамического) предоставления (обновления) требований от Заказчика и их реализацию посредством самоорганизующихся рабочих групп, сформированных из экспертов различного профиля (разработчики, тестировщики, внедренцы и т.д.). Такой перевод Agile, как «гибкая методология разработки» не совсем корректен т.к. обычно Agile не называют методологией, а вот подходы на основе данного манифеста и есть методологии, но с точки зрения Agile их называют — фреймворки. На данный момент существует множество фреймворков (методологий), подходы которых базируются на гибкой методологии разработки, например такие, как: Scrum, Extreme programming, FDD, DSDM и т.д.

Определение с точки зрения BPM CBoK [от англ. — Guide to the Business Process Management Common Body Of Knowledge]. Agile — Одна из методологий итеративной и пошаговой разработки ПО, в противоположность традиционной линейной методологии «водопад». Методология гибкой разработки определяет систему методов проектирования, разработки и тестирования на протяжении всего жизненного цикла ПО. Методы гибкой разработки (например, SCRUM) основаны на оперативном реагировании на изменения за счет применения адаптивного планирования, совместной выработки требований, рационализации самоорганизующихся кросс‑функциональных групп разработчиков, а также пошаговой разработки ПО с четкими временными рамками. Этот подход используется во многих современных проектах разработки коммерческого ПО.

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

За счет того, что разработка программного обеспечения с применением гибкой методологии определяет серии коротких циклов (итераций), с длительностью 2-3 недели, достигается минимизация рисков т.к. по завершению каждой итерации Заказчик принимает результаты и выдает новые или корректирующие требования т.е. контролирует разработку и может на неё сразу влиять. Каждая итерация включает в себя этапы планирования, анализа требований, проектирование, разработку, тестирование и документирование. Обычно одной итерации не достаточно для выпуска полноценного программного продукта, но при этом по окончании каждого этапа разработки должен появляться «осязаемый» продукт или часть функционала, которую можно посмотреть, потестировать и выдать дополнительные или корректирующие меры. На основе проделанной работы, после каждого этапа, команда подводит итоги и собирает новые требования, на основании чего вносит корректировки в план разработки программного обеспечения.

Одной из основных идей Agile, является взаимодействие внутри команды и с заказчиком лицом к лицу, что позволяет быстро принимать решения и минимизирует риски разработки программного обеспечения, поэтому команду размещают в одном месте, с географической точки зрения. Причем в команду входит представитель заказчика (англ. product owner — полномочный представитель заказчика или сам заказчик, представляющий требования к продукту; такую роль выполняет менеджер проекта от заказчика или бизнес-аналитик).

История выпуска Agile манифеста

«Манифест гибкой методологии разработки программного обеспечения» был выпущен и принят в феврале 2001 года (штат ЮТА США, лыжный курорт The Lodge at Snowbird) группой экспертов. Данный манифест определяет 4 основные ценности и 12 принципов для методологий, базирующихся на нем, а также дает альтернативное видение подхода к разработке программного обеспечения в отличие от крупных и известных методов и методологий, но не является сам по себе методологией. Обычно Agile сравнивают в первую очередь с «методом водопада» («waterfall»), т.к. на момент выхода манифеста, именно «метод водопада» являлся основным при планировании разработки программного обеспечения. В разработке и выпуске Agile манифеста принимали участие представители следующих методологий:

Adaptive software development (ASD)
Crystal Clear
Dynamic Systems Development Method (DSDM)
Extreme Programming (XP)
Feature driven development (FDD)
Pragmatic Programming
Scrum

Собственно данные методологии гибкой разработки существовали и до выпуска манифеста. Сам же выпуск манифеста дал новый толчок к развитию гибких методологий, заложил основы, можно сказать конституцию гибкого подхода к разработке программного обеспечения.

Agile-манифест разработки программного обеспечения:

Основной метрикой agile-методов является рабочий продукт. Отдавая предпочтение непосредственному общению, agile-методы уменьшают объём письменной документации по сравнению с другими методами.
Это привело к критике этих методов как недисциплинированных.

Мы постоянно открываем для себя более совершенные методы разработки программного обеспечения, занимаясь разработкой непосредственно и помогая в этом другим. Благодаря проделанной работе мы смогли осознать, что:

Люди и взаимодействие важнее процессов и инструментов
Работающий продукт важнее исчерпывающей документации
Сотрудничество с заказчиком важнее согласования условий контракта
Готовность к изменениям важнее следования первоначальному плану

То есть, не отрицая важности того, что справа, мы всё-таки больше ценим то, что слева.

Авторы манифеста:

Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas

Основополагающие принципы Agile-манифеста:

Мы следуем таким принципам:

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

Критика Agile

Agile плохо описывает процессы управления требованиями, можно сказать, что такое понятие просто отсутствует т.к. гибкая методология разработки не подразумевает под собой долгосрочного планирования (планирование осуществляется на краткосрочную перспективу), как следствие пропущен шаг формирования плана развития продукта или другими словами дорожной карты продукта. Т.к. планирование краткосрочное (на ближайшую итерацию разработки), а Заказчик по окончанию каждой итерации принимает продукт и выставляет новые требования, сам продукт может поменяться в корни, а выставляемые новые требования зачастую противоречат структуре и архитектуре продукта уже поставляемого клиентам. По большому счету, в случае, если Заказчик не до конца понимает, что хочет увидеть в итоге (конечный продукт), а понимание приходит во время разработки (это случается в 90% случаев), процесс разработки превращается в формализованную и легализованную бюрократию т.е. продукт дорабатывается бесконечно, пока не кончаются деньги, или заказчик не переключается на другой продукт. Справедливости ради, необходимо заметить, что Заказчик знает на что идет и сам решает, платить за разработку продукта или нет, по большому счету команда разработчиков просто выполняет требования заказчика. Однако, реально, в работе это приводит к хаосу, срыву сроков и авралам, что порождает новые требования, которые меняют не в лучшую сторону продукт. Более того, снижается качество разрабатываемого продукта, т.к. Agile определяет подход к разработке, в рамках которого необходимо быстро тушить пожары, наиболее простым и быстрым способом. Код пишется не соблюдая требований платформы, на которой разрабатывается продукт, появляется множество обходных решений и дефектов, а такая конструкция не очень устойчива и не безопасна, растет негодование клиентов от частых сбоев в работе программного обеспечения. Бизнес на выходе получает потери, падает качество планирования.

Некоторые эксперты Agile ассоциируют больше с подходом по совершенствованию уже готового продукта, нежели разработки нового. Сторонников много у гибкой методологии разработки, ровно, как и противников. Последние в свое время даже выпустили Anti Agile Manifesto. Далее в ознакомительных целях, мы приводим содержание двух, наиболее популярных манифестов, противоречащих основному манифесу Agile:

Anti-Agile манифест (необходимо отметить, что данный anti-agile манифест на самом деле противоречит не самому Agile, а скорее одному из фреймворков, основанном на принципах Agile — Scrum т.к. в манифести используются термины именно из этого фреймворка):

Через нас прошло множество консультантов и мы провели огромное количество часов на встречах и совещаниях по гибкой методологии. Опираясь на данный опыт, мы поняли, что Agile, это просто запудривание мозгов, потому, что:

эпики (epics) — это просто проекты
пользовательские истории (user stories) — это просто сценарии использования (use case)
спринты (sprints) — это просто работа
стенд апы (stand-ups) — это просто совещания
итерации (iterations) — это просто версии
бэклоги (backlogs) — это просто список дел
скорость команды (velocity) — это просто результаты
и эти задачи (tasks) — это реально, просто задачи

Таким образом, в то время, когда термины слевой стороны предлагается рассматривать как новаторские, меняющие подход к разработке, они просто являются расплывчитыми понятиеми терминов справа.

Разновидность методологий гибкой разработки

На основании ценностей и принципов, определенных в Agile Manifesto были сформированы следующие гибкие методологии разработки:

Agile Modeling (AM) — данный подход в основе своей определяет процедуры моделирования (в т.ч. проверка модели кодом) и документирования в рамках разработки программного обеспечения. В меньшей степени описаны процедуры проектирования и построения диаграмм на UML. также не затронуты области разработки, тестирования, управления проектом, развертывания и сопровождения.
Agile Unified Process (AUP) — унифицированная версия методологии RUP (IBM Rational Unified Process), которая была сформирована Скоттом Амблером. AUP определяет модель создания программного обеспечения в рамках бизнес-приложений.
Agile Data Method (ADM) — набор итеративных методик гибкой разработки программного обеспечения, в рамках которых делается упор на формирование требований и решений посредством сотрудничества различных кросс-функциональных команд.
Dynamic Systems Development Method (DSDM) — итеративный и инкрементный подход, базирующийся концепции быстрой разработки приложений — Rapid Application Development (RAD), упор в котором делается на максимальное привлечение конечного пользователя к разработке программного продукта.
Essential Unified Process (EssUP) — подход, разработанный Иваром Якобсоном (Ivar Jacobson), содержит в себе методы итеративной разработки программного обеспечения, с упором на архитектуру продукта и наработанные практики команды (по сути заимствованные из RUP, CMMI и Agile Development). Идея заключается в том, что вы используете только те практики и методы, которые применимы в конкретной ситуации. На основе выбранных методов и практик определяется целевой процесс. В отличие от RUP, где все практики и методы взаимосвязаны, в данном случае появляется гибкость и возможность вычленить из всего доступного объема именно необходимые элементы (методы и практики).
Extreme programming (XP) — идея экстремального программирования заключается в том, чтобы использовать уже имеющиеся лучшие практики в области разработки программного обеспечения, подняв их на новый (экстремальный) уровень. Например в отличие от обычной практики, когда один программист последовательно проверяет написанный код за своим коллегой, в экстремальном программировании данная проверка осуществляется параллельно, что увеличивает скорость выпуска продукта, но и риски тоже.
Feature driven development (FDD) — основное ограничение, которое накладывается в рамках данного подхода, это «каждая функция должна быть реализована не более, чем за две недели». Т.е. если реально разработать функцию за один присест, то это хорошо, в противном случае данная функция должна разбиться на несколько и реализовываться постепенно.
Getting Real (GR) — в рамках данного подхода исключены процедуры функциональных спецификаций, использующийся для веб-приложений. Разработка начинается от обратного, изначально разрабатывается интерфейс и дизайн, а потом сама функциональность.
OpenUP (OUP) — данный подход определяет итеративно-инкрементальный метод разработки программного обеспечения. Разработан на основе RUP. В рамках данного метода определен жизненный цикл разработки (фаза запуска, фаза уточнения, фаза разработки и передачи заказчику). Благодаря определенной этапности и контрольных точек, повышается эффективность контроля и мониторинга хода реализации проекта, как следствие своевременное принятие решений по проекту.
lean software development — данный подход основан на концепции бережливого управления производственным предприятием (lean production, lean manufacturing).
Scrum — один из самых распространенных подходов гибкой разработки программного обеспечения, определяет правила управления процессом разработки с применением существующих практик разработки. Упор осуществляется на вовлеченность Заказчика в процесс (возможность после каждого этапа менять или уточнять требования к создаваемому продукту), что позволяет вовремя определить отклонения и внести необходимые изменения.

Организация: см. авторов
Сайт организации: http://agilemanifesto.org
Страны: все страны

Почему Agile вам не подходит / Habr

Ни об одной теме я не слышал столько негативных отзывов, как об Аджайл. Дескать, он и неэффективный, и не работает, и подходит для ленивых, и придуман для зарабатывания бабла на консультациях, и вообще, нам аджайл не подходит.

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

Начнём с того, что такое аджайл для разработчика? В первую очередь аджайл — это дисциплина. Дисциплина, которая позволит работать эффективнее, но отнюдь не задаром. Аджайл кое-чего требует от разработчика.

Чтобы информация внутри команды быстро распространялась, и любые проблемы сразу вылезали наружу, аджайл предписывает ежедневные утренние собрания — стэндапы, где каждый вкратце рассказывает, чем занимался вчера, что успел сделать и с какими проблемами столкнулся.

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

Код должен быть простым и читаемым, чтобы его можно было легко менять, причём в любой момент и разным людям. Для этого надо свой код постоянно критически пересматривать и рефакторить. Те, кто относится к своему коду как к детищу, требование постоянно менять код воспринимают как личную обиду. «Я тут старался, созидал, а теперь — снова менять?…»
И конечно, мало кому нравится то, что твой код смотрят и меняют своими грязными лапами посторонние люди.

Чтобы убедиться, что проект работает, приходится писать юнит-тесты. То бишь кода получается вдвое больше, а на разработчика вешается вдвое больше работы. А ради чего? Всё равно тесты не дают стопроцентной гарантии и никогда не найдут всех багов. Так пусть тестировщики их и ищут, они для этого и существуют!

Чтобы убедиться, что проект работает так, как хотел клиент, приходится писать приёмочные тесты. А с ними столько мороки… Они и медленные, и ломаются постоянно… Да какого чёрта, не проще ли руками всё прокликать? Тем более что для этого есть тестировщики.

Чтобы убедиться, что проект не развалится при интеграции изменений разных разработчиков, аджайл предлагает Continuous Integration сервер. Вот ещё, придумали на нашу голову! Теперь в мой почтовый ящик сыпется куча каких-то левых писем о том, что билд сломался. И я должен лезть на какой-то сервер и разбираться, почему тесты красные? Да я, может, и не при чём тут, чего я буду время тратить!

Чтобы постоянно обсуждать все вопросы дизайна, делать непрерывный code review, мгновенно находить ошибки и писать другу другу тесты, аджайл прописал парное программирование. Несомненно, этого разработчики боятся больше всего. Ещё бы! Целый день со мной рядом будет сидеть какой-то чувак, который будет мне указывать, как и что делать. Тыкать носом в мои ошибки. Ни тебе почту почитать, ни новости, ни анекдоты. Нет уж, увольте! А если у него другой стиль? Если наши мнения разойдутся? Если ему нравится ставить скобочки в том же ряду, а мне — в следующем? Мы целый день будем спорить? Спасибо, нам такого добра не надо.

Чтобы разработчик лучше понимал проблемную область и мог своевременно предлагать простые решения, необходимо прямое общение с клиентами. Ой-ой-ой, я и с коллегами-то предпочитаю говорить по телефону, а с клиентом…

Итак, аджайл — это дисциплина, которая

позволяет

создавать работающий продукт с высоким качеством в предсказуемые сроки.
Но вот в чём заковырка. Это имеет смысл, только

если вы хотите

создавать работающий продукт с высоким качеством в предсказуемые сроки.

И тут мы подходим к самом главному: для большинства разработчиков это не является главным приоритетом. Да, такова грустная правда.

Среднестатестическому разработчику интересно писать какой-нибудь нибудь сложный заковыристый модуль (пусть даже никому не нужный), но неинтересно писать простой до безобразия, но работающий продукт. Я знаю, о чём говорю, я сам таким был. Мне было интереснее написать свой класс StringUtils, чем использовать существующую библиотеку типа commons-lang. Просто потому, что это интересно. Интересен сам процесс создания этой фиговины. А что там с клиентом? Да ничего с ним не случится, полгода ждал и ещё подождёт. Сейчас я свой StringUtils закончу и тогда займусь его проблемой.

И самое главное: рядовой разработчик ценит свой комфорт за компьютером. Моё рабочее место — мой дом родной. Я тут настраиваю всё как хочу, ставлю свой десктоп, музыку, аудиоплеер, программки там разные, фотографию в рамке на стол. У меня тут даже чашка своя отдельная. Тут у меня зона комфорта. Тут только я и мой компьютер. Ну да, приходят иногда начальники и тестировщики, врываются в мой мирок, но это временно. Поговорят и уйдут. И снова воцарится мир в моём мире.

Это факт: рядовой разработчик не хочет никого пускать в это пространство! Что вы говорите? Парное программирование повысит производительность? Уменьшит количество багов? Улучшит дизайн кода? Хм… да нет не верю. Да всяко же двое по отдельности сделают вдвое больше. Вот так и рождаются разговоры о том, что аджайл не работает.

Итак:

для большинства разработчиков собственный комфорт важнее, чем работающий софт, чем успех компании и всё прочее.

Поэтому Agile не подходит для большинства разработчиков. Agile отнимет у вас привычный комфорт, отнимет персональный десктоп и заставит работать по правилам. И это только для того, чтобы компании было лучше и клиент был доволен.

Пока в вашей компании собственный комфорт для разработчиков важнее успеха компании, никакой аджайл вам не поможет. Не нужно всех этих дорогущих тренингов, насильственных внедрений Scrum, Lean, TDD и т.д. Всё это ни-па-мо-жыт. Проблема глубже.

Помимо той мотивации, которую может придумать руководство компании, аджайл тоже предлагает свои мотиваторы. Поверьте, когда вы немножко привыкнете, вы поймёте, что практики аджайл могут быть очень весёлыми, как например, пинг-понг программирование. Как сказал Vlad911,

Парное программирование — это отличный способ повысить мотивацию. Всегда можно договорится со своим напарником о том, что делать и как делать, чтобы это не превращалось в рутинную работу, можно динамически меняться ответственностью и не заниматься «одним и тем же», что часто приходится делать в одиночку.

Коммитить код, будучи уверенным, что он работает как надо — само по себе большое удовольствие.

И наконец, один из самых больших мотиваторов — это, как ни странно, живое общение с клиентом. Сравните: когда к вам приходит начальник и спрашивает: «Ну что, наконец-то доделал?», и когда к вам приходит клиент и говорит: «Вау, вы это сделали! Это то, что надо, спасибо!» Оправдаться перед начальником легко: я был на митинге, мержил код, исправлял баги — что угодно. С клиентом такой фокус не прокатит. Надо либо делать работу, либо… другого варианта просто нет.

Так что если вы заинтересованы в успехе проекта, используйте аджайл. Если вам важнее ваша зона комфорта — что ж, заварите кофе и приступайте к чтению новостей. Agile вам пока не подходит.

в чем разница и для чего использовать? — Рамблер/новости

Рубрика «Инновации в корпорациях» выходит при поддержке Spinon.

Определение

Agile (agile software development, от англ. agile — проворный) — это семейство «гибких» подходов к разработке программного обеспечения. Такие подходы также иногда называют фреймворками или agile-методологиями.

Agile возник в IT-среде, но затем распространился и в другие сферы — от промышленной инженерии до искусственного интеллекта.

Смысл Agile сформулирован в Agile-манифесте разработки ПО: «Люди и взаимодействие важнее процессов и инструментов. Работающий продукт важнее исчерпывающей документации. Сотрудничество с заказчиком важнее согласования условий контракта. Готовность к изменениям важнее следования первоначальному плану».

Agile-манифест — главный документ всех «гибких» подходов к разработке. Он был создан в 2001 году группой энтузиастов-программистов, которые хотели понять, что именно лежит в основе разработки востребованного и полезного IT-продукта.

Agile предполагает, что при реализации проекта не нужно опираться только на заранее созданные подробные планы. Важно ориентироваться на постоянно меняющиеся условия внешней и внутренней среды и учитывать обратную связь от заказчиков и пользователей. Это поощряет разработчиков и инженеров экспериментировать и искать новые решения, не ограничивая себя жесткими рамками и стандартами.

К отдельным agile-подходам относятся scrum и kanban.

Scrum — это «подход структуры». Над каждым проектом работает универсальная команда специалистов, к которой присоединяется еще два человека: владелец продукта и scrum-мастер. Первый соединяет команду с заказчиком и следит за развитием проекта; это не формальный руководитель команды, а скорее куратор. Второй помогает первому организовать бизнес-процесс: проводит общие собрания, решает бытовые проблемы, мотивирует команду и следит за соблюдением scrum-подхода.

Scrum-подход делит рабочий процесс на равные спринты — обычно это периоды от недели до месяца, в зависимости от проекта и команды. Перед спринтом формулируются задачи на данный спринт, в конце — обсуждаются результаты, а команда начинает новый спринт. Спринты очень удобно сравнивать между собой, что позволяет управлять эффективностью работы.

Kanban — это «подход баланса». Его задача — сбалансировать разных специалистов внутри команды и избежать ситуации, когда дизайнеры работают сутками, а разработчики жалуются на отсутствие новых задач.

Вся команда едина — в kanban нет ролей владельца продукта и scrum-мастера. Бизнес-процесс делится не на универсальные спринты, а на стадии выполнения конкретных задач: «Планируется», «Разрабатывается», «Тестируется», «Завершено» и др.

Главный показатель эффективности в scrum — это среднее время прохождения задачи по доске. Задача прошла быстро — команда работала продуктивно и слаженно. Задача затянулась — надо думать, на каком этапе и почему возникли задержки и чью работу надо оптимизировать.

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

Примеры употребления

Один из принципов Agile стоит на личной ответственности человека, а не на отлаживании внутренних процессов.

(Из статьи на VC.ru)

Когда в работе с профессиональными командами мы используем Scrum, чаще всего мы выбираем цикл длиной в 2–3 недели с ретроспективными собраниями, которые позволяют держать все под контролем.

(Из интервью «Ведомостей» с Фрэнком Сосьером, коучем компании Freestanding Agility)

Главная идея Kanban — визуализация рабочего процесса. Она заключается в создании физической панели, на которой можно наглядно отмечать прогресс.

(Из перевода колонки Forbes на Rusbase)

Если говорить о том, что такое agile, я бы ограничился такой фразой — это набор ценностей, в рамках которых мы строим свою работу с продуктами, с процессами внутри организации.

(Управляющий партнер ScrumTrek Алексей Пименов в статье на Rusbase)

Слово экспертам

Владимир Овелян

Владелец и генеральный директор Dostаевский

В зависимости от задач мы применяем разные методы — agile, scrum, kanban.

Scrum позволяет развить в сотрудниках необходимые качества — проактивность, самостоятельность, организованность, коммуникабельность и дальновидность. Основной смысл метода — это выполнение задач в самоорганизующихся командах, где у каждого есть своя роль и каждый несет ответственность за свою часть работы. Используя scrum, мы проводим опросы персонала, составляем графики ожидаемой скорости выполнения задач.

Agile мы используем во внутренних коммуникациях. Недавно провели очередной спринт по ликвидации опозданий сотрудников. Все начальники и специалисты, задействованные в проекте, провели целый день на совещании, обсуждая достижения, проблемы и предстоящие задачи в новом спринте.

Сейчас момент мы активно внедряем в компании метод kanban. Цель внедрения kanban — повысить гибкость производства, лучше приспосабливаться к изменяющимся требованиям рынка. На практике метод помог нам добиться соответствия между складскими запасами и реально используемыми в производстве продуктами.

Виталий Сотников

Креативный директор Бюро визуальных коммуникаций «Черника»

Важный момент: agile-методология — это общее направление, а kanban и scrum — уже ее разновидности.

Мы используем связку scrum + waterfall, а также дорабатывали в течение года саму agile-доску. Главная причина использования: прозрачность и простота. По сути, это получается тот же самый конвейер Генри Форда: переход задачи от статуса к статусу со сменой исполнителя, поэтому основным принципом к самой agile-доске является уже простота.

Мы используем agile как непосредственную часть нашего workflow, поэтому все проекты, от брендинга и разработки сайтов и вплоть до нашего стартапа по AI и нативной рекламе NativeOS, в бюро Chernika ведутся как раз по данному workflow.

Работающий продукт важнее подробно прописанной документации. Это не говорит о том, что мы не ведем никакую документацию, нет. Это скорее взгляд в сторону эффективности с ударом по излишней бюрократии.

Илья Шихалеев

Ведущий разработчик и скрам-мастер iSpring

Scrum принес в нашу команду ритмичность и понимание — успеваем или не успеваем в срок. Мы видим скорость работы команды, нет ощущения постоянного факапа. Раньше были ситуации, что перед жесткими релизами scrum куда-то пропадал и все начинали просто херачить — сейчас у нас это пропало, есть постоянное ощущение, что успеваем в срок. Если появляются риски, мы обсуждаем их с PD на ранних этапах, корректируем план или уменьшаем объем задач каким-то образом.

Работа стала прозрачнее, рабочий день стал укладываться в 8-часовую норму и, по ощущениям, мы стали успевать больше. Мы понимаем, что когда у тебя есть ощущение, что ты не успеваешь, чувствуешь, что надо работать больше — это очень плохо влияет на продуктивность, от этого надо избавляться.

Евгений Россинский

Директор по технологии в онлайн-кинотеатре ivi
Для наглядности и открытости работы отдела разработки мы повесили специальную доску с пометками «to do», «in progress», «review», «test», «done», где все члены команды наклеивают стикеры с задачами (в колонке «to do»), а по мере их выполнения перемещают в последующие пункты. И счастливый финал — конечный пункт «done». Это помогает составить общую картину и дает возможность видеть, над чем работает каждый участник.

Очень важный момент метода (и организации рабочего процесса): после утверждения всех задач (“to do”), список блокируется на внесение. Так новые поступающие задачи не отвлекают от процесса и не тормозят работу.

Все участники также оценивают каждую задачу на предмет временных и материальных затрат, которые потребуются на выполнение. И вишенка на торте — еженедельные встречи в определенное время (Daily Scrum), где каждый член команды коротко рассказывает о том, что собирается сделать сегодня, что сделал вчера (и столкнулся ли с какими-то препятствиями). Это важно на пути к долгосрочным задачам — именно так можно вовремя понять, что пора сменить стратегию.

Ирина Черепанова

Директор по продукту uKit Group

Scrum мы внедрили с двух попыток, потому что всем, от команды до пользователей, хочется иметь более прогнозируемый результат. В этом плюс методологии — четкие ритмы упорядочивают коллектив, повышают общий уровень знаний о проекте. Как следствие, результат становится более прогнозируемым, в том числе для наших «стейкхолдеров» — пользователей.

Командная работа также повышает ответственность: все получают бонус, только если команда выполнила поставленные на определенном этапе задачи.

Инга Корягина

Доцент кафедры теории менеджмента и бизнес-технологий РЭУ им. Г. В. Плеханова

Agile — это философия, scrum — структура, waterfall — метод, kanban — система управления. Scrum и kanban — варианты agile, но у них есть некоторые явные различия. Методика scrum требует фиксированных ролей, тогда как у kanban нет необходимых ролей. Scrum основана на итерациях, объединяющих планирование, оптимизацию процессов и выпуск. В kanban это можно делать регулярно или каждый раз, когда вам нужно. Команда scrum требует оценки своей работы, тогда как команде kanban это не нужно.

Что почитать по теме?

Agile-манифест разработки программного обеспечения (Manifesto for Agile Software Development)

Дж. Сазерленд «Scrum. Революционный метод управления проектами»

Д. Андерсон «Канбан. Альтернативный путь в Agile»

Э. Стелманн, Дж. Грин «Постигая Agile. Ценности, принципы, методологии»

K. Schwaber, J. Sutherland «The Scrum Guide»

M. Cohn «Agile estimating and planning»

Текст: Александр Петров.

Cover photo by Daria Nepriakhina on Unsplash

Как agile выглядит на практике? — Хабр Q&A

Есть несколько вопросов по тому, как agile выглядит на практике (давайте для определенности возьмем scrum). Пока разбираюсь теоретически, по книжкам, хотелось бы спросить тех, у кого есть практический опыт — как решаются некоторые (может быть кажущиеся) проблемы и противоречия.

1). Что имеется в виду под кроссфункциональностью команды. «By the book» требуется, чтобы каждый работник мог взять и выполнить любую задачу. Но реально непонятно как это. Вот есть в реальной команде, допустим, фронтендер, бэкендер, специалист по базам и админ. Предлагается дать админу джаваскрипт код, а фронту потюнить базу? Так все развалится через неделю. Встречал уточнение, что на самом деле нужно добиваться того, чтобы команда в целом могла выполнить любую задачу по проекту, а специалисты внутри пусть будут узкими. Но это, понятно, накладывает серьезные ограничения на выбор задач из бэклога и на использование статистики.

2). Planning poker. Ситуация — два участника называют (и аргументируют) кардинально разные сроки. В «традиционном» менеджменте это решается так: Синьор Вася говорит «За 6 дней сделаем», джуниор Петя говорит «Хватит и 2 дней». Петя аргументирует, после чего Вася либо прислушивается в нему и корректирует оценку, либо говорит «Я старше[UPD: имеется в виду по должности], делаем как я сказал». На этом обсуждение завершается с некоторым результатом. В planning poker предлагается обсуждать, пока они не договорятся до какой-то совместной оценки. А если они за два часа не договорятся, что делать? Говорить, что задача «непонятная» и не брать на спринт? Тогда получается, что джуниор Петя заблокировал важную фичу. Во всех методиках переговоров есть план на случай, если компромисса не удастся достичь. Какой он в planning poker?

3). Нагрузочное тестирование. Это такой особенный вид тестирования, который может занимать, например, несколько суток и по его итогам может понадобиться значительная переделка архитектуры. При этом, когда разработчики реализовывают конкретные user stories они о роизводительности не думают, а в целом к системе требования по производительности должны предъявляться. Где место нагрузочному тестированию в scrum?

4). Парное программирование. Кто-нибудь вообще видел, чтобы такое применялось регулярно, а не в формате «джун смотрит через плечо синьора»? Если видели — скажите название компании, очень интересно.

5). Кто (какой человек) отвечает за факапы/срывы сроков и тэдэ. Ответ «вся команда» (= никто) вряд ли понравится заказчику из реального мира.

6) Кто принимает решения об увольнении и найме сотрудников?

Понятно, что на каждый из этих вопросов можно ответить «Примите душой Agile Manifesto и найдите ответы в себе», однако, хотелось бы узнать как это решается на практике. Понимаю, что тема несколько холиварная, но хотелось бы избежать ответов типа «Ты нифига не врубаешься в эджайл, иди в дворники» или «Все ответы есть в гугле/такой-то книжке». Вопросы понятно, заданы не ради троллинга, а ради знаний.