Не так это просто быть Agile

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

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

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

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

Agile манифест для школ

Члены группы выразили разочарование по поводу нынешнего положения дел. Ценность Scrum для обычного заказчика во многом состоит в том, что результат работ (плохой или отличный, не важно) будет продемонстрирован в любом случае. Это знает и команда и Product Owner и другие заинтересованные лица. Если команда не проводит демонстрацию (иное название Sprint Review), то это дискредитирует все преимущества гибких процессов.

Эти принципы развивают основную идею ценностей и конкретно описывают, что значит быть гибким. Разумеется, фраза «вместо следования плану» дает понять, что план реально существует! Планирование – это важная часть разработки Agile. Так, команды и программы в Agile составляют планы чаще и в более непрерывном режиме, чем их коллеги, использующие «водопадную» модель. Однако, планы должны адаптироваться по мере того, как выучиваются новые уроки, появляется новая информация и ситуация меняется. Хуже того, оценка успеха путем измерения соответствия плану приводит к неправильному поведению (например, следование плану вопреки доказательствам того, что план не работает).

Во время встречи Product Owner отвечает на вопросы команды. Какие требования являются приоритетными – это делает Product Owner. Тем не менее, если скрам-процесс проходит с нарушениями (кто-либо из команды опаздывает на daily-meeting), то мастер должен вмешаться и исправить ситуацию. В течение спринта, новые требования не могут появится в Sprint backlog. Это список всех требований, которые нужно сделать по проекту. Когда в Backlog’e нет требований, проект считается завершенным.

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

Предложить свой продукт

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

Гибкие команды создают максимально простые решения, избегая ненужных функций или чрезмерно сложного программного обеспечения (принцип № 10). Но самоорганизующаяся команда не имеет явных требований или фаз разработки. Ее члены совместными усилиями планируют проект (вместо того чтобы полагаться на одного человека, «владельца» плана) и регулярно его пересматривают. Такие команды, как правило, разбивают проект на пользовательские истории или другие мелкие части и начинают работать с наиболее ценными для компании частями. Только после этого подходит очередь подробных требований, дизайна и архитектуры.

• Важно постоянно поддерживать мотивацию, создавать комфортную обстановку и обеспечивать поддержку.
• Мы стремимся поставлять полностью рабочее программное обеспечение каждые несколько недель, в крайнем случае — каждые несколько месяцев.
• Помните интенсивные встречи, на которых бизнес-аналитики совместными усилиями тщательно выводят обширный список исчерпывающих требований?
• Ведь если не создать описание этой конкретной функции, требования, дизайна или примера, то кто-нибудь неправильно поймет документ.
• Если вы хотите добавить отдельную колонку, обозначающую этап верификации задачи – отличная идея!
• Тюнинг в виде Planning Poker— это тоже работа в первую очередь с людьми, цель которой — сделать сложный процесс оценок более простым и независящим от авторитетов.

Разработчики используют итерации для поставки рабочего программного обеспечения, но они завалены документацией. Все действительно счастливы, что не застряли над созданием ПО, которое не будет продаваться. Кажется, что они тратят столько же усилий на обновление документации, сколько и на написание кода. В этот https://deveducation.com/ момент Agile становится привлекательной для традиционного командно-административного менеджера проекта. Установка ограничений на продолжительность итераций дает ему эту возможность. Кроме того, решается также одна из главных задач менеджера — работа с изменениями, которые возникают в самом конце проекта.

Agile/Scrum для начинающих

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

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

Сотрудничество с клиентомважнее согласования условий контракта. В этом материале мы презентуем проектный Bi-Cycle — легковесный гибридный проектный фреймворк для проектов на стыке Agile и классического проектного управления. Среди 12 доменов бизнес-гибкости, показанных на рисунке, Agile полностью покрывает домен «Гибкость процессов», но также связан в той или иной степени с 5-ю другими доменами, по меньшей мере. Конечно, Scrum и Kanban — это далеко не единственные подходы, входящие в Agile. Но большинство других активно развивающихся сейчас гибких подходов касаются проблем другого уровня, нежели описанные в этой статье. В идеале, люди самостоятельно принимают решения и несут за них ответственность.

Agile

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

Постоянное совершенствование проекта и команды

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

Как был создан Agile-манифест?

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

Как применять принципы Agile-манифеста в HR?

Тюнинг в виде Planning Poker— это тоже работа в первую очередь с людьми, цель которой — сделать сложный процесс оценок более простым и независящим от авторитетов. Очень ярко рассказана история Scrum и предпосылки его возникновения в книге Джеффа Сазерленда (бывший военный летчик, стоявший у истоков создания scrum). Например, наглядно показано, что люди очень плохо умеют оценивать объем работы в абсолютных величинах, но намного лучше делают это в относительных. Как устроен https://deveducation.com/ формат пользовательской истории, почему он такой, как формат помогает в обсуждении и понимании ценности заказчику и команде. На этом воркшопе вы узнаете, как сделать использование продукта удобным, понятным, простым и завоевать доверие пользователей, опираясь на их обратную связь и факты. Андрей расскажет о принципах формирования Agile-культуры в крупных компаниях, о возможностях и сложностях внедрения Agile-подходов и фреймворков Scrum и Kanban в российской специфике.

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

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

Автор: Кирилл Семушин