Технология аджайл: Agile-подход к управлению проектами

Agile-подход к управлению проектами

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

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

Концепция Agile-подхода к управлению проектами

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

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

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

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

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

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

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

Преимущества Agile-подхода к управлению проектами

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

Некоторые из наиболее очевидных преимуществ Agile-подхода:

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

Недостатки Agile-подхода к управлению проектами

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

Некоторые возможные недостатки Agile-подхода:

• Руководителям и клиентам может быть сложно утверждать и поддерживать проекты, для которых не составлены точные графики и сметы, а также не определен точный объем.
• Руководителям компаний трудно составлять долговременные планы, когда не ясно, будут ли ресурсы свободны для следующего проекта или задействованы в текущем Agile-проекте.
• Компании с ориентацией на рабочие процессы, с высоким уровнем бюрократии и большим документооборотом, скорее всего, будут отказываться от Agile-подхода, пока не внесут изменения в организационную структуру и корпоративную культуру.
• Бывает сложно оценивать ход выполнения из-за использования многочисленных спринтов, которые могут настраиваться и выполняться как отдельные мини-проекты.
• Выполнение Agile-проектов часто отнимает больше времени и сил, поскольку многие методолoгии требуют проведения ежедневных совещаний и постоянного взаимодействия с клиентом.
• Длительность и объем проекта могут выйти из-под контроля из-за отсутствия четких границ, которые не задаются изначально.
• Некоторые крупные и длительные проекты трудно разделить на краткие спринты.
• Поскольку упор делается на отчетные материалы, а не документацию, сокращаются объемы бумажной работы. Хотя иногда это можно считать достоинством, часто получается так, что участники команды не записывают информацию, которая могла бы помочь при выполнении следующих проектов.

Как внедрить Agile-подход к управлению проектами

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

1. Узнайте об Agile-процессах и концепциях. Уделите время сбору информации об Agile-методологиях, их структуре, принципах и основных концепциях. Затем поделитесь этим знанием с командой, клиентами и всеми участниками проекта.
2. Выясните, когда этот подход нельзя использовать . Прежде чем приступать к работе над новым проектом, стоит рассмотреть достоинства и недостатки Agile-методологии и решить, подойдет ли она в данном случае. Agile-подход — не панацея, и попытка применить его при выполнении неподходящего проекта может привести к большим проблемам.
3. Устраните препятствия. Своевременно информируйте сотрудников, постарайтесь сплотить команду и укрепить совместную работу, позаботьтесь, чтобы у вас было подходящее решение для управления Agile-проектами.
4. Заручитесь поддержкой руководства. Даже самые лучшие инструменты для управления Agile-проектами ничем вам не помогут, если руководители компании не будут с вами на одной стороне. Руководители должны поддерживать принципы Agile-управления и формировать Agile-среду.
5. Начните с малого. Очень важно начинать с небольших проектов. Добейтесь успеха, а затем уже используйте свои наработки с большим числом команд и при выполнении проектов большего объема.
6. Вносите изменения и корректировки. Если после выполнения первого Agile-проекта что-то пошло не так, можно попробовать другую Agile-методологию или внести исправления.

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

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

Что такое agile? | Atlassian

Прагматичное руководство Atlassian по agile-разработке

Просмотр тем

Что такое agile?

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

ЧИТАЙТЕ НИЖЕ

Темы, связанные с agile

Обучающие руководства

[ПРОДОЛЖЕНИЕ]

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

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

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

В чем преимущества agile?

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

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

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

Agile вчера, сегодня и завтра

Методология agile появилась в 2001 году, когда был издан Манифест Agile. С тех пор появилось множество agile-платформ, таких как Scrum, Kanban, бережливое производство и экстремальное программирование (XP). В основе каждой из этих платформ лежат главные принципы методологии agile: работа частыми итерациями, непрерывное обучение и обеспечение высокого качества. Scrum и XP пользуются популярностью среди команд разработчиков, а Kanban предпочитают команды, ориентированные на оказание услуг, например ИТ-отделы или отделы кадров.

Сегодня многие команды, следующие принципам agile, сочетают приемы из различных платформ, дополняя их собственными практиками. Одни команды внедряют ритуалы agile (например, регулярные стендапы, ретроспективы, ведение бэклога и т. п.), другие, например маркетинговые agile-команды, следующие принципам Манифеста Agile для маркетинга, создают новые практики agile.

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

Agile в компании Atlassian

Применение agile на практике должно учитывать уникальные потребности и культуру команды. В компании Atlassian нет двух команд, которые применяли бы agile одинаково.

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

Например, если ваша команда обрабатывает запросы на обслуживание по мере поступления, как ИТ-отдел, Kanban будет для вас идеальным решением. Но вы можете дополнить эту платформу несколькими собраниями Scrum, например сеансами демонстрации результатов для заинтересованных лиц или регулярными ретроспективами.

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

Принципы использования этого сайта

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

Кроме того, на сайте есть обучающие руководства по применению этих практик в сочетании с Jira Software — нашим инструментом управления проектами для agile-команд разработчиков. Хотите создать и настроить доску Kanban? Нужно получить аналитические данные по скорости работы команды? Всю необходимую информацию вы найдете в наших обучающих материалах.

Вы на правильном пути. Вперед, к вершинам!

Описание технологии Agile/Scrum | Институт Типовых Решений — Производство

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

Все эти методики ставят целью минимизацию рисков, достигается эта цель разработкой (проектированием) короткими итерациями.

Основополагающие ценности Agile содержатся в “Манифесте Agile”:

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

Scrum – это конкретная технология (методы ведения проекта и роли участников процесса), реализующая принципы Agile.

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

О плюсах и минусах Agile/Scrum при выполнении проектов автоматизации>>>

Требования к результатам спринта определяются в начале спринта (планирование спринта) и не могут изменяться в процессе спринта. Небольшая длительность спринта придает процессу предсказуемость и гибкость.

Роли Scrum

1. Scrum Master. Бизнес-аналитик, руководитель проекта. Проводит совещания, следит за соблюдением технологии Scrum, снимает противоречия и направляет команду. Основная обязанность – обеспечение выполнения технологии Scrum.
2. Product Owner. Владелец проекта, функциональный заказчик. Представляет интересы заказчика (конечных пользователей).
3. Development Team. Команда специалистов (разработчиков). Состоит из специалистов различного профиля- аналитиков, архитекторов, программистов, тестировщиков. Команда отвечает за результат как единое целое.

Элементы Scrum

Sprints (Спринт)

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

Project backlog (журнал задач проекта)

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

Sprint backlog (журнал задач спринта)

Sprint backlog – журнал пожеланий спринта. Содержит функциональность, отобранную владельцем проекта  (Product Owner) для реализации на текущем спринте.

Burndown chart (Диаграмма сгорания задач)

Burndown chart – диаграмма сгорания задач. Демонстрирует объем сделанной и оставшейся работы относительно срока проекта. Диаграмма актуализируется ежедневно. Предусмотрены два вида диаграмм:

• Диаграмма сгорания для спринта — показывает, сколько уже задач сделано и сколько ещё остаётся сделать в текущем спринте.
• Диаграмма сгорания для проекта — показывает, сколько уже задач сделано и сколько ещё остаётся сделать до завершения проекта.

Abnormal Termination (Остановка спринта)

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

Sprint Planning Meeting (Планирование спринта)

Sprint Planning Meeting – планирование спринта. Происходит в начале каждого спринта:

• Из бэклога проекта выбираются задачи, обязательства по выполнению которых за спринт принимает на себя команда в данном спринте.
• На основе выбранных задач создается бэклог спринта. Каждая задача оценивается в ч/часах. Решение задачи не должно занимать более 12 часов или одного дня. При необходимости задача разбивается на подзадачи.
• Обсуждается и определяется, каким образом будет реализован этот объём работ.
• Продолжительность совещания ограничена сверху 4—8 часами в зависимости от продолжительности итерации, опыта команды и тому подобного. Совещание делится на 2 части:
  1. Участвует владелец проекта и скрам команда. Выбирают задачи из бэклога проекта.
  2. Участвует только команда: обсуждают технические детали реализации, наполняют Sprint Backlog (бэклог спринта).

Daily Scrum meeting (Ежедневное совещание)

Daily Scrum meeting – ежедневное совещание команды. Правила проведения совещания:

• проводится в одно и то же время, в одном и том же месте;
• не более 15 минут;
• каждому участнику надо ответить  на 3 вопроса:
  • Что я сделал вчера
  • Что я планирую сделать сегодня
  • Что мне мешает

Scrum of Scrums (Скрам над скрамом)

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

• Что каждая команда сделала с момента предыдущего ежедневного совещания?
• Что каждая команда сделает к следующему ежедневному совещанию?
• Есть ли проблемы, мешающие или замедляющие работу каждой команды?
• Нужно ли другой команде сделать что-то из задач вашей команды?

Sprint review meeting (обзор итогов спринта)

Sprint review meeting – обзор итогов спринта.  Проводится в конце спринта.

• Команда демонстрирует результаты спринта всем заинтересованным лицам. Привлекается максимальное количество зрителей.
• Все члены команды участвуют в демонстрации (один человек на демонстрацию или каждый показывает, что сделал за спринт).
• Нельзя демонстрировать незавершенную функциональность.
• Ограничена четырьмя часами в зависимости от продолжительности итерации и объема результата.

Retrospective meeting (Ретроспективное совещание)

Retrospective meeting – ретроспективное совещание. Проводится в конце спринта. Обсуждение результатов спринта:

• Члены команды высказывают своё мнение о прошедшем спринте.
• Отвечают на два основных вопроса:
  • Что было сделано хорошо в прошедшем спринте?
  • Что надо улучшить в следующем?
• Выполняют улучшение процесса разработки (решают вопросы и фиксируют удачные решения).
• Ограничена одним-тремя часами.

О плюсах и минусах Agile/Scrum при выполнении проектов автоматизации>>>

23. 01.2016

Как объяснить бабушке, что такое Agile за 15 минут с картинками / Хабр

«Любое дело всегда длится дольше, чем ожидается, даже если учесть закон Хофштадтера.»
— закон Хофштадтера

Самый просматриваемый ролик на YouTube по теме agile. 744 625 просмотров на момент публикации данной статьи. Легкий стиль изложения, картинки и всего 15 минут — лучшее что я видел. TED отдыхает.

Роли

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

Это заинтересованные лица. Они будут использовать продукт, поддерживать его или будут как-то еще вовлечены в разработку.

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

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

Это команда разработчиков. Те, кто будет строить рабочую систему.

Пропускная способность

Так как команда использует гибкую методологию разработки, они не копят все эти истории до большого релиза, наоборот, они выпускают их сразу и как можно чаще. Обычно они выпускают 4-6 пользовательских историй в неделю. Это их пропускная способность. Ее очень просто измерить — количество пользовательских историй за 7 дней.

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

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

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

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

Что произойдет, если мы будем делать все, о чем они нас просят? У нас будет перегруз.

Допустим, команда возьмется сделать 10 новых историй за эту неделю.Если на входе 10 а на выходе 4-6, то команда будет перегружена. Будет спешить, переключаться между задачами, терять мотивацию, в итоге снижается производительность и качество. Это заведомо проигрышная стратегия.

Scrum и XP в этом случае используют метод “вчерашняя погода”. Команда говорит: “За последнее время мы делали 4-6 фич в неделю, какие 4-6 фич мы будем делать на следующей неделе?”

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

Kanban рекомендует ограничиться несколькими задачами — WIP limit. Допустим команда решает, что 5 — это приемлемое количество пользовательских историй, над которыми они смогут работать одновременно без перегруза, не перескакивая с одной на другую.

Оба эти подхода хорошо работают и оба они создают очередь задач, которые в Scrum называется Backlog, или приоритезированный список задач.

Этой очередью тоже необходимо управлять.Если заинтересованные лица запрашивают 10 историй в неделю, а команда реализует 4-6 историй, то эта очередь будет становиться все больше и больше. И скоро ваш Backlog будет расписан на полгода вперед. То есть одна история будет ждать выхода 6 месяцев.

Есть только один способ держать список задач под контролем — это слово “нет”

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

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

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

Принятие решений

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

Как соотносится размер истории и ее ценность? Никак. Больше не значит лучше. Ценность и сложность задачи — вот что помогает Пэт расставлять приоритеты.

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

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

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

Пэт проводит встречу по очистке Backlogа каждую среду с 11 до 12. Обычно на ней собирается вся команда и иногда несколько заинтересованных лиц. Содержание встреч бывает разным. Фокусировка на оценке, на разбивке историй, на критериях приемки.

Владелец ИТ-продукта должен постоянно со всеми общаться

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

Баланс между сложностью разработки и ценностью пользовательской истории

На ранней стадии балансу угрожает неопределенность и сразу несколько рисков.

Риски

Бизнес риск: «Правильную ли вещь мы делаем?»

Социальный риск: «Сможем ли мы сделать то что нужно?»

Технический риск: «Будет ли проект работать на данной платформе?»

Риски со стоимостью и сроками реализации: «Успеем ли и хватит ли денег?»

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

Компромисс между ценностями знания и ценностями для клиента

С точки зрения заказчика кривая выглядит вот так:

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

Компромисс между краткосрочным и долгосрочным мышлением

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

Делать правильные вещи, делать вещи правильно или делать быстро?

В идеале — все три одновременно, но в реальности приходится выбирать.

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

или

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

или

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

Между ролями в Scrum существует здоровое противостояние

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

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

Компромисс между разработкой нового продукта и улучшением старого

Продукт никогда не может быть полностью завершен, потому что ему постоянно нужны изменения. Когда команда начинает работу над новым продуктом, что происходит со старым? Передача продукта от одной команды к другой — очень затратно и рискованно. Обычно команда поддерживает старый продукт, разрабатывая новый. Поэтому скорее понятие “Backlog” относится не к продукту а к команде. Backlog — это список вещей, которые хочет владелец продукта от команды. И набор историй для разных продуктов. Владельце продукта нужно постоянно выбирать актуальные для реализации.

График уничтожения историй

Время от времени, заинтересованные лица будут спрашивать у Пэт: “Когда выпустят мою фичу?” или “Сколько фич выпустят к рождеству?”. Владелец продукта должен уметь управлять ожиданиями пользователя. И управлять ожиданиями реалистично.

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

Предположим, заинтересованное лицо спрашивает, когда вот эта фича будет сделана?

Это вопрос с фиксированным содержанием и неопределенным сроком. Для ответа Пэт использует две линии тренда. Ответ — в апреле или мае.

Заинтересованное лицо спрашивает Пэт: «Сколько будет сделано к рождеству?» Это вопрос с фиксированным сроком и неопределенным содержанием. Линии тренда отсекают на вертикальной шкале вероятный отрезок того, что успеют реализовать.

Заинтересованное лицо спрашивает :«Успеем ли мы сделать вот эти фичи к рождеству?» Это вопрос с фиксированными временными рамками и фиксированным содержанием. Ориентируясь на тренды, Пэт отвечает: «Нет». Добавляя: «К рождеству мы успеем сделать столько, а вот столько времени нам понадобится чтобы завершить всю эту работу полностью.»

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

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

Несколько команд

Пусть у нас несколько владельцев продукта и несколько команд. Модель та же — управление пропускной способностью, коммуникация с заинтересованными лицами, принятие решений по поводу отклонения пользовательских историй. Скорость равна сумме скоростей всех команд. Прогнозирование может быть общее или по каждой команде. У владельцев продуктов появляется дополнительная задача — общение с другими владельцами продукта. Нужно организовать работу над Backlogами так, чтобы минимизировать зависимости и обеспечить синхронизацию. В больших проектах требуется Главный владелец продукта (CPO), чтобы синхронизировать всех остальных.

Исходник — Agile Product Ownership in a nutshell

видео на английском

видео на русском

Agile-методы и проектный подход – в чем разница? — Карьера на vc.ru

Недавно вел модуль, посвященный Agile на Advanced Business Management в Стокгольмской школе экономики. И в обсуждении с участниками модуля проявилась мысль, что в рассказе про Agile-методы обязательно надо фиксировать, в чем отличия с классическим проектным подходом. Потому что проектный подход многие менеджеры изучали, и им надо понимать разницу. У меня в презентации это, конечно, было, но мало и я не делал на этом акцента. И в статьях серии «Менеджмент цифрового мира» я тоже разбирал проблемы проектного подхода, а потом, отдельно – Agile методы. Поэтому я пару недель назад я сделал выпуск на радио ТМFM об этой разнице, а сейчас публикую развернутую статью.

7356 просмотров

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

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

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

Другой пример – плита, микроволновка, мультиварка. Все они готовят пищу за счет термообработки. При этом сильно по-разному устроены, и можно описывать внутреннее устройство каждой. И это устройство, естественно, определяет и возможности приготовления конкретных блюд, и используемые рецепты и время приготовления. И это – важно. Но для выбора устройства важно другое. Микроволновка греет блюда по всему объему, что делает ее незаменимой для быстрого разогрева пище. А мультиварка умеет поддерживать режим медленного кипения, обеспечивая приготовление каш, варку на пару и другие сложные процессы готовки без человеческого внимания: поставил, и через заданное время получил готовое.

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

Перед обсуждением различий стоит пару слов сказать про сам проектный подход, project management. Хотя проекты строительства соборов, зданий, мостов, кораблей реализовывались очень давно, современный проектный подход вырос вовсе не из реализации строительных проектов. Современный проектный подход появился на рубеже 1960-х и 1970-х, и в основе его лежит опыт инженерных проектов, хотя такие практики, как диаграммы Ганта или PERT были известны гораздо раньше и, естественно, были использованы. А первое руководство, PMBOK появилось вообще недавно, в 1996 и преимущественно основано на опыте IT-проектов. Потому что именно проблема низкой успешности IT-проектов была в фокусе внимания.

Отметим, что эту задачу успешно решить проектному подходу как раз не удалось, здесь он проиграл конкуренцию Agile-методам, которые тоже не дают гарантий, однако позволяют вести проекты дешевле и большими шансами на успех. Об этом есть статистика, можно посмотреть 2013 IT Project Success Rates Survey Results, 2018 IT Project Success Rates Survey Results и Standish Group 2015 Chaos Report и другие. Подробнее я писал об этом в статье Статистика успешности Agile. А теперь вернемся к вопросу различий.

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

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

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

Из моих презентаций

На мой взгляд, именно это различное полагание об устройстве мира и представляет собой основную причину, по которой проектный подход не может полноценно включить в себя Agile-методы. Это – принципиальное различие. Agile-методы появились в 2000, и к середине нулевых их успех стал настолько масштабным, что его нельзя было игнорировать. Именно тогда начались первые попытки объединения. Сначала – в рамках разработки третьей версии SWEBOK, массива знаний по программной инженерии, которая вышла в 2004. Затем – в рамках разработки четвертой версии PMBOK, массива знаний по проектному подходу, вышедшей в 2008. Получалась эклектика. И последующие версии PMBOK не смогли решить эту проблему. Именно потому, что в ее основании лежат различные ответы на онтологический вопрос о возможности построения модели мира. Да, модель нужна частичная, того участка, который касается проекта. Но зато построить ее надо не в отдаленном светлом будущем, а во временных рамках проекта.

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

Казалось бы, в разработке софта эксперимент тоже дорог, разработчики пишут код, тестировщики его проверяют, а потом оказывается, что сделано совсем не то. Но это – неверная параллель. На самом деле, написание кода – это не производство опытного образца, это такое низкоуровневое проектирование. А то, что для самолетов делает производство, в IT делает среда разработки по кнопке «собрать проект» и вот этот эксперимент – дешев. И дешевый эксперимент как раз вызвал совсем другой подход к разработке софта, массовое производство образцов с ошибками и их отладку. Это было выяснено давно, есть статья Джека Ривза (Jack W. Reeves) 1992 года «What is software design» (перевод), где все подробно разобрано. Поэтому вместо тщательного проектирования в IT – многочисленные эксперименты. Так дешевле.

Из моих презентаций

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

Проектный подход основан на тщательном проектировании и следовании плану, а Agile-методы – на движении итерациями через эксперименты

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

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

Кстати, именно такой подход к учету неопределенности в сроках начал из мира IT проникать и в классический менеджмент, в том числе в организацию работы на конвейере. Изначально в работе на конвейере человеческий фактор исключался за счет нормирования операций, которое гарантирует, что на каждом рабочем месте рабочий успеет качественно ее выполнить. Качество такого проектирования – отдельный вопрос. Например, одном из советских заводов качественная сборка автомобилей получалась при скорости конвейера в 60% от расчетной, а выше резко возрастал процент брака. А вот Тойота пошла по другому пути: увеличить скорость конвейера, предоставив при этом каждому рабочему кнопку остановке, если он не успевает завершить операцию. И оказывается, что средняя скорость при этом получается выше, не взирая на остановки. Так и в IT – мы планируем поток задач оптимистично, но учитываем, что реально выполним не все.

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

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

Вопрос обеспечения адекватной обратной связи по результатам очередной итерации необходимо рассмотреть отдельно. Дело в том, что для получения обратной связи в рамках итерации не просто должен быть выполнен определенный объем работ, а должно быть создано ценность для конечного потребителя. В IT это называется «выделить MVP», minimum viable product. И это кардинально изменило подходы к работе с требованиями, проектированию и планированию этапов проекта. Потому что в классике сначала проектировали структуры данных – целиком, по площади, делали справочники – они ведь являются основой, а потом добирались до документов, которые тоже делали последовательно, по типам, например, сначала договора, потом движение товаров, потом – платежную часть. А если мы хотим принести пользователям ценный продукт, то мы должны действовать совершенно не так, мы должны сделать поддержку какого-то целостного процесса, а для этого – реализовать кусочки из самых разных частей системы, и уложить это в один-два спринта. В работе с требованиями это породило подход user story, который позволяет мелкую нарезку и который пришел на смену комплексному проектированию системы. А в реализации – разработку почти на живую нитку с постоянным рефакторингом и проблемы с архитектурой. Это – накладные расходы, но без этого адекватную обратную связь получить невозможно, и велик риск долго идти не в ту сторону.

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

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

Необходимо отдельно отметить, что разработка через эксперименты позволяет использовать незрелые технологии. Есть такая шкала – Technology rediness level (TRL), разработанная NASA для оценки технологий, закладываемых при проектировании космических кораблей. Когда Боинг проектирует новый самолет, то разрешается закладывать технологии со зрелостью не ниже 8 из 10, и именно это позволяет Боингу контрактовать самолеты на стадии детального проектирования. Если же мы посмотрим на современную IT-разработку, то там активно используются технологии уровня 4-5. И не из-за тяги к новизне и риску, а потому, что более зрелых технологий, для мобильной разработки просто не успевает появиться – железо развивается очень быстро.

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

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

И так же обстоит дело не только в IT. Это можно наблюдать для любых социальных систем, например, в маркетинге или при создании новых продуктов. Потому что надежной модели человека – нет. Была версия, что люди принимают решения рационально, на этом базировалась экономика. Но многие исследования, включая эксперименты Даниэля Канемана, за которые он получил Нобелевскую премию, показывают, что это не так. Впрочем, экономисты все равно не могли отказаться оснований своей науки, а просто объявили, что изучают модели, основанные на абстракции homo economicus, принимающем рациональные решения. Конечно, физики тоже работают с абстракциями, такими как материальная точка. Отличие в том, что материальная точка во многих случаях хорошо описывает поведение реальных физических тел, а вот homo economicus поведение реальных людей не описывает. Подобно этому многие руководители разработки в IT успешно игнорируют результаты Ривза о том, что кодирование представляет собой низкоуровневое проектирование, и потому результат разработки по проекту не гарантирован.

И тут мы еще не учитываем, что результат разработки, софт, важен не сам по себе, а будучи встроенным в социальную систему – в бизнес или потребительский рынок, которая при этом изменяется с высокой динамикой. При этом встройка софта еще и изменяет эту систему, заранее изучить ее просто невозможно, ее не существует. Это уместно проиллюстрировать парой примеров из моей практики. Первый из логистики. В свое время компания Спортмастер, сделав очередной заказ товара на сезон с учетом предполагаемого роста сети, обнаружила, что существующая технология работы склада не позволяет обработать входящий поток товара с нужной скоростью. Было придумано решение – оперативная сортировка поступившего товара на несколько складов, каждый из которых будет снабжать свои каналы сбыта, без вскрытия коробов и с приемкой уже на складах назначения. Для поддержки нужен был софт, который позволит грузчикам на складе оперативно такое деление провести с приемлемым качеством в режиме 24*7. При этом невозможно было заранее исследовать бизнес-процесс – его просто не существовало на момент постановки задачи, его создавали вместе с софтом, который являлся его основой.

Другой пример – из работы Банка России. В острой фазе финансового кризиса 2008 для обеспечения ликвидности был придуман механизм кредитов без обеспечения. И, естественно, потребовалось оперативно, то есть за неделю-другую создать систему, которая бы обеспечивала банкам доступ к этим кредитам. Опять-тки, никакого бизнес-процесса на входе не было, его создавали и адаптировали к реальным условиям и меняющейся ситуации одновременно с системой.

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

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

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

Из моих презентаций

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

Проектный подход предназначен для сложной (comploicated) области, а Agile-методы работают в запутанной (complex)

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

История развития менеджмента в IT дает яркий пример такого заблуждения – RUP, Rational Unify Process. Неопределенность в проектах IT-разработки и ключевая роль человеческого фактора в успехе, которые делают неприменимыми классический менеджмент, были уже осознаны. Но все равно, в компании Rational были собраны четверо гуру и большая команда, чтобы создать метод ведения проектов, гарантирующий успех. Попытка провалилась, получился очень сложный фреймворк, который практически невозможно применить. Но именно RUP dj многом лег в основу PMBOK. Отметим, что помимо RUP теми же авторами был создан UML, который до сих пор является мощным средством визуального проектирования – команда была реально сильной. Совсем недавно аналогичным образом и, частично, с участием тех авторов был создан Agile-фреймворк SAFe, который тоже претендует на исчерпывающую модель менеджмента. Он, безусловно, лучше классического проектного управления, поскольку в его основе, наряду с практиками Agile, лежит концепция цепочек создания ценности. Но гарантий все равно дать не может.

Кстати, о концепте цепочек создания ценности. Строго говоря, он не относится ни к Agile-методам, ни к классическому менеджменту. Он пришел из системы Тойоты вместе с Lean. Идея состоит в том, что нам не просто надо создать некоторый продукт, надо чтобы этот продукт удобно решал проблему потребителя. Естественно, мы его для решения этой проблемы придумывали, но вовсе не факт, что он будет решать ее хорошо. Это известно всем, кто смотрел, например, мобильные приложения – для любой цели в Apple Store или Google Play их существует множество, и только несколько являются популярными и хорошо решают задачу, приносят ценность потребителям.

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

В проектном подходе возврат инвестиций находится за рамками проекта, а не внутри него

Концепт цепочек создания ценности вместе с Lean был переосмыслен для IT-менеджмента и вошел во многие Agile-практики и методы. В частности, sprint review или демо в Scrum должен оценить именно пригодность для решений задач бизнеса или проблем пользователей того, что создано в итерации, а не просто показать, что сделано. И в ряде случаев это требует специальной организации, потому что не всегда есть люди, которые могут оценить это в ходе демонстрации, и не всегда их можно позвать на демо. А без этого обратная связь оказывается фиктивной и не достигает цели. Углубляться в это я не буду, у меня были отдельные статьи «Завершение спринта в Scrum — демо и ретро» и «Kanban и Lean — эволюция вместо революции».

Проектный подход ориентирован на управление выполнением работ, а Agile-методы – на создание ценности

Отмечу, кстати, что Lean и система Тойоты не была взята в IT механически. Если слушаешь консультантов по промышленному Lean и Lean в IT, кажется, что речь идет о сильно разных подходах. И это – не случайно. Дело в том, что изначально они ориентированы на организацию физического труда, а в IT мы имеем дело с творческим, интеллектуальным трудом. И это накладывает свои особенности, например, лишняя работа, muda для умственного труда имеет свою классификацию. Отметим, что хотя проектный подход тоже разрабатывали для ведения IT-проектов, то есть для организации умственного труда, практики организации физического труда или, во всяком случае, хорошо нормируемого труда, брали из регулярного менеджмента гораздо менее критично, не учитывая этого различия.

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

Вернемся к Кеневин-фреймворку. Сложность конкретной области, конкретного проекта квалифицируется как относительно достижений человечества в целом, так и относительно команды, которая в ней работает. То, что для команды junior-сотрудников лежит в сложной или запутанной области, для опытной команды является простым, просто потому, что им не известны соответствующие модели. Понятно, что можно научиться, но это требует отдельного времени. Можно так же позвать экспертов, если они доступны. И проектный подход как раз требует, чтобы это было сделано, во всех руководствах написано, что необходимым требованием для успеха является компетентная команда. А вот для Agile-методов это является не обязательным. Более того, успех Agile во многом связан с тем, что он решил проблему дефицита разработчиков, возникшую с появлением персоналок. Компьютеры стали доступны мелкому и среднему бизнесу, и сразу потребовалось множество систем для их автоматизации, а количество разработчиков – не увеличилось. На постсоветском пространстве проблема была решена за счет того, что тога развалилась оборонка и множество инженеров пошло в IT, на на западе такого резерва не было, и проблему решило появления Scrum.

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

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

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

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

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

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

И в заключении я хочу привести метафору, которая у меня родилась на сопоставлении японской системы менеджмента с западной на одной из IT-конференций, где одновременно были специалисты из Японии, Европы и Израиля и была развернутая дискуссия между ними. Японская система менеджмента в целом значительно ориентирована на работу в изменяющемся мире, и этим она схожа с Agile-методами, которые много почерпнули из Lean и системы Тойоты в целом. Я тогда написал статью «Запад и Япония: два взгляда на бизнес-процессы», где и появилось сравнение, которое я хочу привести.

Из моих презентаций

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

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

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

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

На этом я завершаю статью. Это было продолжение серии статей «Менеджмент цифрового мира», полное оглавление серии – на моем сайте https://mtsepkov.org/NewMngSeries

РЕАЛИЗАЦИЯ ТЕХНОЛОГИИ AGILE В УПРАВЛЕНИИ ПЕРСОНАЛОМ Текст научной статьи по специальности «Экономика и бизнес»

Имамвердиева М.И.

преподаватель кафедры государственного и муниципального управления и управления персоналом, Сургутский государственный

университет, г. Сургут

РЕАЛИЗАЦИЯ ТЕХНОЛОГИИ AGILE В УПРАВЛЕНИИ

ПЕРСОНАЛОМ

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

Ключевые слова: Agile, персонал, проектный подход, процесс, технология.

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

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

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

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

Система Agile основана на следующих элементах:

• Люди и взаимодействие важнее процессов и инструментов;

• Работающий продукт важнее исчерпывающей документации;

Люди и коммун и кации

Сотрудн ичество

Изменен

• Сотрудничество с заказчиком важнее согласования условий контракта;

• Готовность к изменениям важнее следования первоначальному плану. Системно Agile можно изобразить следующим образом (рис. 1):

( Продукт )

Рис. 1. Элементы системы Agile

Фундаментом внедрения Agile-подхода является интеллектуальная деятельность персонала (Knowledge Work), которая, в свою очередь, представляет собой неотъемлемую часть развития и функционирования современной организации.

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

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

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

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

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

«Гибкий итеративно-инкрементальный подход к управлению проектами и продуктами, ориентированный на динамическое формирование требований и обеспечение их реализации в результате постоянного взаимодействия внутри самоорганизующихся рабочих групп, состоящих из специалистов различного профиля. Существует множество методов, базирующихся на идеях Agile, самые популярные из которых — Scrum и Kanban» [4].

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

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

Таблица 1

Преимущество и сложности внедрения Agile в управление персоналом

Преимущества Сложности внедрения

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

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

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

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

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

Список использованных источников

1. Акопян Сейран Араевич Управление проектами по принципам системы Agile. Scrum как один из методов управления проектами, основанный на Agile // Economics. 2017. №2 (23). URL: https://cyberleninka.ru/article/n/upravlenie-proektami-po-printsipam-sistemy-agile-scrum-kak-odin-iz-metodov-upravleniya-proektami-osnovannyy-na-agile (дата обращения: 05.10.2020).

2. Александрова Т.В. Повышение эффективности проектного управления в организации на основе гибкой методологии Agile // Экономика и бизнес: теория и практика. 2019. №9. URL: https://cyberleninka.ru/article/n/povyshenie-effektivnosti-proektnogo-upravleniya-v-organizatsii-na-osnove-gibkoy-metodologii-agile (дата обращения: 04.10.2020).

3. Терентьева Зинаида Сергеевна, Хализова Ирина Алексеевна Гибкие методы управления проектами, анализ и сравнение // АНИ: экономика и управление. 2019. №1 (26). URL: https://cyberleninka.ru/article/n/gibkie-metody-upravleniya-proektami-analiz-i-sravnenie (дата обращения: 06. 10.2020).

4. Ткаченко Ирина Николаевна, Сивокоз Климентина Климентьевна Использование гибких технологий Agile и Scrum для управления стейкхолдерами проектов // Управленец. 2017. №4 (68). URL: https://cyberleninka.ru/article/n/ispolzovanie-gibkih-tehnologiy-agile-i-scrum-dlya-upravleniya-steykholderami-proektov (дата обращения: 05.10.2020).

5. Чуланова О. Л. Методический инструментарий применения Scrum в реализации проектной деятельности // Материалы Афанасьевских чтений. 2018. №2 (23). URL: https://cyberleninka.ru/article/n/metodicheskiy-instrumentariy-primeneniya-scrum-v-realizatsii-proektnoy-deyatelnosti (дата обращения: 10.10.2020).

6. Чуланова Оксана Леонидовна Технология управления проектами и проектными командами на основе методологии гибкого управления проектами Agile // Вестник евразийской науки. 2018. №1. URL: https://cyberleninka.ru/article/n/tehnologiya-upravleniya-proektami-i-proektnymi-komandami-na-osnove-metodologii-gibkogo-upravleniya-proektami-agile (дата обращения: 01. 10.2020).

Гибкие технологии

Agile Technologies, Inc. Agile Technologies — компания, занимающаяся электронными решениями, предоставляющая комплексные услуги по проектированию электроники, производству и управлению продукцией для глобальные электронные и технологические компании. Мы помогаем нашим клиентам принести продуктов электроники на рынок быстрее и экономичнее, предоставляя полное электронное управление цепочками поставок продуктов, а также всестороннее, индивидуальные, целенаправленные решения в широком спектре отраслей и Приложения. Если вы хотите расширить линейку продуктов, запустите прототип программу или интегрировать совместную производственную стратегию развития, мы повышаем качество вашей продукции при снижении стоимости. Конкурентное преимущество заключается в подборе правильного набора деловые отношения для сохранения и расширения доли рынка. Гибкие технологии стремится к построению прочных партнерских отношений и предоставлению гибких решений для обеспечить успех наших клиентов. Мы адаптивны и гибки и помогаем нашим клиентам сохранить свои лидирующие позиции, объединив производство и логистику функции для сокращения избыточных процессов по всей цепочке поставок. Это позволяет проектирование, сборка и распределение продуктов, которые должны быть завершены и доведены до рынок с меньшим количеством касаний и меньшими затратами. Вы можете рассчитывать на сотрудничество с Agile Technologies. Наш качество, технологии, сервис и опыт в вашем распоряжении. Были готовы и готовы быть быстрыми и отзывчивыми. И мы всегда ставим клиента на первое место. Мы помочь вам стать более успешным, предоставляя компетентность, преданность делу, готовность и боевой дух. Мы предлагаем дизайнерские, производственные и логистические решения это повлияет на вашу прибыль! Проектирование и проектирование Мы предлагаем нашим клиентам дизайнерские и инженерные решения и продолжаем найти способы помочь вам стать более успешным. Какие факторы влияют на успех вашего продукта на рынке? Как выйти на рынок быстрее, с меньшими затратами и с более высоким качеством стандарты? Возможность ответить на эти вопросы помогает установить технологию компаний друг от друга и дает им значительное конкурентное преимущество. С более чем 80 процентами цены продукции и цепочки поставок производительность определяется на этапе проектирования и проектирования, доступ к правильный партнер EMS, который может обеспечить доставку на всех фронтах, является обязательным. Гибкий Качество технологий и технологическое лидерство, а также репутация в Marketplace поможет вам конкурировать и добиваться успеха. Мы являемся частью вашей команды по разработке продуктов. . . Печатная плата и окончательная сборка системы Все это объединяет Agile Technologies. Мы обеспечить сборку печатных плат и полную интеграцию электронных продуктов. Мы быстро закупать компоненты, собирать продукты, проводить сложные испытания и отправлять в ваш конечный клиент. Мы предлагаем комплексное продуктовое решение, синхронизированное с обеспечение качества и процессы тестирования для обеспечения производства на самом высоком уровне на всех сборках. Мы зарабатываем ваше доверие, управляя цепочкой поставок, собирая вашу продукцию и поставить вас на первое место. Логистика В Agile Technologies мы тесно связаны процессы управления производством, логистикой и цепочками поставок, что позволяет дизайн, сборка и распространение вашей продукции, которые будут завершены подробнее быстро, по более низкой цене и с высокими стандартами качества. Зачем позволять логистике и управлению цепочками поставок усложнять ваш бизнес? Готовя свой бизнес к немедленному и будущему росту, обратите внимание на Agile Technologies в качестве вашего предпочтительного партнера. Качество Наше качество и ориентация на клиента очевидны в все, что мы проектируем, производим, тестируем и поставляем. Это акцент на качество, инновационные технологии и комплексное производство решения, которые стимулируют наш бизнес и предоставляют нашим клиентам значительные конкурентные преимущества на мировом рынке. Были ли проектирование и прототипирование продуктов, запуск новых продуктов, развертывание персонала, необходимого для удовлетворения спроса клиентов или доставки поставки нашим клиентам, мы принимаем все меры для обеспечения качества, совершенство и ведущие в отрасли процессы на протяжении всей нашей деятельности. Модульные решения В Agile Technologies так много возможностей. Были прямо там, удовлетворяя все потребности наших клиентов. Необходимость большой опыт в проектировании и производстве модульных решений? смотри нет дальше, чем Agile Technologies. Мы предлагаем широкий ассортимент DRAM, Модули Flash и SRAM, а также другие нестандартные решения. Agile Technologies занимается проектированием, производством и предоставление новейших, наиболее рентабельных и инновационных решений для наших OEM-клиенты по всему миру. Наш широкий ассортимент DRAM, Flash и SRAM модули позволяют OEM-клиентам максимально гибко повышать скорость, качество и дизайн своей продукции. Большой опыт Agile Technologies в модульном проектировании и производство использует инновационные, современные и отраслевые стандарты технологии памяти. Наши передовые возможности проектирования и производства предлагают превосходные решения для сборки, тестирования, программирования и развертывания для всех потребности модульного продукта. Чтобы сохранить наши лидирующие позиции в качестве модульной поставщик продуктовых решений, Agile Technologies постоянно исследует, разработка и внедрение решений нового поколения. Превосходная и гибкая поддержка Наши клиенты полагаются на превосходное качество Agile Technologies, гибкость и быстрое реагирование, чтобы предоставить им правильные решения. Мы предоставить Обширный опыт разработки и производства модульных решений Быстрый вывод на рынок экономичных решений Комплексная поддержка продуктов DRAM, Flash и СОЗУ Стратегия, ориентированная на клиента В Agile Technologies сервис означает способность распознавать, предвидеть и концентрироваться на конкретных потребностях наших клиенты. Наша бизнес-стратегия и повседневная деятельность основаны на отзывы, которые мы получаем от наших клиентов, и мы создали и расширили Agile Технологии один довольный клиент за раз. Сегодня мы предлагаем индивидуальные услуги клиентам в автомобильной, коммуникационной инфраструктуре, корпоративные вычисления и системы хранения, оборонная и аэрокосмическая, медицинская, промышленная и полупроводниковое оборудование, мультимедиа и возобновляемые источники энергии Мировой.

Что такое гибкая методология? Объяснение современной разработки программного обеспечения

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

Исаак Саколик

пишущий редактор, Информационный Мир |

Дрю Грэм (СС0) Содержание

• Роли в гибкой методологии
• Скрам и канбан
• Передовые технические практики для гибких организаций

Показать больше

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

Гибкая разработка имеет богатую историю и объясняет, почему организации используют гибкие методы, такие как схватка и канбан, для модернизации приложений, улучшения качества обслуживания клиентов и внедрения цифровых преобразований. Существует также огромный объем знаний об этих методологиях и их пересечениях с дизайн-мышлением, управлением продуктами и devops. Сегодня все меньше людей спрашивают: «Что такое agile?» Еще больше компаний ищут рекомендации о том, как привести свои команды в соответствие с лучшими практиками гибкой разработки.

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

Роли в гибкой методологии

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

Пользователи

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

Владелец продукта

Владелец продукта должен быть голосом клиента, включая любых внутренних заинтересованных лиц. Этот человек собирает информацию, идеи и отзывы для создания видения продукта. Видение продукта часто бывает кратким и прямолинейным, но, тем не менее, оно рисует картину того, кто является покупателем или пользователем, какие ценности рассматриваются, а также стратегию их решения. Я предполагаю, что первоначальное видение Google выглядело примерно так: «Давайте упростим для всех, у кого есть доступ в Интернет, поиск соответствующих веб-сайтов и веб-страниц с помощью простого интерфейса, основанного на ключевых словах, и алгоритма, который ранжирует авторитетные источники выше в результатах поиска».

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

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

Команда разработчиков программного обеспечения

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

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

Agile-командам часто назначаются другие роли, в том числе следующие:

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

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

Scrum и kanban

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

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

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

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

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

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

Scrum повышает производительность команды, позволяя команде выполнять достижимый объем работы, а не заставляя менеджера продукта, программы или проекта указывать ожидаемые сроки и объем. Пользовательская история формирует микроконтракт, который разделяет потребности бизнеса, критерии приемлемости (или то, что agile-команды иногда называют определение выполнено ), а затем позволяет командам самостоятельно организовать , как реализовать . Обзоры спринтов — это один из видов цикла обратной связи, и владельцам продуктов рекомендуется пересматривать приоритеты и переопределять требования перед каждым спринтом. Ретроспективы спринтов помогают команде улучшить сотрудничество и инициировать улучшения процессов.

Лучшие технические практики для agile-организаций

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

Сегодня многие передовые технические практики включают определение жизненного цикла разработки программного обеспечения (SDLC) и реализацию процессов devops. SDLC содержит рекомендации по написанию кода, управлению программными активами и разработке технических стандартов. Средства автоматизации DevOps, такие как CI/CD, инфраструктура как код (IaC) и непрерывное тестирование, обеспечивают более надежный путь к производству. Другие методы, в том числе методы безопасности со сдвигом влево, наблюдаемые микросервисы, пометки функций, канареечные выпуски и AIOps, обеспечивают более гибкую и надежную модель доставки.

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

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

Agile-команды обычно развертывают такие инструменты, как Jira Software, Azure DevOps и Digital.ai, для совместной работы над agile-бэклогами и досками канбан. Эти инструменты помогают гибким командам расставлять приоритеты в работе, собирать требования, заполнять пользовательские истории, просматривать отчеты о выработке и автоматизировать рабочие процессы с помощью контроля версий, CI/CD и других инструментов.

Концептуальные основы и руководства, такие как SAFe, Enterprise Scrum, LeSS (крупномасштабный Scrum), модель Spotify и StarCIO Agile, могут помочь внедрить принципы, стандарты и методы гибкой разработки во многих сотрудничающих командах.

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

Связанный:

• Гибкая разработка
• Разработка программного обеспечения
• Девопс

Copyright © 2022 IDG Communications, Inc.

Как выбрать платформу разработки с низким кодом

Что такое гибкая методология?

перейти к содержанию

Введите ключевые слова

Свяжитесь с нами

Select a language

• 简体中文
• English
• Français
• Deutsch
• Italiano
• 日本語
• 한국어
• Português
• Español

Добро пожаловать,

Войдите в свою учетную запись Red Hat

Войдите в систему

Ваша учетная запись Red Hat дает вам доступ к вашему профилю участника и предпочтениям, а также к следующим услугам в зависимости от вашего статуса клиента:

Зарегистрируйтесь сейчас

Еще не зарегистрированы? Вот несколько причин, по которым вы должны это сделать:

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

Редактировать свой профиль и предпочтения

Ваша учетная запись Red Hat дает вам доступ к вашему профилю участника, предпочтениям и другим услугам в зависимости от вашего статуса клиента.

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

Выход

Логин аккаунта

Выберите язык

• 简体中文
• Английский
• Французский
• Немецкий
• Italiano
• 日本語
• 한국어
• Português
• Español

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

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

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

Узнайте больше о agile на opensource.com

Agile в том виде, в каком мы его знаем сегодня, ведет свою историю с 2001 года. Реагируя на водопадный подход к управлению проектами, который организует программный проект в виде серии линейных последовательностей, группа разработчиков программного обеспечения сочинила Манифест гибкой разработки программного обеспечения. В этом документе программисты предложили новый подход к разработке программного обеспечения и описали 4 ключевые характеристики, которые, по их мнению, следует ценить выше других проблем. По их словам, agile-команды разработчиков программного обеспечения должны ценить:

• особей и взаимодействий над процессами и инструментами
• Рабочее программное обеспечение В комплексной документации
• КОЛЛЕКТЫ КОЛЛЕКЦИИ В течение контрактного переговора
• ОТЛИЧНЫЕ КЛИЧЕСКИЕ ИСПОЛЬЗОВАНИЯ Следующие поступки
• . в приведенном выше списке имеют некоторую неотъемлемую ценность. Однако они предполагают, что оценка элементов слева (выделены жирным шрифтом) выше элементов справа может привести к лучшим результатам в разработке продукта. Agile-манифест не претендует на то, чтобы предписывать набор практик; это руководство для нового образа мышления о разработке программного обеспечения.

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

  Agile-подходы к работе были созданы для устранения предполагаемых ограничений методологии водопада, которая была основана на производственном методе сборочной линии Генри Форда 1913 года и позже применялась к разработке программного обеспечения. С момента своего основания в 2001 году гибкая разработка процветала в индустрии программного обеспечения и управлении проектами, хотя и имеет множество вариаций.

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

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

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

  DevOps как концепция разрушает старую стену между разработкой программного обеспечения и эксплуатацией. SRE — это реализация DevOps, в которой программное обеспечение используется как инструмент для управления системами и автоматизации операционных задач. Методы CI/CD признают, что программное обеспечение будет постоянно меняться, и предоставляют разработчикам инструменты для ускорения развертывания нового кода.

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

  Agile-фреймворки для разработки программного обеспечения, такие как Scrum, kanban или экстремальное программирование (XP), формируют основу для популярных процессов разработки программного обеспечения, таких как DevOps и непрерывная интеграция/непрерывное развертывание (CI/CD).

  Scrum, пожалуй, самая популярная гибкая среда, используемая сегодня, но не все agile — это Scrum, и, честно говоря, не весь Scrum agile. Scrum — это фреймворк для управления работой, предназначенный для небольших межфункциональных команд из 5–9 человек, которые разбивают свою работу на действия, которые могут быть выполнены в течение определенного периода времени, называемого спринтом. Scrum-команды состоят из членов команды, Scrum-мастера и владельца продукта. Как правило, Scrum применяется, когда большой проект можно разбить на 2–4-недельные спринты. Scrum фокусируется на петлях обратной связи посредством церемонии, называемой «ретроспективой». Неофициальным девизом Scrum может быть «проверка и адаптация».

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

  Узнайте, как гибкие фреймворки могут способствовать инновациям, с Red Hat Open Innovation Labs

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

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

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

  Продукты

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

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

  Статьи по теме

  • Понимание DevOps

  • Облачная CI/CD в Red Hat OpenShift

  • Что такое автоматизация развертывания?

  • Что такое автоматизация DevOps?

  • Кто такой инженер DevOps?

  • Что такое конвейер CI/CD​?
  • Что такое гибкая методология?
  • Что такое управление жизненным циклом приложений (ALM)?
  • Что такое сине-зеленое развертывание?
  • Что такое CI/CD?
  • Что такое непрерывная доставка?
  • Что такое DevSecOps?
  • Что такое GitOps?
  • Что такое SRE (проектирование надежности объекта)?

  Ресурсы

  Автоматизация предприятия с помощью методологии DevOps

  Оптимизация конвейеров CI/CD с помощью Red Hat Ansible Automation Platform

  Контрольный список

  5 способов, которые инженеры по надежности сайта могут помочь вам

  Контрольный список

  6 Преимущества безопасности средах облачных вычислений

  Аналитик материал

  451 Отчет об исследовании. АНАЛИТИЧЕСКИЙ МАТЕРИАЛ

  Ускорение DevOps в государственном секторе

  Получите больше подобных материалов

  Подпишитесь на нашу бесплатную рассылку Red Hat Shares.

  Продолжить

  Agile-методология: что это такое, как она работает и почему это важно

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

  Вот где на помощь приходит Agile-методология.

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

  Что такое методология Agile?

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

  В учредительном документе под названием «Манифест Agile» группа изложила 4 ценности и 12 принципов, лежащих в основе философии Agile:0021 над процессами и инструментами.

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

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

12 принципов Agile

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

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

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

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

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

Вот лишь несколько ключевых преимуществ Agile-управления проектами и Agile-разработки:

Более активное участие и сотрудничество заинтересованных сторон  

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

Предсказуемые затраты и планирование

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

Гибкость в условиях изменений

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

Продукция более высокого качества

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

Снижение риска и более быстрый возврат инвестиций

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

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

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

Этапы методологии Agile

Существует 6 этапов жизненного цикла Agile:

1. Концепция

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

2. Начало

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

3. Итерация

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

Базовый рабочий процесс на этом этапе включает:

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

4. Выпуск

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

5. Производство

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

6. Вывод из эксплуатации

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

Примеры методологии Agile 

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

Scrum

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

Структура Scrum организована по ключевым ролям, событиям и артефактам:

Роли Scrum:

• Владелец продукта
• Скрам-мастер
• Команда разработчиков Scrum

События Scrum: 

• Ежедневный Scrum
• Совещание по планированию спринта 
• Обзор спринта
• Ретроспектива спринта

Скрам-артефакты:

• Задолженность по продукту
• Задел спринта
• Приращение (или цель спринта)

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

Канбан

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

• Визуализируйте свой рабочий процесс.
• Ограничить объем незавершенной работы.
• Организация рабочего процесса на основе приоритета.

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

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

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

Экстремальное программирование (XP)

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

Лучше всего применять, когда

• Постоянно меняющиеся требования
• У команд сжатые сроки
• Заинтересованные стороны хотят снизить риск в установленные сроки
• Команды могут автоматизировать модульные и функциональные тесты

Feature Driven Development

Feature Driven Development (FDD) — это ориентированный на клиента методологический инструмент Agile, ориентированный на инкрементную разработку и отчеты о состоянии на всех уровнях. Этот подход помогает предотвратить два самых больших препятствия в разработке программного обеспечения: путаницу и доработку.

FDD состоит из пяти основных шагов:

• Разработка общей модели
• Создание списка функций
• План по функциям
• Дизайн по элементу
• Сборка по функции

FDD — это масштабируемая модель, которая предоставляет функции в гораздо более короткие сроки, чем другие среды Agile. Например, вместо типичного 4-недельного цикла итерации в Scrum, FDD стремится предоставлять функции каждые 2-10 дней. Это облегчает командам отслеживание и устранение ошибок, адаптацию к запросам клиентов и быстрое информирование новых членов команды.

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

Что такое Agile-модель в тестировании программного обеспечения?

Что такое гибкая методология?

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

Гибкая методология

Что такое гибкая разработка программного обеспечения?

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

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

1. Индивидуальное и групповое взаимодействие по процессам и инструментам
2. Рабочее программное обеспечение поверх исчерпывающей документации
3. Сотрудничество с клиентами в ходе переговоров по контракту
4. Реагирование на переход по плану

Из этого руководства по управлению проектами Agile вы узнаете:

• Что такое методология Agile?
• Гибкая модель против модели водопада
• Скрам
• Бэклог продукта
• Скрам-практики
• Технологический поток методологий Scrum:
• Экстремальное программирование (XP)
• Фазы экстремального программирования:
• Кристаллические методологии
• Метод динамической разработки программного обеспечения (DSDM)
• Разработка, ориентированная на функции (FDD)
• Бережливая разработка программного обеспечения
• Канбан
• Гибкие показатели

Гибкая модель против модели водопада

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

Гибкая модель	Модель водопада
Определение методологии Agile: методологии Agile предлагают поэтапный и итеративный подход к разработке программного обеспечения	Водопадная модель: разработка программного обеспечения протекает последовательно от начальной точки к конечной.
Гибкий процесс в разработке программного обеспечения разбит на отдельные модели, над которыми работают дизайнеры	Процесс проектирования не разбит на отдельные модели
Клиент имеет ранние и частые возможности ознакомиться с продуктом и принять решение и внести изменения в проект	Заказчик может увидеть продукт только в конце проекта
Гибкая модель считается неструктурированной по сравнению с водопадной моделью	Модель Waterfall более надежна, потому что она ориентирована на планирование
Небольшие проекты можно реализовать очень быстро. Для больших проектов сложно оценить время разработки.	Все виды проектов могут быть оценены и завершены.
Ошибка может быть исправлена ​​в середине проекта.	Только в конце тестируется весь продукт. Если обнаружена ошибка требования или необходимо внести какие-либо изменения, проект необходимо начать с начала
Процесс разработки является итеративным, и проект выполняется короткими (2-4) недельными итерациями. Планирования очень мало.	Процесс разработки поэтапный, и эта фаза намного больше, чем итерация. Каждый этап заканчивается подробным описанием следующего этапа.
Документация имеет меньший приоритет, чем разработка программного обеспечения	Документация имеет высший приоритет и может даже использоваться для обучения персонала и обновления программного обеспечения с другой командой
У каждой итерации есть своя фаза тестирования. Это позволяет проводить регрессионное тестирование каждый раз, когда выпускаются новые функции или логика.	Только после этапа разработки выполняется этап тестирования, поскольку отдельные части не полностью функциональны.
При гибком тестировании по окончании итерации поставляемые функции продукта доставляются заказчику. Новые функции можно использовать сразу после отгрузки. Это полезно, когда у вас есть хороший контакт с клиентами.	Все разработанные функции предоставляются сразу после длительного этапа внедрения.
Тестировщики и разработчики работают вместе	Тестировщики работают отдельно от разработчиков
В конце каждого спринта выполняется принятие пользователем	Принятие пользователем выполняется в конце проекта.
Требуется тесная связь с разработчиками и совместный анализ требований и планирование	Разработчик не участвует в процессе требований и планирования. Обычно временные задержки между тестами и кодированием

Также проверьте:- Agile против водопада: знайте разницу между методологиями

Гибкий процесс

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

Модель гибкого процесса

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

Scrum

SCRUM — это метод гибкой разработки, который специально концентрируется на том, как управлять задачами в командной среде разработки. По сути, Scrum основан на действиях, происходящих во время матча по регби. Скрам верит в расширение прав и возможностей команды разработчиков и выступает за работу в небольших командах (скажем, от 7 до 9 человек). Agile и Scrum состоят из трех ролей, и их обязанности объясняются следующим образом:

Скрам-метод

Журнал невыполненных работ по продукту

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

Скрам-практики

Технологическая схема методологий Scrum:

Технологическая схема тестирования Scrum выглядит следующим образом:

• Каждая итерация схватки известна как спринт

  .

• Бэклог продукта — это список, в который вводятся все детали для получения конечного продукта

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

• Команда работает над определенным невыполненным заданием спринта

• Групповые проверки ежедневной работы

• В конце спринта команда обеспечивает функциональность продукта

Экстремальное программирование (XP)

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

Экстремальное программирование

Бизнес-требования собраны в виде историй. Все эти истории хранятся в месте под названием парковка.

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

Фазы экстремального программирования:

В методе Agile XP доступно 6 фаз, которые объясняются следующим образом:

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

• Определение заинтересованных сторон и спонсоров

• Требования к инфраструктуре

• Информация и сбор информации, связанной с безопасностью

• Соглашения об уровне обслуживания и их условия

Анализ

• Съемка историй на парковке

• Приоритет историй на парковке

• Очистка историй для оценки

• Определить интервал итерации (время)

• Планирование ресурсов для команд разработки и контроля качества

Дизайн

• Разбивка задач

• Подготовка сценария тестирования для каждой задачи

• Платформа автоматизации регрессии

Исполнение

• Код

• Модульное тестирование

• Выполнение сценариев ручного тестирования

• Генерация отчета о дефектах

• Преобразование ручных регрессионных тестов в автоматические

• Обзор середины итерации

• Обзор конца итерации

Упаковка

• Малые выпуски

• Регрессионное тестирование

• Демонстрации и обзоры

• Разработка новых историй на основе потребностей

• Усовершенствования процесса на основе комментариев по результатам проверки в конце итерации

Закрытие

Для ежедневного отслеживания работы доступны две раскадровки, которые перечислены ниже для справки.

Кристаллические методики

Методология Crystal основана на трех концепциях

1. Фрахтование: Различные действия, связанные с этим этапом, включают создание группы разработчиков, выполнение предварительного технико-экономического обоснования, разработку первоначального плана и тонкую настройку методологии разработки

2. Циклическая поставка: Основная фаза разработки состоит из двух или более циклов поставки, во время которых

   1. Команда обновляет и уточняет план выпуска
   2. Реализует подмножество требований посредством одной или нескольких итераций интеграции тестирования программы
   3. Интегрированный продукт поставляется реальным пользователям
   4. Обзор плана проекта и принятой методологии разработки
3. Подведение итогов: Действия, выполняемые на этом этапе, включают развертывание в среде пользователя, проверки и размышления после развертывания.

Метод динамической разработки программного обеспечения (DSDM)

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

1. Time Boxing
2. Московские правила
3. Прототип

Проект DSDM состоит из 7 этапов

1. Предпроект
2. ТЭО
3. Бизнес-исследование
4. Итерация функциональной модели
5. Проектирование и сборка, итерация
6. Реализация
7. Постпроект

Разработка, управляемая функциями (FDD)

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

1. Моделирование предметной области
2. Развитие по признаку
3. Компонент/принадлежность класса
4. Специализированные группы
5. Проверки
6. Управление конфигурацией
7. Обычные сборки
8. Видимость прогресса и результатов

Бережливая разработка программного обеспечения

Метод бережливой разработки программного обеспечения основан на принципе «Производство точно в срок». Он направлен на увеличение скорости разработки программного обеспечения и снижение стоимости. Бережливое развитие можно описать семью этапами.

1. Устранение отходов
2. Расширение обучения
3. Отложить принятие решения (принять решение как можно позже)
4. Ранняя поставка
5. Расширение возможностей команды
6. Обеспечение целостности
7. Оптимизировать все

Канбан

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

Скрам против Канбана

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

Также проверьте: — Канбан против. Скрам: в чем разница?

Метрики Agile:

Метрики, которые можно собрать для эффективного использования Agile:

• Коэффициент аэродинамического сопротивления

  • Усилия в часах, которые не способствуют цели спринта

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

  • Новые оценки могут быть увеличены на процент коэффициента аэродинамического сопротивления — Новая оценка = (Старая оценка + коэффициент аэродинамического сопротивления)

• Скорость

• Количество модульных тестов добавлено

• Интервал времени, необходимый для завершения ежедневной сборки

• Ошибки, обнаруженные в итерации или в предыдущих итерациях

• Утечка производственного брака

Что такое гибкая методология? — Обзор гибкой разработки программного обеспечения и гибких моделей

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

При этом Agile стремится решить проблемы, с которыми сталкиваются традиционные «водопадные» подходы к доставке крупных продуктов в течение длительных периодов времени, в течение которых часто меняются требования клиентов, что приводит к доставке неправильных продуктов.

Изучение Agile

• Применение Agile
• Что такое Agile Manifesto?
• 4 Core values ​​of Agile Manifesto
• 12 Principles of the Agile Manifesto
• Key Agile Methodologies
• Scrum Methodology
• Extreme Programming (XP)
• Adaptive Software Development (ASD)
• Dynamic Software Development Method (DSDM)
• Разработка, управляемая функциями (FDD)
• Канбан-метод
• Behavior Driven Development (BDD)

Применение Agile-методологии

На протяжении большей части своей короткой истории (с 1999-2000 гг. ) Agile был преимущественно подходом к разработке программного обеспечения и проектов разработки ИТ-приложений. Однако с тех пор он теперь распространяется и на другие области, особенно в сфере знаний и услуг.

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

Они делают это, разбивая традиционно длинный цикл доставки (типичный для устаревших «водопадных методов») на более короткие периоды, называемые спринтами или итерациями. Итерация обеспечивает ритм доставки рабочего продукта клиенту, получения отзывов и внесения изменений на основе отзывов.

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

«Аджилити в основном зависит от мышления, а не от практики». – Джим Хайсмит Click To Tweet

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

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

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

Что такое Agile-манифест?

Манифест Agile — это заявление об основных ценностях и принципах разработки программного обеспечения. Agile Manifesto для разработки программного обеспечения был создан в 2001 году и представляет собой декларацию из 4 жизненно важных правил и 12 принципов, которые служат руководством для людей, занимающихся гибкой разработкой программного обеспечения. Его создали 17 профессионалов, которые уже практиковали agile-методы, такие как XP, DSDM, SCRUM, FDD и т. д., собравшиеся в заснеженных горах американского штата Юта, созванные Кентом Беком.

Источник: LynneCazaly

4 Основные ценности Agile Manifesto

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

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

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

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

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

 

12 Принципов Agile-манифеста

• Нашей наивысшей задачей является удовлетворение клиента за счет быстрой и непрерывной поставки ценного программного обеспечения.
• Приветствуйте меняющиеся требования, даже на поздних стадиях разработки. Гибкие процессы используют изменения для конкурентного преимущества клиента.
• Доставляйте работающее программное обеспечение часто, от нескольких недель до нескольких месяцев, предпочитая более короткие сроки.
• Бизнесмены и разработчики должны ежедневно работать вместе на протяжении всего проекта.
• Создавайте проекты вокруг целеустремленных людей. Обеспечьте им необходимые условия и поддержку и доверьте им выполнение работы.
• Самый эффективный и действенный метод передачи информации команде разработчиков и внутри нее — беседа лицом к лицу.
• Работающее программное обеспечение является основным мерилом прогресса.
• Гибкие процессы способствуют устойчивому развитию. Спонсоры, разработчики и пользователи должны иметь возможность поддерживать постоянный темп на неопределенный срок.
• Постоянное внимание к техническому совершенству и хорошему дизайну повышает маневренность.
• Простота — искусство максимального увеличения объема незавершенной работы — имеет важное значение.
• Лучшие архитектуры, требования и проекты создаются самоорганизующимися командами.
• Через определенные промежутки времени команда размышляет о том, как стать более эффективной, а затем соответствующим образом настраивает и корректирует свое поведение.

Ключевые Agile-методологии

Agile — это общий термин для нескольких методов и практик. Давайте рассмотрим некоторые из популярных методологий:

• Scrum
• Экстремальное программирование (XP)
• Адаптивная разработка программного обеспечения (ASD)
• Метод динамической разработки программного обеспечения (DSDM)
• Разработка, управляемая функциями (FDD)
• Канбан
• Разработка, управляемая поведением (BDD)

Scrum

Методология Scrum — это простая рабочая среда 903 , и он был создан Кеном Швабером и Джеффом Сазерлендом.

Гибкие методологии разработки программного обеспечения являются итеративными, то есть работа делится на итерации, которые в случае Scrum называются спринтами. Scrum выполняется небольшими командами из 7-9 человек.человек, включая Scrum Master и Product Owner.

В Scrum проекты делятся на циклы (обычно двух- или трехнедельные циклы), называемые спринтами. Спринт представляет собой временной интервал, в течение которого должен быть разработан набор функций. Несколько спринтов могут быть объединены для формирования Релиза, когда осуществляется официальная поставка программного обеспечения/продукта клиенту/рынку.

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

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

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

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

Экстремальное программирование (XP)

Экстремальное программирование (XP) – или парное программирование – это методология, разработанная Кентом Беком в начале 90-х годов. Эта гибкая методология фокусируется на улучшении межличностных отношений как ключе к успеху в разработке программного обеспечения. XP также фокусируется на поощрении командной работы, заботе об обучении разработчиков и создании хорошей рабочей среды. Для него характерно, что разработчики работают парами, когда один разработчик программирует, а другой наблюдает; и они регулярно меняют эти роли на протяжении всего спринта. Таким образом, они обеспечивают непрерывную проверку кода и обратную связь, что повышает качество кода и возможности разработчиков.

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

Адаптивная разработка программного обеспечения (ASD)

Адаптивная разработка программного обеспечения (ASD) была разработана Джимом Хайсмитом и Сэмом Байером в начале 19 века.90-е. Он включает в себя принципы непрерывной адаптации, т. е. приспосабливаться к изменениям, а не бороться с ними . Адаптивная разработка программного обеспечения использует динамический цикл разработки, известный как Speculate, Collaborate, and Learn. Этот цикл посвящен постоянному обучению и интенсивному сотрудничеству между разработчиками и клиентами в связи с постоянными изменениями в бизнес-среде.

В отличие от большинства методологий разработки программного обеспечения, которые используют статический жизненный цикл, т. е. «Планирование-Проектирование-Сборка», ASD предлагает нелинейный итеративный жизненный цикл, где каждый цикл может повторяться и изменяться, пока выполняется другой цикл. Это указывает на быструю разработку приложений ( RAD ), в котором подчеркивается скорость разработки для создания высококачественного продукта с минимальными затратами на техническое обслуживание, максимально вовлекающего пользователя. Основные характеристики ASD:

1. Спекулят: Это этап инициации проекта, на котором необходимо установить основные цели и задачи проекта, поняв ограничения (зоны риска), с которыми работает проект.
2. Совместная работа: На этом этапе сосредоточена большая часть разработки, поддерживая координацию между командами, которая гарантирует, что то, что изучено одной командой, передается остальным и не требует повторного изучения другими командами с нуля. .
3. Узнать: Последний этап заканчивается серией циклов сотрудничества – задача состоит в том, чтобы зафиксировать то, что было изучено, как положительное, так и отрицательное. Этот этап имеет решающее значение для эффективности проекта.

«В agile-проекте команда занимается задачами, а руководитель проекта заботится о команде». – Джим Хайсмит Нажмите, чтобы твитнуть

Метод динамической разработки программного обеспечения (DSDM)

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

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

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

Feature Driven Development (FDD)

Методология Feature Driven Development (FDD) в основном ориентирована на более крупные команды с большим количеством людей, чем те, к которым обычно применяются другие гибкие методологии, такие как Scrum. FDD был разработан Джеффом Де Лукой и Питером Коудом в 19 году.97. Эта методология ориентирована на короткие итерации, которые позволяют получить ощутимые поставки продукта за короткий период времени (2 недели).

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

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

Одна из самых популярных книг по методу FDD была опубликована Стивеном Палмером в 2002 году под названием «Практическое руководство по функционально-ориентированной разработке».

Канбан-метод

Канбан-метод был определен Дэвидом Андерсоном в начале-середине 2000-х годов в ответ на некоторые вызовы различных методов Agile, особенно Scrum. Эти методы, пытаясь решить проблемы традиционных/водопадных методов, сами стали жертвами некоторых из тех же проблем.

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

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

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

Канбан определяется как высокоэффективная и действенная производственная система. Происхождение методологии Канбан лежит в производственных процессах «точно вовремя» (JIT), разработанных Toyota, в которых карты использовались для определения потребностей в материалах в производственной цепочке. Вы можете узнать больше о канбане здесь: https://www.digite.com/kanban/what-is-kanban/

Разработка, управляемая поведением (BDD)

Разработка, управляемая поведением (BDD) — это методология гибкой разработки, ориентированная на поведение. Он был создан Дэном Нортом в 2003 году как развитие методологии TDD. Дэн Норт стремился объединить людей, не являющихся техническими специалистами, в процессе создания технической функциональности системы. Бывает, что когда мы разрабатываем программное обеспечение, мы невольно не включаем бизнес-концепции, присутствующие в функционале, что приводит к возможному потоку повторяющихся и даже серьезных ошибок.

Источник: Johnfergusonsmart.com

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

No related posts.