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

"Что с этим нам делать то, у нас из программирования только сайт?"

В итоге примерно для 100% компаний Agile смахивает на шарлатанство.

Но вот парадокс - в мире 77% компаний*, использующих Agile в проектах, занимаются совсем не разработкой программного обеспечения.

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

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

Команда в игре "Что? Где? Когда?" существует по принципам Agile. Взаимодействиям отдана ключевая роль. Капитан выполняет роль заказчика продукта (верного ответа), 2-3 эрудита перебирают массивы информации, кто-то следит за временем, есть человек, который анализирует, задает вопросы и побуждает общение, любой может высказаться и привести к результату или все провалить, за пределами игры есть разбор полетов (ретроспектива).

Противовес Agile - это конвейерный (каскадный) метод с жесткой иерархией и точными задачами поставленными как можно ближе к SMART. По этим принципам в "Что? Где? Когда?" капитан должен был бы раздавать точные задачи - кому в каком направлении думать и пытаться собрать это в ответ. Каждый участник должен был бы соблюдать приличия и высказываться когда дойдет очередь. В случае провала нужно было бы кому-нибудь понизить мотивацию или уволить и принимать это решение будет капитан.

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

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

Но . Даже если вы веб-студия и для вас это тысячный сайт, для клиента это первый раз. И его желания останутся неопределенностью до самого конца. Многие студии делают 3-4 варианта главной страницы и закладывают неделю на непредвиденные доработки. У всех, кого я знаю, работа разбита на итерации, после каждого есть демонстрация и обсуждение. Общение с заказчиком важнее подписанного контракта.

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

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

Итого ключевые ценности Agile (манифест):

• свободное взаимодействие в команде
• результативность проекта (классный продукт)
• партнерское общение с клиентом
• готовность к изменениям

Что такое команды с ролями?

В привычной команде есть две роли: Начальник и Подчиненный, один умный другой дурак. В Agile принципиально важны три: Заказчик продукта, Методист, Участник команды.

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

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

Со стороны гибкая команда от привычной отличается именно наличием или отсутствием так называемого повествовательного диалога (narrative collaboration). Если идет обсуждение вопроса "Как реализовать продукт?" на всех уровнях, значит команда гибкая. Если ищут кто виноват, что не выполнен список конкретных задач, значит все как обычно.

Главный вопрос: "Как управлять ресурсами когда все так гибко?"

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

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

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

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

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

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

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

Мы используем третий, но оценки бывают только 1h, 2h, 4h, 8h.

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

5. Burndown chart (график сгорания)
Очень простая вещь - это график с двумя линиями; первая - сколько времени сгорело и это всегда прямая, на второй - сколько задач в пересчете на ресурсы закрыто и тут возможны колебания. Фактически это графический ответ на вопрос идет ли команда по плану или отстает.

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

• самая частая ошибка - попытка попадать в оценки очень точно, команда перестает работать на результат
• самый успешный подход - заложить запас по времени, планировать на 80% ресурсов

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

Топ 5 самых популярных Agile-практик понятных всем

Еще раз подчеркну, Agile на базовом уровне применения - это просто. Нет никаких сверхсложных приемов, которые надо долго изучать. Ниже для примера приведено 5 самых популярных практик (по данным все того же опроса от VersionOne)

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

1. Итерационное планирование - спринты (90% команд используют)
Работать небольшими забегами с промежуточным результатом - хорошая практика. Спринт - это несколько недель. Слишком короткие или слишком длинные отрезки - плохо. Одинаковый интервал на все случаи жизни тоже не годится. У спринта должна быть максимально точная цель, исходя из этого и определяется длительность.
Самый частый ошибкой является то, что команды привыкают просто расписывать задачи раз в две недели, теряются процессы постановки промежуточных целей и подведение итогов в конце. Работа сваливается в обычный поток задач с обновлением раз в спринт. Проблему должен решать методист.

2. Ежедневные планерки (88% команд используют)
Задача - чтобы каждый день команда подтверждала единое направление движение всех участников. По классическому описанию каждый в команде раскрывает три вопроса:

• Что сделано к этому моменту из спринта?
• Что планируется на сегодня?
• Какие проблемы возникли или что мешает?

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

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

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

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

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

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

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

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

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

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

Аспирант «Нетологии» Максим Пименов рассказывает про Agile — гибкую методологию разработки программного обеспечения.

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

Чтобы процесс создания программы шел правильно, программисты используют методологии. Методология — это набор стратегий и способов создания продукта. Их много и новичок не знает, что выбрать: RUP, XP, Waterfall или другой набор букв.

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

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

Пары «план — спринт» идут одна за другой, пока живет проект.

Команда работает как захочет

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

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

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

На самом деле не все любят Agile

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

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

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

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

Если забыть о философии, ничего не выйдет

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

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

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

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

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

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

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

Agile — мировоззрение, а не набор советов. Примите Agile, и только потом беритесь за практику.

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

Общая информация

Первоначально давайте разберёмся с техническими моментами. Что собой представляет Agile? Перевод (дословный) этого слова с английского языка - «живой, подвижный», немногим реже упоминается «гибкий». И кстати, это сокращение. Полное название этого подхода это Agile software development. Но поскольку это слишком долго, то и было решено сократить. И сейчас говорят просто Agile. Перевод как «гибкий» используется из-за того, что он в наибольшей мере соответствует реальной ситуации.

Что же сюда включено?

Продолжаем рассматривать, что такое Agile. Здесь хочется сконцентрировать внимание на том, что это гибкий подход, в основе которого лежит множество различных ХР, "Канбан", Lean). Для того чтобы лучше разобраться в теме, давайте проведём параллели. Допустим, что Agile-технологии - это процесс зарождения Вселенной. Конечный продукт - непосредственно сам существующий мир. А большой взрыв - это наиболее болезненная проблема, с которой только приходится встречаться, - изменение перечня требований к продукту. Обычно процессы создания подразумевают использование каскадной модели. В этом случае всё идёт последовательно и по этапам. Такой подход можно выразить кратко: вижу цель - иду к ней. И если меняются требования к конечному результату, то иногда приходится переделывать заново едва ли не всё. Что еще усложняет такую ситуацию, так это попытка сделать вид, что всё нормально, и нужно двигаться вперед.

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

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

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

Устройство процессов

Рассматривая, что такое Agile, давайте обратимся к одной из самых популярных методичек, известной как "Скрам" (Scrum). Что же она предлагает? Для начала нужно:

1. Выбрать владельца продукта. На эту роль подходит человек, что видит, к какой цели нужно идти, и что будет в конечном итоге.
2. Определиться с командой. Для этого необходима группа, численностью от трех до десяти человек, что владеют навыками, позволяющими получать результат.
3. Выбрать ответственного специалиста. Это человек, что будет следить за развитием проекта и помогать команде обходить трудности.
4. Разобраться с трудностями. Следует собрать в одном месте все существующие требования к продукту и расставить приоритеты. Владелец продукта должен собрать здесь все свои пожелания. Потом команда их оценивает и разбирается, можно ли это реализовать, и сколько времени для этого нужно.
5. Следует разбить весь объем работ на отрезки времени, длиной в неделю или две, во время которых команда будет выполнять определённые наборы задач.
6. Ежедневно следует проводить встречи, длиной не более пятнадцати минут. На повестке следует обговаривать, что было сделано вчера, какие планы на сегодня, и преграды, мешающие брать высоту.
7. Делать обзоры по итогам недели (двух), во время которых командой рассказывается о том, что было сделано. При этом необходимо демонстрировать работоспособность частей продукта.
8. После каждого временного периода необходимо обсуждать проблемы и искать решения. Причем все наработки необходимо внедрять сразу.

Как опознать Agile?

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

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

Давайте представим реку. На одном берегу заказчик. На втором - команда. В таком случае гибкая методология разработки имеет преимущества для всех:

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

Социальный фактор

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

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

Небольшой пример

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

Поскольку используется гибкая методология разработки, то пользовательские истории не копятся до большого релиза, а выпускаются сразу после завершения и как можно чаще. Количество обработанных обращений составляет пропускную способность команды на неделю. Чтобы не потерять темп и не увязнуть в ручном тестировании, команда должна работать над автоматизированной интеграцией. В чем она заключается? Для каждого рабочего момента пишется автоматический тест. Если историй слишком много, то может возникнуть спешка, потеря мотивации, снижение производительности и качества. На такие случаи предусмотрен метод «вчерашняя погода». Он заключается в том, что нужно установить жесткие рамки количества работы и тщательно выбирать, что именно будет реализовываться. Упомянутый ранее "Канбан" предлагает устанавливать лимит задач.

А что делать с очередью?

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

Принимаем решения

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

Возможные риски

Для избегания проблем необходимо дать честные ответы на ряд вопросов. Это:

1. Правильные вещи ли мы делаем? Это бизнес-риск.
2. Можем ли мы реализовать то, что нужно?
3. Будет ли работать проект на данной платформе. Это технический риск.
4. Хватит ли денег, и успеем ли? Это риски сроков реализации и стоимости.

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

Как обучиться?

IT-индустрия чрезвычайно быстро развивается, и чтобы не проиграть в конечном итоге, необходимо постоянно учиться, повышать квалификацию и эффективность работы. Поэтому как никогда актуальны вопросы обучения и внедрения. С чего начать? Самый лучший вариант - это кооперация с компанией, где уже применяется 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, возникает опасность долгой работы. Конечные пользователи, которые видят, что эти требования могут быть выполнены «легко» (они видят только результат, а не усилия), будут запрашивать дополнительные функции. Если менеджер проекта и разработчики не могут управлять ожиданиями, конечные пользователи будут продолжать запрашивать больше, пока вся команда не будет загружена дополнительной работой.

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

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

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

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

Внедрение Agile

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

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