«Мы работаем по agile» — обычно с такой фразы начинают представление компании опытные продавцы услуг IT услуг. «Ммм, я такое слово слышал, кажется это что-то модное», — думает человек на другом конце трубки, — «Эти ребята наверное крутые». Но не спешите делать выводы — применение гибких методик не гарантирует результат и не делает IT компанию «крутой» по-умолчанию. Почему? Расскажу ниже.
Давайте определимся что же такое пресловутый Agile. В конце 80х началось то, что историки позже назовут «третья промышленная революция». Её обычно характеризуют появлением цифровых технологий, распространением интернета и улучшения связи в целом. В нашем контексте важно другое. Интернет и связь усилили глобализацию: конкуренция перестала быть локальной, и смело перешагнула границы стран и континентов. В условиях, когда у компаний появились новые, доселе невиданные, конкуренты и условия работы, на передовую вышли информационные технологии. В первую очередь, речь идёт о развитии онлайн торговли и WEB технологий в целом. Компании не могли больше себе позволить ждать новую версию сайта месяцами и годами. Им нужно было получать результат быстрее конкурентов. Счёт шёл на недели, дни или даже часы. Вот тут-то (2001 год) и подсуетились Кент Бек (Kent Beck), Мартин Фаулер (Martin Fowler), Джеф Сазерленд (Jeff Sutherland) и прочие со своим Agile Manifesto. Они разработали четыре правила и двенадцать принципов гибкой разработки программного обеспечения.
Если внимательно ознакомиться с составом Манифеста, и держать в голове время, в которое он появился, то всё складывается в понятную картинку. Авторы Манифеста пытались определить принципы, которые помогли бы разработчикам программного обеспечения давать компаниям полезные программные продукты быстрее, помогать опережать конкурентов и занимать новые рынки.
Ещё один важный компонент того что называется «гибкими методиками» — это методика управления проектами SCRUM. Я упоминаю его вторым в списке, но на самом деле сама книга «Agile Software Development with SCRUM» вышла раньше появления Манифеста. Важна эта методология по нескольким причинам:
- Это был первая целостная концепция гибкой разработки ПО;
- Уже в 2002 году появляется Scrum Alliance — организация, которая формирует культуру гибкой разработки, а также сертифицирует специалистов по этой методологии. Сертификат от Scrum Alliance признаётся и является ценным достижением для профессионалов во всём мире; По данным scrum.org в мире сертифицировано 529 000 скрам-мастеров (о том кто это такие — ниже);
- По данным Scrum Allince (данные за 2016 — 2018 годы), 94% респондентов из 96 стран указали что используют именно SCRUM в проектах гибкой разработки ПО;
- Методика постоянно развивается и подстраивается под современные условия. На текущий момент (04.2021) вышло 6 редакций, последняя из которых — в Ноябре 2020го;
- На основании SCRUM созданы десятки методик, которые копируют и дополняют основы SCRUM;
Так что же не так со всем этим гибким прекрасным будущим, и почему применение SCRUM не гарантирует ожидаемого результата? Всё просто: Agile как идеология и любая методика управления проектами работает тогда, когда применена полностью. Джефф Сазерленд (один из авторов Agile Manifesto и методологии SCRUM) приводит неутешительную статистику: из 100% проектов, использующих SCRUM, только 10% получают все его бонусы – высокую производительность, качество и т.д. Остальные 90% команд хоть и стараются быть гибкими, но таковыми не являются.
Виновником такого положения вещей является ScrumBut (Скрам-Но), или, переводя на русский почти дословно, недо-скрам. Появляются те самые «но» по очень простой причине: использовать всю методологию SCRUM просто-напросто дорого. Ниже объясню почему. Из-за этого, команды принимают что они стремятся использовать скрам, но они не хотят выполнять одно из действий, предусмотренных методологией. Например: Мы используем скрам, но проводить каждое утро планёрки — это скучно. Мы используем скрам, но проводить совещания по результатам спринта — это скучно. Ну и так далее. Понимаете? Это звучит как «Я купил мотоцикл, но носить шлем — это скучно». Что обычно бывает с такими мотициклистами? А думаете в бизнесе по-другому?
Я выше упомянул что SCRUM — это дорого. Давайте разбираться из чего состоит стоимость применения гибкой (да и любой другой) методики:
- Из времени команды на специфические активности
- Из времени руководителя на контроль соблюдения методологии и специфические мероприятия
- Из времени представителя бизнеса на специфические мероприятия
Так как эта статья не для профессионалов в IT а для широкого круга читателей — я постараюсь не углубляться в детали, а просто скажу что по каждому из пунктов активностей должно происходить много, а часть из них — вообще на ежедневной основе. Именно это подталкивает команды отказываться, сокращать или пересматривать активности, предусмотренные методологией. Итого получается вроде скрам, а вроде и нет. именно поэтому верить компании, которая в своих буклетах утверждает что они гибкие и модные не особо стоит. Спросите лучше проводят ли они Ежедневный Скрам (Daily Scrum) или пересмотр спринта (Sprint Review).
Что же на самом деле предполагается когда подрядчик предлагает вам работать по гибкой методологии:
- Результат вы будете получать быстро, небольшими порциями и, скорее всего, каждый день;
- Любые задачи которые возникают у вас сегодня — будут решены в очередном коротком промежутке планирования, который в терминах SCRUM называется «Спринт». Рекомендуемая продолжительность спринта — 1 — 3 недели. То есть если сегодня поставить задачу — то максимум через 6 недель (если вам не повезло, и спринт начался только сегодня) вы получите готовый результат;
- Зачастую, вы сможете свободно управлять приоритетами задач, и по важным вопросам получать результат быстрее, не дожидаясь очередного спринта.
Надеюсь, я смог донести основные составляющие гибких методологий, и при этом не запутать неподготовленного читателя. Буду рад любым замечаниям и комментариям.
Добавить комментарий