База знаний

Метод «Agile» - как и когда использовать систему гибкого планирования в стартапе?

09 ноября 2018

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

Зачем используется Agile?

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

Agile противоположен подходу, когда применяется тщательное предварительное планирование, согласование.

Что из себя представляет Agile?

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

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

Как работать, применяя метод Agile?

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

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

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

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

Если количество людей меньше, то роли объединяются и так вплоть до одного человека.

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

В каких случаях уместно применять Agile подход?

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

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

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

Для использования Agile никакие сложные инструменты не нужны: вполне можно использовать обычные бумажные стикеры, Excel или программу trello.

Главное договориться со всеми участниками процесса, донести суть и при этом учитывать ограниченность трех основных ресурсов: навыков, времени и денег.

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

Руководитель разработки создает в trello 5 досок:

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

- «Сделать» - На эту доску перемещаются отобранные задачи, к которым программисты вскоре приступят.

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

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

- «Готово» - Руководитель разработки может ознакомиться с завершенными задачами, после чего отправляет карточку в архив.

И так по кругу.

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

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

Принципы, которые разъясняет Agile Manifesto:

  • удовлетворение клиента за счёт ранней и бесперебойной поставки ценного программного обеспечения;

  • приветствие изменений требований даже в конце разработки (это может повысить конкурентоспособность полученного продукта);

  • частая поставка рабочего программного обеспечения (каждый месяц или неделю или ещё чаще);

  • тесное, ежедневное общение заказчика с разработчиками на протяжении всего проекта;

  • проектом занимаются мотивированные личности, которые обеспечены нужными условиями работы, поддержкой и доверием;

  • рекомендуемый метод передачи информации — личный разговор (лицом к лицу);

  • работающее программное обеспечение — лучший измеритель прогресса;

  • спонсоры, разработчики и пользователи должны иметь возможность поддерживать постоянный темп на неопределённый срок;

  • постоянное внимание улучшению технического мастерства и удобному дизайну;

  • простота — искусство не делать лишней работы;

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

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