Философия agile. Гибкие методологии управления проектами

Рассказываем, что представляет собой лежащая в основе методология, раскрываем основные понятия, объясняем, как устроена agile-команда и как оценивается ее эффективность.

Agile - это целое семейство методологий гибкого управления проектами. Интересно, что само понятие управления здесь оказывается не вполне верным. Было бы более точным употреблять формулу «Agile - это способ командного взаимодействия, позволяющий совместно создавать продукты». Однако мы слишком привыкли к силе вертикальных, иерархических связей, поэтому и здесь устойчивым стало употребление слова «управление».

Неудобные вопросы

• Как сделать так, чтобы задержка в работе одного отдела не останавливала остальных?
• Как справиться с тем, чтобы разработка плана проекта не занимала до 30% времени от всего объема его реализации?
• Как, в конце концов, добиться того, чтобы эти планы соблюдались?

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

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

Оказалось, что искать ответы на большинство этих больных вопросов просто незачем. Их нужно снять, а понятия, их породившие, по возможности упразднить. Так на месте поэтапной waterfall-разработки возникли гибкие методологии.

Делай сразу!

Главное мерило эффективности, принятое в гибкой методологии, - продукт. Пока другие только готовят документацию, agile-команды стремятся представить работоспособный прототип. Это - как в знаменитой мотивирующей формуле «сделано - это лучше, чем идеально». Реализуйте первую функцию и начните тестировать ее, создавая следующую, и так раз за разом - вот главное правило.

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

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

Горизонтальная организация

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

Принципы формирования agile-команд разнятся в зависимости от конкретного проекта. Например, в музыкальном сервисе Spotify они строятся вот так:

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

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

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

Как внедрить Agile?

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

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

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

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

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

Agile, с точки зрения управления проектами будет необходим вашей компании, если:

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

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

Аджайл методология (agile методология) позволяет сформировать agile команды нового типа управления и лидерства, при этом обеспечив прозрачность и эффективность процесса, скорость принятия решения, разработки, адаптации и масштабирования продукта, а также умения реагировать на неопределенности, изменения и кризис.

Agile методология что это?

Можно ли сказать, что эджайл это инструмент кризис-менеджмента и управления изменениями? Определено Да!

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

Как правильно внедрить Agile?

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

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

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

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

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

Когда нельзя внедрять Agile

Есть простое правило:

Agile методологию можно использовать, только тогда когда вы готовы платить за ошибки.

Agile методология дает не только результат:

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

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

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

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

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

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

Алгоритм внедрения Agile в компании

Давайте рассмотрим ориентировочный алгоритм внедрения Agile методологии в текущие бизнес-процессы компании, ориентируясь на Agile в управлении проектами:

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

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

Построение Agile команды в компании

Сформировать Agile команду можно довольно быстро, на это может потребоваться несколько дней, но сколько времени потребуется на «притирку» участников команды?

Конечно с точки зрения командообразования выделяются этапы: формирования, конфликтов, выработки правил и норм, и в итоге получаем: определенный стиль работы, но в Agile команде все происходит немного по-другому:

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

Agile методология это:

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

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

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

Состоящего из 12 принципов. Конечно, отдельные положения Agile-подхода появились появлялись и до этого, но только этот документ систематизировал и изложил их в достаточной для использования мере. Каждый год под манифестом подписываются новые компании, IT-специалисты и проектные менеджеры. Появляются новые методы и модификации гибкой системы разработки.

Что такое Agile Methodology (гибкая методология)?

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

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

12 принципов, которые составляют Agile Methodology, можно поделить на 4 главные идеи:

• Приоритет людей и общения над инструментами и процессами;
• Приоритет работающего продукта над полной документацией;
• Приоритет сотрудничества с заказчиков над утверждением контракта;
• Приоритет готовности меняться над следованием первоначально созданному плану.

Методы присутствующие в Agile:

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

Метод успешно применяют такие компании как Microsoft, Yahoo, Siemens Healthcare, а проектный менеджер в Amazon даже описал на основе полученного опыта.

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

Джефф Сазерленд, автор выделил 8 шагов по использованию методики:

1. Выберите владельца продукта — он знает о цели проекта и ожидаемом результате.
2. Соберите команду — до 10 человек с необходимыми для создания работоспособного продукта навыками.
3. Найдите скрам-мастера — он следит за ходом проекта, помогает проектной команде бороться с трудностями.
4. Составьте бэклог продукта — на Agile-доске расставьте приоритеты по каждому требованию к продукту. В этом большую роль играет владелец продукта, который собирает пожелания к продукту для оценки командой бэклога.
5. Запланируйте спринты (итерации) — отрезки времени на выполнение определенного ряда задач.
6. Организовывайте ежедневные пятнадцатиминутные «мит-апы» — задавайте по 3 вопроса каждому из команды: что делал вчера, что будет сегодня, что мешает выполнить задачу.
7. Делайте обзоры рабочих частей продукта — с вовлечением в просмотр и обсуждение стейкхолдеров.
8. Проводите ретроспективу — обсуждение проблемы и поиск решения после каждого спринта. Полученный план изменения внедряете на следующем спринте.

Ретроспектива в Agile

В скрам есть 4 ключевых элемента:

• Product Backlog — список требований по проекту
• Sprint Backlog — список требований, которые нужно выполнить в ближайший спринт
• Sprint Goal — цель спринта
• Sprint Burndown Chart — диаграмма, которая обновляется по мере завершения задач. По ней легко понять динамику и уровень продвижения команды в проекте.

(XP)

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

Он применим исключительно в сфере разработки ПО, и строится вокруг 4 процессов:

1. кодирование — согласно единым в команде стандартам оформления;
2. тестирование — тесты пишутся самими программистами до написания кода, который будут тестировать;
3. планирование — как финального билда, так и отдельных итераций. Последнее проходит в среднем раз в две недели.
4. слушание — как разработчиков, так и клиента, в ходе которого исчезают неясности, определяются требования и ценности.

Methodologies

Малоизвестное на отечественных просторах проектного менеджмента семейство методологий, разработанное Алистером Кокберном, одним из автором «Манифеста гибкой разработки ПО». Классификацию Кокберн предлагает проводить по цветам за критерием количества человек в команде: от 2 (Crystal Clear) до 100 (Crystal Red). Под более масштабные проекты выделены цвета Maroon, Blue и Violet.

Crystal-проекты должны соответствовать 3 основным показателям:

1. быстрая доставка рабочего кода — развитие идеи итеративной модели разработки Agile.
2. совершенство через рефлексию — новая версия ПО улучшается на основе данных о предыдущей.
3. «осмотическое» взаимодействие — нововведение Алистера, метафора коммуникации и обмена информацией между разработчиками ПО в одной комнате.

Dynamic Software Development Method (DSDM)

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

Особая роль отводится участия конечного потребителя (пользователя) в процессе разработки. Помимо этого принципа, к базовым относятся:

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

DSDM делится на версии, которые обновляются по мере развития технологий, появления новых требований к разработке ПО. Последняя на сегодня — DSDM Atern, выпущенная в 2007 году, хотя предыдущая (2003 года) еще в строю.

В начале команда изучает реальность разработки приложения и область применения. Дальше работа делится на три взаимосвязанных цикла:

1. цикл функциональной модели — создание аналитической документации и прототипов.
2. цикл проектирования и конструирования — приведение системы в рабочее состояние.
3. цикл реализации — развертывание системы.

Feature Driven Development (FDD)

Методология, которая появилась даже раньше, чем "Манифест гибкой разработки ПО«.

Хоть в FDD тоже применяется итерационная модель разработки, от Agile она отличается в следующем:

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

Feature Driven Development состоит из таких цикличных этапов:

1. Создание общей модели — видение проекта на основе предварительных данных.
2. Разработка списка свойств — аналог product backlog в методике скрам.
3. Планирование по свойствам — оценка сложности свойств каждым членом команды.
4. По каждому свойству — технический дизайн и реализация — финальная стадия, по окончанию которой свойство уходит в продукт и цикл повторяется.

Software Development

Lean Software Development — скорее не методология, а набор принципов бережливого производства, который направлен на повышение эффективности процесса разработки, минимизацию затрат.

В набор входят следующие 7 принципов:

1. избавление от потерь — всё, что не прибавляет ценности продукту для конечного потребителя.
2. постоянное обучение — непрерывное развитие команды увеличивает возможности эффективного выполнения задач.
3. принятие решения так поздно, как только можно — приоритет не спонтанным решениям, а продуманным, разработанным на основе полученных знаний.
4. быстрая доставка — по сути основа итеративной модели.
5. усиление команды — один из принципов «Манифеста...» гласит, что люди и взаимодействие важнее процессов и инструментов. Проектная команда — основа успешного завершения задач.
6. целостность и качество — нужно изначально делать качественный продукт, чтобы не тратить время и ресурсы на дальнейшее тестирование и избавление от багов.
7. видение цельной картины — разбиение проекта на отдельные части невозможно без понимания текущего статуса разработки, целей, концепции и стратегии разрабатываемого ПО.

Разновидность методологий гибкой разработки

Agile Modeling (AM)

Agile Modeling — набор ценностей, принципов и практик для моделирования программного обеспечения.

AM используют как составляющую полноценной методики разработки ПО — например, экстремального программирования или Rapid Application Development.

Принципы Agile Modeling таковы:

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

Agile Unified Process (AUP)

AUP — упрощённая версия другой методологии разработки ПО — Rational Unified Process (RUP). С 2012 года её заменили на Disciplined Agile Delivery (DAD), но кое-где AUP еще встречается.

Автор методики, Скотт Амблер, выделил следующие ключевые позиции Agile Unified Process:

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

Agile Data Method (ADM)

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

Суть Agile Data Method определяется шестью положениями:

1. Данные — основа создания любого приложения.
2. Проблемы с проектом — их можно обнаружить только при чётком понимании цели и концепции проекта.
3. Рабочие группы — помимо непосредственной команды разработчиков есть enterprise groups, которые поддерживают другие рабочие группы.
4. Уникальность — нет идеальной методики, под каждый проект нужно комбинировать инструменты с разных методологий.
5. Работа в команде — совместная работа гораздо эффективнее, чем поодиночке.
6. «Сладкое пятно» — поиск оптимального решения проблемы («сладкого пятна»), избегая крайностей.

Essential Unified Process (EssUP)

Разработка шведского учёного Ивара Якобсона, созданная для улучшения Rational Unified Process.

EssUP оперирует понятием практики, в которые входят:

• сценарий использования — описание поведения системы.
• итерационная разработка — создание рабочих кусков кода короткими циклами в несколько недель.
• командные практики — направленные на сплочение команды и повышение её эффективности.
• процессуальные практики — например, «Думай глобально, начинай с малого» или «Вовлекайте стейкхолдеров в бизнес-процессы».

Все практики в том или ином виде встречаются в методологиях RUP, CMMI и гибкой методике разработки.

Getting Real (GR)

Эффективная для стартапов и начинающих команд методология, которая предлагает по максимуму использовать особенности небольших проектов и компаний: мобильность, гибкость, поиск новых решений, отсутствие жёсткой запутанной иерархии и т.д. Джейсон Фрид и Давид Ханссон, основатели компании 37signals (теперь — Basecamp), определили Getting Real как систему для решения реальных задач: максимально простую, понятную и функциональную.

GR — сборная солянка из десятка инструментов гибкой разработки, которые используются для минимизации:

• возможностей
• опций и настроек
• структуры компании
• встреч
• обещаний.

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

OpenUP (OUP)

Независимая от инструментов методология разработки ПО без жесткой структуры, которая содержит такие практики:

• измерение скорости работы команды;
• проведение ежедневных встреч и ретроспектив по завершению итераций;
• концепция микрошагов и раннего тестирования с использованием чеклистов;
• методика гибкого моделирования (AMDD).

Практики реализуются на основе четырех принципов:

Agile показатели

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

Для большинства проектов хватит 4 направлений метрик:

1. Производительность — сюда относятся Velocity и WIP. Первая подойдёт не для всех проектов, так как идет измеряются количество выполненных задач в итерацию, а они неравнозначны. Метрика Work-in-Progress определяет лимит задач на разных стадиях: и чем он выше, тем хуже;
2. Прогнозирование — метрика capacity: определение количества идеальных часов, доступных в следующем спринте. Соответственно, можно понять, сколько времени есть на работу, насколько эффективно выполнение задач и как для спринта;
3. Качество — например, индекс стабильности требований, который рассчитывается по формуле = (Общее количество оригинальных бизнес-требований + Число требований, которые поменялись к этому времени + Число добавленных требований + Число убранных требований) / (общее число оригинальных требований). С помощью метрики определяется количество времени, затраченное на переделывание задач;
4. Ценности — в каждом случае просчитывается индивидуально, зависимо от формата проекта. Например, стартап AirBnb в качестве метрики, определяющую конечную ценность продукта для пользователей, выбрала количество загруженных фотографий высокого качества. С их увеличением пропорционально росло и количество потребителей.

К метрикам применимы те же правила, что и к другим Agile-инструментам.

Нет единственно верной или нужной вашему проекту метрики.

Их нужно постоянно пересматривать, отбрасывать устаревшие и добавлять новые по мере необходимости. Она должна быть понятна и доступна всей всей команде, не превращаться в самоцель. Метрика ради метрики — плохое решение.

Разрушители мифов: Agile

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

Миф № 1: Agile подойдет для всех проектов.

Самое упорное заблуждение. Ни один метод Agile не добавит сам по себе ценности продукту и не смотивирует команду.

Миф № 2: Agile против документации.

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

Миф № 3: Agile и планирование несовместимы.

Опровержением этого мифа служат дневные планирования с 10-минутными стэндапами, итерационное планирование каждые две недели, спринт-встречи и т.д.

Миф № 4: Agile требует много переделывания (re-work).

В гибкой методологии разработки ПО переделывание проявляется в двух формах: переделывание требований (пользователи понимают, что им действительно нужно) и программного обеспечения (команды разработчиков находят улучшенные способы написать и спроектировать приложение). Но с этим приходится сталкиваться и в других методиках! Более того, для уменьшения негативного влияния rework и нужна итерационная модель, которая является особенностью Agile.

Плюсы и минусы использования Agile

Плюсы:

1. вовлечение стейкхолдеров — у команды появляется больше возможностей понять желания клиента. А ранняя и частая доставка ПО усиливает доверие стейкхолдеров к проектной команде и еще глубже вовлекает в проект.
2. ранняя и предсказуемая доставка — модель разработки через итерации (короткие промежутки от 1 до 6 недель) дает гибкость, ускоряет выпуск релиза продукта.
3. фокусирование на бизнес-ценности — коллаборация с клиентом обеспечивает понимание командой того, как сделать продукт максимально ценным для потребителя.
4. непрекращающееся улучшение качества — тестирование во время каждой итерации, деление финального билда на отдельные куски рабочего кода позволяют улучшать и справляться с ошибками ПО до выхода финального продукта.

Минусы:

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

Приложения

Для ведения проектов с Agile подходят далеко не все сервисы или программы для проектного менеджмента, ведь у каждого есть своя специфика.

Если ваш бизнес относится к маркетинг и рекламным, дизайнерским, seo или digital агентствам , то saas-сервис можно применить для работы всей команды целиком. Нас рекомендуют .

Вот пара лайфхаков, чтобы настроить Agile в

1. настройте метки и статусы , которые необходимы для работы именно вашей компании.
   Статусы могут быть такими: в работе, проверка, выполнено, требует доработки, критично, фича, оплатить .
   Метки часто выглядят как: верстка, тестирование, продакшен, концепт, код.
2. создайте проект-беклог и проект-спринг.
3. создавайте задачи и предварительные чеклисты, скетчи и прочее в беклоге.
4. на мит-апах определяйте задачи на спринг и переносите их из беклога в спринт.
5. используйте гостевой доступ клиентов к задачам, чтобы всегда иметь согласованные и актуальные комментарии по проекту.
6. отмечайте ответственных в задачах , чтобы каждый коллега знал зону своей ответственности и чувствовал причастность к результату спринта.

Вердикт

С гибкой методологией разработки программного обеспечения небольшие проектные команды добиваются максимальной эффективности. Agile реализуется через другие гибкие методы: Scrum, XP, Lean и т.п.

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

Гибкая методология разработки (от англ. - Agile software development) - манифест, определяющий способ мышления и содержащий основные ценности и принципы, на которых базируется несколько подходов (фреймворков, от англ. framework - каркас, структура) к разработке программного обеспечения (хотя в последнее время идет тенденция и попытки применения гибкой методологии разработки к иным направлениям деятельности, не только в части информационных технологий), подразумевающих под собой интерактивную разработку, периодического (динамического) предоставления (обновления) требований от Заказчика и их реализацию посредством самоорганизующихся рабочих групп, сформированных из экспертов различного профиля (разработчики, тестировщики, внедренцы и т.д.). Такой перевод Agile, как "гибкая методология разработки" не совсем корректен т.к. обычно Agile не называют методологией, а вот подходы на основе данного манифеста и есть методологии, но с точки зрения Agile их называют - фреймворки. На данный момент существует множество фреймворков (методологий), подходы которых базируются на гибкой методологии разработки, например такие, как: Scrum, Extreme programming, FDD, DSDM и т.д.

Определение с точки зрения BPM CBoK [от англ. - Guide to the Business Process Management Common Body Of Knowledge]. Agile - Одна из методологий итеративной и пошаговой разработки ПО, в противоположность традиционной линейной методологии «водопад». Методология гибкой разработки определяет систему методов проектирования, разработки и тестирования на протяжении всего жизненного цикла ПО. Методы гибкой разработки (например, SCRUM) основаны на оперативном реагировании на изменения за счет применения адаптивного планирования, совместной выработки требований, рационализации самоорганизующихся кросс‑функциональных групп разработчиков, а также пошаговой разработки ПО с четкими временными рамками. Этот подход используется во многих современных проектах разработки коммерческого ПО.

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

За счет того, что разработка программного обеспечения с применением гибкой методологии определяет серии коротких циклов (итераций), с длительностью 2-3 недели, достигается минимизация рисков т.к. по завершению каждой итерации Заказчик принимает результаты и выдает новые или корректирующие требования т.е. контролирует разработку и может на неё сразу влиять. Каждая итерация включает в себя этапы планирования, анализа требований, проектирование, разработку, тестирование и документирование. Обычно одной итерации не достаточно для выпуска полноценного программного продукта, но при этом по окончании каждого этапа разработки должен появляться "осязаемый" продукт или часть функционала, которую можно посмотреть, потестировать и выдать дополнительные или корректирующие меры. На основе проделанной работы, после каждого этапа, команда подводит итоги и собирает новые требования, на основании чего вносит корректировки в план разработки программного обеспечения.

Одной из основных идей Agile, является взаимодействие внутри команды и с заказчиком лицом к лицу, что позволяет быстро принимать решения и минимизирует риски разработки программного обеспечения, поэтому команду размещают в одном месте, с географической точки зрения. Причем в команду входит представитель заказчика (англ. product owner - полномочный представитель заказчика или сам заказчик, представляющий требования к продукту; такую роль выполняет менеджер проекта от заказчика или бизнес-аналитик).

История выпуска Agile манифеста

«Манифест гибкой методологии разработки программного обеспечения» был выпущен и принят в феврале 2001 года (штат ЮТА США, лыжный курорт The Lodge at Snowbird) группой экспертов. Данный манифест определяет 4 основные ценности и 12 принципов для методологий, базирующихся на нем, а также дает альтернативное видение подхода к разработке программного обеспечения в отличие от крупных и известных методов и методологий, но не является сам по себе методологией. Обычно Agile сравнивают в первую очередь с "методом водопада" ("waterfall"), т.к. на момент выхода манифеста, именно "метод водопада" являлся основным при планировании разработки программного обеспечения. В разработке и выпуске Agile манифеста принимали участие представители следующих методологий:

• Adaptive software development (ASD)
• Crystal Clear
• Dynamic Systems Development Method (DSDM)
• Extreme Programming (XP)
• Feature driven development (FDD)
• Pragmatic Programming
• Scrum

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

Agile-манифест разработки программного обеспечения:

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

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

• Люди и взаимодействие важнее процессов и инструментов
• Работающий продукт важнее исчерпывающей документации
• Сотрудничество с заказчиком важнее согласования условий контракта
• Готовность к изменениям важнее следования первоначальному плану

То есть, не отрицая важности того, что справа, мы всё-таки больше ценим то, что слева.

Авторы манифеста:

Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas

Основополагающие принципы Agile-манифеста:

Мы следуем таким принципам:

1. Наивысшим приоритетом для нас является удовлетворение потребностей заказчика, благодаря регулярной и ранней поставке ценного программного обеспечения.
2. Изменение требований приветствуется, даже на поздних стадиях разработки. Agile-процессы позволяют использовать изменения для обеспечения заказчику конкурентного преимущества.
3. Работающий продукт следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев.
4. На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе.
5. Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им.
6. Непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри команды.
7. Работающий продукт - основной показатель прогресса.
8. Инвесторы, разработчики и пользователи должны иметь возможность поддерживать постоянный ритм бесконечно. Agile помогает наладить такой устойчивый процесс разработки.
9. Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта.
10. Простота - искусство минимизации лишней работы - крайне необходима.
11. Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд.
12. Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы.

Критика Agile

Agile плохо описывает процессы управления требованиями, можно сказать, что такое понятие просто отсутствует т.к. гибкая методология разработки не подразумевает под собой долгосрочного планирования (планирование осуществляется на краткосрочную перспективу), как следствие пропущен шаг формирования плана развития продукта или другими словами дорожной карты продукта. Т.к. планирование краткосрочное (на ближайшую итерацию разработки), а Заказчик по окончанию каждой итерации принимает продукт и выставляет новые требования, сам продукт может поменяться в корни, а выставляемые новые требования зачастую противоречат структуре и архитектуре продукта уже поставляемого клиентам. По большому счету, в случае, если Заказчик не до конца понимает, что хочет увидеть в итоге (конечный продукт), а понимание приходит во время разработки (это случается в 90% случаев), процесс разработки превращается в формализованную и легализованную бюрократию т.е. продукт дорабатывается бесконечно, пока не кончаются деньги, или заказчик не переключается на другой продукт. Справедливости ради, необходимо заметить, что Заказчик знает на что идет и сам решает, платить за разработку продукта или нет, по большому счету команда разработчиков просто выполняет требования заказчика. Однако, реально, в работе это приводит к хаосу, срыву сроков и авралам, что порождает новые требования, которые меняют не в лучшую сторону продукт. Более того, снижается качество разрабатываемого продукта, т.к. Agile определяет подход к разработке, в рамках которого необходимо быстро тушить пожары, наиболее простым и быстрым способом. Код пишется не соблюдая требований платформы, на которой разрабатывается продукт, появляется множество обходных решений и дефектов, а такая конструкция не очень устойчива и не безопасна, растет негодование клиентов от частых сбоев в работе программного обеспечения. Бизнес на выходе получает потери, падает качество планирования.

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

Anti-Agile манифест (необходимо отметить, что данный anti-agile манифест на самом деле противоречит не самому Agile, а скорее одному из фреймворков, основанном на принципах Agile - Scrum т.к. в манифести используются термины именно из этого фреймворка):

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

• эпики (epics) - это просто проекты
• пользовательские истории (user stories) - это просто сценарии использования (use case)
• спринты (sprints) - это просто работа
• стенд апы (stand-ups) - это просто совещания
• итерации (iterations) - это просто версии
• бэклоги (backlogs) - это просто список дел
• скорость команды (velocity) - это просто результаты
• и эти задачи (tasks) - это реально, просто задачи

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

Разновидность методологий гибкой разработки

На основании ценностей и принципов, определенных в Agile Manifesto были сформированы следующие гибкие методологии разработки:

• Agile Modeling (AM) - данный подход в основе своей определяет процедуры моделирования (в т.ч. проверка модели кодом) и документирования в рамках разработки программного обеспечения. В меньшей степени описаны процедуры проектирования и построения диаграмм на UML. также не затронуты области разработки, тестирования, управления проектом, развертывания и сопровождения.
• Agile Unified Process (AUP) - унифицированная версия методологии RUP (IBM Rational Unified Process), которая была сформирована Скоттом Амблером. AUP определяет модель создания программного обеспечения в рамках бизнес-приложений.
• Agile Data Method (ADM) - набор итеративных методик гибкой разработки программного обеспечения, в рамках которых делается упор на формирование требований и решений посредством сотрудничества различных кросс-функциональных команд.
• Dynamic Systems Development Method (DSDM) - итеративный и инкрементный подход, базирующийся концепции быстрой разработки приложений - Rapid Application Development (RAD), упор в котором делается на максимальное привлечение конечного пользователя к разработке программного продукта.
• Essential Unified Process (EssUP) - подход, разработанный Иваром Якобсоном (Ivar Jacobson), содержит в себе методы итеративной разработки программного обеспечения, с упором на архитектуру продукта и наработанные практики команды (по сути заимствованные из RUP, CMMI и Agile Development). Идея заключается в том, что вы используете только те практики и методы, которые применимы в конкретной ситуации. На основе выбранных методов и практик определяется целевой процесс. В отличие от RUP, где все практики и методы взаимосвязаны, в данном случае появляется гибкость и возможность вычленить из всего доступного объема именно необходимые элементы (методы и практики).
• Extreme programming (XP) - идея экстремального программирования заключается в том, чтобы использовать уже имеющиеся лучшие практики в области разработки программного обеспечения, подняв их на новый (экстремальный) уровень. Например в отличие от обычной практики, когда один программист последовательно проверяет написанный код за своим коллегой, в экстремальном программировании данная проверка осуществляется параллельно, что увеличивает скорость выпуска продукта, но и риски тоже.
• Feature driven development (FDD) - основное ограничение, которое накладывается в рамках данного подхода, это "каждая функция должна быть реализована не более, чем за две недели". Т.е. если реально разработать функцию за один присест, то это хорошо, в противном случае данная функция должна разбиться на несколько и реализовываться постепенно.
• Getting Real (GR) - в рамках данного подхода исключены процедуры функциональных спецификаций, использующийся для веб-приложений. Разработка начинается от обратного, изначально разрабатывается интерфейс и дизайн, а потом сама функциональность.
• OpenUP (OUP) - данный подход определяет итеративно-инкрементальный метод разработки программного обеспечения. Разработан на основе RUP. В рамках данного метода определен жизненный цикл разработки (фаза запуска, фаза уточнения, фаза разработки и передачи заказчику). Благодаря определенной этапности и контрольных точек, повышается эффективность контроля и мониторинга хода реализации проекта, как следствие своевременное принятие решений по проекту.
• lean software development - данный подход основан на концепции бережливого управления производственным предприятием (lean production, lean manufacturing).
• Scrum - один из самых распространенных подходов гибкой разработки программного обеспечения, определяет правила управления процессом разработки с применением существующих практик разработки. Упор осуществляется на вовлеченность Заказчика в процесс (возможность после каждого этапа менять или уточнять требования к создаваемому продукту), что позволяет вовремя определить отклонения и внести необходимые изменения.

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

• Введение
• 1. Анализ подходов к управлению проектами на основе классической и гибкой методологии
• 1.1 Введение в гибкие методологии управления проектами
• 1.2 Критика и проблемы гибкого управления проектами
• 1.3 История развития взглядов на гибкие методологии
• 1.4 Гибкие методологии в сравнении с традиционным подходом к управлению проектами
• 1.5 Ключевые факторы успеха IT проектов, использующих гибкие методологии
• 1.6 Ситуационный подход в управлении проектами в сфере информационных технологий
• 1.7 Общее описание ИТ проектов
• 1.8 Особенности управления проектами в разных странах
• 1.9 Этнокультурные особенности проектной деятельности в России
• 1.10 Переход на agile с традиционного подхода к управлению проектами
• Выводы по главе
• 2. Эмпирическое исследование КФУ для IT проектов
• 2.1 Методология исследования
• 2.2 Исследовательские гипотезы
• 2.3 Описание процесса проведения опроса
• 2.4 Анализ результатов
• 2.4.1 Демографические показатели респондентов
• 2.4.2 Тест надёжности переменных модели
• 2.4.3 Анализ корреляций независимых переменных с успешностью проекта
• 2.4.4 Построение модели множественной линейной регрессии
• 2.5 Интерпретация результатов
• Выводы по главе
• 3. Практические рекомендации
• 3.1 Советы по переходу на agile методологию
• 3.2 Рекомендации по проведению качественной ретроспективы
• 3.3 Саморегулируемая команда как способ ускорить процесс принятия решений
• 3.4 Ситуационный подход в практике управления проектами
• Рекомендации для будущих исследований
• Выводы по главе
• Заключение
• Список использованной литературы
• Список иллюстраций
• Приложение 1. Вопросник
• Приложение 2. Диаграммы остатков регрессии
• Приложение 3. Результаты опроса
• Приложение 4.Расшифровка для результатов опроса

Введение

Сегодня мы живём в мире, в котором информация стала основным продуктом и ресурсом общества. Деятельность практически всех компаний так или иначе связана с её переработкой, хранением, производством и использованием. Таким образом, информационные технологии плотно вошли в нашу жизнь, стали её неотъемлемой частью. Информационное общество характеризуется колоссальной скоростью развития и изменения. Такого не наблюдалось ещё несколько десятилетий назад: инженер мог получить образование, и этих знаний ему хватало на всю жизнь. Сейчас же появилась необходимость не просто периодического повышения квалификации, а непрерывного обучения в течение всей жизни. Словом, темп изменений окружающей среды сильно возрос, поэтому появилась необходимость справляться с изменениями среды. Так в области разработки программного обеспечения (ПО) со временем появилась концепция гибкой разработки. Она позволяло адекватно справляться с изменениями среды и создавать продукт, необходимый заказчику.

Сейчас данная концепция значительно переросла рамки разработки ПО и стала, фактически, некоторой альтернативой традиционному подходу в управлении проектами во всех сферах. Но особенно она популярно всё же в сфере информационных технологий (IT), в силу динамичности этой области. Однако несмотря на растущую популярность и текущую скорость изменений в бизнес-среде, многие компании по-прежнему придерживаются традиционного подхода. Agile (гибкий) подход для них является, как правило, незнакомым, поэтому переход на новую методологию может вызывать сложности. В такой ситуации полезно иметь набор ключевых точек, на которые стоит обратить особое внимание. В литературе они называются ключевые факторы успеха (КФУ). В зарубежной литературе присутствует значительное число работ на эту тематику, однако в России данная область только начинает развиваться, поэтому работ на эту тему практически нет. В то время как социокультурные факторы, соответствующие разным странам, значительно влияют напроцесс управления. И стоит принимать это во внимание при работе с проектами.

Целью данной работы будет заполнить пробел в исследованиях: рассмотреть ключевые факторы успеха проектов в сфере IT, использующих agile методологии, в России и предоставить рекомендации по их практическому использованию

Для этого будет необходимо осуществить следующие задачи:

1. Идентифицировать вероятные КФУ с помощью анализа литературы.

2. Провести глубинные интервью с менеджерами для уточнения и дополнения КФУ.

3. Спроектировать и провести онлайн-анкетирование менеджеров проектов в IT, работающих с гибкими методологиями

4. Проанализировать результаты.

Объектом работы выступают ключевые факторы успеха проектов.

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

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

Методом для сбора является опрос менеджеров проектов в IT относительно их проекта, выполненного с использованием гибких методологий. Формирование опроса проходило в 3 этапа:

1. Формирование первичного перечня КФУ на основе имеющейся литературы

2. Уточнение КФУ в ходе неструктурированного интервью с 3 менеджерами проектов

3. Составление опросника и пилотажное тестирование

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

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

Структурно работа разделена на 3 большие главы. Первая - теоретическая, представляет собой анализ существующей литературы по данной теме в основном из зарубежных источников. Наибольшее внимание было уделено статьям из International Journal of Project Management и специализированным журналам, касающимся разработки ПО. Вторая глава представляет собой подробное описание методологии исследования, анализу и интерпретации полученных выборочных данных. Третья глава представляет собой набор рекомендаций для практиков, основанных на результатах исследования.

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

1. Анализ подходов к управлению проектами на основе классической и гибкой методологии

1.1 Введение в гибкие методологии управления проектами

Методологии правления проектами в сфере ИТ можно глобально разделить на два подхода:

· Традиционный

· Гибкий (итеративный)

Традиционный - базируется на достаточно жёстком планировании проекта до запуска и минимальным вмешательствам после. При таком подходе каждая последующая фаза начинается после предыдущей: реализация после планирования и так далее. При этом возврата к более ранним фазам не предусмотрено, поэтому такой метод иногда называют водопадным. Традиционный подход соотносится с классическим стандартом управления проектами от PMI - PMBoK. В частности хорошо описывает процесс определение управления проектом:

Приложение знаний и навыков, инструментов и методов к работам проекта для удовлетворения требований, предъявляемых к проекту.

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

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

Практика использования методологий также подтверждает эти выводы: доля Agile проектов в общем массиве неуклонно растёт (с 2% в 2002 до 9% в 2010), в то время как традиционные подходы теряют популярность, что особенно заметно в области разработки приложений.

Управление проектами существует на различных уровнях иерархии. В представлении (Maylor, Brady, Cooke-Davies, & Hodgson, 2006) она выглядит следующим образом

Рисунок 1. Окружение проекта

Изначально данная схема была направлена на проекты по разработке программного обеспечения, однако примерно в таком же виде она существует и в других проектах в IT. При этом очевидно, что (Maylor, Brady, Cooke-Davies, & Hodgson, 2006) выделяют конкретные Agile методологии, как SCRUM и XP в качестве методологий уровня команды. Однако некоторые исследователи склонны смотреть на SCRUM как на более общую методологию, относящуюся и к уровню менеджера проекта в том числе (Barlow et al., 2011). Ряд исследователей также рассматривает Scrum в других сферах, отличных от IT. Данная методология демонстрирует неплохие результаты и в других областях, например, строительства (Owen, Koaskela, & Henrich, 2006).

1.2 Критика и проблемы гибкого управления проектами

Однако agile подход к управлению проектами имеют и определённые недостатки, отмеченные многими исследователями. В частности (Coplien & Harrison, 2004) отмечают, что многие менеджеры сегодня «словно лемминги» следуем за последними трендами, вместо того чтобы заботиться об использовании оптимального подхода. Кроме того (Coplien & Harrison, 2004) обеспокоены тем, что Agile отходит от принципов, заложенных в Manifesto. Всё чаще стремление направлено на сам факт применения agile подхода без осмысления лежащих в его основе принципов.

В качестве одного из основных рисков agile проекта (Boehm & Turner, 2003) выделил возможные ошибки при разработке, так как усложняется контроль со стороны из-за отсутствия документации.

Существует точка зрения, что в силу того, что для agile проекта требуется более подготовленная в техническом плане и достаточно самостоятельная команда, успех проекта во многом обеспечен именно этим фактом, а не применением какой-либо методологии (Cohen, Lindvall, & Costa, 2004). В таком случае большинство исследований, касающихся эффективности подхода становятся необъективными.

1.3 История развития взглядов на гибкие методологии

Agile методологии - целый набор различных методик: SCRUM, Xtreme programming, Lean и другие, но объединяет их соответствие 4 базовым принципам, описанным в Agile Manifesto в 2001 году:

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

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

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

· Готовность к изменениям важнее следования первоначальному плану

Тем не менее, Agile не появился в 2001 году в головах нескольких человек, на самом деле история его развития насчитывает несколько десятков, и Manifesto явился лишь закреплением основ.

Несовершенство существующего подхода осознавалось задолго до 2001 года, и предпринимались попытки применения новых подходов. Уже в 1970-1980 годах применялись итеративные и инкрементные методологии, которые имели серьёзные преимущества в скорости реализации проектов и их эффективности. Например, EVO, RAD, DSDM- всё это методологии очень близкие к идеям гибкого управления проектами, они появились и использовались задолго до манифеста. Многие даже имели определённый успех: в 1988 году компания представила свою методологию Rapid Iterative Production Prototyping (RIPP), благодаря которой им удалось значительно сократить время разработки программного обеспечения. Компания гарантировала клиентам готовый продукт в течение 90 дней или возврат денег.

Наиболее интересной частью статьи выглядит таблица сравнения принципов из Agile Manifesto с методологиями предыдущих подходов. Сравнительно новые только 2 пункта из 12 , а все остальные - уже были отмечены или даже применены в упомянутых выше методологиях. Другими словами, большинство принципов agile - результат нескольких десятилетий развития альтернативных подходов к реализации проектов.

Отличный обзор эмпирических статей на тему Agile методологий представили (Dybе & Dingsшyr, 2008). Были обнаружены 1996 работ, 36 из которых оказались эмпирическими и были отобраны для анализа. В ходе детального обзора и систематизации, авторы пришли к выводу, что существует нехватка качественных эмпирических исследований на эту тему.

1.4 Гибкие методологии в сравнении с традиционным подходом к управлению проектами

Несмотря на достаточно долгий период успешного применения в различных проектах, многие менеджеры до сих пор относятся скептически к agile методологии и предпочитают традиционные методы. Такая позиция частично обоснована: все проекты уникальны и требуют различного полхода. Этот аспект хорошо описан в статье (Fernandez & Fernandez, 2008). Ответ на вопрос кроется в ситуации применения. Авторы выделают 4 типа начальных условий проекта:

1. Цель и путь её достижения определены

2. Определённая цель, без пути достижения

3. Определённый путь, без определённой цели

4. Неопределённая цель и путь

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

1.5 Ключевые факторы успеха IT проектов, использующих гибкие методологии

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

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

Рисунок 2. Проектный треугольник

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

Первым концепцию ключевого фактора успеха предложил (Daniel, 1961) в своей статье в Harvard Business Review «Management Information Crisis». Более подробно термин раскрыл (Rockart, 1979):

Ключевые факторы успеха - «несколько ключевых областей, в которых необходим положительный результат, для достижения успеха организации». Таким образом, это самые важные для менеджмента области, внимание к которым критически важно для успешной реализации проекта. Это те самые 20%, которые приносят 80% результата согласно принципу Парето.

Стоит отметить, что модель КФУ является сравнительно хорошей моделью, но она, как и любая другая модель, имеет некоторые недостатки и упрощения:

Однофакторность. Модель учитывает каждый фактор в отдельности, тогда как связь между факторами не менее важна (Nandhakumar, 1996)

Статичность. Модель предполагает, что внедрение или проект не изменяются со временем, при этом на практике на различных этапах тот или иной фактор может быть наиболее важен для успеха (Larsen & Myers, 1999).

Ключевые факторы успеха (КФУ) для управления проектами довольно хорошо освещены различными авторами. (Fortune & White, 2006) В своей статье проанализировали 63 публикации и выделили самые популярные КФУ. Оказалось, что у исследователей нет единогласия во мнениях: поддержка руководства, чёткие и реалистичные цели, детальный план - факторы, получившие наибольшее количество упоминаний, встречались все три вместе только в 17% работ.

В области IT проектов также есть определённый пласт работ по данной проблематике, однако и в данном случае консенсуса среди исследователей нет. (Misra, Kumar, & Kumar, 2009) В своей работе провели масштабное исследование ключевых факторов успеха в проектах, использующих гибкие методологии. Авторы акцентировали своё внимание на разработке программного обеспечения, но никаких существенных препятствий для распространения выводов на IT сферу в целом нет.

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

(Misra, Kumar, & Kumar, 2009) Выделили следующие факторы как наиболее существенные:

1. Ориентация на потребителя

2. Время принятия решений

3. Распределённость команды (географическая)

4. Размер команды

5. Корпоративная культура

6. Планирование и контроль

7. Компетентность

8. Личные характеристики

9. Коммуникация и переговоры

10. Социально-культурные особенности

11. Знания и обучение

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

Основные противоречия у исследователей возникают в отношении 3 факторов:

· Распределённость команды

· Размер команды

· Знания и обучение

Высказываются различные точки зрения - (Dybе & Dingsшyr, 2008) отмечают, что важно не просто расположить всю команду вместе, но и покупателя тоже, так как это позволяет детально обсуждать все рабочие моменты. В свою очередь (Misra, Kumar, & Kumar, 2009), несмотря на включение этого фактора в теоретическую модель, не нашли практического подтверждения значимости для успеха проекта. Такой же результат получил (Livermore, 2008) в своём исследовании. Таким образом, стоит отметить, что расположение команды проекта в одном месте - аспект требующий дальнейшего изучения.

(Misra, Kumar, & Kumar, 2009) Не обнаружили и серьёзной корреляции успешности проекта и размера команды, хотя в литературе главенствует точка зрения, что Agile методологии были разработаны и применимы к небольшим командам.

(Livermore, 2008)Отметил, что Scrum, как одна из гибких методологий применим как к большим проектам (и, соответственно, командам), так и к крупным, в отличие от Extreme Programming и других.

Знаний и обучения команды также существуют противоречивые точки зрения: с одной стороны опытная команда показывает лучшие результаты (Wysocki, 2012), что довольно ожидаемо и подтверждается исследованиями. С другой стороны - обучение именно методологии не выглядит столь однозначно. (Livermore, 2008) обнаружил значительную корреляцию между успехом проектов и обучением, в то время как (Misra, Kumar, & Kumar, 2009) не нашли подтверждения этой позиции в своём эмпирическом исследовании. Стоит отметить, что выборки и в одном, и в другом случае были значимые статистически и обладали большим числом респондентов из разных областей (более 100 и более 200 соответственно)

1.6 Ситуационный подход в управлении проектами в сфере информационных технологий

С каждым годом увеличивается разнообразие проектов - по сферам бизнеса, масштабу и другим факторам. В ответ на это менеджеры разрабатывают новые методы управления этими проектами. Надёжный контроль возможен только тогда, когда управляющая система имеет разнообразие действий не ниже, чем разнообразие вероятных действий управляемой системы. Так звучит изложенный в более понятных терминах «Закон о необходимом разнообразии» сформулированный математиком Уильямом Эшби в книге «Введение в Кибернетику». В первоначальном варианте он был сформулирован для технических систем и звучал следующим образом: «Разнообразие исходов [ситуации], если оно минимально, может быть еще более уменьшено лишь за счет соответствующего увеличения разнообразия, которым располагает регулятор» (Эшби, 2015) в главе 11. Но этот же закон работает и для других систем, таких как организация или проект, впоследствии его даже стали называть «Первым законом управления». Таким образом, для эффективного управления необходимо увеличивать разнообразие возможных действий - использовать разные методологии и их комбинации.

Многие исследователи и практики до сих пор считают, что проекты похожим друг на друга и ими можно управлять одинаково (Shenhar, 2001). Однако всё большую популярность набирает ситуационный подход, согласно которому необходимо подбирать методологию под каждый проект индивидуально в зависимости от ряда факторов: условий внешней среды, характеристик организации и самого проекта. В условиях растущего количества альтернатив при выборе методологии перед менеджерами проектов стоит сложная задача выбора правильного варианта.

(Howell et al., 2010) в своей работе на основе анализа литературы предложили модель, позволяющую соотнести особенности проекта и наиболее эффективную методологию.

Рисунок 3. График Неопределённость - последствия

По горизонтальной оси представлена степень неопределённости, по вертикальной - значимость последствий. В эти 2 измерения включены все факторы, выделенные авторами при анализе литературы:

· Степень неопределённости включает неопределённость, сложность и срочность проекта

· Значимость последствий - критичность последствий и ответственность команды.

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

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

Рассмотрением такого гибридного подхода занялись (Baird & Riggins, 2012) статьи «Planning and sprinting: Use of a hybrid project management methodology within a CIS capstone course». В качестве проектных команд у исследователей выступали группы студентов, выполнявших определённый проект. Этот факт, конечно, накладывает некоторые ограничения на применение результатов: переносить прямо в сферу бизнеса можно с трудом.

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

Результаты исследования показали, что и преподаватели (условно представлявшие собой клиентов) и участники команд остались довольны процессом реализации и конечным продуктом. Исследователи продемонстрировали, как можно решить некоторые проблемы гибкого управления проектами, например, одну из наиболее важных - сложность с долгосрочным планированием. В Scrum планирование производится в основном на текущий спринт, а не на долгосрочный период. Эту проблему частично помогло решить изменение цели первого спринта на производство плана. Хотя исследователи отметили небольшое снижение мотивации из-за этого процесса, польза планирования перевешивает этот фактор.

1.7 Общее описание ИТ проектов

В первую очередь стоит определить, что включает в себя понятие IT. IT - information technology принято называть всё, что связано с обработкой, хранением и использованием информации, однако в последнее время, в связи с развитием компьютерной техники и интернета, IT в первую очередь связывают именно с ними. В данной работе под IT проектом будет пониматься проекты в области разработки программного обеспечения, Информационной безопасности, корпоративных систем.

IT, на сегодняшний день, - одна из наиболее динамично развивающихся сфер. Компании не могут обойтись без различных систем (системы безопасности, CRM, ERP систем) и серверов, поддерживающих бизнес, так и без сайтов и страничек в социальных сетях. На сегодняшний день значительное количество проектов в сфере IT завершаются с превышением бюджета, сроков, либо оборачиваются полной неудачей. Согласно отчёту CHAOS Summary 2010 (“CHAOS Summary 2010,”[Электронный ресурс] 2010) только 37% проектов завершаются успешно. Ещё 42% испытывают затруднения по сроках, бюджету или качеству, а оставшиеся 21% - считаются полностью проваленными. Хотя наблюдается определённая положительная тенденция, серьёзных улучшениях пока не приходится. 37% довольно малая часть от общего количества проектов. Данный отчёт в основном акцентируется на проектах по разработке программного обеспечения, однако похожая ситуация наблюдается и с другими проектами.

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

1.8 Особенности управления проектами в разных странах

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

Наиболее популярную типологию ценностей организации представил Г Хофштед: в его терминологии представлено 5 индексов, которые зависят от национальной культуры.

· Индивидуализм - коллективизм

· Дистанция власти

· Избегание неопределённости

· Феминность - маскулинность

· Ориентация на долгосрочную

Первоначально было выделено 4 измерения, последнее - Ориентация на долгосрочную перспективу, было добавлено в последующих работах. Данные для анализа культурных ценностей были получены авторов во многом случайно, когда он работал психологом в крупной межнациональной корпорации - IBM, и занимался там исследованием. За время проведения с 1967 по 1971 было проанализировано более 116000 сотрудников из множества стран.

Рассмотрим подробнее каждое культурное измерение и его влияние на управление проектами.

Индивидуализм - коллективизм. В странах с преобладающей культурой индивидуализма общество даёт индивиду значительно больше свободы, меньше связывает его с окружающими: он заботится только о себе и, возможно, ближайших членах семьи. В более коллективистских странах люди ближе друг к другу и ощущают себя включёнными в группу. Они разделяют групповые интересы и мнения, а группа в некоторой степени защищает их, даёт поддержку в беде. Есть сильная зависимость между душевым ВВП и степенью индивидуализма: индивидуалистские страны, как правило, богаче. Управление проектами - идея появившаяся в индивидуалистских странах. В более коллективистских странах, гибкие структуры и временный характер проектов ставят людей в положение, когда они не привязаны к какой-то определённой группе и испытывают отчуждённость. Это непривычная для них ситуация. Для того чтобы избежать подобной ситуации (Hofstede, 1983) предлагает больше внимания уделять отношениям людей в проекте. Лучше использовать сложившиеся команды или формировать их из людей одной группы. Стоит также учитывать при планировании сроков время на установление отношений в команде.

Дистанция власти. Следующее измерение связано с понятием неравенства. Люди неравны от природы в силу физических и интеллектуальных различий. Некоторые страны дают этому неравенству усилиться (высокий уровень дистанции власти), некоторые наоборот - стараются его сократить (низкий уровень).

Избегание неопределённости. В некоторых странах людей настраивают на то, что неопределённости не нужно бояться, её нужно принять. Они легче идут на риск, более спокойно относятся к поведению и мнениям, отличным от их собственного. Эти страны имеют низкий уровень избегания неопределённости. В противоположность им, страны с высоким уровнем, стараются «совладать» с будущим. А так как будущее непредсказуемо, жители этих стран стараются создать институты для обеспечения безопасности и уменьшения риска. Это могут быть технологии, законы, религии (в том числе и наука, в некотором смысле).

По двум измерениям - Дистанции власти и Принятию неопределённости, страны были расположены в плоскости.

Рисунок 4. Распределение стран по кластерам, в зависимости от культурных особенностей

Горизонтальная ось - индекс дистанции власти, вертикальная ось - индекс принятия неопределённости. Страны разбились на несколько кластеров. Правый верхний угол соответствует модели «семьи» - высокая дистанция власти, низкий индекс принятия неопределённости. Правый нижний угол - модель «пирамиды» высокий индекс дистанции власти и принятия неопределённости. Левый нижний- «хорошо смазанная машина», низкий индекс дистанции власти и высокий принятия неопределённости. Левый верхний угол - «деревенский рынок», низкие индексы дистанции власти и принятия неопределённости. Управление проектами предполагает модель «деревенского рынка», когда иерархия не столь важна (их может быть две - проектная и функциональная), важно не бояться неопределённости и уметь решать конфликты с помощью переговоров (Hofstede, 1983). Для других типов культур необходимо приспосабливать управление для достижения лучшего результата.

Маскулинность и феменинность. Страны с высоким уровнем разделения ролей по половому признаку (например, учитель - женская работа, водитель - мужская) называют маскулинными, а с низким - феменинными. С точки зрения Хофштеда, это измерение не связано существенно с управлением проектами.

В этих терминах Российской культуре соответствует:

· Индивидуализм

· Высокая дистанция власти

· Высокая степень избегания неопределённости

· Феминность

· Ориентация на краткосрочную перспективу

Различия в национальной культуре накладывают определённые ограничения на применение теорий и методологий, написанных для организаций с принципиально другой культурой. Этот фактор отмечен учёными и сейчас активно ведутся исследования в данном направлении.

В Своде Знаний по управлению проектами PMBoK: PMI культура отмечена как один из важных факторов среды организации. «В свете глобализации понимание влияния культур критически важно» Культура становится критическим фактором в определении успеха проекта». PMBOK. Некоторые исследователи также отмечают, что одно из предположений PMBOK: в управлении проектами существует неизменная часть и вариативная часть, на которую факторы национальной культуры оказывают прямое влияние. Особенно это актуально для проектов, в которые вовлечена мультикультурная команда, либо географически распределённая по разным местам. В Российских условиях - самая большая в мире и мультинациональная страна, это довольно часто встречающаяся ситуация, поэтому эта тема особенно актуальная для российских менеджеров проектов.

1.9 Этнокультурные особенности проектной деятельности в России

Развитие данной темы в сфере управления проектами в России пока на начальной стадии, однако начинают появляться новые научные труды, например, (Кожевникова, 2013) в работе «Этнокультурные факторы проектной деятельности в России: проблемы и инструменты» представила исследование влияния этнокультурных факторов. В ходе опроса менеджеров проектов из различных компаний (от крупных строительных до небольших ИТ и консалтинговых) были выявлены основные проблемные области управления проектами: управление сроками, качеством, персоналом и содержанием.

Сегодня огромное количество данных собирается о людях из разных стран, в том числе достаточно данных об этнокультурных характеристиках. В частности The World Values Survey (www.worldvaluessurvey.org) - глобальная сеть учёных-социологов, занимающаяся изучением изменения в ценностных установках, а также их влиянием на социальную, политическую и другие сферы жизни. На основе данных с этого портала построена, а также собственного исследования менеджеров, (Кожевникова, 2013) была составлена таблица ценностных ориентиров россиян по сравнению с американцами.

Таблица 1Сравнение россиян с жителями США.

	Оценка проявления у россиян (по сравнению с американцами)
Ориентация на результат	Меньше ориентированы на результат, хотя сознают необходимость его достижения
Работа среди жизненных ценностей	Инструментальная ценность работы (работа как достижение посторонних целей, а не самореализации), как следствие, вторичность работы по отношению к личной жизни
Отношение к вознаграждению	Более чувствительны к материальным ценностям и вознаграждению
Формализм и требования	Признают менее формальный подход, при этом привыкли к давлению на работе
Инициатива и достижения	В меньшей степени готовы проявлять инициативу и не ориентируются на достижения
Доверие и толерантность	Обладают меньшим уровнем доверия и толерантности

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

Пункты «Формализм и требования», «Инициатива и достижения», «Доверие и толерантность» представляют непосредственный интерес для практиков гибких методологий управления проектами в IT и других сферах. Тот факт, что россияне «признают менее формальный подход», является позитивным моментом, так как Agile практики основаны на менее формальной и более личной (не стоит воспринимать абсолютно) коммуникации, предпочитая неформальные планы и непосредственное общение между членами команды. Напротив, относительно низкий уровень доверия и толерантности, а также низкое желание проявлять инициативу и слабая ориентация на достижение являются негативными факторами. Основой практически каждой гибкой методологии управления проектами является слаженная команда, обладающая должной степенью самостоятельности. Вполне очевидно, что низкая степень доверия и желания проявлять инициативу негативным образом сказываются на способностях команды.

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

1.10 Переход на agile с традиционного подхода к управлению проектами

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

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

Сложность перехода на новую методологию варьируется от организации к организации и зависит от множества факторов. Менеджер должен уделить особенное внимание обучению команды новым методикам, донесению ценности новой методологии до команды, ресурсной поддержке внедрения, апробации нового подхода (Fernandes, Ward, & Araъjo, 2015).

Важным аспектом при внедрении являются также способности персонала. (Cockburn, 2002) отмечал, что различия людей делают их более или менее приспособленными для определённого типа работы. (Boehm & Turner, 2003) развили классифицию, выделив 5 типов сотрудников:

3 - способны к переосмыслению метода, нарушению его правил для успешного применения в совершенно новой, непредсказуемой ситуации

2 - Способны к приспособлению метода к текущей ситуации

1 А - После обучения способны к использованию различных методов, предполагающих самостоятельный выбор. С опытом могут перейти в категорию 2.

1 В - После обучения способны выполнять стандартные процедуры

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

Для успешного внедрения гибких методологий необходимо достаточноеколичество сотрудников 2 и 3 типа. Если в организации значительная доля негибких сотрудников 1В, внедрение agile подхода рискованно. Стоит рассмотреть плановый, либо гибридный подход, который предполагает более основательное и формализованное планирование. Стоит также отметить, что данный подход даже более соответствует российской организационной культуре (Кожевникова, 2013).

Выводы по главе .

Гибкие методологии являются одной из главных альтернатив традиционному подходу к управлению проектами. Особенно эффективны они в условиях постоянно меняющихся условий среды, а значит - и требований к продукту. Подобная ситуация особенно характерна для сферы IT. Модель КФУ является хорошим способом показать факторы, которым менеджеру стоит уделить наибольшее внимание. В зарубежной литературе на данную тему нет единогласия: исследователи выделяют разные факторы в качестве ключевых для успех проекта. В России же подобных исследований практически нет. В то время как между странами существуют объективные различия в социокультурных факторах. Они не позволяют с большой долей вероятности проецировать выводы зарубежных исследований на российские компании.

2. Эмпирическое исследование ключевых факторов успеха для IT проектов

2.1 Методология исследования

Гибкие методологии управления проектами, базирующиеся на создании бизнес-ценности для заказчика в процессе постепенной итеративной разработки продукта прочно вошли в проекты в сфере IT. Они доказали свою эффективность в условиях неопределённости, которая сопровождает бизнес нашего времени. Однако вопрос применения agile на практике до сих пор вызывает споры среди теоретиков и практиков. В англоязычной литературе достаточно статей относительно ключевых факторов успеха agile проекта, но сложно сказать, что они единогласно выделяют какие-либо показатели (Fortune & White, 2006). Более того, в этих работах исследуются респонденты из разных стран, в то время как каждая страна имеет свои особенности в управлении проектами (Hofstede, 1983). Подобных работ о российских проектах крайне мало. Закрыть этот пробел - основная цель исследования.

Проведённое исследование можно разбить на 4 этапа:

· Подготовительный этап

· Этап сбора информации

· Этап анализа полученной информации

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

Сбор информации на втором этапе исследования осуществлялся с помощью дистанционного опроса профессионалов из сферы IT через интернет. Для этого опросник, созданный на предыдущем этапе был размещён на тематических форумах и группах в социальных сетях с использованием сервиса Google Docs.

Анализ полученной информации был осуществлён с помощью SPSS. Особое внимание было уделено анализу корреляций и построению регрессионных моделей.

2.2 Исследовательские гипотезы

На основе результатов предыдущих исследований были выдвинуты следующие гипотезы:

Таблица 2. Исследовательские гипотезы

Переменная	Связь
Удовлетворённость заказчиков	Связана с успехом
Взаимодействие с заказчиками	Связана с успехом
Время на принятие решений	Связана с успехом
Расположение команды	Не связана с успехом
Размер команды	Связана с успехом
Корпоративная культура	Связана с успехом
Планирование	Связана с успехом
Контроль	Связана с успехом
	Не связана с успехом
Личностные характеристики	Связана с успехом
Коммуникация	Не связана с успехом
Контакт с руководством	Связана с успехом
Использование специального ПО	Не связана с успехом
Видение у руководства	Не связана с успехом
Понимание роли	Связана с успехом

2.3 Описание процесса проведения опроса

Опрос - основной метод сбора информации в исследовании. Основой для вопросника послужила методика, применённая в статье (Misra, Kumar, & Kumar, 2009). Оригинальный опросник был переведён на русский язык и впоследствии модифицирован. После анализа предварительных интервью с менеджерами были добавлены несколько вопросов:

· Команда проекта и руководство компании регулярно обмениваются информацией о ходе реализации проекта

· Мы используем специальное ПО для удобства управления и коммуникации внутри команды

· У команды и руководства имелось чёткое видение, какого результата проект должен достичь

· Каждый член команды хорошо осознаёт свою роль и функции внутри проекта

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

Часть вопросов, была исключена из методики после обсуждения в ходе интервью с менеджерами и в ходе пилотажа исследования силами студентов НИУ ВШЭ. В частности переменная «Социокультурные факторы» не имеет смысла в контексте данного исследования, так как исследование проводится в рамках одной страны - России, поэтому факторы предопределены. В исследовании (Misra, Kumar, & Kumar, 2009) данная переменная отвечает за различия между странами, в которых осуществляют деятельность респонденты, что в данном случае некорректно.

После окончательной проверки опрос был размещён на сервисе Google Docs, а затем опубликован на тематических форумах и группах в социальных сетях:

· http://www.cyberforum.ru/

· http://programmersforum.ru/

· http://www.pmprofy.ru/

· http://www.microsoftproject.ru/

· http://www.pmi.ru/forum/

· https://www.facebook.com/

· https://www.linkedin.com/

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

Выдвижение исследовательских гипотез

2.4 Анализ результатов

Подход к опросу был полностью количественным, если не считать демографических вопросов. Были применены различные статистические методы для анализа данных закрытых вопросов. Основная цель исследования отношения между переменными: 15 независимыми (некоторые включали более 1 вопроса) и 1 зависимой - успешностью проекта. Были рассчитаны коэффициенты корреляции Пирсона для каждой независимой переменной, а также построена регрессионная модель.

2.4.1 Демографические показатели респондентов

В ходе исследования также была собрана дополнительная информация о респондентах. Большинство респондентов представляют компании в отраслях, связанных с компьютерами (software, hardware и т.п.) (76%), остальные отрасли представляют по 1 респонденту (6%) - телекоммуникации, консалтинг, продажи и финансы.

Значительно большее разнообразие имеется по размерам представленных организаций:

Таблица 3. Описательная статистика - количество работников в организации

Можно сказать, что представлены как совсем небольшие организации в 10-20 человек, так и средние и крупные компании.

Большинство респондентов представляют команды в 5-10 человек (41,2%) или 11-20 человек (41,2%), остальные размеры команды представлены небольшим количеством респондентов (по 5,9%). Стоит отметить довольно ровную выборку: примерно 50% респондентов представляют маленькие команды (до 10 человек) и 50% команды более 10 человек.

Самый важный момент в демографической части опроса - опыт работы с Agile методологиями:

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

Выборка довольно ровная: присутствуют респонденты с различным опытом работы с agile методологиями. Некоторое преобладание респондентов с опытом до 3 лёт, вероятно, обуславливается тем фактом, что agile подход в России только начинает набирать популярность.

2.4.2 Тест надёжности переменных модели

Анализ валидности был проведён для переменных, составленных из нескольких показателей. В качестве способа определения был выбран коэффициент Альфа Кронбаха. Данный показатель оценивает внутреннюю согласованность переменных и измеряется в значениях от 0 до 1, где 0 - полностью не согласованы, 1 - полностью согласованы. Таким образом, чем выше значение, тем лучше для исследования. Существуют различные точки зрения на порог отсечения, но наиболее популярное пороговое значение - 0,7.В таблице представлены результаты для составных переменных:

Таблица 5. Анализ валидности переменных

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

2.4.3 Анализ корреляций независимых переменных с успешностью проекта

Основная концепция исследования - анализ взаимосвязи между 15 независимыми переменными (представляющими критические факторы успеха) и 1 зависимой - успешностью проекта. Одним из основных инструментов является коэффициент корреляции Пирсона. Для данного исследования уровень значимости - 95%. Результаты проведённого анализа представлены в таблице.

Таблица 6. Корреляция переменных

Переменная	Коэффициент корреляции Пирсона	Значимость
Удовлетворённость заказчиков
Взаимодействие с заказчиками
Время на принятие решений
Расположение команды
Размер команды
Корпоративная культура
Планирование
Контроль
Техническая компетентность команды
Личностные характеристики
Коммуникация
Контакт с руководством
Использование специального ПО
Видение у руководства
Понимание роли

По результатам анализа, только 3 независимые переменные обнаружили статистически значимую связь с успешностью проекта: Ориентация на удовлетворённость потребителя, Время на принятие решений, Контроль. Данные результаты согласуются с выводами исследования (Misra, Kumar, & Kumar, 2009). Самую сильную взаимосвязь с успешностью проекта.

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

2.4.4 Построение модели множественной линейной регрессии

...

Подобные документы

Сущность и функции корпоративной системы управления проектами (КСУП), ее элементы и предъявляемые к ней требования. Базовые методологии и процессы управления проектами. Характеристика основных ролей в контексте КСУП, этапы ее разработки и внедрения.

контрольная работа , добавлен 13.06.2013


Сущность понятия "проект". Связь методологии управления проектами с другими управленческими дисциплинами. Разница между менеджером и владельцем. Источники успеха руководителя. Рычаги управления проектами. Жизненный цикл и фазы инвестиционного проекта.

презентация , добавлен 21.11.2011


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

курсовая работа , добавлен 07.07.2015


Анализ существующих информационных технологий в области управления проектами. Разработка методики внедрения в работу образовательного учреждения программного комплекса управления проектами Microsoft Project и оценка эффективности его использования.

курсовая работа , добавлен 14.01.2014


Характеристика этапов развития управления проектами в России. Понятие, роль и актуальность проектного управления. Основные формы планирования и контроля текущей деятельности фирмы. Особенности управления проектами в фирмах-партнерах "1С:Франчайзи".

курсовая работа , добавлен 23.10.2015


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

практическая работа , добавлен 07.04.2015


Управление проектами в рыночных условиях, особенности управления ими в России. Управление эффективностью, рентабельностью и продолжительностью работы проекта. Деятельность людей в проектах. Факторы и правила достижения успеха в управлении проектами.

курсовая работа , добавлен 25.03.2008


Понятие, состав и виды проектов. Этапы управления проектами на предприятии. Организационно-экономическая характеристика ТОО "Казцинктех". Анализ экономических показателей работы предприятия. Основные проблемы в управления проектами и пути их решения.

дипломная работа , добавлен 22.05.2012


Проект и его характеристика. Управление проектом как одна из самых сложных и трудоемких задач управленческой деятельности. Виды организационных структур управления проектами. Анализ организационной структуры управления проектами в ООО "Ай-Ти Сервис".

дипломная работа , добавлен 18.02.2013


Понятие и структура корпоративной системы управления проектами. Основные методы диагностики уровня зрелости управления проектами. Инициация и планирование, финансирование проектов. Управление программами, рисками, коммуникациями и портфелем предприятия.