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

Agile — это методология разработки программного обеспечения, призванная помочь командам быстро и эффективно создавать продукты.

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

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

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

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

Продукт должен решать задачи клиента и нравится ему. Поэтому Аджайл–команда начинает работу над продуктом с выяснения того, что нужно клиенту. Команда выпускает новый функционал, и каждый раз собирает обратную связь у клиента. Это помогает сделать продукт, который решает поставленные задачи. За такой продукт люди готовы платить.

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

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

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

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

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

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

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

Существует множество преимуществ agile–подхода, включая:

• повышенная гибкость

• повышение эффективности и производительности

• повышение качества работы

• расширение сотрудничества между командами

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

Особенно хорошо Agile показывает себя в условиях работы в условиях высокой неопределенности.

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

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

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

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

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

Сократите количество узкоспециализированных специалистов, начните искать и развивать T-Shaped специалистов. Начните работать кроссфункциональными командами. Сократите количество «компонентных» команд (работающих с отдельными частями продукта) и повысьте количество функциональных команд (которые разрабатывают продукт end-to-end).

Agile — это набор принципов и практик для разработки программного обеспечения. Вкратце его можно описать следующим образом:

• Работайте в небольших командах.

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

• Принимать решения через регулярные промежутки времени, основываясь на целях и фактах.

• Стройте проекты вокруг мотивированных людей. Обеспечьте им необходимые условия и поддержку и доверьте им выполнение работы.

• Наиболее эффективными и действенными методологиями разработки программного обеспечения являются самоорганизующиеся команды.

Чтобы работать в Agile, вам необходимо:

• Планировать свою работу на короткие циклы (спринты)

• Работать кросс–функционально с членами вашей команды

• Использовать быстрые циклы обратной связи для принятия решений

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

Agile — это методология управления проектами, которая фокусируется на коротких, итеративных циклах разработки и частом предоставлении рабочего программного обеспечения.

Но какой смысл в наличии процесса, если вы не знаете, что это такое?

Вот четыре вещи, без которых Agile не будет работать:

1. Видение вашего продукта, включая особенности и функциональность

2. План того, как ваша команда будет реализовывать это видение.

3. Коммуникация между всеми, кто участвует в создании продукта (например, клиентами, менеджерами).

4. Способ измерения результатов

Agile — невероятно мощная методология, но и у нее есть свои ограничения.

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

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

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

Agile не будет работать без четкого видения продукта и способности донести это видение до команды.

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

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

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

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

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

Первым шагом во внедрении agile является оценка текущей ситуации. Какие процессы у вас существуют? Хорошо ли они работают? Не сломаны ли они?

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

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

Одним из основных шагов во внедрении agile является определение проблем и целей, которые вы хотите решить.

Затем необходимо выяснить, каковы культура и структура вашей организации. Это поможет вам понять, подходит ли agile для вашей компании или нет.

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

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

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

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

Хорошие консультанты Agile стоят дорого. Давайте примерно рассчитаем: Допустим, 1 команда живет под наблюдением и помощью консультанта Agile хотя бы пол года (за это время приходит понимание, в нужную ли сторону идет команда), доукомплектовываем команду хорошими скрам–мастерами. В сумме получится от 1.000.000 руб. минимум. В среднем около 2.500.000.

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

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

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

Если в вашей компании есть небольшие команды, и при этом всего один или два разработчика на команду, то вы можете попробовать метод экстремального программирования (Extreme Programming, или XP). Этот метод фокусируется на индивидуальной производительности и оптимизации путем объединения каждого разработчика с другим разработчиком, обладающим взаимодополняющими сильными сторонами (это известно как объединение в пары).

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

В среднем, компании, внедряющие Agile, получают возврат инвестиций (ROI) около 300%. Именно так — они в три раза увеличивают свои инвестиции менее чем за год.

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

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

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

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

Разница между Agile–коучем и Scrum–мастером зависит от компании.

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

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

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

• Собираете обратную связь у клиента и пользователей на каждом этапе работы над продуктом.

• Разбиваете работу над проектом на задачи и подзадачи.

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

• Показываете часть продукта клиенту, после каждого этапа работы. Один этап длится 2-3 недели.

• Расставляете приоритеты. То, что продвинет проект вперед, делаете первым. То, что не так важно для прогресса подождет до завтра.

• Меняете продукт на любом этапе, если изменился бизнес клиента, требования рынка или он не решает задачи пользователей.

Если вы узнаете в этом себя и свою команду — то вам стоит задуматься о том, как внедрение Agile может помочь вам повысить производительность и увеличить Time to Market. Вы далеки от agile, если вы:

• Собираете требования клиента на старте проекта и следуете им до его завершения.

• Работаете по плану: три недели на дизайн, месяц на программирование и верстку, десять дней на тестирование.

• Заранее планируете нагрузку на членов команды. Объем задач определяете на старте проекта и не отходите от него. Если кто–то не успевает, сдвигаете сроки всего проекта или подгоняете команду.

• Показываете клиенту продукт, когда все работы по нему завершены. Или демонстрируете результат после каждого большого этапа: сделали дизайн — показали, сделали верстку — показали.

• Работаете по плану, который согласовали с клиентом на старте проекта. Выпускаете продукт в том виде, в каком он был в самом начале согласован с заказчиком.

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

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

Команда использовала форму Agile–метода под названием "Экстремальное программирование" (XP), которая показала свою эффективность в работе. Они решили кодифицировать этот метод в набор принципов, которые можно было бы применять в разных отраслях и контекстах. Результатом стал Манифест Agile, который был опубликован в Интернете в 2001 году.

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

Подход Crystal появился в 1992 году. В его основе лежит командная работа, обсуждение задач и работы. Важно, чтобы все понимали, кто и что делает. Продукт создают по кусочками, код выпускают через частые поставки.

Метод Scrum появился в 1995 году. Он основан на отказе от долговременного планирования. Вместо этого Скрам предлагает делить разработку на короткие этапы. Каждый этап заканчивается экспресс–оценкой и внесением правок. Важное место в Скрам отводят расстановке приоритетов.

Метод экстремального программирования — XP возник в 1996-1999 году. В этом методе работа над продуктом строится на пользовательских историях — User Stories. Это сценарии, которые пользователь проходит в продукте. Например, загрузить фотографию на аватар или оформить заказ товара в корзине. В XP зародились и продуктовые релизы. Это результат каждого этапа работы над продуктом.

У каждого из этих методов есть свои авторы — разработчики и инженеры. Двадцать лет назад они собрались на горнолыжном курорте Сноуберд в США.

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

Что именно происходило на горнолыжном курорте, одному Богу известно. Но результатом их встречи стал Манифест Agile, который с тех пор был принят многими другими отраслями и компаниями как способ повышения эффективности и качества в различных сферах бизнеса. Документ, который навсегда изменил подход к разработке IT–продуктов.

Создатели методологии Agile

Аджайл–манифест — это документ, в котором описаны принципы и ценности гибкой разработки. Манифестом его назвали за то, что ценности звучат как боевой клич и противопоставляются традиционным принципам работы.

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

Манифест построен вокруг четырех ценностей:

1. Люди и взаимодействие важнее процессов и инструментов.

2. Работающий продукт важнее исчерпывающей документации.

3. Сотрудничество с заказчиком важнее согласования условий контракта.

4. Готовность к изменениям важнее следования плану.

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

На первое место встает работающий продукт, а не документы и согласования.

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

Цель разработки — принести пользу клиентам. Каждая задача дает ценность. Нет разработке ради разработки.

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

Методы гибкого управления подходят не только для IT–компаний. Их применяют строительные фирмы, банки, стоматологии, медцентры, бренды одежды и другие бизнесы.

Scrum выбирают для проектов, которые создают с нуля. Команде не от чего оттолкнуться, какой результат будет в конце — неизвестно. Задачи в Скрам делятся на подзадачи, для каждой назначается свой приоритет: делать ее сейчас или позже. Задачи распределяются на спринт, который длится 2-3 недели. В конце спринта команда выпускает готовую часть продукта или функцию.

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

В Scrum–команду входит Product owner (владелец продукта) и Скрам–мастер. Product owner выступает в роли руководителя, он общается с заказчиком, ставит задачи команде. Scrum master планирует и организует совещания, он отвечает за соблюдение правил Скрам, устраняет препятствия, которые мешают команде работать.

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

Kanban перешел в IT с заводов Тойота, его использовали в цехах, чтобы контролировать объемы и сроки производства. Канбан помогал производить столько деталей, сколько нужно потребителям.

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

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

Пример: есть приложение онлайн–стилист. Нужно добавить к нему функционал онлайн–шопинга со стилистом.

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

Метод Lean помогает разобраться, в каком месте компания теряет ресурсы, время и деньги.

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

Пример: при работе над приложением онлайн–стилист команда потратила время на дизайн кнопок. Для пользователей было важнее наладить поиск одежды по брендовым магазинам.

Agile — это не универсальный инструмент, который разом решит все проблемы и поможет создать прорывной продукт. Spotify и Netflix работали по Agile с самого начала, это помогло им стать лидерами в своих нишах. Amazon переходил на гибкие методы управления постепенно, и это дало свои результаты. Но есть еще тысячи примеров компаний, которые перешли на Аджайл и закрылись.

Методология подойдет, если у вас есть опытная команда. В команде работают сотрудники–профессионалы, которые готовы, если нужно, подтягивать новичков.

Agile помогает стартапам быстро получить рабочую версию продукта или MVP (минимальный жизнеспособный продукт). Это не гарантирует, что вы не провалитесь через год. Но гарантирует, что этот год вы потратите с умом и получите опыт.

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

Agile–планирование в условиях крайней неопределенности — это стратегия планирования, которая позволяет командам быстро двигаться и менять направление по мере необходимости.

Как правило, при планировании agile–проектов команда начинает с плана высокого уровня, затем учитывает реалии ситуации (например, изменение требований) и корректирует свои планы в соответствии с ними. Эта стратегия хорошо работает во многих случаях.

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

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

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

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

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

Agile–планирование — это методология, которая особенно хорошо подходит для ситуаций крайней неопределенности.

Agile–планирование в условиях крайней неопределенности включает в себя следующие шаги:

1. Определить все возможные риски и возможности, связанные с проектом.

2. Для каждого риска или возможности определить вероятность его возникновения и его влияние, если он возникнет.

3. Присвоить каждому риску или возможности значение, основанное на их вероятности и воздействии, используя один из нескольких методов (например, средневзвешенное значение 1/3).

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

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

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

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

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

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

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

Рискуете, бесконечно набиваете шишки. Потом встаете и все по кругу.

Вы бесконечно тестируете все, что создаете.

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

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

Вы больше не сможете никого наказывать штрафами, даже если очень хочется.

Будьте готовы отказаться от долгосрочного планирования: завтра проект может свернуть в другую сторону.

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

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

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

Религиозные войны между адептами Agile и сторонниками негибкой, каскадной модели управления уже в прошлом. Сегодня многие из тех, кто когда–то перешел на «чистый Agile», применяют гибридный подход к управлению проектами. Почему и когда такое происходит?

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

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

Такой гибрид Agile и Waterfall применяли и в компании Schneider Electric. Это позволило команде разработчиков программного обеспечения работать независимо от команды, которая отвечала за "железо". Разработчики применяли Agile. А вторая команда не отступала от каскадной модели. Планировали все этапы и следовали жестким срокам.

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

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

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

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

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

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

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

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

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

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

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

Существует множество ситуаций, в которых Agile не является лучшим подходом для проекта.

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

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

Эта подборка книг поможет разобраться с принципами Agile и «продать» эту философию команде разработчиков.

• Agile Project Management for Dummies Марка Лейтона. Здесь много практических примеров и реальных кейсов, как компании внедряют и реализовывают проекты по Agile. Можно брать и пробовать у себя. Плюс полезные советы, как прокачать членов команды и руководителей.

• The Software Project Manager’s Bridge to Agility от Michele Sliger и Stacia Broderick. Эта книга пригодится тем, кто переходит на Agile с традиционных методов управления проектами. Или тем, кто сейчас задумался, а, собственно, надо ли? Авторы подробно рассказывают о разнице между подходами и способах безболезненного перехода.

• Project Management the Agile Way: Making it Work in the Enterprise, автор John Goodpasture. Здесь много полезного про техники и инструменты, которые нужны под разные проекты. Еще книгу можно смело давать членам команды, чтобы они прониклись философией Agile и точно поняли, чего вы от них хотите.

• Agile Retrospectives: Making Good Teams Great от Esther Derby и Diana Larsen. Эта книга особенно пригодится тем, кто начинает проводить ретроспективы или не доволен тем, как они проходят сейчас. Тут описаны способы организации этих встреч, причем не только удачные, но и не удачные варианты, рассказано, как мотивировать команду к активному участию в них. И, главное, как сделать ретроспективы реально полезными для всех, а не для «галочки». Еще здесь описаны способы, как усилить вашу и без того классную команду.