Для чего применяется методология agile
Что такое Agile: методология, команда, оценка эффективности
Рассказываем, что представляет собой лежащая в основе методология, раскрываем основные понятия, объясняем, как устроена agile-команда и как оценивается ее эффективность.
Agile — это целое семейство методологий гибкого управления проектами. Интересно, что само понятие управления здесь оказывается не вполне верным. Было бы более точным употреблять формулу «Agile — это способ командного взаимодействия, позволяющий совместно создавать продукты». Однако мы слишком привыкли к силе вертикальных, иерархических связей, поэтому и здесь устойчивым стало употребление слова «управление».
Неудобные вопросы
Управленцы самого разного уровня, от менеджеров низшего звена до директоров корпораций и государственных чиновников, бились над этим десятилетиями. Но до тех пор, пока единственным известным способом более-менее контролируемого создания продуктов и разработки проектов оставался поэтапный — шаг за шагом, одно за другим, — ничего с этими вызовами было не сделать.
Для того чтобы перейти на качественно новый уровень проектной работы, потребовалось коренное изменение парадигмы.
Оказалось, что искать ответы на большинство этих больных вопросов просто незачем. Их нужно снять, а понятия, их породившие, по возможности упразднить. Так на месте поэтапной waterfall-разработки возникли гибкие методологии.
Делай сразу!
Главное мерило эффективности, принятое в гибкой методологии, — продукт. Пока другие только готовят документацию, agile-команды стремятся представить работоспособный прототип. Это как в знаменитой мотивирующей формуле: «„Сделано“ — это лучше, чем „идеально“». Реализуйте первую функцию и начните тестировать её, создавая следующую, и так раз за разом — вот главное правило.
Этап разработки в Agile, это самое «раз за разом», называется итерацией. Итерации имеют одинаковую длительность на протяжении всего проекта и в среднем составляют две недели. В рамках отдельной итерации выполняется конкретная задача, главным свойством которой является то, что ее решение должно обновлять продукт до новой версии или увеличивать его эффективность. Именно по этому признаку такие задачи и отбираются.
Как итеративный подход обеспечивает гибкость? Благодаря тому, что отдельные процессы могут идти параллельно и независимо друг от друга. Да, надо признать, что это может увеличить конечный срок разработки от идеи до полностью готового продукта. Но в том-то и дело, что рабочий, функциональный и уже способный встретиться с конкурентами и порадовать пользователей продукт создаётся в Agile гораздо раньше, а цикличность доработок позволяет добиться куда лучшей проработки таких функций и возможностей, до которых при плановой работе руки бы не дошли никогда.
Горизонтальная организация
Agile-команда строится на принципах самоорганизации и относительного равенства всех участников. Даже человек, которого многие представляют главой проекта, product owner, на самом деле — лишь персонификация требований к продукту. Он выполняет роль носителя знаний о том, каким ожидается конечный результат, но отнюдь не является управляющим в стандартном понимании. Поскольку привычка к иерархичности трудноискоренима, во многих командах ему, увы, приходится брать на себя и контролирующие функции. Но идеалом гибкой разработки является коллективная ответственность членов команды друг перед другом.
Принципы формирования agile-команд разнятся в зависимости от конкретного проекта. Например, в музыкальном сервисе Spotify они строятся вот так:
Ещё одна важная ценность agile-команд — взаимопроникновение знаний. Член команды не должен замыкаться в своей узкой области, ему следует стремиться к кросс-дисциплинарности. Это не значит, что программист должен быть и продавцом, а дизайнер — маркетологом.
Важно!
Но иметь базовые знания о смежных специализациях в гибкой разработке необходимо.
Изначально предполагалось, что это просто будет повышать эффективность работы и уровень взаимопонимания в команде, но сегодня, с развитием нейронаук, стало понятно, что такой подход вдобавок обеспечивает поддержание мозга в тонусе и динамичное создание новых нейронных связей. Такое «перекрёстное опыление» знаниями в Agile называется t-shape. Иллюстрация ниже объяснит, почему так, лучше всяких слов.
Как внедрить Agile?
Переход от каскадной разработки, до сих пор привычной для многих организаций, к гибким методам работы над проектами может быть довольно болезненным.
Во-первых, вам предстоит упразднить иерархичность и при этом добиться того, чтобы все участники процессов смогли на равных разделить ответственность за результат.
Во-вторых, переход к итеративной разработке заставит сосредоточиться на том, чтобы каждый из этапов гарантированно привносил в продукт что-то новое. Это непросто, инерция плановой разработки будет преследовать вас первые несколько месяцев.
Третий вызов — если вы ведёте заказную разработку, будет непросто объяснить клиентам принципы работы, а если входите в состав крупной организации, та же проблема может возникнуть при обосновании перехода на Agile перед вышестоящими руководителями.
Если вам удастся справиться, процессы станут заметно эффективнее, а качество работы — выше. Главное, никогда не забывайте четыре основных ценности Agile, с которых начинается Манифест гибкой разработки:
Следование им и поможет на этапе внедрения, и будет подспорьем в процессе работы.
Лучше познакомиться с Agile и другими современными методологиями, применяемыми в сферах от IT до медиа и маркетинга, а также погрузиться в построенные на их основе процессы вы сможете, пройдя курс «Руководитель digital-проектов» от Skillbox.
В Чем Секрет Популярности и Эффективности Методологии Agile
Сегодня в мире управления проектами существует множество инструментов и методологий, которые помогают улучшить качество производимого продукта.
Также участники опроса рассказали, в каких департаментах их организаций используют Agile методологии. Среди них:
В этой статье мы подробнее расскажем, что же такое Agile методология, на чем она основана и почему так популярна.
Что такое методология Agile?
Agile — это набор практик, целью которых является оперативная реакция на изменения в ходе рабочего процесса.
Такие подходы помогают командам быстро реагировать на обратную связь от клиентов и заказчиков, тем самым постоянно улучшая производимый продукт.
Стоит отметить, что Аджайл (от англ. agile — гибкий) — это не набор конкретных методов и не свод инструкций. Будет правильнее сказать, что Agile — это группа методологий, которые стремятся к улучшению производимого продукта с помощью повторяющихся рабочих циклов и постоянного фидбека от клиентов.
Философию Agile характеризуют гибкость и скорость команды, а также максимальная прозрачность рабочих процессов.
Проще говоря, Agile — это не про отчетность, документооборот и четкий план, а про постоянное общение с клиентом и готовность оперативно реагировать на изменения в ходе проекта.
Чаще Agile используется для разработки программного обеспечения. В этой сфере Аджайл базируется на итерациях фаз программирования и тестирования на протяжении полного жизненного цикла продукта. В Agile и разработка, и тестирование выполняются одновременно, в отличие от методологии Waterfall, в которой проект выполняется поэтапно.
В программировании методология Agile начинается с описания клиентом результата, которого он стремится достичь. Команде важно четко понимать, какие проблемы с помощью разработанного продукта хочет решить заказчик.
С началом работы команда циклично проходит процессы планирования, проектирования, реализации и оценки. В ходе выполнения этих процессов конечный результат может измениться, если выяснится, что он будет еще больше соответствовать целям и стремлениям клиента.
Постоянное взаимодействие команды с заказчиком и остальными заинтересованными лицами способствует оперативному обсуждению грядущих изменений. Это позволяет принимать полностью обоснованные и согласованные со всеми участниками команды решения.
Непрерывное стремление компаний улучшить производимый продукт помогает им оставаться конкурентоспособными на протяжении долгого времени.
Преимущества Agile:
Agile манифест
Публикация Agile манифеста в 2001 году знаменовала рождение Agile как методологии.
Началась эта история в американском штате Юта, где в начале 21 века 17 независимых программистов собрались для обсуждения будущего разработки программного обеспечения.
Группа сошлась во мнении, что главная проблема среди команд разработчиков заключалась в том, что они были чрезмерно сосредоточены на планировании и документировании циклов разработки ПО. И упускали из виду то, что действительно имело значение, а именно удовлетворенность заказчиков.
Манифест группы разработчиков стал новаторским и в корне изменил подход к сотрудничеству с клиентами и достижению целей команды. Agile Manifesto не являет собой свод правил, он выделяет ключевые ценности, которые ставят взаимодействие с людьми на первое место.
За последние 20 лет с момента создания манифест приняли многие команды и организации из разных профессиональных сфер. Сегодня документ доступен более чем на 50 языках, включает в себя 4 ценности и 12 принципов.
4 ценности Agile манифеста:
Авторы манифеста отметили, что не отрицают необходимость пунктов, находящихся в правом столбце. Но все же в приоритет выносят ценности, расположенные слева.
12 принципов Agile манифеста о разработке программного обеспечения:
Популярные Agile методологии
Существует множество различных методологий (или фреймворков) гибкой разработки, которые держат за основу ценности и принципы Agile манифеста. Канбан (Kanban), Скрам (Scrum), Бережливое производство (Lean) и Экстремальное программирование (XP) — часто используемые из них.
Kanban
Это визуализированный подход к управлению проектами. Используя Канбан, команды визуализируют задачи при помощи доски и стикеров либо специальных онлайн-инструментов.
Задачи перемещаются между столбцами, обозначающими их статус. Такой подход позволяет эффективно расставлять приоритеты, контролировать прогресс выполнения проекта, а также ограничивать объем незавершенной работы.
Scrum
Скрам — это методология управления проектами, в которой командой руководит Скрам-мастер. Его главная задача состоит в устранении преград на пути к завершению проекта.
Работа в команде делится на короткие повторяющиеся циклы, которые называются спринтами и обычно длятся 1-4 недели. При этом команда собирается на ежедневные митинги (стендапы), чтобы обсудить текущие задачи и препятствия, которые предстоит преодолеть.
Экстремальное программирование (XP)
Название методологии произошло от идеи использовать полезные классические методы разработки ПО, подняв их на «экстремальный» уровень.
Доступно проиллюстрирует идею XP способ «парного программирования». В этом случае один разработчик занимается написанием кода, а его коллега непрерывно просматривает и проверяет написанное, не дожидаясь окончания работы первого программиста.
Бережливое производство (Lean)
Ключевой задумкой бережливого производства является максимально экономный и разумный подход к ресурсам проекта. Методология Lean — это набор инструментов и принципов, направленных на выявление и устранение возможных потерь для ускорения процесса разработки.
В понятие потерь входят не только затраты времени, финансов и труда. Сюда же относится и нереализованный творческий потенциал команды и каждого ее участника.
Другие гибкие методологии разработки ПО
В управлении проектами существует ряд других методологий управления проектами кроме тех, что мы перечислили выше:
Каждая методология воплощает в себе принципы частых итераций, непрерывного обучения и высокого качества производимого продукта.
Что это будет, классический Скрам из учебников или смесь Канбан и XP, зависит целиком и полностью от вас. Главное, чтобы выбранный способ удовлетворял потребностям проекта. Гибкость приветствуется даже в выборе методологии этой самой гибкости.
Например, разработчики программного обеспечения чаще предпочитают Scrum и XP, в то время как Канбан — любимец команд, ориентированных на сервис (IT, маркетинг или отдел кадров).
Кому подойдет методология Agile?
Несмотря на популярность и высокие результаты при использовании методологии Agile, применять ее в работе над каждым проектом нет никакой необходимости. Все же Agile не панацея.
К примеру, простой баннер или веб-сайт можно сделать поэтапно, используя техническое задание от заказчика.
Существует несколько условий, при которых проекту наверняка потребуется гибкая методология управления:
В этом случае разумнее реализовывать проект постепенно и постоянно его тестировать. Это поможет сэкономить непредвиденные расходы.
Чем дольше будет длиться работа над проектом, тем сложнее прогнозировать и планировать его развитие в отдаленном будущем.
Так бывает, когда команда разрабатывает инновационный продукт. В этом случае невозможно заранее проработать весь его функционал. Поэтому логичнее идти к созданию продукта небольшими шагами и опять же постоянно его тестировать.
Когда идей много, внедрять их одновременно — решение рискованное и экономически нецелесообразное. Ведь заранее сложно сказать, какие из них окажутся удачными.
Идеальное условие для внедрения Agile методологий — это заинтересованность заказчика в плотном сотрудничестве с командой.
Инструменты для работы с Agile-проектами
Вовлеченность в проект нескольких команд делает рабочий процесс менее прозрачным. Кроме того, менеджеру, руководителю и заказчику становится все сложнее следить за прогрессом проекта, контролировать его реализацию и вносить изменения.
Облегчить работу с комплексными проектами и настроить взаимодействие между участниками команды помогут инструменты управления Agile-проектами. С ними вы всегда можете видеть общую картину проекта, контролировать загрузку работников, общаться с командой и держать заказчика в курсе изменений и корректировок.
Онлайн-диаграмма Ганта с легкостью выполнит все эти задачи и упростит работу с проектом всем его участникам.
Онлайн диаграмма Ганта GanttPRO
Ведите проекты, управляйте временем, ресурсами и финансами.
Какую гибкую методологию управления проектами предпочитаете вы?
Agile — незаменимый подход к управлению проектами, который держит команду в тонусе и постоянно помогает добиваться лучших результатов. Благодаря тесному сотрудничеству команды и заказчика, а также вовлеченности и обратной связи потребителей продукта, результат приносит еще большее удовлетворение каждому участнику проекта.
А какие Agile методологии управления проектами предпочитает ваша команда? Делитесь в комментариях ниже.
Обзор методов agile
Я назову этот текст обзором методов agile, расскажу как выбирать между agile и каскадной методологией разработки, дам ссылки на подробные статьи и книги о методах, так как каждую часть этого обзора можно писать как отдельную статью. Буду писать иногда сумбурно, иногда субъективно. Я не журналист, который стремится показать разные точки зрения. А мудрый читатель с высокоразвитым критическим мышлением придет к своему «правильному» ответу. Поэтому, точка зрения авторская. Любые совпадения считать верными, додумки и стереотипы точными. Шутка.) Главной задачей ставлю себе написать простым языком для начинающих знакомиться с миром Agile. Тем более я сейчас сам начинающий продакт-менеджер, учусь в product University. Когда буду давать ссылки на разную литературу и источники, увы много на английском. Зато прокачаете язык. Для будущего продакт-менеджера — это хороший навык.
Начнем с истории методов. Я привык читать и слышать бизнес истории о том, как много работали и придумывали методы. Много табличек, экспериментов, компаний пилотников. После всего, через 100500 лет, появилась методика, которую внедряли, через жуткое сопротивление сотрудников, полусуициидальные настроения топов и т.д. История про Agile, по-моему, вообще не про это. В начале стоит сказать, что Agile — это не метод, а группа методов управления проектами. Что самое крутое, большинство методов появилось раньше самого семейства agile.
Оговорочка: то, что в себя включает Agile не всегда именно метод, это может быть подгруппа, свод правил, набор инструментов и, Боже упаси, фреймворк.
Все методы раскрывать не буду. Если вдруг сюда попадут спецы, есть ссылки на литературу, можно зачитаться. Мне важно раскрыть самые распространенные из них и показать хронологию событий.
1. 1992 – Crystal Methods. Позже в 1997 году упростили до Crystal. Скажем спасибо Алистеру Коберну, за его идеи в своём подходе, потому что именно они легли в основу начала движения Agile. В его методе мы также можем увидеть основы agile-манифеста, о нем чуть позже. Его подход базировался на принципах разумного улучшения, частой поставке кода и работа в группах 6-8 человек, активной коммуникации в группе разработчиков.
2. 1993 – Refactoring. Об этом методе можно прочитать в оригинале жми сюда
3. 1994 – Dynamic Systems Development Method (DSDM). Разработан консорциумом и отличнно раскрыт здесь
4. 1995 – Scrum and Pair Development. Вот он мой любимчик. Основан Джефом Сазерлендом и Кеном Швабером. Но здесь важно еще упомянуть одного человека — Майк Бидл (Mike Beedleв оригинале), который продвинул идеи SCRUM в массы. И по сути именно этот метод больше всего ассоциируется с Agile, а иногда даже считается синонимом.
5. 1997 – Feature Driven Development (FDD). Под эту методологию есть целая книга ссылочка.
6. 1999 – Adaptive Software Development и снова книга
7. 1999 (или 1996, по разным источникам) — XP (экстремальное программирование) книга и сайт. Этот метод дал нам User Stories и релизы.
8. 1999 — The Pragmatic Programmer — опять книга. Эта методология нам дала понимание early adopters (ранних последователей)
9. 2001 — Выпуск agile-manifesto. Вот ссылка на сайт, где опубликован сам манифест и история его создания. А также, воспоминания Мартина Фаулера, одного из соавторов о создании манифеста. Были еще несколько публичных заметок участников, но что-то пошло не так и теперь домены не доступны.
10. 2002 — Test Driven Development (TDD). Книга, как же без нее. Спасибо, за то что это методология дала нам сначала тест, потом уже в боевую версию.
11. 2003 – Lean Software Development (интересная аббревиатура получится). Бережливая разработка ПО. Прекрасная книга ссылка.
Каждый из этих подходов имеет своего автора или группу авторов. Каждый из них творил что хотел, но в целом они все очень умные и классные парни.
1. Люди и взаимодействие важнее процессов и инструментов.
2. Работающий продукт важнее исчерпывающей документации.
3. Сотрудничество с клиентом важнее согласования условий контракта.
4. Готовность к изменениям важнее следования первоначальному плану.
1. Наивысшим приоритетом является удовлетворение потребностей клиента, благодаря регулярной и ранней поставке ценного программного обеспечения.
2. Изменение требований приветствуется, даже на поздних стадиях разработки.
3. Работающий продукт следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев.
4. На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе.
5. Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им.
6. Непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри команды.
7. Работающий продукт — основной показатель прогресса.
8. Инвесторы, разработчики и пользователи должны иметь возможность поддерживать постоянный ритм бесконечно.
9. Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта.
10. Простота — искусство минимизации лишней работы — крайне необходима. 11. Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд.
12. Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы
Классная инфографика на эту тему от scrumteck
Хотя авторы под ценностями подписали, что считают важнее то, что слева, но не стоит забывать о том, что с права. Я же писал, что они умные. Некоторые эти принципы и ценности трактуют буквально. Я сталкивался с тем, что ПО работает, все хотелки клиента удовлетворены, никто не следил за документацией и все счастливы, мы в agile.
Интересно наблюдать баталии в комментариях к статьям последователей и противников Agile. Одни считают это заповедями на скрижалях, другие покушением на инженерную святыню, к которой притронулись садомиты.
Что же круче? Agile — как единственный метод разработки ПО и новый метод работы любого бизнеса в современном мире. Или whaterfalls — как фундамент и единственный метод правильного построения бизнеса и ПО. Я расскажу чуть позже.
Пока писал эту статью узнал о том, что оказывается гуляет в интернетах версия манифеста 2.1. Но это тема отдельного трактата.
Как мы видим широко прижились scrum, kanban, lean. Даже есть scrumban, дитя любви scrum и kanban. Симпатичный получился метод.
Как писал выше, ассоциируется с agile, почти что синонимы. Scrum — это регбийный термин, обозначающий борьбу за мяч.
Коротко о методе. Разработка делится на спринты, короткие дистанции разработки фиксированной длительностью 1-4 недели, наверняка есть и другие. У спринта есть стадии: 1. ежедневные короткие встречи, где обсуждается что сделано, что будет сделано, какие проблемы. Эти встречи не должны длиться часами. Как правило это 15-20 минут. 2. процесс разработки, 3. демонстрация, 4. ретроспектива — переосмысление того, что можно сделать лучше. Важно знать. Есть backlog — список требований к продукту. Есть роли, нет должностей. У srumteck есть классная инфографикана эту тему
Эти два метода имеют общую ДНК. Уходит все корнями в Японию, философию бизнеса Кайдзен и Тойоту.
Про Канбан я нашел упоминания от 1959 года. Этим методом стремились повысить прозрачность процессов производства, вовлеченность сотрудников и их мотивацию, организовать таким образом процесс непрерывного улучшения. Главный момент в Канбане — визуализация процесса, канбан-доска. Где есть шаги, статусы, коридоры и задачи. Принципы: вовлеченность всей команды, строгий контроль времени выполнения.
Ну, и конечно классная инфографика для наглядного примера и резюме.
Lean. Мне трудно его описать как метод, для меня это больше способ мышления, свод правил и рекомендаций. Эта философия бизнеса и подхода к разработке описана в двух книгах Эрик Рис Lean startup и Масааки Имаи Кайдзен.
Характерным для Lean будет:
1. Устранять в продукте все, что не приносит ценности клиенту.
2. Самый эффективный инструмент решения задач — постоянное обучение команды
3. Принятие решения как можно позже.
4. Быстрая доставка изменений.
5. Основа успеха в сильной команде.
6. Экономия ресурсов достигается через изначально качественный продукт.
7. Важна целостная картина. Придание ее частям целей, контроль статусов и видение общей стратегии развития ПО.
Scrumban. Совмещение Kanban и Scrum. Это когда в процессе спринта используется канбан-доска для визуализации работы над задачами.
Мы разобрали некоторые методы agile. А что такое watrefalls или каскадный метод разработки ПО, пока нет. Исправим это. Это последовательная разработка ПО, где компетентные и умные сотрудники все делают без привлечения клиентов. Только полностью завершив производство показывают продукт. Как автомобиль демонстрируют и продают клиенту только после того, как он готов. Кузов без обшивки и покраски ведь не показывают, и если что-то не так, не вносят корректировки. Каскадный метод был предложен в 1970 году Уинстоном Ройсом. Некоторые наметки agile были и раньше предложенного Ройсом метода. В тоже время каскадный метод стал гораздо более распространенным, чем agile. Это связано с тем, что раньше порог входа в любой бизнес и в разработку в частности был очень высок. Нужно было быть терминатором на каждом этапе. Соответсвенно, и мания величия участников высокая — как так допустить неучей-клиентов к инженерному производству. Сейчас огромные скорости обучения и выхода новых продуктов. Пользователь имеет большой опыт и требования, сценарии взаимодействия другие, код проще писать, колоссальный массив знаний в открытом доступе. Да и многие поняли, что команда сильнее самого крутого терминатора (даже если отдельно это не самые лучшие специалисты). Спасибо Аристотелю с его Метафизикой, спустя столько веков въехали, что он имел ввиду.
Ранее упоминал, что забавно наблюдать баталии сторонников и противников обоих методов. Каждый приводит убедительные аргументы и не слышит другого. Все правы и никто не прав. Хвала вселенной, которая послала нам модель cynefin.
Согласно изречению Эдварда Деминга, потребитель – самый главный элемент производственного процесса.
И что? Потребитель есть разный, где-то он знает что хочет, где-то не знает. Есть производитель, который близок к своему потребителю или далек. Знает как удовлетворить потребность или не знает. Много всяких условий и контекста.
И у нас возникает определенный конфликт. Waterfalls — традиционный подход к проектам с длительным планированием или Agile — где все быстро и все меняется со скоростью света.
Товарищ Сноуден, не тот о котором можно подумать, а Дейв, в начале 2000х разработал удобную управленческую модель для работы с проектами. Эта модель успокоила фанатов традиционных способов управления проектами и сбила спеси с любителей agile. В эту модель укладывается всё, уживаются рядом и waterfalls и agile.
В модели описываются 4 вида систем с разной степенью неопределенности: