Сегодня гибкие разработки переживают пик своей популярности – множество IT (и не только IT) компаний работают исключительно по ажайл. А те, кто отстал от тренда спешно нанимают тренеров, переучивают сотрудников, перестраивают процессы и внедряют у себя agile в том или ином виде.
Но так ли хорош и универсален ажайл как утверждают его адепты? Ведь при неумелом использовании он может принести намного больше проблем и разочарований от своей гибкости, чем пользы? Давайте разбираться вместе...
Рассмотрим наиболее распространенные кейсы и вопросы которые волнуют менеджеров и владельцев бизнеса, когда они задумываются о переходе на гибкие разработки:
Ответы на все эти вопросы отнюдь не тривиальны и требуют понимания основ гибких разработок, их сильных и слабых сторон.
В нашем цикле статей посвященных особенностям работы по ажайл мы раскроем вам все секреты, которые позволят принимать обдуманные и взвешенные решения.
Ажайл предполагает:
Также, ажайл перестает эффективно работать при длинных итерациях, какой смысл в гибких разработках, если мы увидим результат наших коррекций только через пол года - год?
Также, ажайл перестает эффективно работать при длинных итерациях, какой смысл в гибких разработках, если мы увидим результат наших коррекций только через пол года - год?
Но как быть в таком случае со сложными проектами, такими как: строительством мостов, зданий, производством самолетов, ракет или медицинского оборудования?
Можно ли построить Мост по ажайлу, если после реализации и демонстрации каждого компоненты у нас будут уточняться требования и приоритеты?
Ведь в таком случае, узлы будут изменяться и поставляться согласно меняющимся приоритетам заказчика, а не так как это необходимо с инженерной точки зрения. Более того, изменения в конструкции некоторых из узлов может привести к катастрофическим последствиям: компоненты могут перестать сочетаться или могут быть оказаться нарушены общие требования к прочности и безопасности конструкции...
В IT также существуют множество сложных проектов, требующего тщательного планирования. Это и софт для финансовых или медицинских учреждений, и программы по управлению различными узлами в самолетах, машинах ракетах... Перечислять можно очень долго.
Все звучит так, что стоит отказаться от agile в сложных проектах и использовать старый добрый водопад, с гигантскими спецификациями, четкими процессами и полной невозможностью изменить что либо после начала проекта...
Однако, мы считаем, что даже при реализации любых супер сложных задач, гибкие разработки все еще возможно и нужно применять, хотя и с оговорками. Ведь, ажайл подарит огромные преимущества любому проекту.
Благодаря постоянным коррекциям и обратной связи на всех этапах, итоговый продукт получится намного современнее, будет лучше соответствовать нуждам ваших клиентов, будет внедрен с учетом самых последних тенденций и технологии, чего конечно мы будем лишены в случае водопадной модели.
Конечно же, это будет весьма нетривиальный вызов. Он потребует команду опытных менеджеров, глубокого вовлечение технических специалистов, а также мощных инструментов для визуализации и планирования задач.
Нельзя даже пробовать, браться за изменения в процессах разработки, если вы управляете проектами только с помощью доски со стикерами, через excel, outlook, или через какое нибудь другое, устаревшее и неудобное приложение. Очень важно чтобы это был мощный современный инструмент (Такие как TBB, Jira, Azure DevOps) обладающими широкими возможностями для мониторинга всех важных деталей проекта с различных ракурсов.
Итак, вернемся к примеру со строительством моста. Чтобы иметь возможность реализовать этот проект по ажайл, в первую очередь необходима правильная декомпозиция скоупа работ на слабо зависимые модули. (Аналогичная схема применима для любого сложного проекта) 
После необходимо выделить:
В процессе реализации, проектная команда должна тщательно отслеживать все изменения особенно в зонах взаимодействия модулей, тщательно тестировать их на совместимость и также осуществлять периодическую ревизию всего проекта на предмет соответствия общим стандартам.
Например, мы можем разбить конструкцию моста на следующие модули:
Опоры, Рролеты, инфраструктура вокруг моста и декоративная отделка моста.
Возможно, эти рекомендации звучат немного размыто. Но каждый проект по своему уникален и каждый должен искать свой путь для гибкого внедрения. В данной статье мы показали упрощенный пример, как можно подходить к реализации, сложных проектов с использования преимущества гибких подходов.
Более подробно ознакомиться с одним из перечисленных инструментов по управлению проектами и другими нашими статьями вы можете здесь.
