Что такое методология Agile и в чем принципы манифеста Agile Manifesto?

Содержание

Agile — что такое. Методология, подход и принципы

Что такое методология Agile и в чем принципы манифеста Agile Manifesto?

Agile – это термин, который сейчас у всех на слуху, но что за ним стоит? Является ли он панацеей проектного управления или это замена устаревшим методам? Применим ли он где-то, кроме IT? Ответы на эти вопросы читайте статье.

Agile методология

Agile (англ. «проворный, сообразительный») – философия, совокупность гибких подходов к разработке программного обеспечения, которые стали использовать для управления проектами.

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

Исполнение требований заказчика обеспечивают рабочие группы, которые состоят из специалистов различного профиля.

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

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

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

Основные принципы Agile

Термин «agile», применительно к проектному подходу, официально появился с подписанием в 2001 году «Манифеста гибкой методологии разработки программного обеспечения» (Agile Manifesto). Задачей Манифеста была «сверка часов», выработка общих принципов и терминологии, объединение усилий для продвижения новой концепции в массы.

Рассмотрим 12 основных принципов Agile.

1. Наивысший приоритет – удовлетворение потребностей заказчика благодаря ранней и бесперебойной поставке ценного продукта.

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

В тренде этой концепции требование к технологическим стартапам по разработке минимально жизнеспособного продукта – minimum valuable product (MVP), задача которого проверить востребованность ключевых качеств продукта на рынке и оценить размер спроса, так как вероятность ошибки с выводом на рынок нового продукта очень высока.

Узнайте, каким образом модная технология позволила медикам больше зарабатывать. Мы внедрили Agile в реальном бизнесе. Что из этого вышло?

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

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

4. Постоянная коммуникация на протяжении всего проекта между командой и заказчиком. Этот принцип лежит в той же плоскости, что и удовлетворение заказчика как высший приоритет – достичь такого удовлетворения без постоянной коммуникации с заказчиком вряд ли возможно.

5. Проекты следует поручать только мотивированным профессионалам. Создайте условия и доверяйте им – тогда проект будет реализован на высоком уровне.

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

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

6. Оптимальным методом обмена информацией является личное общение. Для этого все члены команды должны находиться в одном пространстве, хотя бы в одном здании. Желательно чтобы в этом пространстве находился и сам заказчик.

7. Работающий продукт – критерий прогресса задачи. Заказчик ждет продукт, его не интересует достижение очередной вехи в диаграмме Ганта или выполненный пункт плана.

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

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

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

10. Простота, как искусство минимизации лишней работы. Принцип «бритвы Оккама» в действии – суть не в том чтобы упрощать продукт, а в том, чтобы избегать ненужной работы и не добавлять в продукт что-то избыточное для его функционального назначения. См. также про систему Канбан>>

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

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

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

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

Agile SCRUM

SCRUM («скрам») – термин из регби. его применяют для названия наиболее структурированной на данный момент методики гибкой разработки Agile.

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

Для такой фазы игры из-за ее высокой травматичности используются лучшие и самые подготовленные игроки команды, а если таких игроков по какой-то причине не хватает (из-за удаления, например, или травмы) scrum не проводится.

В России методология получает все большее распространение.

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

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

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

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

Методология предусматривает также структуру ролей в проекте:

  • Scrum-master – посредник между заказчиком и командой;
  • Product Owner – представитель заказчика, задачи которого — формировать и приоритизировать Product Backlog, и принимать промежуточные результаты спринтов;
  • Team – команда проекта, в которой нет отдельных ролей, она является самоорганизующейся системой из кроссфункциональных мотивированных профессионалов.

Зачем Agile подход финансистам

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

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

Ключевой проблемой является юридическое оформление такой формы организации работы с внешней командой разработчиков.

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

Ознакомиться с опытом коллег

Перспективы гибкой методологии Agile

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

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

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

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

Получить бесплатный доступ

Источник: https://www.fd.ru/articles/158359-agile---chto-takoe-metodologiya-podhod-i-printsipy

Что такое Agile? Как внедрить Agile в компанию? // Михаил Бакунин

Что такое методология Agile и в чем принципы манифеста Agile Manifesto?

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

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

История Agile

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

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

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

В 1990-х годах был разработан ряд гибких методов разработки программного обеспечения в ответ на преобладающие тяжеловесные методы.

К ним относятся: с 1991 года — RAD (быстрая разработка приложений); с 1994 года — метод разработки динамических систем (DSDM); с 1995 года — Scrum; С 1996 года, Crystal Clear и экстремальное программирование (XP); А с 1997 года — Feature driven development (FDD).

Хотя они возникли до публикации Манифеста Agile Software Development, они все вместе называются гибкими методами разработки программного обеспечения.

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

Манифест Agile

Манифест Agile состоит из 4 основополагающих идеи и 12 принципов. Каждая методология Agile применяет эти идеи по-разному, но все они полагаются на них, чтобы управлять проектами максимально эффективно.

4 идеи Agile

  1. Люди и взаимодействие важнее процессов и инструментов.
  2. Рабочее программное обеспечение важнее документации.
  3. Сотрудничество с клиентами важнее согласования условий контракт.
  4. Готовность внести изменения в приоритете, нежели придерживаться первоначального плана.

12 принципов Agile

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

  3. Частая поставка рабочего программного обеспечения (каждый месяц, две недели, неделю и т.д.).
  4. Сотрудничество между заинтересованными сторонами (заказчиком и разработчиками) на протяжении всего проекта.
  5. Поддержка, доверие и мотивация вовлеченных людей.

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

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

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

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

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

  10. Простота.
  11. Самоорганизующиеся команды поощряют отличную архитектуру, требования и проекты.

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

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

Основа метода Agile

Основой метода гибкого управления проектами является ряд ключевых элементов:

  1. Визуальный контроль. Участники проекта в ходе работы над проектом используют карточки различных цветов и видов, которые сигнализируют, какой элемент  конечного продукта уже разработан, спланирован, завершен и т.д. Таким образом,  команда имеет наглядное представление о существующем положении дел. Визуальный контроль обеспечивает одинаковое видение проекта каждым из участников.
  2. Все участники проекта работаю рядом, включая клиента. Такой подход не только ускоряет многие процессы, связанные с информированием участников рабочей группы, но и  создает благоприятную атмосферу для сотрудничества и эффективной работы.
  3. Адаптируемое управление. Руководитель проекта – не человек, который раздает указания, а лидер, определяющий основные правила работы и сотрудничества.
  4. Совместная работа. Команда, руководитель проекта и клиент работают сообща, что исключает возможность потери информации и непонимания целей.  Также прозрачность всех процессов позволяет моментально исключать появившиеся проблемы и находить удачные решения и улучшения.
  5. Работа, основанная на разделении общего объема проекта на составные части. Такая система работы значительно снижает сложность проекта и позволяет командам сфокусироваться на каждой части в отдельности.
  6. Работа над ошибками. В ходе работы одного цикла команда осваивает новые навыки и анализирует произошедшие ошибки, что исключает их появление в следующем цикле.
  7. Спринты и ежедневные встречи. Спринты – отрезки времени, за которые команды выполняет ряд задач, — позволяют четко видеть результаты работы. Разделив время работы над проектом на спринты, получаем, например, 10 спринтов, каждый по две недели. А ежедневные встречи не более чем на 15 минут помогут каждому члену команды ответить для себя на три вопроса: что я делал вчера, что я  буду делать сегодня, что мне мешает выполнять работу?

Таким образом, внедрение гибкого метода Agile возможно при следующих условиях:

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

На данный момент методология Agile широко распространена в  IT-сфере и начинает осваивать деловую сферу, в частности маркетинг, менеджмент, обучение и т.д.. Метод гибкого управления проектами используется многими компаниями и госструктурами, например, правительства Норвегии и Новой Зеландии применяют Agile. В России «Сбербанк» осваивает Agile для коммерческой сферы.

Системы управления проектами, основанные на Agile

Существует множество методов, основанных на идеи Agile, самые популярные из них — Scrum и Kanban.

SCRUM

Scrum — это методология управления проектами, в основе которой делается акцент на качественном контроле процесса работы.  Хиротака Такэути и Икудзиро Нонака — первые, кто описал подход Scrum, объяснили его как “подход регби”, в котором scrum — это борьба за мяч.

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

Работа в рамках одного спринта состоит из нескольких этапов:

  1. Планирование объемов работы для одного спринта.
  2. Ежедневные совещания на 15 минут для коррекции работы команды и подведения промежуточных итогов.
  3. Демонстрация результатов работы.
  4. Ретроспектива спринта, в которой рассмотрены удачные и неудачные события в рамках прошедшего спринта.

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

Scrum значительно увеличивает производительность и сокращает время до преимуществ по сравнению с классическими процессами «waterfall». Процессы Scrum позволяют организациям плавно адаптироваться к быстро меняющимся требованиям и создавать продукт, отвечающий изменяющимся бизнес-целям. Scrum позволяет:

  • Повысить качество результатов;
  • Лучше справиться с изменениями;
  • Обеспечить более точные оценки, тратя меньше времени на их создание;
  • Лучше контролировать сценарий проекта и этапы работы.

Kanban

Kanban — это процесс, призванный помочь командам работать вместе более эффективно. В переводе с японского kanban обозначает “рекламный щит, вывеска”, а сам метод взят и адаптирован с производственной системы Toyota.

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

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

Kanban основан на трех принципах:

  1. Визуализация задач: видимость всей информации о проекте поможет увидеть недочеты, ошибки и накладки.
  2. Контроль и ограничение WIP (work in progress — работа, выполняемая одновременно): это помогает сбалансировать подход, основанный на потоках, чтобы команды не начинали и не совершали слишком много работы сразу.
  3. Контроль времени на выполнение задачи и оптимизация работы для экономии времени.

Достоинства и недостатки Agile

Любая методология имеет преимущества и недостатки. Рассмотрим плюсы и минусы Agile.

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

1. Больше гибкости по сравнению с методологией Waterfall.

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

2. Меньше дефектов в конечном продукте.

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

Недостатки

1. Постоянное получение обратной связи приводит к постоянному переносу даты завершения проекта.

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

Конечные пользователи, которые видят, что эти требования могут быть выполнены «легко» (они видят только результат, а не усилия), будут запрашивать дополнительные функции.

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

2. Документация

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

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

3. Частые встречи

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

Внедрение Agile

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

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

    Готов ли коллектив к изменениям? Подходят ли проекты компании для гибких методик? На эти и многие другие вопросы обычно помогают ответить бизнес-тренеры, специализирующиеся на Agile. Помимо прочего будет также составлен список тренингов и план, по которому будет вестись внедрение Agile в компании.

  3. Демонстрация Agile.

    Своеобразный тест-драйв Agile, которые проводится под контролем специалиста и показывает все этапы работы, объясняет функции ролей, взаимодействие внутри команды и между командами и т.д.

  4. Создание команды.

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

  5. Выбор инструментов, необходимых для распределения задач, ведения отчетности, аналитики и прочее.

  6. Первый проект с Agile. В первом проекте будут ошибки, несостыковки, отказ от одних инструментов и выбор других. Любая методика требует своеобразной адаптации под особенности компании, в которую она внедряется.

, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Источник: https://Bakunin.com/agile-is/

Что такое методология Agile и в чем принципы манифеста Agile Manifesto?

Что такое методология Agile и в чем принципы манифеста Agile Manifesto?

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

В начале 2000-х годов в американском штате Юта появился «Манифест гибкой разработки ПО» (Agile Manifesto), где говорилось о методологии Agile (перевод с англ. – «живой», «подвижный», «гибкий»).

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

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

Что такое Agile

Если проще, то Agile – это способ разбить большой проект на несколько этапов (пользовательских историй или спринтов) и вычленить самые важные.

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

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

Суть Agile простыми словами

Что такое система Agile можно довольно легко пояснить в нескольких предложениях:

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

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

Интересно:

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

Принципы Agile

Всего насчитывается четыре принципа, без которых сложно представить Agile:

Люди и коммуникация важнее инструментов

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

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

Продукт, который работает, лучше правильной документации

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

Взаимодействие с клиентом важнее контракта

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

Изменения важнее чёткого плана

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

Кто является участниками Agile?

  • Команда – обычно включает в себя пять-девять человек. В случае, если в разработке продукта задействовано больше сотрудников, их делят на несколько групп. Идеальным вариантом будет тот, когда в каждой команде есть разработчики, тестировщики и несколько участников с другим функционалом.
  • Заказчик или владелец продукта – тот, кто даёт задачу и знает, для кого и чего предназначен готовый продукт. Он может предлагать идеи, вносить и согласовывать изменения.
  •  Стейкхолдеры или заинтересованные лица – те, у кого есть определённые ожидания относительного готового продукта. Они также могут принимать решения и влиять на требования. Например, если продукт создаётся для компании, в их число могут войти сотрудники разных отделов.
  • Agile scrum-мастер – человек, который не мешает процессу, но регулирует его и помогает участникам команды выдержать сроки.

Интересно: 

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

Кому подойдёт Agile?

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

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

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

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

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

Интересно:

«Космос. Agile-ежедневник для личного развития» разработала Катерина Ленгольд, став самым молодым президентом в аэрокосмической отрасли. Это собственная система управления временем, основанная на принципах Agile. Такой ежедневник поможет тем, кто вынужден справляться со множеством дел, и хочет навести порядок как в профессиональной, так и личной жизни.

Александр Григорян, Директор по развитию агентства digital-трансформации «Улей».

Источник: https://promdevelop.ru/rabota/chto-takoe-metodologiya-agile-v-chem-osnovnye-printsipy-manifesta-agile-manifesto/

Agile/Scrum для начинающих. Что такое гибкая методология?

Что такое методология Agile и в чем принципы манифеста Agile Manifesto?

В переводе с английского языка «agile» означает «живой, подвижный», но переводят его чаще как «гибкий». В отрасли разработки программного обеспечения этот термин появился в начале 2000-х годов, когда в штате Юта был издан «Манифест гибкой разработки ПО». С тех пор под «agile» понимают набор подходов по “гибкой” разработке программного обеспечения.

Agile Manifest

Суть agile-подхода изложена в “манифесте”, но для заказчика ее можно коротко сформулировать так:

  • разработка ведется короткими циклами (итерациями), продолжительностью 1-4 недели;
  • в конце каждой итерации заказчик получает ценное для него приложение (или его часть), которое можно использовать в бизнесе;
  • команда разработки сотрудничает с Заказчиком в ходе всего проекта;
  • изменения в проекте приветствуются и быстро включаются в работу.

В настоящее время agile-принципы используются в работе десятки тысяч команд по всему миру.

Основополагающие принципы Agile.

Краткое видео о том, что такое Scrum (english).

Что такое Scrum?

Scrum – это одна из нескольких методологий гибкой разработки ПО:

    • Scrum
    • Lean
    • Feature Driving Development
    • Extreme Programming

Scrum процесс на одном листе

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

Артефакты в Scrum

В скрам используется всего четыре артефакта:

  • Product Backlog
  • Sprint Backlog
  • Sprint Goal
  • Sprint Burndown Chart.

Я рекомендую вам посетить наш тренинг “Scrum для проектных команд“. Тренинг помогает изучить Scrum-процесс от начала и до последних нюансов.

Product backlog:

  • Это список всех требований, которые нужно сделать по проекту. Когда в Backlog’e нет требований, проект считается завершенным.
  • Все требования описаны по единому шаблону, который называют User Story (пользовательская история).
  • Требования составлены так, что очевидно и понятно, какую ценность они представляют для пользователя
  • Требования отсортированы по приоритетам, которые пересматриваются каждый спринт.

На снимке ниже представлен Backlog проекта.

Команда проекта выбрала 2 требования в Sprint#3.

Project Backlog (JIRA)

Sprint backlog:

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

Sprint Backlog – это обязательство команды: что они должны выполнить за ближайшие 2 недели.

Каждое требование разделено на задачи, которые представлены на Kanban-доске.

Kanban Доска в Спринте

Sprint Goal

  • это краткое описание того, ради чего выполняется данный спринт.
  • цель на спринт помогает команде принимать обоснованные решения.

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

Sprint Burndown Chart

  • дословно “диаграмма сгорания”
  • в качестве “сгорающих” элементов выступают человеко-часы или идеальные единицы (Story Points).
  • диаграмма обновляется каждый раз, когда завершается какая-либо задача.

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

Burndown диаграмма в Jira

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

Роли в Scrum

В скрам используется всего три роли:

  • Product Owner
  • Scrum Master
  • Team.

Роль Product Owner

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

Product Owner – это представитель подразделения, которое владеет разрабатываемым продуктом. Например в банке это может быть Департамент карточных продуктов. Правильно определить Product Ownera не просто, т.к. эта роль требует сочетания следующих качеств:

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

В некоторых случаях допустимо назначить более одного человека на роль Product Owner. Но в этом случае необходимо назначить среди них “главного”, который будет авторизовать требования в Bcaklog’e и лично расставлять приоритеты.

Роль Scrum Master

  • следит за корректным применением принципов Agile и процессов (ритуалов) Scrum
  • организует работу команды и обеспечивает её всем необходимым
  • защищает команду, несёт ответственность за её эффективность
  • только один человек.

Очень сложная роль. В классическом project management есть Руководитель проекта. В Scrum такая роль не предусмотрена. Лучшим синонимом роли Scrum Master будет “администратор”.

Скрам Мастер организовывает работу команды проекта, но не вмешивается в её работу.

  • Скрам мастер не назначает людей на задачи – это делает сама команда;
  • Мастер не заставляет людей делать работу – это ответственность команды;
  • Мастер не указывает Product Owner какие требования он должен написать – это работа владельца продукта.

Тем не менее, если скрам-процесс проходит с нарушениями (кто-либо из команды опаздывает на daily-meeting), то мастер должен вмешаться и исправить ситуацию.

Источник: https://www.pmoffice.by/blog/agile/agile-approach.html

«Scrum головного мозга»: что такое Agile и где его применять — Офтоп на vc.ru

Что такое методология Agile и в чем принципы манифеста Agile Manifesto?

Вы, наверное, уже сталкивались с дискуссиями по теме 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-манифеста

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

Кстати, позвольте придерусь к первой ценности в русскоязычном манифесте. В оригинале на месте слова «важнее» стоит слово “over», которое дословно переводится как «над». То есть дословный перевод — «Люди и взаимодействие над процессами и инструментами».

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

Agile — про создание программных продуктов?!

Не просто про создание программных продуктов, а про создание продуктов, для которых не существует чёткого и понятного плана «как сделать это правильно».

Такой план невозможно составить, например, если у вас:

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

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

Первый полет братьев Райт

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

Всё, уже можно про Scrum?

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

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

Трансформация компании

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

В каждой компании, которая достаточно давно на рынке, есть определенная сложившаяся культура — свои ритуалы, понятия, формальные и неформальные правила.

Фундаментально, существует два пути изменить что-либо:

  • построить всё заново с нуля;
  • плавно меняться, аккуратно убирая или заменяя те участки системы, которые препятствуют положительным изменениям.

Scrum

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

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

  • брать на себя ответственность;
  • признавать свои ошибки;
  • поддерживать коллег;
  • достигать цели, поставленные команде.

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

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

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

Простой пример — компания не отменила персональные KPI, и запускает Scrum. Но в Scrum ответственность командная, вот и «приехали». На практике, успешные истории транфсормации компаний с помощью Scrum:

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

Так что Scrum — это про ломать то, что есть (если есть) и строить с нуля. Это абсолютно точно не плавный переход, а серьёзная встряска, и к этому вопросу нужно подходить с полной осознанностью.

Оказывается, Agile — сложно?

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

Многие недоумевают, почему такие огромные деньги инвестируются в стартапы. Ответ-то простой — стартап (как правило) гибкий и быстрый от природы.

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

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

Маркетинг, продажи и Agile

А теперь, внимание. Моя любимая история. «Привет, мы теперь используем Scrum/Kanban/другое слово в ИТ, у нас наладились отношения между закачиком и технической командой, мы “быстрее бежим», и меньше делаем дорогих ошибок, но прибыль что-то у компании не растет».

А еще и затраты стали больше, правда ведь? Консультанты, агенты по трансформации, повышение зарплат (спецназ же) и так далее. А чего вы ждали-то? Вы разве к ИТ-отделу ходите за финотчетами?

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

  • Growth hacking.
  • Lean startup.
  • Lean marketing / UX.

И с этими словами тоже нужно познакомиться, потому что там где заканчивается Agile, начинается Business Agility — а это уже история для отдельной статьи.

В чём же суть agile

Один из авторов манифеста (Дейв Томас) после его создания не посещал конференции, мероприятия, не интересовался тренингами по Agile. В рамках своего знаменитого выступления «Agile мёртв» он описал, что и как надо делать.

Что делать

  1. Понять что сейчас происходит вокруг.
  2. Сделать маленький шаг в сторону достижения поставленной цели.
  3. Скорректировать текущее понимание ситуации по результатам полученной информации.
  4. Повторить вышеописанные действия.

Как делать

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

Что для этого нужно

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

И эти правила не персональные, они должны работать на уровнях:

  • человек;
  • команда;
  • организация.

Так что берите их на вооружение и начинайте меняться уже сегодня.

Источник: https://vc.ru/flood/18265-agile-srcum-tsyrulnik

Поделиться:
Нет комментариев

    Добавить комментарий

    Ваш e-mail не будет опубликован. Все поля обязательны для заполнения.