Принципы Agile — это просто. Рассуждаем о гибкой методологии Agile

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

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

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

Почему Agile?

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

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

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

1-20219-ebaa40.png

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

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

Так что же такое Agile?

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

2-20219-fb26b4.png

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

Задачи (user stories) поставляются или непрерывно, или маленькими циклами, которые называются спринтами.

3-20219-acb34f.png

Как работает Agile?

Общий алгоритм можно представить следующим образом: «Требования—План—Работа—Ревью—Повтор».

4-20219-1a64fe.png

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

Далее следует оценить каждый этап разработки, что делается по часам либо по story point’ам. Story point — относительные оценки, выставляемые в сравнении и по отношению с другими stories. При этом нужно учитывать, что есть вероятность неточного результата, то есть вы не сможете получить четкое представление о том, сколько конкретно времени уйдет на реализацию проекта.

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

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

Scrum vs Kanban

Это можно назвать двумя основными фреймворками для Agile.

5-20219-8792d0.png

Давайте их сравним: 1. Scrum: - делит работу на части, называемые спринтами (как мы уже говорили, чаще всего речь идёт о двухнедельных спринтах); - спринты планируются на основании требований для конкретного момента времени; - используется относительная оценка времени выполнения работы; - выполняется ревью каждого спринта, что помогает понять, как всё прошло, что можно улучшить и т. п.; - по поставляемому продукту даётся фидбек; - каждый день проводятся очень короткие собрания. 2. Kanban: - собрания проводятся еженедельно; - разработка производится непрерывно; - процесс реализации проекта визуализируется на доске; - сначала решаются наиболее важные задачи; - улучшения выполняются поэтапно.

Вместо заключения

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

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

Данный материал является свободным переводом статьи What is Agile Workflow? (ELI5). Первоисточник находится здесь.

Автор
0 комментариев
Для комментирования необходимо авторизоваться