7 техник из Agile, которые помогут вам работать эффективнее

Agile, или Гибкая методология разработки, — это свод техник и практик, которые нацелены на то, чтобы ускорить работу команды и сделать ее эффективнее. Почти все техники сводятся к тому, чтобы разбить большой объем работы на несколько подзадач или этапов (итераций). Согласно отчету VersionOne, 94% организаций из сферы разработки программного обеспечения придерживаются Agile. В этой статье дадим 7 техник, которые вы можете взять на вооружение для оптимизации работы своей команды. 

1. Итеративное планирование

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

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

2. Итеративное выполнение задач 

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

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

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

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

3. Пользовательские истории

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

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

Формат можно корректировать. Пользовательские истории должны соответствовать следующим признакам: 

• Самостоятельность
• Возможность обсуждения
• Ценность
• Возможность оценки
• Небольшой объем
• Возможность тестирования

4. Оценка и определение приоритетов

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

Покер планирования — это гибкая методика оценки, основанная на договоренностях и консенсусе. Чтобы начать сеанс покера планирования, владелец продукта или клиент читает пользовательскую историю и описывает ее функцию оценщикам. Каждый оценщик держит в руках колоду карт со значениями 0, 1, 2, 3, 5, 8, 13, 20, 40 и 100. Эти значения представляют собой количество дней или других единиц измерения, в которых оценивается работа команды.

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

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

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

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

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

5. Демо, ретроспективы и стендапы

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

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

6. Коммуникация и сотрудничество

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

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

7. Командные структуры и роли

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

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

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

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

Источник: smartinsights.com