ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 18.03.2024
Просмотров: 14
Скачиваний: 0
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
Agile-манифест
Как началась эта революция? Принято вести отсчет от появления в 2001 году основного документа движения — «Манифеста гибкой разработки программного обеспечения», теперь именуемого Agile-манифестом. Agile-манифест провозгласил, что «открытие лучших способов разработки программного обеспечения» требует отмены некоторых фундаментальных положений менеджмента ХХ века.
Сторонники Agile ценят «личности и взаимодействия, а не процессы и инструменты, рабочее программное обеспечение, а не обширную документацию, сотрудничество с клиентом, а не заключение контракта, адаптацию к переменам, а не следование плану».
Предлагая перечисленные ценности, Agile-манифест косвенно поднимал и более глубинные вопросы. Могут ли компании создать адекватные рабочие места для талантливых сотрудников и предоставить им возможность полностью сосредоточиться на создании ценности для клиентов и других заинтересованных сторон? Как должны выглядеть эти рабочие места? Как связать их с существующими целями, принципами и ценностями? Насколько надежной будет новая система и сможет ли она в дальнейшем масштабироваться?
Спустя некоторое время стало понятно, какие конкретно методы работают, а какие нет. В результате внимание компаний сместилось в сторону определенной группы целей, принципов и ценностей. Они доказали бóльшую продуктивность, оказались более чуткими к нуждам современного рынка по сравнению с традиционным менеджментом и могли применяться в большом масштабе.
Принципы Agile
В компаниях, работающих по принципам Agile-менеджмента, самоорганизующиеся команды постоянно создают новую ценность для своих пользователей. Благодаря такому взаимодействию с клиентами организация имеет возможность постоянно совершенствовать свои предложения, порой в режиме реального времени.
Команды работают в едином ритме — короткими равными итерациями, стартуя в один и тот же день, что позволяет им совместно реализовывать сложные, комплексные проекты и создавать надежные продукты — ценность как для себя, так и для покупателей. Все ресурсы компании — материальные, информационные и финансовые — легко перемещаются на основе комплексного подхода
, зачастую со значительным эффектом масштаба.
Принимая Agile, организация перестает быть похожей на военный корабль. Она становится флотилией из юрких скоростных катеров. Работу выполняют маленькие команды, которые действуют короткими циклами. Принципы: деление задач на блоки, автономность, прозрачность, ежедневные стендапы, обратная связь пользователей и другие.
Гибкость Agile
В традиционных организациях процессы работают в рамках каскадной модели (или waterfall model) — все происходит поэтапно и последовательно. Проще говоря, «вижу цель — иду к цели». И если в какой-то момент требования к продукту, конечной цели меняются, иногда приходится переделывать заново. Как только превосходно отточенный план сталкивается с реальностью, он сразу рассыпается в прах. Но вместо того чтобы выбросить в мусорную корзину и сам план, и свой подход к нему, руководители делают вид, будто план работает, и даже нанимают для этого специалистов. По сути, они платят людям за то, что те им лгут.
Agile-методы же призваны бороться с этим за счет своей гибкости. Можно сказать, что Agile — сборная солянка нескольких подходов, призванная минимизировать всяческие риски при помощи набора принципов. Если упростить формулировки, чтобы «выкристаллизовать» соображения, которыми руководствуются все, кто работает по эджайлу, получится следующее:
— Самое главное люди, а не вещи
— Документация (которую еще и никто не читает) не должна никому мешать работать
— Сотрудничайте, а не перечитывайте контракт
— Живите, дышите, меняйтесь так быстро, насколько это возможно
Как устроен Scrum — самая популярная гибкая методика
Scrum
Посмотрим, как можно работать по эджайлу. Для примера возьмем Scrum — сегодня это самая популярная гибкая методика. Джефф Сазерленд, автор книги «Scrum», изобрел ее, чтобы справиться с недостатками классического управления проектами.
1. Выберите владельца продукта
Это человек, обладающий видением того, что вы собираетесь делать, производить, достигать. Он принимает во внимание риски и выгоды, что нужно выполнить, что может быть сделано и что вас воодушевит.
2. Выберите команду
Кто те люди, которым предстоит выполнить работу? Специалисты, входящие в группу, должны обладать всеми навыками и знаниями, необходимыми, чтобы воплотить идею владельца продукта в жизнь. Команда должна быть небольшой, от трех до девяти человек — это золотой стандарт Скрама.
3. Выберите скрам-мастера
Это человек, который следит за ходом проекта, обеспечивает проведение всех коротких собраний и помогает команде устранять мешающие ей препятствия.
4. Создайте бэклог продукта
Это список абсолютно всех требований, предъявляемых к продукту и расставленных по их приоритету. Бэклог существует и развивается на протяжении всей жизни продукта, чьим ориентиром он является.
Владелец продукта должен беседовать со всеми заинтересованными лицами и командой, чтобы гарантировать всю полноту обратной связи и отображать в бэклоге все требования и пожелания потребителя.
5. Уточните и оцените бэклог продукта
Крайне важно, чтобы участники группы, которые будут выполнять задания из бэклога, оценили, сколько усилий это потребует. Команда должна взглянуть на каждую задачу и определить, выполнима ли она в принципе. Достаточно ли информации, чтобы выполнить задачу? Достаточно ли она обозрима, чтобы ее можно было оценить?
Не оценивайте задания бэклога в часах, поскольку люди плохо с этим справляются. Оценивайте в относительных размерах: «малый», «средний», «большой».
6. Планирование спринта
Это первое скрам-собрание. Команда, скрам-мастер и владелец продукта планируют спринт. Как правило, выбирают спринты длиной в одну или две недели. Команда смотрит в верхнюю часть бэклога и прогнозирует количество заданий, которое возможно выполнить за этот спринт. Скрам-мастер и команда должны в каждом спринте наращивать динамику.
Планирование спринта — это еще одна возможность для владельца продукта и команды удостовериться, что все точно понимают, как реализация заданий служит воплощению замысла. На этой встрече все должны договориться о цели спринта и определить, что должны выполнить за спринт.
Основное правило Скрама — если команда договорилась об определенном количестве заданий, которые нужно выполнить за один спринт, то добавлять новые уже нельзя. Команда должна быть в состоянии работать автономно на протяжении всего спринта и завершить то, что пообещала заказчику сделать.
7. Работа должна быть видимой
Прозрачность всех действий и процессов обеспечивает скорейшее достижение цели. Наиболее распространенный способ добиться этого — завести скрам-доску с колонками: «Нужно сделать, или бэклог»; «В работе»; «Сделано». Стикеры — это пользовательские требования, которые нужно реализовать; по мере того как они выполняются, команда перемещает стикеры из одной колонки в другую.
8. Проводите ежедневные собрания
Это пульс всего процесса Скрама. Каждый день в одно и то же время не более чем на пятнадцать минут команда и скрам-мастер встречаются и дают ответы на три вопроса.
1. Что ты делал вчера, чтобы помочь команде завершить спринт?
2. Что ты будешь делать сегодня, чтобы помочь команде завершить спринт?
3. Какие препятствия встают на пути команды?
Вот и все. Вся встреча. Если на это требуется больше пятнадцати минут, значит вы что-то делаете неправильно.
9. Обзор спринта
Это встреча, на которой команда рассказывает, что сделано за спринт, и демонстрирует готовые части продукта. Присутствуют владелец продукта, скрам-мастер, команда и любые заинтересованные лица: заказчик, представители руководства, потенциальные потребители. Это открытая встреча, где команда демонстрирует, что удалось переместить в колонку «Сделано» за время спринта.
10. Ретроспективное собрание
После того как команда показала, что она сделала за прошедший спринт и что может быть сдано клиенту для получения обратной связи, все садятся за общий стол и обсуждают ряд вопросов. Что прошло хорошо? Что можно было сделать лучше? Что можно сделать лучше в следующем спринте? Какое улучшение команда может внедрить в процесс немедленно?
С методикой Скрам не слишком трудно удвоить производительность и в два раза приблизить время сдачи проекта. Если вы сделаете это вовремя, ваши доходы и стоимость акций удвоятся. Действуйте.
Иерархия компетенции в Agile
«Клиент всегда на первом месте» — эти слова часто произносят в традиционных организациях, но редко за ними что-то стоит. Вся методология Agile построена как раз на том, чтобы принести пользу клиенту. Взять, к примеру, работу небольшими временными отрезками — спринтами. После каждого блока важно получить обратную связь: клиент доволен? Нет? Тогда работаем дальше! Закон клиента — один из основ Agile.
Распространено заблуждение, что Agile-организации обязательно имеют горизонтальную структуру и в них отсутствует иерархия. На самом деле высшее руководство по-прежнему выполняет в них важную функцию — задает вектор движения. Нерадивых сотрудников по-прежнему увольняют за невыполнение работы. Более того, Agile-организации стремятся к высоким результатам даже настойчивее, чем традиционная бюрократия. Абсолютная прозрачность процесса и ответственность перед коллегами не дают возможность пересидеть аврал.
Но в Agile-организации главенствует иерархия компетенции, а не иерархия власти.
Эффективность выражается не в том, угодил ли ты своему руководителю, выполнив его поручение, а в том, чтобы ты повысил ценность для своего истинного босса — потребителя.
Общие практики Agile
1. Работа над мини-блоками
Чтобы справиться со сложностью и непредсказуемостью, задачу по возможности разбивают на блоки. В каждом из них содержится нечто потенциально ценное для потребителя или конечного пользователя. Каждый можно реализовать за короткий цикл; при таком подходе даже в сложных и крупных проектах виден прогресс или его отсутствие.
2. Маленькие кросс-функциональные команды
Работа обычно выполняется в автономных кросс-функциональных микрокомандах. Каждая из них выполняет что-то потенциально ценное для потребителя. Размер команд варьируется. Одно из главных правил — «семь плюс-минус два». В одних компаниях команды состоят из 10–12 человек, в других они меньше.
3. Ограничение объема незавершенной работы
В Agile-менеджменте команды учатся концентрироваться на том объеме работы, который можно выполнить за короткий цикл. Если ограничить объем незавершенной работы, снижается количество ее очередей.
4. Автономность команд.
В начале каждого короткого цикла составляется план работы, а дальше команды сами решают, как его выполнить. Руководство компании определяет базовые «дорожные правила», но исполнители свободны в выборе метода действий. «Дорожные правила» также варьируются: некоторые организации придерживаются фреймворка Scrum: работа в спринтах, в общем темпе, чтобы расширить возможности координации между командами. В других организациях право выбора предоставляется команде.