Agile-методология: 4 главных мифа

Agile-методология: 4 главных мифа

Как появилась и развивалась методология Agile Оригинальный манифест методологии Agile Как выглядит работа по методологии Agile на практике 4 главных мифа методологий Agile управления проектами Что собой представляет методология Agile SCRUM Где применяются методологии Agile Kanban, Lean, Six Sigma Кратко о внедрении методологии разработки Agile Две стороны монеты: преимущества и недостатки методологии Agile Как оценить эффективность работы по Agile-методологии управления проектами 6 лучших книг по Agile-методологии Agile-методология: 4 главных мифа
Время чтения: 16 минут
Отправим материал вам на:

Из этого материала вы узнаете:

  • Как появилась и развивалась методология Agile
  • Оригинальный манифест методологии Agile
  • Как выглядит работа по методологии Agile на практике
  • 4 главных мифа методологий Agile управления проектами
  • Что собой представляет методология Agile SCRUM
  • Где применяются методологии Agile Kanban, Lean, Six Sigma
  • Кратко о внедрении методологии разработки Agile
  • Две стороны монеты: преимущества и недостатки методологии Agile
  • Как оценить эффективность работы по Agile-методологии управления проектами
  • 6 лучших книг по Agile-методологии

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

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

Гибкие методологии Agile: как появилась и развивалась идея

Первые шаги по созданию программного обеспечения для управления проектами предпринимались начиная еще с 70-х годов 20 века.

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

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

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

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

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

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

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

Гибкие методологии Agile

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

Таким образом, в 90-х годах на смену сложным в исполнении схемам пришел целый ряд гибких способов формирования программного обеспечения. А именно:

  • Метод гибкой разработки для приложений RAD (1991 год).
  • Метод разработки для динамических систем DSDM (1994 год).
  • Методология разработки Agile SCRUM (1995 год).
  • Фреймворк для гибкой разработки Crystal Clear и система экстремального программирования XP (1996 год).
  • Интерактивная методика формирования программного обеспечения FDD (1997 год).

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

Позже в Америке (курортный городок Snowbird, штат Юта, 2001 год) состоялась встреча с участием семнадцати разработчиков ПО. Цель — обсуждение методов разработки. Результатом стала публикация документа под названием «Манифест о гибкой разработке программного обеспечения Agile». Agile переводится как «быстрый», «подвижный», «проворный», «гибкий» (последний вариант подразумевается чаще всего). Именно этот термин стал использоваться в отношении методик по разработке ПО.

Оригинальный манифест методологии Agile

Оригинальный манифест методологии Agile

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

Основные идеи Agile-методологии:

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

Основные принципы Agile-методологии:

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

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

Как выглядит работа по методологии Agile на практике

Как выглядит работа по методологии Agile на практике

Для начала вспомните, как велась работа по так называемой каскадной методике (Waterfall), которая использовалась до Agile и выстраивалась на принципе последовательности:

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

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

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

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

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

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

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

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

На данном этапе завершена очередная итерация, а далее продолжается общая разработка.

4 главных мифа методологий Agile управления проектами

4 главных мифа методологий Agile управления проектами

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

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

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

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


Миф 1. Методологию Agile можно применять на всех проектах

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


Миф 2. Методология Agile и ведение документации несовместимы

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


Миф 3. Методология Agile не приемлет планирования

Это неправда. Гибкое управление подразумевает регулярные спринт-встречи, итерационное планирование дважды в месяц, планерки в течение дня, быстрые стендапы (по 10 минут) и проч.


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

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

Что собой представляет методология Agile SCRUM

Что собой представляет методология Agile SCRUM

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

О методологии разработки Agile SCRUM первыми заговорили в 1986 году исследователи Икуджиро Нонака и Хиротака Такеучи (Япония). Принципы, подталкивающие к быстрой генерации новых идей, были изложены в статье The new new product development game. Так, одним из условий определялось формирование команды, которой предоставлялась возможность самоорганизации и свободного воплощения творческих задумок. Руководство не вмешивалось в процесс. Сами авторы описывали это так:

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

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

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

Методология разработки Agile SCRUM, сформулированная Нонакой и Такеучи, активно используется в сферах IT-технологий, машиностроения, электроники. Уже в 90-х годах SCRUM превратился в эффективную, проверенную на практике систему, приемы которой позволяют полностью наладить работу группы специалистов. Кен Швабер и Джефф Сазерленд нашли способ применения SCRUM (который иные разработчики считают поистине уникальным продуктом) в сфере IT-технологий.

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

Product owner формулирует задачу. Именно он должен иметь четкое представление о том, какой конечный продукт необходим. Для изложения всех требований формируется специальный перечень, называемый Product Backlog. В него записываются пожелания касательно функциональных возможностей, внешнего оформления и прочие требования к продукту (в SCRUM они обозначаются словом stories, то есть «истории»). Backlog формируется еще до начала работы над проектом, но в процессе может меняться, пополняться; сюда же вносятся и приоритеты, связанные с возможными доработками.

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

Разработка программ по методологии SCRUM Agile

Разработка программ по методологии SCRUM Agile предполагает деление на итерации. Тут часто берут формулировки из спорта. В частности, для участков работы используют определение «забег» или «спринт». В начале каждого из них задача участников группы — выбрать из списка истории, реально выполнимые именно в этом «спринте» (для него таким образом формируется отдельный список — sprint backlog). Обозначается конечная цель «забега», задачи для каждого участника группы — и можно приступать к работе.

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

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

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

Где применяются методологии Agile Kanban, Lean, Six Sigma

Где применяются методологии Agile Kanban, Lean, Six Sigma

1. Lean

Если следовать рекомендациям методологии Agile, то следует делить на части управляемые пакеты работ. Однако четкой схемы действий не предоставляется. Процессы и процедуры можно позаимствовать из SCRUM. А система Lean дает схему потока операций (ее называют workflow), которая позволяет выполнять каждую итерацию максимально качественно.

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

Обычно проектный менеджмент предлагает такие этапы:

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

Lean

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

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

Плюсы Lean:

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

Минусы Lean:

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

2. Kanban

Kanban

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

Методология Agile SCRUM Kanban базируется на трех основных принципах:

  • Задачи четко визуализированы. Вся информация открыта, виден каждый шаг — это позволяет сразу замечать и устранять возможные ошибки.
  • Объем одновременно выполняемой работы контролируется и ограничивается (принцип WIP, то есть Work-in-Progress). Смысл в том, что группа не должна быть перегружена и пытаться сделать сразу больше, чем запланировано.
  • Время, отводимое на выполнение каждого этапа работы, контролируется и по возможности сокращается за счет оптимизации.

3. «6 сигм» (Six Sigma)

В свое время и компания «Моторола» внесла свой вклад в дело разработки гибких методов управления. Имеется в виду концепция под названием «6 сигм», которую предложил работавший там инженер Билл Смит (в 1986 году). Данная система является версией Lean, однако она отличается более детальной структурой (по сравнению с Kanban). В разработке больше внимания уделено экономному расходованию ресурсов, снижению количества брака и повышению качества конечного продукта.

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

«6 сигм» (Six Sigma)

Данная концепция представляет собой схему, состоящую из пяти этапов, именуемых DMEDI:

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

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

Этап 3. Исследование (Explore). Здесь решения принимает менеджер проекта. Он намечает ход действий, которые обеспечат своевременное и качественное выполнение поставленной задачи в рамках бюджета. При возникновении проблем тут важно умение руководителя мыслить креативно и быстро находить нужные решения.

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

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

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

Плюсы от использования Six Sigma:

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

Минусы системы Six Sigma:

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

Кратко о внедрении методологии разработки Agile

Кратко о внедрении методологии разработки Agile

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

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

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

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

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

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

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

Вот плюсы данной системы:

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

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

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

В системе Agile существует и ряд отрицательных моментов.

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

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

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

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

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

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

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

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

  9. Постоянная спешка
  10. Работа по методологии Agile предполагает достаточно бодрый темп. Тут все нужно делать быстро: придумывать идеи, внедрять их, проверять, что-то менять и т. д. На глубокое обдумывание времени не дается.

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

    Но кто гарантирует, что при таком подходе не будет сбоев?

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

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

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

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

Большинству проектов можно дать оценку по четырем направлениям метрик:

  1. Производительность. В качестве примеров — Velocity и WIP (Work-in-Progress). Первый вариант не всегда эффективен, потому что там оценка идет по числу выполненных задач в рамках одной итерации, а задачи эти не всегда равноценны. WIP оценивает лимит необходимых задач на разных этапах, и плохо, если этот показатель высокий.
  2. Выстраивание прогнозов. Пример — метрика capacity. Она дает возможность спрогнозировать, за сколько часов можно будет завершить следующий забег. Отсюда станет ясно, сколько есть времени на весь проект, верно ли распределены задачи по спринтам и насколько эффективно они выполняются.
  3. Качественные показатели, такие как, к примеру, индекс стабильности требований. Согласно существующей формуле это = (Общее число сгенерированных оригинальных требований + Количество требований, суть которых изменилась + Число требований, добавленных в процессе работы + Число требований, удаленных из проекта) / (общее количество рассмотренных оригинальных требований). Данная метрика позволяет понять, сколько времени уходит на переделывание отдельных элементов проекта.
  4. Ценность. Данный показатель определяется индивидуально в каждом случае. К примеру, ценность продукта в проекте Airbnb определялась числом высококачественных загруженных фото. Получалось, что, когда их количество росло, пользователей становилось больше.

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

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

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

6 лучших книг по Agile-методологии

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

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


1. Agile Project Management for Dummies

Agile Project Management for DummiesАвтор — сертифицированный SCRUM-тренер Марк Лейтон.

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

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

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

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


2. The Lean Product Playbook: How to Innovate with Minimum Viable Products

The Lean Product Playbook: How to Innovate with Minimum Viable ProductsКнигу написал Дэн Олсен.

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

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

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

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


3. The Lean Startup

The Lean StartupИмя автора — Эрик Райс.

Здесь масса дополнительных сведений о применении в разработках принципов Lean Startup.

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

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


4. The Software Project Manager’s Bridge to Agility

The Software Project Manager’s Bridge to AgilityАвторы — PMP-сертифицированные специалисты управления проектами Мишель Слигер и Стейша Бродерик.

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

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

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


5. Coaching Agile Teams: A Companion for Scrum Masters, Agile Coaches, and Project Managers in Transition

Coaching Agile Teams: A Companion for Scrum Masters, Agile Coaches, and Project Managers in Transition

Создатель — Лисса Эдкинс.

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

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


6. Project Management the Agile Way: Making it Work in the Enterprise

Project Management the Agile Way: Making it Work in the EnterpriseКнигу написал Джон Гудпесче.

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

В Project Management the Agile Way объясняются методики внедрения Agile в различные бизнес-проекты, излагаются способы определения критериев для выбора эффективного инструментария для разных требований.

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

article_banner.png

Статья опубликована:

Читайте также

Генератор Продаж
Опубликовано
Генератор Продаж
г. Рязань, Куйбышевское шоссе, 25
Телефон: 8 (800) 775-43-06