Agile — Вопрос по проектированию приложений


Содержание

Agile — Вопрос по проектированию приложений

Текст: Дмитрий ПАРАМОНОВ, Валерий ФУНТОВ, Сергей МАЛОЗЕМОВ, Жанна ПРУСОВА

Впервые в атомной отрасли России для решения сложных инженерных задач была применена Agile-методология управления проектами. Это позволило в рекордные сроки оптимизировать компоновку ядерного острова АЭС «Ханхикиви‑1», сократив объем зданий более чем на четверть. Об опыте применения Agile — в материале, подготовленном специалистами ИК «АСЭ».

Иллюстрация: Влад СУРОВЕГИН
Фото: Собственность автора

Серийный дизайн-проект АЭС поколения III+, разработанный инжиниринговым дивизионом ГК «Росатом», отвечает действующим российским нормам и правилам.

С минимальными изменениями этот дизайн-проект может быть реализован в большинстве стран мира, допускающих сооружение АЭС по российским нормам (Египте, Китае и других). Но при выходе с данным проектом на европейские рынки потребовалась его глубокая адаптация в части гармонизации российских и европейских норм. Кроме того, в связи со значительным увеличением физических объемов зданий ядерного острова по сравнению с референтной Ленинградской АЭС‑2, возникла необходимость в оптимизации дизайн-проекта.

В этой работе участвовали технические специалисты различных проектных институтов группы компаний ИК «АСЭ». На оптимиза-цию проекта было дано всего три месяца. Учитывая сверхсжатые сроки, на основе накопленного опыта было принято решение впервые в ГК «Росатом» использовать гибкие методологии Agile в виде Scrum.

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

В комплексе работ по оптимизации были применены следующие базовые и адаптированные принципы Agile:

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

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

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

Манифест Agile:
1. Главное — люди, а не вещи.
2. Документация не должна никому мешать работать.
3. Сотрудничайте, а не перечитывайте контракт.
4. Живите, меняйтесь — так быстро, как возможно.

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

Технический лидер отвечал за расстановку приоритетов, за качество разработанных группой технических решений, осуществлял взаимодействие между командой, представителем заказчика и техническими специалистами, совместно с Администратором планировал спринты и разработку отчетной документации.
Было организовано масштабирование управления (Scrum of Scrums): назначены Старший администратор и Главный технический лидер, которые по правилам Scrum определяли основные направления оптимизации, согласовывали технические решения, решали административные вопросы.

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

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

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

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

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

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

4. Необходимо правильно и последовательно применять инструменты Agile: «Журнал требований проекта» (Product Backlog), «Журнал требований к итерации» (Sprint Backlog), ежедневные встречи (Daily Scrums), «Обзор итерации с заказчиком» (Review with Customer), «Анализ итерации» (Retrospective).

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

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

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

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

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

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

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

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

Валерий Фунтов,
проф., д. э. н., PMP, Бизнес-школа ИМИСП

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

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

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

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

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

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

Еще одним полезным инструментом оказалась таблица сбора фактов — интерактивный список задач на итерацию с указанием их исполнителей и возможностью выбора процента выполнения (Burning Curve). Использование таблицы позволило сократить затраты времени на ежедневную актуализацию статуса разрабатываемых командой задач.

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

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

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

В результате выполнения комплекса работ по оптимизации точно в срок была достигнута основная цель проекта — объем зданий ядерного острова АЭС «Ханхикиви‑1» был снижен на 26%. Было сокращено количество технологических систем и оборудования, оптимизированы компоновка помещений и структура генплана, предложены новые меры по физзащите зданий. Все эти результаты были достигнуты без снижения надежности и безопасности АЭС.

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

Из положительных эффектов внедрения Agile можно отметить следующие:

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

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

Что такое Agile?

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

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

История Agile

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

В 1990-х годах был разработан ряд гибких методов разработки программного обеспечения в ответ на преобладающие тяжеловесные методы. К ним относятся: с 1991 года — RAD (быстрая разработка приложений); с 1994 года — метод разработки динамических систем (DSDM); с 1995 года — Scrum; С 1996 года, Crystal Clear и экстремальное программирование (XP); А с 1997 года — Feature driven development (FDD). Хотя они возникли до публикации Манифеста Agile Software Development, они все вместе называются гибкими методами разработки программного обеспечения.

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

Манифест Agile

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

4 идеи Agile
  1. Люди и взаимодействие важнее процессов и инструментов.
  2. Рабочее программное обеспечение важнее документации.
  3. Сотрудничество с клиентами важнее согласования условий контракт.
  4. Готовность внести изменения в приоритете, нежели придерживаться первоначального плана.
12 принципов Agile
  1. Удовлетворенность клиентов за счет ранней и непрерывной поставки программного обеспечения. Клиенты более счастливы, когда они получают рабочее программное обеспечение через регулярные промежутки времени.
  2. Вносить изменения требований к продукту на протяжении всего процесса разработки.
  3. Частая поставка рабочего программного обеспечения (каждый месяц, две недели, неделю и т.д.).
  4. Сотрудничество между заинтересованными сторонами (заказчиком и разработчиками) на протяжении всего проекта.
  5. Поддержка, доверие и мотивация вовлеченных людей. Мотивированные команды с большей вероятностью выполняют свою лучшую работу, чем сотрудники, недовольные условиями труда.
  6. Взаимодействие лицом к лицу. Коммуникация более успешна, когда команды разработчиков имеют возможность общаться напрямую.
  7. Рабочее программное обеспечение является основной мерой прогресса. Предоставление функционального программного обеспечения клиенту является конечным фактором, который измеряет прогресс.
  8. Поддержка постоянного темпа работы. Команды устанавливают повторяемую и поддерживаемую скорость работы, с которой они могут доставлять функционирующее программное обеспечение.
  9. Внимание к техническим деталям и дизайну. Правильные навыки и хороший дизайн позволяют команде поддерживать темп, постоянно совершенствовать продукт и работать над изменениями.
  10. Простота.

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

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

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

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

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

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

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

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

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

SCRUM

Scrum — это методология управления проектами, в основе которой делается акцент на качественном контроле процесса работы. Хиротака Такэути и Икудзиро Нонака — первые, кто описал подход Scrum, объяснили его как “подход регби”, в котором scrum — это борьба за мяч. Сам метод представляет собой процесс разработки, разделенный на небольшие итерации — спринты, по завершении которых пользователи получают улучшенный вариант ПО. Спринт жестко фиксирован по времени, а его длительность составляет от 2 до 4 недель. Работа в рамках одного спринта состоит из нескольких этапов:

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

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

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

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

Kanban

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

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

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

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

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

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

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

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

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

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

Недостатки

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

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

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

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

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

Внедрение Agile

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

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

Что нужно учесть при проектировании своего приложения

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

Упростите жизнь разработчикам

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

Что упростит разработчику жизнь:

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

Уделите внимание мелочам

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

Помните о юзабилити

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

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

Обеспечьте безопасность

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

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

Обеспечьте надёжность


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

  • Очевидно, что в системе не должно происходить сбоев, но всё же они происходят. Нужно обеспечить журналирование и анализ таких сбоев;
  • Система должна быть максимально автономной — если произошёл сбой, будет идеально, если она сама с этим справится;

AGILE – гибкая система управления проектами

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

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

Метод Agile: определение и краткая история

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

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

На основе этого в 90-х удалось создать комплекс гибких методов разработки ПО, способных заменить сложные и трудоемкие методы. Происходило это так:

  • В 1991 году появился метод быстрой разработки приложений RAD
  • В 1994 году появился метод разработки динамических систем DSDM
  • В 1995 году появилась платформа (фреймворк) гибкой разработки Scrum
  • В 1996 году появилась гибкая методология разработки Crystal Clear, а также экстремальное программирование XP
  • В 1997 году появилась итеративная методология разработки ПО FDD

Все вместе эти методы объединились под общим названием гибких методов разработки ПО.

Четыре года спустя – в 2001 году в штате Юта (США) на курорте Snowbird собрались семнадцать разработчиков программного обеспечения. В результате обсуждения методов разработки был опубликован «Манифест о гибкой разработке программного обеспечения Agile» (в переводе с английского понятие «agile» означает «подвижный», «проворный» или «быстрый», но в большинстве случаев его переводят именно как «гибкий»). Он и задал темп всей дальнейшей работе над созданием ПО.

Манифест Agile

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

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

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

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

Ключевые моменты в применении Agile

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

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

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

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

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

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

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

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

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

  • Что я делал вчера?
  • Чем я буду занят сегодня?
  • Что мешает мне работать?

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

  1. Четко обозначается значение проекта
  2. В процессе реализации активно участвует клиент
  3. Общий объем работ выполняется пошагово
  4. Ориентироваться следует на конкретный результат
  5. Численность одной рабочей группы: от 7 до 9 человек

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

Примеры: правительство Новой Зеландии, правительство Нигерии, Норвежский пенсионный фонд, компания Return Path (программное обеспечение), компания Oreo (производство печенья), компания Aviasales (крупнейший поисковик авиабилетов), компания Hewlett-Packard (крупнейшая американская IT-компания), «Сбербанк» (наверное, знаете, что это).

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

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

Существует немало методов проект-менеджмента, которые применяются разными современными компаниями. Но самыми известными и востребованными среди них по праву считаются Scrum (Скрам) и Kanban (Канбан).

Метод Scrum

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

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

  • Определяются объемы работы
  • Каждый день проводятся 15-минутные встречи, чтобы члены команды могли скорректировать свою работу и подвести промежуточные итоги
  • Демонстрируются полученные результаты
  • Спринты обсуждаются для поиска удачных и неудачных решений и действий

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

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

Метод Kanban

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

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

Цукерберг рекомендует:  О пользе стажировки и одном стартапе

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

Это лишь примеры основных методов управления проектами, основанных на Agile. Но не стоит пренебрегать и другими методами, такими как PRINCE2, Lean, Six Sigma, XP, CCPM, ECM, Waterfall и другие. К тому же у Аджайл, наряду с преимуществами, есть и некоторые недостатки.

Плюсы и минусы Agile

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

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

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

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

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

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

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

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

Внедрение Agile

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

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

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

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

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

Заключение

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

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


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

Хотя этот процесс начался намного раньше, официально agile-движение существует с момента принятия Agile-манифеста в феврале 2001 г. (Beck et al.). Манифест был разработан и подписан 17 «идеологами облегченных методологий», как они называли себя в то время. Их документ дал и название проповедуемому ими подходу к разработке программного обеспечения, и заявления о ценностях. Авторы Agile-манифеста писали о том, что для них более значительную ценность имеют:

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

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

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

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

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

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

Agile-подход к проекту

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

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

Agile-команда работает как единое целое

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

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

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

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

Последняя роль — руководитель проекта. Как пишет Хайсмит (Highsmith, 2004a), роль руководителя проекта изменяется в случае применения agile-подхода. Руководители agile-проектов концентрируют внимание больше на лидерстве, а не на менеджменте. В некоторых agile-проектах лицо, выполняющее роль руководителя проекта, выступает также и в другой роли: нередко как разработчик, а иногда как владелец продукта.

Работа agile-команды разбивается на короткие итерации

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

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

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

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

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

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

Agile-команда фокусируется на бизнес-приоритетах

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

Во-вторых, agile-команды фокусируются на разработке и поставке ценных для пользователей функций, а не на выполнении изолированных задач (которые в конечном итоге объединяются в ценную для пользователей функцию). Одним из лучших подходов к этому является работа с пользовательскими историями, которая представляет собой облегченную методологию представления требований к программному обеспечению (Cohn, 2004). Пользовательская история — это краткое описание функциональности с точки зрения пользователя или клиента системы. Пользовательские истории излагаются в свободной форме, какие-либо синтаксические правила их составления отсутствуют. Тем не менее в целом неплохо придерживаться следующей формы: «Как я хочу с тем, чтобы ». Воспользовавшись этим шаблоном, можно написать, например, такую историю: «Как покупатель книг я хочу осуществлять их поиск по номеру ISBN с тем, чтобы быстро отыскивать нужное издание».

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

Agile-команда проверяет и модифицирует

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

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

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

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

Agile-подход к планированию

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

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

Мы зачастую не учитываем эти новые знания и не планируем возможность их получения. Как результат, процесс планирования строится на допущении о том, что нам уже известно все необходимое для получения точного плана. В мире разработки программного обеспечения такое случается редко, если вообще случается. Уорд Каннигем заметил, что «это больше планирование того, что вы хотите узнать, а не того, что [продукт] получится в конце» (Van Schooenderwoert, 2004).

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

Многоуровневость планирования

При постановке задач и их пересмотре важно помнить, что мы не можем видеть дальше горизонта и что точность плана быстро снижается по мере того, как мы все дальше уходим за черту, до которой видим. Допустим, вы стоите на палубе небольшого судна и ваши глаза находятся на высоте 2,7 м над уровнем воды. Расстояние до горизонта в этом случае составляет примерно 6 км. Если вы планируете 30-километровое путешествие, то вам необходимо составить план на перспективу как минимум в пять раз дальше горизонта, который составляет 6 км. Поскольку вы не можете видеть дальше горизонта, нужно периодически осматриваться и корректировать свой план.

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

Рис. 1. Луковица планирования; agile-команды составляют планы как минимум на уровне релиза, итерации и текущего дня

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

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

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

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

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

Состояние удовлетворенности

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

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

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

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

Рис. 2. Условия удовлетворенности определяют ход планирования релиза и итерации

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

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

  • Пользователь, который аннулирует заказ более чем за 24 часа, получает полное возмещение своих средств.
  • Пользователь, который аннулирует заказ менее чем за 24 часа, получает возмещение своих средств за вычетом комиссии в размере $25.
  • Условия аннулирования заказа размещаются на сайте и высылаются пользователю по электронной почте.

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

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

Резюме

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

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

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

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

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

Вопросы для обсуждения

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

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

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

Методология Agile: преимущества, пути внедрения и подводные камни


Вопросы, рассмотренные в материале:

  1. Что явилось предпосылками для разработки гибкой методологии управления проектами Agile
  2. Каковы преимущества и недостатки методологии Agile
  3. Какие инструменты входят в концепцию методологии Agile
  4. Как внедрить Agile-методологию и не похоронить компанию

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

Как появилась Agile-методология управления проектами

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

Раньше любой программный продукт мог появиться, только совершив определенный путь:

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

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

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

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

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

Для систематизации и объединения в одно целое всех подходов к управлению проектами (а их на тот момент насчитывалось больше десяти) разработчики, внедрившие разные «гибкие методы», собрались вместе – всего 17 человек.

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

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

Технологии для маркетинга

Михаил Дашкиев, сооснователь Бизнес Молодости:

«Технологии меняются. Целевая аудитория меняется. Маркетинг меняется. Поэтому развивается тот, кто успевает использовать восходящие тренды.

Взгляните на цифры

– 5,5 часов в день средний взрослый пользователь проводит в интернете. (По данным Distill Networks, 2015).

– Количество пользователей, блокирующих рекламу, выросло на 124%: с 54 до 121 млн. (По данным Ad Blocking Goes Mainstream, PageFair. 2015).

– Молодёжь проводит на 40% больше времени в мессенджерах, чем в социальных сетях. (По данным Attention Spans: Consumer Insight, Microsoft, 2015).

– 59% трафика генерируют чат-боты. (По данным Distill Networks, 2015).

– 65% пользователей не устанавливают новые приложения. (По данным Attention Spans: Consumer Insight, Microsoft, 2015).

– Продолжительность концентрации внимания сократилась на 30%: с 12 до 8 сек. (По данным Attention Spans: Consumer Insight, Microsoft, 2015).

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

Цукерберг рекомендует:  Помощь - Нужен совет по разработке мобильного сайта на конструкторе

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

Выйти на новый уровень проще, чем кажется. Убедись в этом сейчас — https://start.molodost.bz

Философия и принципы Agile-методологии

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

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

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

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

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

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

В основе метода гибкого управления проектами несколько важных составляющих:

  1. Наглядный контроль. По ходу работы над проектом все его участники пользуются разноцветными карточками нескольких разновидностей, каждая из которых – это своеобразный знак, показывающий стадии готовности элементов конечного продукта (что разработано, что спланировано, что завершено и т. д.). Благодаря таким сигналам команда всегда видит реальную ситуацию по продвижению проекта. Причем с помощью данного контроля обеспечивается одинаковая для восприятия всеми участниками общая «картина».
  2. Все задействованные в проекте лица, в том числе клиент, трудятся рядом. Такой принцип, во-первых, позволяет ускорить рабочие процессы (например, связанные с донесением информации до каждого участника общего дела), во-вторых, создает хорошие предпосылки для сотрудничества и продуктивной деятельности.
  3. Адаптируемое управление. Тот, кто стоит во главе проекта, не просто человек, номинально спускающий директивы, а реальный лидер, который определяет ключевые правила выполнения работы и взаимодействия.
  4. Работа в команде. Руководитель, участники проекта и заказчик действуют совместно – благодаря этому исключается возможность искажения информации и непонимания целей. Все рабочие процессы отличаются прозрачностью, что позволяет нивелировать возникающие проблемы и принимать оптимальные решения.
  5. Дробление общего объема работы на несколько отдельных частей. Такой подход к делу существенно упрощает задачи проекта, давая возможность членам команды сконцентрировать усилия на каждой составляющей.
  6. Работа над ошибками. В процессе одного цикла участники команды овладевают новыми навыками и проводят тщательный анализ случившихся ошибок – это помогает исключить их в следующем цикле.
  7. Спринты и кратковременные встречи каждый день. Спринты (временные отрезки, в течение которых команда решает круг задач) дают возможность отчетливо наблюдать за результатами. Если разбить период работы над проектом на спринты, можно получить, к примеру, 10 спринтов продолжительностью две недели каждый. А лучше спланировать индивидуальный план помогут регулярные ежедневные встречи минут на 10–15, чтобы каждый участник команды мог сам себе дать ответ на 3 вопроса: чем я занимался вчера, что буду делать сегодня и что мне не дает выполнять работу?

Итак, чтобы внедрить гибкий метод Agile, должны быть соблюдены условия:

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

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

Какие преимущества дает компании работа по методологии Agile

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

1. Обычный хлебозавод в России

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

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

2. Agile-хлебозавод в России

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

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

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

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

В России принципы гибкого управления используются такими компаниями, как:

  • «Альфа-банк»;
  • «Додо пицца»;
  • бухгалтерский сервис «Кнопка».

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

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

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

Недостатки методологии Agile

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

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

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

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

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

4 мифа про применение методологии Agile

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

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

Спустя 15 минут генеральный, закричав, что демократия закончилась и вернулась диктатура, приступил к раздаче распоряжений, а подчиненные начали старательно записывать их. Изумленный японский гость только и сумел произнести: «Какое же это agile-управление проектами? В Японии каждый рабочий завода может остановить конвейер и внести свои коррективы, не говоря уже об идеях на планерках…» На что получил ответ директора: «Да, это не принципы эджайл! Это Россия, здесь такие гибкие методы не действуют!»

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


Миф № 1: Методология Agile применима для всех проектов

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

Миф № 2: Методология Agile не приемлет ведения документации

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

Миф № 3: Методология Agile и планирование несовместимы

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

Миф № 4: При внедрении методологии Agile требуется много переделывания (re-work)

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

Часто задаваемые вопросы про методологию Agile

  1. Подходит ли Agile малому бизнесу?

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

Легко ли внедрить методологию Agile?

Встречный вопрос: легко изучить незнакомый язык? Привить компании новую философию быстро не получится. Для этого требуется много времени и постепенные шаги.

Изменятся ли бизнес-процессы в компании после внедрения гибкой методологии управления?

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

Как станут работать люди?

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

Кто должен быть начальником?

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

Владимир Тарасов. Искусство управления:

Краткое описание основных методологий Agile: Scrum, Kanban, Lean

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

Методология Scrum представляет собой такое управление, где основной акцент делают на качестве контроля за ходом работы. Первыми теоретиками, описавшими данный принцип, были Хиротака Такэути и Икудзиро Нонака. Они сравнили Scrum с регби, назвав его борьбой за мяч.

Еще один исследователь, Джефф Сазерленд, написавший книгу «Scrum.

Революционный метод управления проектами», выделяет 8 шагов, которые помогут освоить и использовать данную методику:

  1. Выбрать того, кто владеет продуктом, – ему известна цель проекта и ожидаемый результат.
  2. Собрать команду – нужно около 10 человек, обладающих навыками, которые требуются для создания конкурентного продукта.
  3. Найти скрам-мастера – он будет следить за рабочим процессом и помогать команде проекта преодолевать трудности.
  4. Составить бэклог продукта – разместить на Agile-доске приоритеты по каждому из требований к продукту. Здесь большая роль отводится владельцу продукта: он должен собрать все пожелания, чтобы команда оценила бэклог.
  5. Запланировать спринты (итерации) – определить временные отрезки, которые отводятся для выполнения конкретных задач.
  6. Организовать ежедневные «мит-апы» продолжительностью 15 минут – для опроса каждого участника команды по трем пунктам: что делал вчера, чем занимается сегодня и что мешает выполнению задачи.
  7. Делать обзоры рабочих частей продукта – к просмотру и обсуждению должны быть привлечены стейкхолдеры.
  8. Проводить ретроспективу – обсуждать проблему и поиск путей решения по окончании каждого спринта. План с полученными коррективами реализуется на следующем спринте.

Итак, Scrum – это процесс разработки, разделенный на спринты (небольшие итерации), по истечении которых пользователям отдают улучшенный вариант ПО. У спринта есть жесткие временные границы, а продолжительность его – от 2 до 4 недель.

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

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

Как правило, проектные методологии управления Аgile и Scrum применяют для разработки сложных ПО и продукта с использованием итеративных и инкрементных методов.

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

С помощью Scrum:

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

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

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

Этапы могут быть такими, как в традиционном проектном менеджменте:

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

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

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

Сильные стороны Lean

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

Слабые стороны Lean

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

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

Процесс Kanban нацелен на помощь в организации более эффективной командной работы. Kanban в переводе с японского означает «рекламный щит, вывеска». Метод заимствован у производственной системы «Тойота» и адаптирован под другие. В чем суть? Kanban призван обеспечить максимальную прозрачность процесса разработки и равномерное распределение нагрузки между всеми участниками команды. «Канбан» подстегивает к укреплению сотрудничества, способствует стремлению активно развиваться, совершенствовать знания и навыки.

В основе метода Kanban лежат три принципа:

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

«6 сигм» (SIX SIGMA)

Так же, как и «Тойота», свою лепту в развитие мирового проектного управления внесла компания «Моторола». Один из ее инженеров, Bill Smith, разработал в 1986 году концепцию «6 сигм». Она представляет собой более структурированную, чем Kanban, версию Lean, куда вошло дополнительно больше планирования для экономии ресурсов, повышения качества, уменьшения бракованного материала и разного рода проблем.

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

Для этого предлагается путь, включающий 5 шагов, известных как DMEDI:

Шаг 1. Определение (Define). Начальный этап очень схож с ранними этапами других систем проектного управления. Здесь определяются с содержанием проекта, аккумулируют информацию о его предвестниках, задают цели.

Шаг 2. Измерение (Measure). Six Sigma направлена на сбор и анализ качественных сведений о проекте. На этом этапе решают, от каких показателей будет зависеть успех дела и какую информацию потребуется собрать и оценить.

Шаг 3. Исследование (Explore). На этапе исследования менеджер проекта должен решить, каким путем команда придет к поставленным целям и удовлетворит все требования в срок, придерживаясь бюджетных рамок. Особую ценность здесь имеет нешаблонное мышление руководителя проектов, когда требуется разрешить возникшие проблемы.

Шаг 4. Разработка (Develop). Данный этап нужен для того, чтобы реализовать все задуманное ранее. Необходимо осознавать, что тут не обойтись без детального плана, содержащего описание всех действий, которые нужны для достижения целей. На этом же этапе оценивают прогресс проекта.

Шаг 5. Контроль (Control). Это главный этап в методологии Six Sigma. Ключевая задача – долгосрочное улучшение процессов реализации проектов. На данном шаге требуется тщательно документировать все усвоенные уроки, анализировать собранные сведения и уметь грамотно воспользоваться приобретенными знаниями как в проектах, так и вообще в компании.

Six Sigma и Kanban сильно похожи, если рассматривать их с установленными этапами реализации задач (планирование, определение целей, тестирование качества). Скорее всего, при использовании «6 сигм» команде придется встречаться чаще, чем при «Канбан», но процесс реализации проектов однозначно будет отличаться большей структурированностью, а участникам труднее будет сбиться с намеченного пути. К тому же «6 сигм», как «Канбан», несложно адаптировать под нужды конкретной компании или команды. Единственное категоричное требование – скрупулезно измерять и контролировать показатели проекта на этапах реализации, без этого планомерное долгосрочное улучшение процессов реализации немыслимо.

Сильные стороны «6 сигм»

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

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

Слабые стороны «6 сигм»


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

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

Какие еще гибкие Agile-методологии управления проектами применяются на практике

1. eXtreme Programming (XP)

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

Сфера применения – исключительно разработка ПО.

Внимание сфокусировано на 4 процессах:

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

2. Crystal Methodologies

Представленное семейство методологий нельзя назвать широко распространенным на просторах проектного менеджмента России. Автор методики – Алистер Кокберн, который создал «Манифест гибкой разработки ПО». Предлагаемая Кокберном классификация – по цветам в зависимости от количества участников команды: от 2 (Crystal Clear) до 100 (Crystal Red). Для более масштабных проектов предусмотрены цвета Maroon, Blue и Violet.

3 основных показателя, каким должны отвечать Crystal-проекты:

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

Все детали, касающиеся данного семейства методологий, можно рассмотреть в книге Алистера «Crystal Clear: A Human-Powered Methodology for Small Teams».

3. Dynamic Software Development Method (DSDM)

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

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

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

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

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

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

4. Feature Driven Development (FDD)

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

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

Feature Driven Development включает цикличные этапы:

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

5. Lean Software Development

Точнее было бы сказать о Lean Software Development не методология, а принципы бережливого производства – они нацелены повысить эффективность процесса разработки и сократить затраты.

В совокупности их 7:

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

Как определить эффективность той или иной методологии управления Agile применительно к вашей компании

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

Большинство проектов может обойтись следующими направлениями метрик:

  1. Производительность – сюда подойдут Velocity и WIP (первая применима не для любых проектов, потому что измеряет, сколько выполнено задач в итерацию, а они неравнозначны, метрикой Work-in-Progress определяют лимит задач на разных стадиях: чем выше, тем хуже).
  2. Прогнозирование метрика Сapacity (определяется количество идеальных часов, доступных в следующем спринте, благодаря чему можно понять: какое время отводится для работы, насколько эффективно выполняются задачи, как спланировать их количество для спринта).
  3. Качество – к примеру, индекс стабильности требований (его можно рассчитать по формуле: <Общее количество оригинальных бизнес-требований + Число требований, которые изменились к данному времени + Число добавленных требований + Число удаленных требований>/ <Общее число оригинальных требований>; метрика помогает вычислить время, потраченное на переделывание задач).
  4. Ценности – просчитываются индивидуально в каждом случае и зависят от формата проекта (скажем, для стартапа AirBnb метрикой, определяющей ценность продукта для пользователей, стал объем загруженных фото высокого качества – с его увеличением пропорционально росло число потребителей).

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

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

Как радикально изменить жизнь:

Особенности внедрения методологии Agile

Есть сотни примеров небольших и крупных компаний, как, например, Spotify, Netflix, которые с самого начала использовали Agile и пришли к успеху. Немало и тех, что внедряли гибкие методы вместо традиционной иерархии не сразу (вспомним Amazon и USAA – компанию, оказывающую финансовые услуги для военного сообщества). Есть также опыт реорганизации процессов, от которой не было пользы.

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

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

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

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

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

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

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

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

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

Вместо планирования запускается первый поток agile-команд, осуществляется анализ их работы для следующего шага. Это способствует объективной оценке:

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

Если налицо выгода, дают старт следующей волне гибких команд, в противном случае проводится анализ: как сделать работу более продуктивной (например, по-другому расставить приоритеты, повысить качество прототипов или пригласить опытных специалистов по Аgile).

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

  • стратегическое значение,
  • рамки бюджета;
  • издержки;
  • риски и т. д.

Главное – помнить про «боли» клиентов и сотрудников, с одной стороны, и про ограничения компании – с другой. Так будет выдержан баланс и придет понимание: сколько гибких команд компании по силам запустить и поддержать.

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

На смену им пришли agile-отряды: примерно 40 процентам сотрудников предстояло вступить на новые рабочие места, кардинально изменив свое мышление (подробнее: «One Bank’s Agile Team Experiment» HBR, March–April 2020).

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

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

По мнению Джеффа Безоса, основателя и главы Amazon, на полную отдачу уходит от 5 до 7 лет, но маркеры позитивных перемен появляются быстро: работа с клиентами упрощается, продукция выпускается быстрее.

Компания SAP (специализация – корпоративное ПО) приступила к внедрению Agile 10 лет назад. Топ-менеджеры сформировали немногочисленную группу, она занималась консультациями и обучением новым способам деятельности. Создали также трекер результатов команд.

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

Чек-лист, который поможет понять, что команде пора переходить на Agile:

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


С какими трудностями придется столкнуться при внедрении Agile и гибких методологий работы

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

    Эджайл – не инструмент

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

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

Свой нос в чужие дела

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

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

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

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

Введение

Недавно задал вопрос:

Ближайшие 2 ответа были примерно следующими:

«Аджайл работает только если заказчик готов таким образом работать. . Но если заказчик так работать не готов, то лучше и не связываться.» (ответ от @Qwertiy)

Наиболее часто требования меняются. «Во всех более-менее крупных разработках я только пару раз работал не с Agile . когда заказчик выдавал действительно законченные ТЗ. . Во всех остальных работах что-то постоянно менялось (иногда сильно, . иногда слабо . ). » (ответ от @avp)

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

Не получается ли так, что: сначала реализуются одни требования -> потом приходят новые -> ломается часть сделанного -> на этой уже кривой основе строится что-то новое -> и в итоге получается «крокодил»?

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

Вопрос

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

Уточнение вопроса

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

Интересны любые советы, мысли, наблюдения, выводы из опыта.

Update:

Очень интересны краткие описания технических решений. Например, из имеющихся ответов: скрывать старый функционал за Фасадами. Или использовать Агрегаты в БД по принципам DDD.

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

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

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

Всплывают в уме термины TDD, BDD. Какое им место при проектировании и реализации?

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

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

Расширенная форма предыдущего пункта. Допустим, есть уже основа из старого ПО, над которым надо делать новый функционал. Как часто бывает, по хорошему, старое надо конкретно, структурно модифицировать, прежде чем надстраивать новое (или вообще выкинуть старое). Старое уже как бы мертвое, но пока используется. Единственная возможность, как мне кажется, как ботаники делают, к старому стволу прилепить маленькую веточку нового, чтобы она прижилась и выросла в новое дерево. То есть с помощью какого-нибудь технического приема использовать старую систему, как черный ящик или как ресурс новой системы. Если не находится красивых/хороших проектных решений по модификации или по таким выходам из ситуации, как ботаники делают, то не является ли это ранним признаком провала проекта в долгосрочной перспективе?

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

4 ответа 4

Краткое изложение моего опыта.

Я Proxy Product Owner / техдиректор на SaaS проекте, который разрабатывается по SCRUM. Я же и занимался внедрением SCRUM на проект около 6-7 лет назад.

Проект с историей (живет больше 12 лет), с несколькими сменами целевых ниш, 2 попытками переписать с нуля.

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

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

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

Иначе не взлетит.

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

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

  • процесс разработки (анализ требований, планирование, взаимодействие людей)
  • абстрактный подход к архитектуре (TDD/BDD/DDD и прочие DD)
  • какие-то конкретные технические решения конкретно вашей проблемы (старый проект, черный ящик и все такое)

это ортогональные понятия.

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

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

  • Individuals and interactions over Processes and tools
  • Working software over Comprehensive documentation
  • Customer collaboration over Contract negotiation
  • Responding to change over Following a plan.

Проблема с этим манифестом в том, что он просто озвучивает здравые мысли. Вполне применимые в том же водопаде.

Как этот манифест контролирует, в какой момент вам надо «делать базу» и как «работать с заказчиком»? Да вообще никак.

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

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

Попробую написать своё видение, но оно очень субъективно.

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

От кода тут практически ничего не зависит. Главное условие — код не должен быть страшной лапшой без признаков ООП. Всё остальное вполне исправимо. Максимально используйте основной плюс — обратную связь. Всё, что делается, должно быть как можно раньше показано если не пользователям, то хотя бы аналитику\PO\заказчику. Все их отзывы — обрабатывайте, решая какие из них важны для продукта, а какие — блажь и не нужны. Ну и, кто-то главный (PO обычно) должен держать в голове всегда виденье продукта целиком. Не каждой отдельной частицы, а именно всего продукта. Чтобы добавление новой плюшки не выглядело костылем. Чтобы изменение какой-нибудь мелочи не выбивалось из общего «стиля» программы.

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

Я не понял, в чем конкретно проблема. Почитайте DDD, он довольно толково объяснит, как разрабатывать программы, чтобы они не оказались «от программистов для программистов», а были разработаны с учетом потребностей пользователей и для пользователей.

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

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

По поводу переписывания старого и всего остального: Для того чтобы начать писать проект или начать переписывать проект — вам нужны специалисты, которые смогут это спланировать\спроектировать и будут при этом понимать предметную область хотя бы по крупному. Опытный архитектор как минимум на начальной стадии — необходим. Разбить крупную тему «продукта» на таймлайне критически необходимо как можно раньше, согласовать её с заказчиком — тем более. Таймлайн поможет идти по аджайлу — выпустили сырой продукт, показали аналитику\PO\заказчику, получили фидбэк, переделали. Пара-тройка прототипов до всего этого — тоже вполне хороший вариант.

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Критика Agile

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

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

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

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

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

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

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

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

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

10 советов по применению Agile от практиков

Agile — гибкая методология разработки и управления проектами — применяется и хорошо работает в небольших компаниях и способствует созданию успешного пользовательского опыта, считает консультант по UX в компаниях Microsoft, Samsung и HP Хоа Лоранджер.

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

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

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

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

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

«Вливайтесь в работу на ранней стадии».

«Потратьте дополнительное время на уточнение всех деталей. Согласуйте цели продукта до начала проекта».

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

«Проведите исследования перед созданием концепции, разработкой дизайна и визуализацией возможностей».

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

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

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

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

«Имейте наготове макеты для планирования спринта».

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

Объем и сложность проекта влияют на то, насколько заблаговременно дизайнеры должны проработать UХ. Многие рекомендуют работать с опережением на один или два спринта.

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

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

Методология Agile в двух словах

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

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

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

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

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

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

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

Короткие итерации

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

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

Коммуникация, общение внутри команды

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

Обратная связь

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

Доверие

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

Согласование

Гибкая команда может быстро выровнять и настроить процесс в зависимости от необходимости. Принцип KIS или Keep It Simple — это то, чем они должны руководствоваться.

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

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

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

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

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

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

Agile манифест подразумевает четкую и измеримую структуру и поощряет итеративную разработку, совместную работу и принятие изменений.

Вы можете прочитать о ценностях и принципах Agile манифеста ниже:

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

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

Agile Управление проектами

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

  • Сотрудничество,
  • Гибкость,
  • Постоянное улучшение и
    Качественные результаты.

Он использует шесть основных «результатов» для мониторинга прогресса и выпуска продукта.

Видение продукта

Резюме, которое определяет цели продукта.

Дорожная карта продукта

Общий обзор требований к реализации.

Backlog продукта

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

План выпуска

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

Backlog cпринта

Список пользовательских историй, выбранных в последнем спринте.

Инкремент

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

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

Наиболее известные из них — Scrum и Kanban, поддерживающие жизненный цикл разработки Agile.

Подводя итоги

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

Цукерберг рекомендует:  Считаем количество параграфов, слов и символов с помощью Countable.js
Понравилась статья? Поделиться с друзьями:
Все языки программирования для начинающих