Что Такое Методология Agile и Каким Проектам Она Подходит

Что такое agile

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

С моей точки зрения, общепринятый перевод полного термина Agile software development как «гибкая разработка программного обеспечения» не очень точный. Авторы термина изначально рассматривали в качестве названия вариант Adaptive, и мне он кажется немного точнее, чем Agile.

Во-вторых, Agile — это философия, мировоззрение, выкристаллизованное из многолетнего опыта практиков. Прежде чем был сформулирован Agile-манифест, его авторы более 10 лет прорабатывали различные подходы к созданию ПО. Сейчас эти подходы известны как «гибкие», среди них — Scrum, eXtreme Programming, Crystal, Feature Driven Development и другие.

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

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

Вместо этого существует группа подходов, позволяющих реализовать ценности и принципы Agile на практике. Помимо упомянутых выше к ним относятся Nexus, LeSS, SAFe и некоторые другие.

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

Меньшая предсказуемость.

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

12 принципов agile манифеста о разработке программного обеспечения:

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

Больше времени и обязательств.

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

Повышенные требования к разработчикам и заказчикам.

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

4 ценности agile манифеста:

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

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

Проект легко сбивается с пути

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

Agile манифест

Публикация Agile манифеста в 2001 году знаменовала рождение Agile как методологии.

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

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

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

За последние 20 лет с момента создания манифест приняли многие команды и организации из разных профессиональных сфер. Сегодня документ доступен более чем на 50 языках, включает в себя 4 ценности и 12 принципов.

Agile-манифест

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

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

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

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

Kanban

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

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

Scrum

В 1995 году Кеном Швабером и Джеффом Сазерлендом  на OOPSLA 95 в Остине была представлена новая сформулированная и задокументированная методология ведения проектов при разработке ПО. Назвали ее Scrum (Схватка — термин взятый из регби). 

Ее разработкой и внедрением Д. Сазерленд занимался во время своей работы в компании Easel в 1993 году. Перед ним стояла задача в очень сжатые сроки создать абсолютно новую линейку ПО. Он решил отказаться от каскадной модели ведения проекта и занялся поиском оптимального решения.

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

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

Итак давайте рассмотрим основные принципы Scrum:

Бережливое производство (lean)

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

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

Гибкость agile

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

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

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

— Самое главное люди, а не вещи

— Документация (которую еще и никто не читает) не должна никому мешать работать

— Сотрудничайте, а не перечитывайте контракт

— Живите, дышите, меняйтесь так быстро, насколько это возможно

Гибкость agile методик

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

Ценности и принципы Agile:

К основные методологиям Agile относятся Scrum, Kanban и Lean. Scrum мы уже рассмотрели, а что из себя представляют Kanban и Lean. Они тоже пришли к нам из Японии, и  родственны  философии бизнеса Кайдзен и Тойоту. 

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

Что касается Lean, то это больше философия и набор методик для создания бизнеса и подхода к разработке. Она подробно описана в книге Lean startup  Эрика Риса.

Характерно для Lean:

Другие гибкие методологии разработки по

В управлении проектами существует ряд других методологий управления проектами кроме тех, что мы перечислили выше:

• Разработка, управляемая функциональностью (FDD).
• Crystal Clear. 
• Метод разработки динамических систем (DSDM).
• Разработка через тестирование (TDD).
• Адаптивные рамки проекта (APF),
• и другие.

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

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

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

Например, разработчики программного обеспечения чаще предпочитают Scrum и XP, в то время как Канбан — любимец команд, ориентированных на сервис (IT, маркетинг или отдел кадров).

Иерархия компетенции в agile

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

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

Но в Agile-организации главенствует иерархия компетенции, а не иерархия власти.

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

Инструменты agile

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

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

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

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

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

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

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

Инструменты для работы с agile-проектами

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

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

Онлайн-диаграмма Ганта с легкостью выполнит все эти задачи и упростит работу с проектом всем его участникам. 

Онлайн диаграмма ганта ganttpro

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

Попробуйте бесплатно

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

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

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

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

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

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

Нам они известны как “Диаграммы Ганта” или Каскадная модель. Они совершили настоящую революцию в управлении проектами в 20-х годах XX века. Диаграммами пользовались во многих грандиозных инженерных проектах, например при строительстве дамбы Гувера и при строительстве сети скоростных магистралей США.

Как внедрить

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

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

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

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

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

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

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

Как устроен scrum — самая популярная гибкая методика

Scrum
Посмотрим, как можно работать по эджайлу. Для примера возьмем Scrum — сегодня это самая популярная гибкая методика. Джефф Сазерленд, автор книги «Scrum», изобрел ее, чтобы справиться с недостатками классического управления проектами.

1. Выберите владельца продукта

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

2. Выберите команду

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

3. Выберите скрам-мастера

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

4. Создайте бэклог продукта

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

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

5. Уточните и оцените бэклог продукта

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

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

6. Планирование спринта

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

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

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

7. Работа должна быть видимой

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

8. Проводите ежедневные собрания

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

1. Что ты делал вчера, чтобы помочь команде завершить спринт?

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

3. Какие препятствия встают на пути команды?

Вот и все. Вся встреча. Если на это требуется больше пятнадцати минут, значит вы что-то делаете неправильно.

9. Обзор спринта

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

10. Ретроспективное собрание

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

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

Какую гибкую методологию управления проектами предпочитаете вы?

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

А какие Agile методологии управления проектами предпочитает ваша команда? Делитесь в комментариях ниже.

Когда гибких методологий следует избегать

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

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

Компромиссы agile

С преимуществами гибкой разработки программного обеспечения приходят и ряд недостатков. С гибкой разработке программного обеспечения легко потерять чувство равновесия. Брайан Лоули, генеральный директор 280 Group так говорит об Agile:

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

Кому подойдет методология agile?

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

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

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

• Если грядущий проект технологически сложный и комплексный.

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

• Если проект продолжительный по времени.

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

• Если в реализации проекта много неопределенных моментов.

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

• Если количество идей по проекту превышает возможности команды.

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

• Если клиент хочет участвовать в каждом этапе реализации проекта.

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

Минусы agile

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

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

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

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

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

С момента массового появления в 1980-е годы персональных компьютеров, стало проще создавать самые разнообразные и сложные диаграммы — делать их по настоящему комплексными.Они превращались в подлинные художественные произведения. Абсолютно каждый шаг проекта детально размечен. Любая стадия. Всякая дата. Диаграммы Ганта производят глубокое впечатление. Но есть одна единственная проблема: они всегда неправильны.

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

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

Практически у всех разработчиков того времени встречались одни и те же проблемы:

Новое движение

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

Они вовремя приходят на работу, но предпочитают не проявлять инициативы.

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

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

Общие практики agile

1. Работа над мини-блоками

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

2. Маленькие кросс-функциональные команды

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

3. Ограничение объема незавершенной работы

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

4. Автономность команд.

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

5. Достижение стадии готовности.

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

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

6. Беспрерывная работа.

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

7. Полная прозрачность и использование досок со стикерами.

Использование «бумажных источников информации» стало неожиданным открытием. Фактически любой мог попасть на рабочее место сотрудников и сразу узнать статус работы и источник потенциальных проблем.

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

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

По материалам книг «Scrum» и «Эпоха Agile».

Изображения: источник.

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

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

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

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

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

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

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

Примеры проектов и применение agile

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

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

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

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

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

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

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

Совсем большой масштаб требует дополнительных процессов, таких как Nexus, LeSS или SAFe. Известен кейс создания самолета 5-го поколения компании Saab. Модель Gripen-E создавали больше 100 команд, каждая из которых разрабатывала свой блок, узел или подсистему, в результате чего удалось добиться впечатляющих характеристик продукта при соблюдении установленных ограничений.

Принципы agile

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

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

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

Резюме

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

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

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

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

Доступно проиллюстрирует идею XP способ «парного программирования». В этом случае один разработчик занимается написанием кода, а его коллега непрерывно просматривает и проверяет написанное, не дожидаясь окончания работы первого программиста.