Вестник цифровой трансформации

Три заблуждения о скорой разработке
Три заблуждения о скорой разработке




Методология agile приобретает все больше сторонников в корпоративной среде, но у руководителей ИТ-служб есть ряд общих заблуждений по этому поводу

09:24 27.07.2016  |  Шерон Флорентин | Методология agile приобретает все больше сторонников в корпоративной среде, но у руководителей ИТ-служб есть ряд общих заблуждений по этому поводу4967 просмотров



Методология agile приобретает все больше сторонников в корпоративной среде, но ряд заблуждений еще остаются – и хуже всего то, что они сохраняются у ИТ-руководителей. И эти стойкие заблуждения мешают более широкому распространению методологии.

Заблуждение 1: Методология agile вносит сложности в бюджет

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

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

«Вряд ли ИТ-директору понравится годовой бюджет ИТ-службы в размере 25 млн долл., из которых 15 млн долл. приходится на незавершенную разработку ПО, – подчеркнул Дусет. – Массовый переход на методологию agile можно только приветствовать, но, поскольку бюджеты по-прежнему верстаются исходя из методологии водопада, возникает много трудностей с продуктами и бюджетированием,. Для реального ускорения необходимо внедрять agile-подход, причем в отношении как мэйнфреймов и унаследованных приложений, так и современного ПО и новых продуктов».

Заблуждение 2: Переход к agile-методологии проводится по указанию сверху

«Я не раз сталкивался с ситуацией, когда ИТ-директор из компании, входящей в список Fortune 500, прочитав статью об agile-разработке, сразу загорается этой идеей, – говорит Мэнни Гонсалес, генеральный директор компании Scrum Alliance. – После того как соответствующее указание доходит до одного из ИТ-менеджеров, вызывают нас, приглашают нашего консультанта и пытаются проводить необходимые преобразования. Но это не agile-подход – это указание, исходящее сверху. Мы ощущаем разрыв в знаниях и определенное сопротивление: люди просто не понимают принципов методологии, которую предстоит внедрить в масштабах всей организации».

В какой-то степени это объясняется отсутствием четкого представления о важности agile- проектирования на всех уровнях организации, а в какой-то – боязнью перемен и обвинений в несоответствии занимаемой должности. Если компания стремится к гибкому менталитету самоорганизующихся команд, к повышению их независимости и «плоской» организационной структуре, возникает вопрос: а для чего тогда нужны менеджеры и руководители?

На управленческом уровне люди ощущают угрозу своей роли и зоне ответственности: «команды переходят к самоуправлению, но я не знаю, каким образом мне следует изменить свой управленческий стиль». И сотрудники начинают думать о том, как бы не остаться без работы.

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

Заблуждение 3: Переход к agile-методологии прост

«Существует ошибочное представление о том, что переход к agile-методологии прост, – указывает Дэйв Уэст, владелец ресурса Scrum.org. – Принципы и постулаты agile-проектирования легки для понимания, но их сложно реализовать на практике. Необходимо полностью поменять в организации менталитет всех сотрудников снизу доверху, изменить их подход к выстраиванию своей карьеры, к оценке своей работы и своей роли».

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

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

– Sharon Florentine. 3 misconceptions CIOs have about agile. CIO. Apr 25, 2016

Теги: Управление ИТ Agile Цифровая трансформация

На ту же тему: