популярные мифы о гибкой разработке / Mail.ru Group corporate blog / Habr

Методологии гибкой разработки (Agile) прижились и в IT, и в не-IT, обросли своими приметами, стереотипами, суевериями и мифологией. Редакция блога Mail.Ru Cloud Solutions решила поговорить об этой мифологии с Agile-коучем Василием Савуновым из ScrumTrek.

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

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

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

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

Миф 1. Agile — это только для IT

Уже нет. Достаточно посмотреть на список компаний, от лица которых выступают спикеры на конференциях Agile Days и Agile Business Conference: «Газпромнефть», «Ростелеком», «Северсталь», PTG-Group, 12Storeez. Эти и масса других организаций, не относящихся к IT-индустрии, более чем успешно используют Agile-подходы.

Миф 2. Agile — не для проектов с фиксированным бюджетом

В рамках фиксированного бюджета можно работать очень по-разному. Вопрос в том, каковы взаимоотношения между исполнителем и заказчиком. Если использовать Agile, то нужно сосредоточиться на том, что решает проблему заказчика. Иными словами, если на старте заказчик и исполнитель вместе проведут планирование и выделят главные приоритеты продукта, то дальше ничто не помешает им определить, какую, максимально полезную, часть продукта исполнитель сможет реализовать в рамках ограниченного бюджета. А если ещё и оговорить регулярные показы сделанного заказчику, то вполне возможно корректировать процесс на коротких отрезках и, соответственно, регулировать затраты на реализацию проекта.

Миф 3. Agile — панацея для бизнеса и разработки: внедри, что-нибудь да улучшится

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

Определённо, Agile не нужен там, где залог успеха в следовании чётко заданному алгоритму действий. Например, в работе колл-центра, где для лучшего обслуживания операторы должны вести разговор по «скриптам», т.е. заранее прописанным сценариям коммуникации. Тут нет поля для экспериментов, и они тут могут оказаться даже вредны. А значит, Agile в деятельности операторов колл-центра, не нужен.

Agile окажется вреден там, где стоимость «переработки» или «доработки» продукта колоссальна или даже может быть сопряжена с человеческими жертвами. Скажем, при строительстве атомной электростанции – очевидно, что мы не можем строить ее итеративно-инкрементально, как нам диктует Agile.

Миф 4. Scrum, Lean, Kanban не пересекаются между собой

Следует разделять методологии и инструменты. Методология — это алгоритм построения рабочего процесса. Инструменты – это те «кирпичики», которые в этом алгоритме используются.

Разные методологии могут включать в себя одни и те же инструменты, но в разной компоновке. Часто можно увидеть, как при реализации Scrum прибегают к инструментам XP (экстремального программирования) или Kanban. И это нормально, так как все они отвечают ценностям Agile, и позволяют сделать рабочий процесс создания продукта гибким.

Если рассуждать о конкретных Agile-подходах, которые сейчас получили наибольшее распространение, то это, безусловно, Scrum и Kanban. Другие — FDD, XP, RUP и так далее, либо сошли со сцены, либо редко применяются целиком, но отдельные инструменты из их арсенала задействуются при реализации Scrum или Kanban.

Методологии гибкой разработки

Миф 5. Scrum — это как быстро и дёшево сделать продукт

Насчёт «быстро» всё верно, а вот насчет «дёшево» — нет. Судите сами: вам нужно сформировать полноценную команду, выделив в неё на 100% нужные компетенции. Эти люди будут заняты только разработкой вверенного им продукта и ничем другим, а значит, придётся либо нанять таких специалистов, либо «оторвать» их от какого-то отдела. То же самое касается бизнес-части: хочешь, не хочешь, а потребуется выделить владельца продукта, который 50–80% своего времени будет уделять только этой команде и её продукту.

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

Спринты

Спринт — термин из арсенала Scrum. Это фиксированный отрезок времени, в течение которого команда делает часть продукта, имеющую ценность для заказчика. Смысл — в том, что за каждый спринт команда должна сделать ещё один шаг, к цели, который можно «пощупать», оценить по реальному результату. Чаще всего длина спринта составляет 2 недели.

Спринт включает 4 обязательных встречи: планирование, реализация, релиз, спринт-ревью с ретроспективой. Кроме того, каждый день проводятся короткие встречи (stand-up meetings), на которых члены команды в едином формате «сверяют часы» и согласуют свои действия. Добавлять новые задачи в открытый спринт нельзя — это приучает команду к планированию и страхует от возникновения управленческого хаоса.

Миф 6. Канбан — это доски с вывешенными на них задачами

Вовсе нет! Доски — это лишь первый, самый простой шаг в Канбане. Но им дело не ограничивается. В основе Канбана — сложный математический аппарат, основанный на статистических данных. Поэтому приравнивать Канбан к доскам — значит не заглядывать дальше его фасада.

Если в двух словах, то главный смысл Канбана — в том, чтобы:

• Сделать текущий рабочий процесс прозрачным, причем охватить все стадии — от возникновения задачи в голове бизнеса до ее реализации и отгрузки продукта потребителю.
• Управлять рабочим процессом, выявляя потери времени и устраняя их. Таким образом, мы делаем наш рабочий процесс предсказуемым.
• Принимать управленческие решения на основе метрик, а не ощущений.

Миф 7. Scrum и Канбан можно насадить в любых проектах и компаниях

Мне не нравится слово «насаждение», всё-таки Agile — про работу с людьми. Правильнее будет говорить о том, чтобы «прививать» команде новую философию мышления.

При этом, алгоритм прививания Scrum и Канбан — разный.

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

Внедрение Scrum вообще требует больших изменений, как в структуре организации, так и в контрактовании с подрядчиками (нужен контракт time & material), и в бюджетировании (поэтапное бюджетирование), и во всём остальном.

Kanban столь радикальных изменений не требует. Он предлагает: «Начните с того, что есть, и начните эволюционно это улучшать». Скорость изменений будет значительно ниже, чем в Scrum, зато все изменения будут основываться на статистике и иметь чёткое обоснование.

Миф 8. Scrum рассчитан только на проекты, которые делаются с нуля

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

Например, один из создателей Scrum Джефф Сазерленд в своей книге «Scrum: The Art of Doing Twice the Work in Half the Time» рассказывал, как он применил Scrum для разработки автоматизированной системы учёта данных ФБР. Когда он взялся за проект, разработка шла четвёртый год, ни одну функцию не довели до релиза и ни конца, ни края проекту не было видно. Джеффу удалось радикально ускорить разработку и сделать её прозрачной для заказчиков. Через полгода увидела свет первая рабочая версия продукта, а в течение двух лет разработка была успешно завершена.

Пара слов о книге Джеффа Сазерленда

Scrum: The Art of Doing Twice the Work in Half the Time. В русском переводе — «Scrum: революционный метод управления проектами». Впервые изданная в 2014 году, книга описывает предпосылки к созданию методологии, её базовые принципы, инструментарий и примеры внедрения. За 20 лет, прошедшие с тех пор, как автор книги Джефф Сазерленд и Кен Швайбер системно описали концепцию Scrum, они приложили немало усилий к тому, чтобы распространить методологию за пределы IT-отрасли и поставить её на службу нетехнологическим компаниям — финансовым, промышленным и так далее.

Миф 9. При внедрении гибких методологий неизбежны конфликты с представителями традиционной иерархии

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

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

UPD. А вот и продолжение: Все дело в Agile — 2: особенности внедрения гибкой разработки

Нет времени объяснять, материал бескорыстно и с любовью подготовила команда Mail.Ru Cloud Solutions.

Agile умер, да здравствует… Agile / Habr

За последние несколько лет гибкие методологии почти вытеснили традиционные способы разработки – полностью по принципам Agile сейчас работают две трети IT-компаний. Оправдались ли ожидания, какие возникают проблемы и куда всё движется? Предлагаем анализ существующего российского и зарубежного опыта работы по Agile и ответы на эти вопросы.

Несмотря на то, что 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 лет гибкие методологии откроют себе путь в оставшуюся треть корпораций, которые до тех пор не осмелятся переводить разработку на более современный, но рискованный лад.

«Что такое описание процесса в agile?» – Яндекс.Кью

Agile — это образ мышления, основанный на ценностях и принципах Agile–манифеста.

В 2001 году на пару дней собрались вместе одни из самых лучших экспертов в IT–разработке. Они хотели найти решение проблемы, с которой они сталкивались очень часто: бюджет проектов разрастался до безумных размеров, а по результату — клиентам было не нужно то что было сделано.

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

Мы постоянно открываем для себя более совершенные методы разработки

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

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

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

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

1. Наивысшим приоритетом для нас является удовлетворение потребностей заказчика, благодаря регулярной и ранней поставке ценного программного обеспечения.
2. Изменение требований приветствуется, даже на поздних стадиях разработки. Agile-процессы позволяют использовать изменения для обеспечения заказчику конкурентного преимущества.
3. Работающий продукт следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев.
4. На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе.
5. Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им.
6. Непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри команды.
7. Работающий продукт — основной показатель прогресса.
8. Инвесторы, разработчики и пользователи должны иметь возможность поддерживать постоянный ритм бесконечно. Agile помогает наладить такой устойчивый процесс разработки.
9. Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта.
10. Простота — искусство минимизации лишней работы — крайне необходима.
11. Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд.
12. Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы.

Лучшие приемы и практики Agile для технических и нетехнических команд

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

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

Компании, которые не связаны с IT быстро обнаружили преимущества использования гибкого мышления и некоторых Agile-практик, которые могут помочь бизнесу достичь большего, принести клиентам максимум пользы и удовольствия, а также сплотить команду внутри.
С 2001 года Agile-принципы оформили в знаменитый манифест Agile, а сама методология стала стандартным процессом разработки ПО.

Каковы ключевые практики Agile сделали методологию столь известной и востребованной?

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

Список лучших практик Agile

Очередь задач

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

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

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

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

Итерации

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

Клиентоориентированность

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

User stories

В Agile описывается функциональность по общению с клиентами, а затем с позиции продукта определенным образом (помните формулу “Я как , хочу , потому что ”?). История пользователей в Agile project management означает единицу работы, которая должна быть завершена в одном спринте.

User stories включают описание, критерии приемки и оценку времени. Когда они слишком сложны, менеджеры продуктов разделяют их на более мелкие.

Agile-роли

Методология включает разные роли и, соответственно, разные их названия. Если обобщать, роли в Agile можно разделить по группам, включающим:

• Team Lead, Project Lead и Скрам мастера
• Членов команды
• Собственника продукта для Scrum и On-site customer для XP
• Заинтересованные стороны (stakeholders)

Команды Agile могут также состоять из дополнительно привлекаемых технических специалистов.

Value stream analysis

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

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

Timeboxing

Timeboxing используется в качестве метода планирования проекта. Расписание делится на несколько отдельных периодов времени (таймбоксы), каждый из которых имеет свои конечные результаты, срок и бюджет.

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

Ежедневные собрания

Например, Scrum meeting — это ежедневное мероприятие, короткая утренняя или дневная встреча, обычно организованная менеджером продукта или владельцем продукта. Длится 10-15 минут и требует присутствия Скрам-мастера и всей команды. Такая встреча организуется, чтобы:

• вспомнить, что было сделано вчера
• определить, что будет сделано сегодня
• выявить любые препятствия, если такие есть

Sprint demo meeting

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

Retrospective meeting

Речь идет о ретроспективе по окончательному итеративному развитию. Retrospective meeting рекомендуется посещать всем членам команды. Клиенты также могут участвовать.
Здесь обсуждаются возможности улучшения процессов, качества работы, используемых инструментов и т. д.

Тестирование

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

Burndown chart

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

Приоритизация требований

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

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

Планирование релиза

Релиз продукта представляет собой набор новых функций или финальный запуск продукта. Грамотное планирование релиза помогает командам выпускать качественные продукты.

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

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

Этот список можно продолжать и дополнять другими интересными практиками. Однако какие же практики могут быть использованы нетехникеской командой?

Яркий пример — использование бэклога и приоритизация задач командой авиатранспортной компании Air Methods, которая специализируется на оказании скорой помощи.

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

Так команда пришла к Agile-практике использования и управления бэклогом и определению приоритетов. За визуализацию стали отвечать инструменты Trello.

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

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

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

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

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

Аджайл: что это и зачем нужно

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

Что такое Аджайл

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

Буддисты верят, что можно достичь просветления. Они медитируют, стараются быть умеренными и не причинять вреда другим.

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

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

Как появился Аджайл

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

Прогрессивные разработчики стали пробовать новые подходы. Так появились Скрам, Канбан и ещё с десяток способов. Команды могли тестировать и менять продукты в процессе работы — за это такие подходы назвали гибкими. Эксперименты оказались удачными: клиенты не обманывались в ожиданиях, а разработчики укладывались в сроки и бюджеты.

Чтобы найти формулу работающих продуктов, в 2001 году 17 практиков современных подходов собрались в горной деревушке Сноубёрд. Они обсудили свои способы управления и поняли: подходы у всех разные, но идеи совпадают. Эти идеи заложили в основу Аджайла, внесли в Аджайл Манифест и дополнили Принципами Аджайла.

В чём суть философии Аджайла

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

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

Традиционная пекарня Рецептами занимаются шеф и технолог. Мнение кондитеров и продавцов они спрашивать не будут: первым дадут готовую инструкцию, вторым — новую выпечку. О результате шеф и технолог должны отчитываться перед владельцем пекарни, а он — хвалить или ругать их.

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

Аджайл — это быть командой самостоятельных профессионалов

Процесс работы тоже сильно отличается. Строгое распределение функций в традиционной пекарне и совместные эксперименты аджайловой команды:

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

Аджайловая пекарня Владелец пекарни объясняет, почему нужны новые пирожные и какая себестоимость будет выгодна. Продавцы уточняют, какую выпечку ждут покупатели. Закупщики предлагают продукты, на которые сейчас выгодные цены. Процесс строится вокруг экспериментов. Команда придумывает рецепт, печёт пробную партию и получает обратную связь.

Аджайл — это работа с клиентами и готовность изменить первоначальный план

Результат тоже разный. Непредсказуемый у одних и гарантированно хороший у других:

Традиционная пекарня Вся производственная цепочка сложилась только к концу, и проблемы возникали на каждом этапе: с закупкой необходимых продуктов, замесом теста, выпечкой и объёмом продаж. Результат непредсказуемый, на проверку гипотез ушло много ресурсов.

Аджайловая пекарня Команда начала с самого простого рецепта и успела его несколько раз изменить, опираясь на отзывы. Новым пирожным довольны владелец пекарни и покупатели. Процесс оптимизирован, все проблемы пройдены на этапе экспериментов.

Аджайл — это выпуск работающих продуктов, которые нравятся всем

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

Что даёт Аджайл

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

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

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

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

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

При чём тут Скрам и Канбан

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

Чтобы применить философию Аджайла на практике, используют Скрам, Канбан и другие способы управления. Это правила, которые объясняют, как организовать работу в духе Аджайла. Они бывают разной степени конкретности. Например, в Канбане шесть общих правил, а в Скраме описаны роли, события и артефакты. Их можно расширять и адаптировать, главное, следовать ценностям Аджайла.

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

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

что это и зачем нужно

В России распространяется Аджайл: про него говорят в страховых и бухгалтерский компаниях, в банках и на заводах. Если в вашей компании тоже скоро будет Аджайл, самое время разобраться в теме.

Что такое Аджайл

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

Буддисты верят, что могут достичь просветления. Они медитируют, стараются быть умеренными и не причиняют вреда другим.

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

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

Как появился Аджайл

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

Прогрессивные разработчики стали пробовать новые подходы к работе. Так появились экстремальное программирование, Скрам и ещё с десяток новых техник. Команды могли тестировать и изменять продукт в процессе работы, за это такие подходы назвали «гибкими». Эксперименты оказались удачными: клиенты получали отличные продукты, разработчики выдерживали сроки и бюджеты, а размеры компании не влияли на продуктивность команды.

Чтобы найти формулу успешных продуктов, в 2001 году семнадцать практиков современных подходов собрались в маленькой горной деревушке Сноубёрд. Они обсудили свои стратегии разработки и сделали открытие: подходы у всех разные, но общие идеи совпадают. Эти идеи легли в основу «гибкой» философии, которую назвали Аджайлом. Их записали в итоговых документах: «Манифесте» и «Принципах Аджайла».

В чем суть философии Аджайла

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

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

Традиционная пекарня Новыми рецептами занимаются шеф и технолог. Мнение кондитеров и продавцов учитываться не будет: первым дадут готовые инструкции для работы, вторым — готовую продукцию. Шеф и технолог будут отчитываться перед директором пекарни. А он — хвалить или ругать за неудачный проект.

Аджайл пекарня Для создания рецепта привлекут всех, кто будет работать с новой выпечкой: кондитеров, продавцов из розничных магазинов, специалистов отдела доставки и закупки продуктов, владельца пекарни, технолога и шефа. И обязательно — реальных покупателей. В команде нет начальников и иерархии. Решение принимают профессионалы, которые вместе отвечают за успех или неудачу

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

Процесс работы тоже отличается: строгое распределение функций в традиционной пекарне и совместные эксперименты аджайл-команды:

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

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

Аджайл — это работа вместе с клиентом, эксперименты и готовность изменить план

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

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

Аджайл пекарня Команда начала с самого простого рецепта и успела его несколько раз изменить, опираясь на отзывы клиентов. Новыми пирожными довольны клиенты и владелец пекарни. Процесс выпечки оптимизирован, все проблемы отлажены на этапе экспериментов.

Аджайл — это быстрый выпуск работающего продукта, который нравится клиентам и заказчикам

Чтобы выстроить работу в духе аджайла пекарня из нашего примера использовала в работе постулаты «Манифеста»:

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

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

Что дает Аджайл

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

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

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

Больше общения. Внутри коллектива складываются настоящие команды, где «один за всех, и все за одного». Такие мушкетеры делятся проблемами и в нужный момент приходят товарищу на помощь ради успеха общего дела.

Комфортный режим работы и объем нагрузки. Один из принципов Аджайла: команда должна быть в состоянии работать бесконечно долго. Аджайл запрещает авралы и пропагандирует комфортный ритм, в котором интересно работать и справляться с новыми профессиональными вызовами.

Аджайл помогает быть счастливее: видеть в работе дело жизни и получать от нее удовольствие.

При чем здесь Скрам и Канбан

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

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

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

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

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

Можно использовать фреймворки без Аджайла. Это беда большинства российских компаний, которые пробуют Аджайл. Часто они вешают доски с листочками-задачами, переименовывают планерки в митинги, но по сути ничего не меняют. Это малоэффективно и похоже на культ Карго.

Лучший вариант — соединить философию с практикой и получить предсказуемо хороший результат.

Шпаргалка

Запомнить Аджайл — это образ мышления со своей системой ценностей. Фреймворк — это набор правил, шаблоны действий для переноса философии Аджайла в жизнь. Вместе они дают результат.

Говорить правильно быть аджайл работать в духе Аджайла работать по Аджайлу аджайл образ мышления

agilebasics.ru

Что новичкам нужно знать об Аджайле

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

Но требования к ПО или мобильному приложению меняются очень быстро. Хочется добавить еще одну фичу. Или убрать, потому что вчера появилось точно такое же приложение конкурента. 

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

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

Agile, в переводе с английского — “ловкий” или “гибкий”. Он противопоставлен линейному методу — Waterfall. В отличие от него, Аджайл позволяет работать в условиях, когда не все технические рекомендации уточнены или когда они беспрерывно меняются. 

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

Преимущества и недостатки Аджайл

Аджайл не универсален. Он может быть очень крут или наделать много бед — зависит от проекта. Посмотрим, когда его лучше использовать и где избегать.

Когда использовать Аджайл:

• Нужно снизить риски при выводе нового продукта на новый рынок. Когда технические требования к проекту быстро меняются или вы сами не знаете, куда хотите прийти, Аджайл — подходящее решение. Он создан для того, чтобы можно было вносить изменения в проект В ПРОЦЕССЕ разработки и лучше всего функционирует в условиях постоянно меняющегося рынка. 

• Чтобы сэкономить трудовые и материальные ресурсы. Сначала мы разрабатываем базовое решение, например, простой инструмент для анализа валютного рынка. Затем мы возвращаемся к его “докрутке”: добавляем новые фичи и привлекательный дизайн. Продукт функционален сразу после релиза, но такой подход позволяет избежать больших вложений на начальном этапе.

Когда Аджайл не подходит:

• Все требования к проекту ясны с самого начала. Использовать Аджайл в такой ситуации бессмысленно — если все технические требования и так ясны, нужно просто включить их в спецификацию и назначить дедлайн.
• Очень крупный и сложный проект. Делаете второй Google? Тогда забудьте про аджайл. При проектировании большого проекта нужно проанализировать огромный скоуп задач и продумать архитектуру заранее. Иначе на полпути ограничения в “железе” или другие затруднения остановят проект. И придется все переделывать.

Фреймворки

Наборы правил или рекомендаций, как следует реализовывать философию Аджайла на практике называются фреймворками. Компании, работающие по Аджайлу, выбирают тот, что лучше согласуется с их бизнес-целями. Самые популярные: Скрам (Scrum), Lean и Канбан (Kanbun). В этом посте мы расскажем про самый популярный фреймворк, который использует и Магора, — Scrum.

Введение в Scrum 

Организация Аджайл команды

Scrum-команда состоит из трех участников – владельца продукта, Scrum-команды и сертифицированного Scrum-мастера. 

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

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

Scrum-мастер — уникальная роль в методологии разработки программного обеспечения. Этот человек отвечает за интеграцию принципов Scrum в компанию. Он ведет встречи и указывает на несоответствия в следовании принципам фреймворка. В идеале Scrum-мастер следует философии «лидерства-служения».

Организация работы по Аджайл

Спринты как единица времени

В отличие от Waterfall, гибкие фреймворки делят разработку на короткие промежутки. Обычно около 2-4 недель. На каждом этапе разработки команда выполняет запланированный набор задач из беклога.

Как использовать Backlog

Бэклог (Backlog) — это список невыполненных элементов на проект, который постоянно пополняется новыми. Некоторые из них планируются при первой встрече с клиентами, в то время как другие появляются неожиданно на протяжении всего процесса разработки.

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

Доска задач Scrum разделена на три части:

— сделать;

— в процессе;

— готово. 

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

Что такое User Story в гибкой методологии?

С первой встречи в Scrum мы создаем не список фичей, а пользовательские истории (User Stories). Это описания бизнес-целей пользователей.

Например, для инструмента мониторинга трафика цель можно сформулировать так: «Как интернет-маркетолог, я хочу видеть статистику того, сколько пользователей посетило сайт”. 

Преимущества User Story

• Отражает потребности пользователей;
• Легка для понимания;
• Может быть установлена в качестве исходной точки;
• Упрощает планирование спринта проекта.

Руководство: как создать историю пользователя.

Epic Stories

По Скраму, каждая пользовательская история должна быть завершена внутри итерации. Но иногда они слишком велики, и их невозможно покрыть за один спринт. Такие истории называются Epic Stories (эпическими историями) или epics. 

Для завершения итерации они должны быть разделены на более мелкие пользовательские истории. Чтобы оценить сложность истории пользователя, используют бальную систему. 

Диаграмма сгорания задач

Диаграмма сгорания задач, или в английском варианте Burndown chart, используется во время более длительных итераций, чтобы увидеть, сможет ли команда завершить все заявленные User Stories. 

Каждый график имеет две линии. Одна показывает желаемый результат, а вторая — суровые факты. Узнайте, как нарисовать диаграмму здесь.

События в Scrum 

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

Sprint Planning Meeting

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

На совещании по планированию команда решает, как реализовать выбранные User Stories. Участники оценивают сложность задач и сколько часов это займет. При этом соответствующая информация о каждой пользовательской истории размещается на Scrum-доске.

Ежедневные стендапы

Согласно рекомендациям Scrum, ежедневные стендапы должны проводиться для команды. Так каждый член в курсе, какой точки достигли их товарищи по команде. Всем задают эти 3 вопроса: 

• Что ты сделал вчера?
• Что ты планируешь делать сегодня?
• Существуют ли какие-либо препятствия?

Ежедневные встречи проводятся Scrum-мастером. Они не должны превышать 15 минут. Если есть какие-либо серьезные нерешенные вопросы, члены команды обсуждают их позже.

Sprint Review 

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

Retrospective Meeting

Это заключительное собрание итерации, где команда встречается, обсуждает и документирует следующее:

1. Что прошло хорошо во время спринта?
2. Что можно было сделать лучше?
3. Усвоенные уроки
4. Точки роста.

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

На этом все. Теперь вы знаете, что такое Аджайл и сможете отличить Скрам-мастера от простого менеджера. Если вы пока не уверены, что стоит включить в ваш проект, то Скрам — это то, что нужно.