Рассказываем, что из себя представляет методология Agile, на каких принципах она основана, как работает на практике и какие проблемы может спровоцировать.
Agile – больше, чем методология управления. Это целая философия, которая продвигает радикально иной подход к проектной работе. В этом смысле, Agile вообще не про «управление», а про работу без руководителей, но с командой, участники которой несут ответственность друг перед другом. То есть «горизонталь» вместо «вертикали».
В чём идея
Гибкую методологию управления придумали, чтобы решить ряд проблем классической/каскадной/водопадной методологии (Waterfall). Например, слишком большой упор на планирование и влияние задержек в одних командах на работу других. Для этого, как я уже сказал, пришлось полностью пересмотреть взгляд на проектную работу, а не менять какие-то отдельные механики.
«Гибкость» заключается в способности agile-команды постоянно адаптироваться к изменяющимся условиям и достигается за счёт:
- Итеративности. Вместо того чтобы долго-долго прорабатывать план, а потом ещё дольше делать идеальную версию продукта, agile-команда старается как можно раньше выпустить работоспособный прототип, а затем раз за разом его тестировать и допиливать. Итеративность может негативно повлиять на продолжительность разработки, но зато у тебя почти сразу есть более или менее рабочий продукт.
- Самоорганизации. В команде все равны, нет никаких руководителей и управляющих, а значит нет и адских согласований. Это экономит ресурсы, особенно время.
- Взаимопроникновения знаний. Любой специалист в agile-команде должен иметь хотя бы базовые знания о смежных специальностях. Помимо кросс-функциональности, постоянно погружение в новые темы позволяет держать мозг в тонусе (вообще, если мозгу регулярно давать новую информацию, ещё и деменция придёт гораздо позже; но это совсем другая история).
Краткая история Agile
Гибкий подход начинает своё существование где-то с первой половины XX века (хотя, есть мнение, что что-то на него похожее было и раньше). Примерно в 30-х физик Уолтер Шухарт применяет итеративный подход Plan-Do-Study-Act, которым делится со своим учеником Ульямом Демингом (сейчас мы знаем этот подход к управлению, как Цикл Деминга). После окончания Второй мировой, компания Toyota (та самая, где придумали Lean, Kanban и много чего ещё, связанного с Agile) нанимает Деминга обучить своих менеджеров.
В следующие годы во многих компаниях придумывают свои методики гибкого управления: Scrum, XP, FDD и так далее. Но про «agile» никто не говорит до 2001 года, пока 17 разработчиков, практикующих методики гибкого управления, не собираются вместе и не составляют Манифест гибкой разработки программного обеспечения (Manifesto for Agile Software Development или просто Agile Manifesto). Здесь и возникает понятие «agile», вокруг которого сегодня столько разговоров.
Основные ценности Agile-методологии
В статье про методы управления проектами я дал такое определение:
Методология — набор методов и принципов, подкреплённых теорией.
Так вот теория в случае с Agile — это ценности, описанные в Agile Manifesto:
- Люди и взаимодействие важнее процессов и инструментов. Если в твоей команде есть принципы, традиции, структуры, инструменты или условия, которые явно мешают работе — от них следует избавиться. Люди сами должны выбирать способ организации, набор процессов, используемые инструменты. В конце концов, всё это должно помогать работе, а не мешать.
- Работающий продукт важнее документации. Это не значит «работать по Agile — работать без документов». В agile-командах тоже есть документация, но на неё не тратят огромное количество времени и ресурсов.
- Сотрудничество с заказчиком важнее согласования условий контракта. Посмотри немного дальше согласования ТЗ и сметы. Нет смысла портить отношения с заказчиком, пусть и ценой своевременной оплаты. Если ты не можешь согласовать работы и портишь общение, в итоге потеряешь и этого клиента, и, возможно, следующих. Любые контракты, документы и соглашения должны идти на руку твоим взаимоотношениям с клиентами, а не портить их.
- Готовность к изменениям важнее следования первоначальному плану. Даже если есть план проекта, в него, почти наверняка, со временем придётся внести изменения — в этом суть Agile.
Ещё в Манифесте описаны принципы, но скорее в попытке разжевать ценности. Так что приводить я их здесь не буду. Если хочешь, сходи почитай на Википедии.
Какие могут быть проблемы
Ай, какой классный Agile, да? Увы, хотя его и можно применять в любой компании (даже если ты — прости, Господи — банк), подходит он далеко не всем. Да ещё и его внедрение может быть крайней болезненным.
Я вижу три проблемы (хотя, вполне может статься, что их больше), из-за которых нельзя советовать переходить на Agile всем подряд:
- Сложно отказаться от концепции «начальник — подчинённый». Ведь Agile — это не способ планирования, а философия работы всей команды. Далеко не каждая компания сможет спокойно пережить подобную трансформацию.
- Не все готовы к по-настоящему командной работе. Многим людям комфортнее работать в одиночку, отчитываться перед руководством и никуда не лезть. А в случае с Agile всем придётся во всём разбираться и постоянно участвовать в чужой работе.
- Не все готовы к тому, что часть времени может просто пропасть. Допустим, команда работала над задачей, а потом оказалось, что цели проекта поменялись и продолжать почти законченную работу нет смысла. Все твои усилия были напрасны. Это психологически сложная ситуация, которая может запросто убить всю мотивацию.
Но если твоя команда работает над кучей проектов, хорошо знает своё дело и топит за идеальный результат, возможно, Agile — это ваше.
Agile-методология позволяет то, что не позволяет каскадная модель — создавать качественные продукты без подробнейшего плана на все этапы. Всё благодаря итеративности, обратной связи клиентов и сотрудников и самоорганизации команды.
Главное, помни, что Agile – это методология и философия. Чтобы применять всё это для управления проектами, из этого конструктора нужно собрать свою методику или выбрать одну из существующих — о них я расскажу в следующих статьях.
Источник: https://weeek.net/ru/blog/chto-takoe-agile