Agile простыми словами. «Гибкая разработка»: кратко о методологиях Agile

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

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

Размещено на 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


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

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

Общая информация

Первоначально давайте разберёмся с техническими моментами. Что собой представляет Agile? Перевод (дословный) этого слова с английского языка - «живой, подвижный», немногим реже упоминается «гибкий». И кстати, это сокращение. Полное название этого подхода это Agile software development. Но поскольку это слишком долго, то и было решено сократить. И сейчас говорят просто Agile. Перевод как «гибкий» используется из-за того, что он в наибольшей мере соответствует реальной ситуации.

Что же сюда включено?

Продолжаем рассматривать, что такое Agile. Здесь хочется сконцентрировать внимание на том, что это гибкий подход, в основе которого лежит множество различных ХР, "Канбан", Lean). Для того чтобы лучше разобраться в теме, давайте проведём параллели. Допустим, что Agile-технологии - это процесс зарождения Вселенной. Конечный продукт - непосредственно сам существующий мир. А большой взрыв - это наиболее болезненная проблема, с которой только приходится встречаться, - изменение перечня требований к продукту. Обычно процессы создания подразумевают использование каскадной модели. В этом случае всё идёт последовательно и по этапам. Такой подход можно выразить кратко: вижу цель - иду к ней. И если меняются требования к конечному результату, то иногда приходится переделывать заново едва ли не всё. Что еще усложняет такую ситуацию, так это попытка сделать вид, что всё нормально, и нужно двигаться вперед.

И вот управления, призвана бороться со всем этим благодаря своей гибкости. Эта сборная "солянка" минимизирует различные риски посредством использования наборов принципов. Все они отражены в Agile-манифесте, выпущенном в 2001 году. Если кратко, то звучат они следующим образом:

1. Главное - это люди, а не вещи.
2. Сотрудничайте, а не читайте контракт.
3. Документация не должна мешать работать.
4. Меняйтесь настолько быстро, насколько это возможно.

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

Устройство процессов

Рассматривая, что такое Agile, давайте обратимся к одной из самых популярных методичек, известной как "Скрам" (Scrum). Что же она предлагает? Для начала нужно:

1. Выбрать владельца продукта. На эту роль подходит человек, что видит, к какой цели нужно идти, и что будет в конечном итоге.
2. Определиться с командой. Для этого необходима группа, численностью от трех до десяти человек, что владеют навыками, позволяющими получать результат.
3. Выбрать ответственного специалиста. Это человек, что будет следить за развитием проекта и помогать команде обходить трудности.
4. Разобраться с трудностями. Следует собрать в одном месте все существующие требования к продукту и расставить приоритеты. Владелец продукта должен собрать здесь все свои пожелания. Потом команда их оценивает и разбирается, можно ли это реализовать, и сколько времени для этого нужно.
5. Следует разбить весь объем работ на отрезки времени, длиной в неделю или две, во время которых команда будет выполнять определённые наборы задач.
6. Ежедневно следует проводить встречи, длиной не более пятнадцати минут. На повестке следует обговаривать, что было сделано вчера, какие планы на сегодня, и преграды, мешающие брать высоту.
7. Делать обзоры по итогам недели (двух), во время которых командой рассказывается о том, что было сделано. При этом необходимо демонстрировать работоспособность частей продукта.
8. После каждого временного периода необходимо обсуждать проблемы и искать решения. Причем все наработки необходимо внедрять сразу.

Как опознать Agile?

Методология управления независимо от выбранного направления всегда обладает такими особенностями:

1. Минимизация рисков. Это главная цель, которую преследует любой гибкий подход.
2. Итеративная разработка. В данном случае подразумевается работа в небольших циклах.
3. Самое важное - это люди и коммуникация между ними.

Давайте представим реку. На одном берегу заказчик. На втором - команда. В таком случае гибкая методология разработки имеет преимущества для всех:

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

Социальный фактор

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

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

Небольшой пример

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

Поскольку используется гибкая методология разработки, то пользовательские истории не копятся до большого релиза, а выпускаются сразу после завершения и как можно чаще. Количество обработанных обращений составляет пропускную способность команды на неделю. Чтобы не потерять темп и не увязнуть в ручном тестировании, команда должна работать над автоматизированной интеграцией. В чем она заключается? Для каждого рабочего момента пишется автоматический тест. Если историй слишком много, то может возникнуть спешка, потеря мотивации, снижение производительности и качества. На такие случаи предусмотрен метод «вчерашняя погода». Он заключается в том, что нужно установить жесткие рамки количества работы и тщательно выбирать, что именно будет реализовываться. Упомянутый ранее "Канбан" предлагает устанавливать лимит задач.

А что делать с очередью?

Ладно, вот команда решила, что она может обрабатывать четыре истории на неделю. Но как сориентироваться во всём, что есть? Допустим, пользователи подкидывают по десять историй на неделю. Обрабатывается четыре. Таким образом, очередь будет постоянно расти. На этот случай есть только один эффективный метод - слово "нет". Для владельца продукта это чрезвычайно важно. Сказать «да» не трудно. Значительно сложнее и важнее решить, что не нужно делать. Причем за это необходимо ещё и нести ответственность. Поэтому следует решать, чему уделять внимание сейчас, а что следует отложить. Чтобы правильно нужно чтобы владелец продукта понимал ценность и объем каждой истории.

Принимаем решения

Часть историй чрезвычайно нужна. Другие же просто представляют собой приятный бонус. Одни истории будут разрабатываться несколько часов. На создание других уйдут месяцы. Многие часто проводят соотношение между размером истории и её ценностью. Но это не всегда правильно. Больше - не равнозначно лучше. Петру правильно рассматривать приоритеты помогает сложность и ценность выполняемой задачи. Как определить эти характеристики в количественном значении? Да никак. Это настоящая игра в угадайку. И для большей эффективности в неё необходимо вовлекать достаточно много людей. Это и команда разработчиков, которая проинформирует про объем работ, и заинтересованные лица. Но следует понимать, что все данные, полученные таким способом, представляют собой приблизительные догадки. Здесь не бывает точных цифр. Первоначально будут промахи. Но по мере получения опыта их количество и масштаб будут понижаться.

Возможные риски

Для избегания проблем необходимо дать честные ответы на ряд вопросов. Это:

1. Правильные вещи ли мы делаем? Это бизнес-риск.
2. Можем ли мы реализовать то, что нужно?
3. Будет ли работать проект на данной платформе. Это технический риск.
4. Хватит ли денег, и успеем ли? Это риски сроков реализации и стоимости.

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

Как обучиться?

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

Что ждёт в будущем?

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

В заключение

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

• Перевод

«Любое дело всегда длится дольше, чем ожидается, даже если учесть закон Хофштадтера.»
- закон Хофштадтера

Самый просматриваемый ролик на YouTube по теме agile. 744 625 просмотров на момент публикации данной статьи. Легкий стиль изложения, картинки и всего 15 минут - лучшее что я видел. TED отдыхает.

Роли

Пропускная способность

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

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

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

Scrum и XP в этом случае используют метод “вчерашняя погода”. Команда говорит: “За последнее время мы делали 4-6 фич в неделю, какие 4-6 фич мы будем делать на следующей неделе?”

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

Kanban рекомендует ограничиться несколькими задачами - WIP limit. Допустим команда решает, что 5 - это приемлемое количество пользовательских историй, над которыми они смогут работать одновременно без перегруза, не перескакивая с одной на другую.

Этой очередью тоже необходимо управлять.Если заинтересованные лица запрашивают 10 историй в неделю, а команда реализует 4-6 историй, то эта очередь будет становиться все больше и больше. И скоро ваш Backlog будет расписан на полгода вперед. То есть одна история будет ждать выхода 6 месяцев.

Есть только один способ держать список задач под контролем - это слово “нет”

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

Принятие решений

Как соотносится размер истории и ее ценность? Никак. Больше не значит лучше. Ценность и сложность задачи - вот что помогает Пэт расставлять приоритеты.

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

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

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

Пэт проводит встречу по очистке Backlogа каждую среду с 11 до 12. Обычно на ней собирается вся команда и иногда несколько заинтересованных лиц. Содержание встреч бывает разным. Фокусировка на оценке, на разбивке историй, на критериях приемки.

Владелец ИТ-продукта должен постоянно со всеми общаться

Баланс между сложностью разработки и ценностью пользовательской истории

Риски

Социальный риск: «Сможем ли мы сделать то что нужно?»

Технический риск: «Будет ли проект работать на данной платформе?»

Риски со стоимостью и сроками реализации: «Успеем ли и хватит ли денег?»

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

Компромисс между ценностями знания и ценностями для клиента

Компромисс между краткосрочным и долгосрочным мышлением

Делать правильные вещи, делать вещи правильно или делать быстро?

Между ролями в Scrum существует здоровое противостояние

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

Компромисс между разработкой нового продукта и улучшением старого

График уничтожения историй

Предположим, заинтересованное лицо спрашивает, когда вот эта фича будет сделана?

Обычно лучше уменьшать содержимое проекта, чем увеличивать время. Если мы уменьшаем содержание, у нас будет возможность отодвинуть сроки. Мы можем выпустить кое-что здесь, а остальное - позже.

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

Методология Agile – термин, который сейчас у всех на слуху, но что за ним стоит? Является ли он панацеей проектного управления или это замена устаревшим методам? Применим ли он где-то, кроме IT? Ответы на эти вопросы в данной статье.

Что такое Agile

Agile (англ. «проворный, сообразительный») – философия, совокупность гибких подходов к разработке программного обеспечения, которые стали использовать для управления проектами. Гибкие подходы подразумевают, что продукт создают в результате итераций, заказчик формирует требования постепенно, причем изменения требований приветствуются даже на поздних стадиях разработки. Исполнение требований заказчика обеспечивают рабочие группы, которые состоят из специалистов различного профиля. Ключевые идеи и принципы Agile закреплены в Agile-манифесте.

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

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

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

Скачайте и возьмите в работу:

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

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

Agile SCRUM

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

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

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

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

Методология предусматривает также структуру ролей в проекте:

• Scrum-master – посредник между заказчиком и командой;
• Product Owner – представитель заказчика, задачи которого - формировать и приоритизировать Product Backlog, и принимать промежуточные результаты спринтов;
• Team – команда проекта, в которой нет отдельных ролей, она является самоорганизующейся системой из кроссфункциональных мотивированных профессионалов.

Зачем Agile финансистам

Ключевые достоинства методологии управления проектами Agilw для финансистов:

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

• сбор требований;
• их анализ;
• создание архитектуры;
• создание дизайна системы;
• кодирование;
• тестирование;
• выкладка;
• эксплуатация.

Для чего нужна методология гибкой разработки?

• Ускорение вывода продукта на рынок . Если вы хотите что-то сделать быстрее, нужно делать это в соответствии с Agile. Очень простой пример. Есть две компании, у них примерно одинаковый бизнес. Одна пишет ТЗ, затем проектирует систему и рисует дизайн - это водопадная модель, на разработку которой может уйти несколько месяцев. Во второй компании, работающей по Agile, к этому времени может быть уже запущен сайт, выпущено ПО, она начнет зарабатывать деньги и захватывать рынок, что самое главное.
• Управление изменениями в приоритетах . Это, пожалуй, весьма болезненная проблема практически для всех компаний. Если вы делаете проект, который длится хотя бы несколько месяцев, то у вас обязательно поменяются требования. Конечно, если это не софт, например, для спутника или марсохода. Хотя даже спутникам и марсоходам обычно заливают свежую версию софта, когда они прилетают в точку назначения. Если говорить про коммерческую разработку, то проблема в том, что мы, программисты, аналитики и дизайнеры, никогда не знаем, что нужно не только заказчику, который нам платит, но и пользователям. Обычно все подходят к вопросу так: пока пользователь не попробует функционал сайта или приложения, вы не знаете, нужен он или нет.
• Улучшение взаимодействия между IT и бизнесом . Это головная боль, особенно для крупных компаний, ведь у бизнеса периодически меняются требования, каждый говорит на своем языке. В результате стороны друг друга не понимают.

Манифест гибкой разработки

• Если вы хотите построить гибкий процесс, вам нужно взаимодействовать и общаться между собой. В чем это выражается - рассмотрим ниже на примере Scrum. При этом вы можете (и обязательно будете) использовать какие-то инструменты и процессы, например, трекеры - JIRA, Redmine и т.д. Но ваша работа должна опираться на различные митинги, встречи и взаимодействие, а не на настройки трекеров или TFS (если говорить про Microsoft стэк).
• Работающий продукт, который мы делаем, намного важнее, чем документация по нему. Выше был приведен пример с двумя компаниями: у одной имеется готовый продукт, который можно дать пользователям, заказчику, захватив рынок; а вторая пишет ТЗ, рисует макеты и т.д. Вся эта документация, которую пользователь не может применить по причине не готовности продукта, не приносит ценности этому пользователю. Если мы научимся работать, минимизируя эти шаги, либо делая их небольшими кусочками, то у нас получится более гибкий процесс.
• Сотрудничество и взаимодействие с заказчиком важнее жестких контрактных ограничений. Обычно подписывается договор, в котором указано, что к конкретной дате за определенную сумму разработчик обязуется выполнить оговоренный объем работ. Естественно, к договору прикладывается ТЗ. То есть фиксируется время, объем работ и сроки. Это называется Fixed Price. Такой подход не очень хорош, если вы хотите работать на долгосрочную перспективу и быть гибкими. В этом случае правильнее выстраивать партнерские отношения с заказчиком. Если говорить про контрактные оформления, то обычно это выливается в контракты по схеме «время - материалы», когда разработчику просто оплачивается потраченное время. Самое главное, что здесь начинается поиск партнерства и ситуации Win-Win, когда побеждает и заказчик, и его подрядчик.
• Готовность к изменениям во взвешивании со следованием первоначальному плану.

Приведу свежий пример. Мы выкатили небольшую фичу на HeadHunter, когда ваши навыки может подтверждать любой - поставил вам плюсик, и появится надпись, что столько-то человек подтвердило ваш навык. У меня Scrum подтвердило 18 человек. Мы специально запустили это в очень простом виде, чтобы посмотреть, как к этому отнесутся пользователи. Мы исходили из логики, что будет взаимодействие а-ля LinkedIn или Хабр, где пользователи друг друга плюсуют. Сняли статистику, и оказалось, что у нас эти плюсики ставят, вероятно, после собеседований HR. То есть дальше мы можем развивать эту фичу в сторону HR, либо как-то ее модифицировать, чтобы она была более полезна соискателям. Таким образом, в Agile существует четыре ценности:

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

12 принципов Agile

1. Наивысшая ценность - это удовлетворение потребностей заказчика благодаря регулярной и максимально ранней поставке ценного для него ПО. Если заказчик хочет получить от нас большого слона, но мы можем дать ему часть этого слона не через год, а через три месяца, потом еще через три месяца еще одну часть, а затее ежемесячно выдавать кусочки, то чем чаще мы это будем делать и чем раньше, тем лучше.
2. Мы всегда готовы изменять требования, даже на поздних стадиях проекта, если узнаем что-то новое. Таким образом, мы создаем бизнесу или внешнему заказчику конкурентное преимущество. Допустим, работают две компании: одна написала ТЗ и за год сделала продукт, а мы сделали концепцию продукта (неважно, в каком виде) и постепенно его выкатываем и раскатываем. Тогда наш продукт будет больше соответствовать требованиям заказчиков, пользователей и рынка в целом.
3. При использовании Agile работающий продукт выпускают максимально часто. В манифесте прописаны сроки - от пары недель до пары месяцев. На самом деле это неделя/месяц, если вы используете Scrum. В России чаще всего каждые две недели выпускается что-то новое. А если делают какой-то веб-проект, то обычно используют одну из вариаций Kanban, значит, релизы можно делать каждый день. В HeadHunter обычно ежедневно выходит несколько релизов, что создает большие проблемы для наших конкурентов. Это могут быть правки багов, но мы умеем добавлять что-то ценное для наших пользователей.
4. Бизнес обязательно должен работать вместе с программистами, помогать им понять специфику данного рынка. Например, программисты в HeadHunter должны понимать, как работает HR, и как соискатели ищут работу. Если вы работаете в банке, то вам требуется понимание принципа работы банка в целом и очень подробные сведения о той сфере, за которую вы отвечаете. Наиболее частой проблемой, по моему опыту, является недоступность бизнеса - когда разработчик не может получить у сотрудника нужную информацию. При использовании Agile важно избегать возникновения подобных ситуаций.
5. Команда - один из краеугольных камней Agile. Наилучших результатов достигает команда замотивированных профессионалов. Есть гениальное замечание о том, что эффективность Scrum зависит от руководителя. В Agile руководитель прежде всего должен создавать условия для команды и обеспечивать всестороннюю поддержку, проводить коучинг, следить за атмосферой в коллективе.
6. Есть много исследований, которые показывают, что лучшее общение - лицом к лицу. Причем желательно, чтобы было какое-то средство визуализации, на котором можно писать: лист бумаги, доска со стикерами и т.д. Самый простой и эффективный способ узнать требования клиента, заказчика или пользователя - поговорить с ними.
7. Работающий продукт. Про него повторяться не буду. Степень готовности проекта должна измеряться не словами, о том, что ТЗ уже написано и 50% макетов нарисовано, а количеством функционала, выпущенного в production.
8. В Agile важен ритм, постоянные улучшения. Бизнес и программисты всегда должны иметь возможность делать процесс устойчивым, постоянно его улучшать.
9. Про этот пункт менеджеры обычно не любят говорить разработчикам, но Agile вообще не будет работать, если вы написали быдло-код. У вас должна быть хорошая гибкая архитектура, в которую можно добавлять разные элементы и при необходимости легко их изменять. И если команда не будет уделять максимум внимания техническому качеству (писать хороший код, использовать инженерные практики, автоматизировать процессы), то никакого Agile у вас не будет.
10. Простота. Она проявляется в технической составляющей, в дизайне. Это один из принципов экстремального программирования. Простота очень важна также с точки зрения выпуска продукта: когда вы хотите «нарезать» того «слона», лучше начать с простой части.
11. Менеджер (руководитель, Scrum-коуч, Agile-коуч) в команде меняет свою роль: он не столько занимается организацией процесса, сколько учит команду, поэтому команда должна быть самоорганизованной. Есть специальные стратегии, как из группы людей сделать самоорганизованную команду.
12. Команда должна постоянно анализировать свою работу, процессы: что получилось, как они этого добились, и постоянно улучшать организацию работ.

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

Практики

1. На первом месте стендапы . В России, даже если компания полностью зафейлила внедрение, использование и адаптацию Agile, обычно все равно остаются стендапы. Если у вас не получается их использовать, значит, у вас совсем не организованная команда. Практика простая: каждый день в определенное время команда собирается и синхронизирует свою деятельность.
2. На втором месте планирование итераций , когда команда планирует объем работ на ближайшую итерацию. Это к вопросу о том, что в Agile нет планирования. Если у нас итерация идет две недели, то мы пытаемся сделать план, декомпозицию, может быть, разбить бизнес-задачи на задачи технические.
3. Unit-тестирование - одна из самых простых инженерных практик, которую можно достаточно быстро начать использовать. При наличии проблем с качеством порядка 60-70% багов можно отловить unit-тестированием.
4. Планирование релизов . Здесь мы уже планируем большими кусками - что и когда выпустим. Если речь идет о Scrum, то измеряем большими мазками, в спринтах.

Нам надо дойти из точки А в точку Б. «Дойти» - означает «получить обратную связь». Допустим, у меня есть GPS, я могу дойти до какой-то точки и свериться, правильно ли я дошел. Водопадная модель - фактически, один большой шаг. То есть я куда-то пришел, выпустил на рынок продукт, и только после этого могу понять, то ли я сделал. Итеративная модель - это серия шагов. Я делаю первый шаг, снимаю метрики, что у меня используется в продукте, затем корректирую дальнейшие шаги. Пусть я приду не в точку Б, но окажусь в ее окрестностях.

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

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

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

Если вы работаете по «водопаду», то обычно у вас фиксировано содержание проекта. Вам говорят: «Хочу, чтобы вы сделали это. Я точно знаю, чего хочу я и мои пользователи. Оцените, сколько человек вам для этого нужно и сколько времени на это уйдет». В Agile мы действуем по-другому: у нас есть команда и фиксированные отрезки времени (я говорю про Scrum), например, двухнедельные итерации. Исходя из этого, мы планируем объем работ, который мы можем выполнить за это время.

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

Scrum

• Первый тип (A): у нас есть фаза разработки, все жестко, последовательно и хорошо.
• Второй тип (B): связи пересекаются, есть возможность получить обратную связь. Я запрограммировал что-то, программирую еще, отдаю тестировщику, он дает свои комментарии, я успеваю их обработать до завершения своей работы.
• Третий тип: каждая фаза пересекается более чем с одной другой фазой. Я программирую еще что-то, а мои первые задачи тестируются, выкладываются в production, с них снимаются метрики, я могу внести изменения.

Тип C двое японцев сравнили с ситуацией в регби. Почему? Смысл игры в том, чтобы взять мяч и донести его до линии поля противника, преодолевая сопротивление. Но в регби нельзя кидать мяч вперед. Когда ты бежишь и понимаешь, что сейчас тебя положат наземь, то мяч можно отдать назад члену своей команды. Он его ловит и бежит дальше. Если не может преодолеть сопротивление, то бежит назад.

Современный Scrum создан двумя айтишниками - Кеном Швабером и Джефом Сазерлендом. На официальном сайте www.scrumguides.org вы можете ознакомиться с официальным описанием Scrum. Так выглядит общая схема Scrum:

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

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

Компоненты Scrum

Роли
Scrum-команда состоит из команды разработки, владельца продукта и Scrum-мастера.

• Почему мы говорим, что Scrum - это гибкий Agile-фреймворк? Потому что он напрямую реализует ценности и принципы, описанные в начале публикации. Команда в Scrum должна быть самоорганизующейся, а Scrum-мастер помогает ей такой стать, учит, как можно быстрее и качественнее из элементов бэклога создать инкремент продукта - новую версию софта. Scrum-мастер отвечает за то, чтобы все процессы работали, чтобы участники понимали, зачем и как это делается.
• Владелец продукта, product manager - человек, ответственный за максимизацию ценности продукта, он отвечает за продукт (например, Стив Джобс).
• Команда разработки должна состоять из мотивированных профессионалов, которые могут в течение каждого спринта делать поставку, то есть на основании требований создавать готовый продукт.

Процессы

• Ежедневный скрам - это планерка, на которой члены команды рассказывают, что сделано, с какими проблемами столкнулись, что планируется сделать в ближайшее время, чтобы каждый понимал, кто и что делает.
• Спринт - итерация с фиксированным сроком, то есть в Scrum должен быть ритм.
• Планирование спринта. Перед началом спринта все собираются и определяют, что нужно сделать в течение спринта и в каком виде.
• Обзор спринта или демонстрация: все собираются и демонстрируют, что нового в инкременте продукта, смотрят, фиксируют замечания, может быть, меняют ближайшие планы.
• Ретроспектива: все собираются и думают, что можно улучшить в следующем спринте. Например, было много багов, пользователи недовольны. Давайте попробуем в следующем спринте использовать модульное тестирование. Пробуем, на следующей ретроспективе смотрим, помогло или нет, придумываем что-то еще.

Бэклог спринта - верхняя часть бэклога. Количество элементов обычно определяется скоростью команды на мероприятии, которое называется «планирование спринта», и проводится перед началом самого этапа спринта. Спринт длится 1-4 недели (чаще всего 2 недели). Чем быстрее и дешевле можно релизить, тем меньше продолжительность данного этапа.

Каждый день команда проводит 15-минутный стендап, Scrum-митинг, на котором все члены команды синхронизируют свои действия. Зачастую эти встречи называют просто «скрамами».

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

Артефакты
Это могут быть карточки на доске с кратким описанием, что собой представляет конкретный функционал. При этом содержание карточки может представлять собой обсуждения с владельцем продукта. Обычно это выливается в тикеты в трекере, который вы используйте - JIRA, Redmine и т.д.

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

Примеры Scrum-практик: оценки

Agile и Scrum предлагают использовать такую практику: делать относительные оценки, то есть «измерять в попугаях». Это значит, что я оцениваю время, которое у меня уйдет на решение задачи, и сколько она займет попугаев. Их обычно называют story point. Эти story point лучше не привязывать ни к каким временным промежуткам. Каким образом делать такую оценку, почему она называется относительной? Обычно берут какую-то задачу, небольшую, стандартную и понятную всем, и объявляют ее мерой, эталоном - она занимает 1 попугай, 1 story point. Берется следующая задача, сравнивается с первой - она оказывается в 2 раза больше. Сколько она занимает? 2 story point. И таким образом мы раскладываем все задачи. В итоге мы не оцениваем каждую задачу по времени, а сравниваем их между собой. Если где-то ошибаемся, то это нормально. Главное, чтобы во всех задачах ошибались одинаково. Оценка делается командой и в рамках команды.

Что мы можем сделать после этого? Например, запустить двухнедельный спринт и взять верхние задачи без каких-то оценок. Когда спринт закончится, на выходе получим инкремент продукта, в который будет включено какое-то количество задач. Посчитаем, сколько story point мы сделали, и на следующий спринт просто можем планировать такое же количество story point. Подобная оценка получается относительной и эмпирической. Мы не предполагаем, как любят делать управленцы, что программист Вася работает 8 часов и с одинаковой эффективностью, а реально измеряем, сколько команда может проживать story point за спринт. Шкала оценок обычно подбирается так, чтобы различать задачи разных классов.

Если приглядеться, то похоже на числа Фибоначчи, либо на степени двойки. При этом оцениваются обычно действительно большие задачи, которые дальше разбиваются на более мелкие. Для формирования оценок обычно используется покер-планирование. Это модификация метода Delphi. Каждому члену команды дается колода карточек с числами от 0 до 100. Есть еще карточка с надписью «Я не понимаю, что это за задача» и карточка с кофе («Давайте сделаем перерыв, я уже замучился заниматься этой оценкой»). После этого берем задачу номер такой-то, читаем и обсуждаем, что она собой представляет: «Пользователь вводит логин-пароль для того, чтобы авторизоваться на сайте». Обсуждаем, как эта авторизация происходит, где мы храним пользователей. Затем каждый член команды рубашкой вверх кладет карту с оценкой, которую считает нужной. При этом разные члены команды друг на друга никак не влияют, потому что обычно в команде есть тимлид, ведущий, старший разработчик, на которого равняется большинство. После этого происходит вскрытие карт и обсуждение.

Согласно методу Delphi, обсуждение происходит между теми, кто поставил наибольшую и наименьшую оценки. Поставивший наибольшую обычно видит какие-то риски, которые не заметили другие члены команды. Он скажет: «Вы знаете, в эту базу, где у нас хранятся логины и пароли, мы давно не заходили. Там надо что-то отрефакторить, добавить колонку, применить другой хэш» и т.д. А человек, поставивший наименьшую оценку, либо не понимает задачу, либо видит способ сделать быстрее, либо уже делал что-то подобное. После этого происходит второй этап обсуждения: опять все кладут карточки рубашками вверх, потом вскрывают их. Обычно оценки более-менее сглаживаются. Снова проходит этап обсуждения, приходят к консенсусу. В результате записывается в трекер, в тикет-систему, либо прямо на карточку, что у нас эта задача на 3 story point.

Почему это очень хороший Agile-подход? Мы беседовали, обсуждали содержание задачи, основывали наши действия на взаимодействии людей, а не на каких-то формальных процессах. Если кому-то интересны процессные вещи - обратитесь к методу оценки Кокома. Чем еще хорош данный метод? Здесь получается некая командная ответственность за размер задачи. Все берут на себя ответственность за то, что задача действительно такого «размера». Если же вы будете измерять трудоемкость задач, скажем, в днях, то будут ситуации, когда кто-то в команде оценит ее в 8 дней и она попадет к нему, то он ее и будет делать 8 дней.

Что делать в том случае, если заказчик хочет понять, сколько времени займет реализация проекта и просит сразу дать ему оценку? Идеальный вариант - работать с заказчиком по системе «время - материалы». Если заказчик новый, то можно один проект сделать по Fixed Price, убедиться, что заказчик адекватный, и дальше придерживаться системы «время - материалы». Если заказчик не соглашается сразу на данную систему, то можно ее скорректировать: например, если вы заканчиваете проект к определенной дате, то получаете какой-то бонус. На эту тему в сети тоже есть презентации.

Примеры Scrum-практик: скорость команды

Если какая-то задача не помещается по размеру, то ее можно разбить на более мелкие, либо пометить, что она не войдет, либо отказаться от ее решения. Надо понимать, что скорость не будет равномерной. Люди работают с переменной интенсивностью, кто-то заболевает, кто-то работает медленнее из-за проблем дома, кому-то надо срочно пообщаться в соцсети, кто-то взял отпуск. Всегда нужно прямо и однозначно говорить владельцу продукта: «У нас есть задачи A, B, C, мы их точно успеем сделать, они попадают в нашу самую низкую скорость. Есть также задача D, которую мы, скорее всего, успеем сделать. Но есть и задача F, которая может выпасть». Кажется, что это неточность, и владелец скажет: «Вы что? Надо все успеть». На самом деле, когда вы ему говорите точно, что самые важные задачи будут сделаны, то это увеличивает доверие между вами и владельцем продукта или заказчиком, и он для каждого спринта сможет выбирать самые важные задачи и гарантированно их получать.

Примеры Scrum-практик: путевой контроль

По горизонтали отмечаем дни - это двухнедельный спринт, 10 рабочих дней. По вертикали с одной стороны отложены story point, с другой - истории пользователей или элементы бэклога. Если бы мы с вами были роботами, а задачи маленькими и разбитыми на кусочки, то мы шли бы по пунктирной линии - это линия идеального Burn Down Charts. Что эти линии означают? Верхняя - сколько мы сделали историй пользователей, нижняя - количество story point. Такие графики автоматически строятся во многих системах для трекинга задач.

Как их читать? Если ваш график находится над линией идеального Burn Down, то вы отстаете, медленно работаете. Тогда к концу спринта будет не ноль задачек или story point, а где-то 20-25. Можно в Excel построить тренд или регрессию и посмотреть, сколько у вас получится задач с такой скоростью - очень просто и наглядно. Если команда видит, что она идет поверх идеального Burn Down, то надо принимать меры. На практике обычно получается вот так.

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

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

Примеры Scrum-практик: доски задач

Примеры Scrum-практик: обзор спринта

Примеры Scrum-практик: ретроспектива

Начинается ретроспектива с открытия. Обычно она занимает 5% времени. Задача - растормошить всех присутствующих на ретроспективе, потому что очень часто в командах, особенно айтишных, присутствуют не очень общительные люди, но порой имеющие блестящие мысли. Задача ведущего заключается в том, чтобы разговорить этих людей. Второй этап - сбор данных, он занимает до половины времени. Команда ищет какие-то факты. Их можно вспомнить, достать из трекера, распечатать. Также можно собрать статистику по багам, кто репортил, каков их статус - вариантов множество. После сбора фактов начинается мозговой штурм: нужно понять, в чем проблема, проникнуть в суть, сгенерить идеи, которые помогут ее решить. На это уходит до трети времени. Например, если у нас много мелких багов, возникающих не на уровне интеграции системы, а в коде разработчиков, то можно предложить использовать модульное тестирование. Если у нас очень плохое качество, как его улучшить? Можно попробовать парное программирование, какие-то инструменты, которые делают автоматизированную проверку кода, еще что-то. Обычно набирается 5-10 идей. Далее нужно воплотить эти идеи в жизнь. Мы не можем сразу внедрить code review, разработать какие-то инструменты. Поэтому выбирается максимум одна-две идеи, реализацию которых надо запланировать на следующий спринт. После этого благодарим всех и закрываем ретроспективу. А еще через две недели можно оценить, получилось у нас это или нет, изучить другие проблемы.

На ретроспективе можно также понять моральный дух команды - для этого тоже есть инструменты. Можно просто начертить временную линию спринта, чтобы каждый член команды вспомнил, что происходило в этот день, наклеил стикер с фактом «закончил разрабатывать задачу», «исправлял быдло-код», «применил новую технологию Machine learning». После этого по каждому факту можно внизу нарисовать, насколько этот факт был для человека интересным, или, наоборот, отстойным. После этого построить медиану, которая отразит состояние и динамику морального духа команды.

Есть такое понятие, как «Цикл Деминга». Он состоит из четырех этапов: Plan - Do - Check (Study) - Act.

• Планирование (Plan).
• Реализация (Do).
• Проверка (изучение) (Check (Study)).
• Изменение (Act).

После этого можем вносить изменения: например, хотели сделать покрытие 50% - сделали, количество багов уменьшилось, но они еще остались - давайте поднимем до 70%. Или сделали 70%, цикл прокрутили второй раз, проверяем - улучшилось. Давайте сделаем 90%. Еще раз прокрутили: количество багов не уменьшилось, а затрат на написание и поддержку тестов получается много. Давайте сделаем более слабую границу. Благодаря этому циклу команда постепенно улучшает какую-то часть процессов. Самый простой вариант ретроспективы - Real-Time Board Service.

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

Напоследок о Scrum

Kanban

Ценности и принципы

• Начинаем с того, что есть сейчас, и дальше путем эволюции и постепенных изменений делаем из этого непонятного хаоса четко настроенную Kanban-систему. При этом стараемся только эволюционно изменять роли, зоны ответственности и обязанности. Поощряем инициативные действия на всех уровнях организации. Главная практика - визуализация, обычно в виде доски. Работа каждого члена команды должна быть визуализирована, видна всем.
• Количество работы в каждом процессе ограничивается. То есть в работе одновременно может быть не более какого-то количества задач. Это нужно для исключения мультитаскинга, который убивает эффективность. К тому же это дает определенные инструменты управления потоком задач.
• Все правила должны быть явными. Необходимо дать определение завершенности. Например, задача выполнена, если написан код, есть unit-тесты с покрытием 70%, и т.д.
• Необходимо делать улучшения с помощью постоянных экспериментов, используя модели и научный подход, в том числе цикл Деминга.

Визуализация

Обычно используется та же самая доска, что и в Scrum. Самый простой вариант - прото-Kanban. Поток задач разбивается на отдельные этапы. Что-то находится в плане, что-то в аналитике, что-то в разработке, что-то в тестировании, что-то мы уже сделали. При этом реализуется принцип ограничения количества одновременно находящихся в работе задач - WIP (Work in Progress). Есть формула Литтла, которая связывает скорость прохождения задачи в такой системе и количество одновременных задач. Чем меньше WIP, тем быстрее задачи проходят цепочку. Допустим, у нас завал в тестировании, а разработчик сделал следующую задачу. Он видит, что у тестировщиков проблема. Тогда разработчик помогает им что-то сделать, или они идут к руководителю и говорят: «Нам нужен еще тестировщик».

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

Здесь есть те же самые WIP, внизу - критерии готовности (Definition of Done). Столбец делят на две части: «в работе» и «выполненное». Иногда доску делят на дорожки и размещают WIP по горизонтали. Это уже более продвинутая, полноценная Kanban-система. Каждая дорожка соответствует определенному классу обслуживания. Например, есть горячие задачи, когда к вам прибегает начальник и говорит: «Надо сделать это быстрее». Это отдельный класс обслуживания, под него стоит забронировать WIP.

Как и в Scrum, здесь тоже можно создавать диаграммы. Обычно их называют «Диаграммы кумулятивного потока». По горизонтали отмечено время, по вертикали - количество задач. Разными цветами показаны разные этапы. Я упоминал, что улучшение нужно осуществлять на основе цифр, используя научный подход. Эти цифры можно извлечь из диаграмм. Самые важные из них - WIP, то есть количество задач за исключением запланированных и выполненных. Мы его должны сокращать.

Вторые важные критерии - Cycle Time и Lead Time. Определения бывают разными, нужно очень внимательно смотреть. Эти два числа показывают, насколько быстро задачи проходят через вашу Kanban-систему.

В данном случае Lead Time включает в себя ожидание, то есть как воспринимают вашу Kanban-систему заказчики. Cycle Time - насколько быстро задача проходит через Kanban-систему без ожидания, в общем бэклоге. Оба параметра нужно уменьшать, тогда ваша система будет работать быстрее.

Итог

• «Scrum и XP: заметки с передовой». Автор - Хенрик Книберг, Agile-коуч из компании Spotify. Книга полностью бесплатна и на русском языке. Ее минус - она очень старая. Ее большой плюс - в ней разобрано много инструментов, приведены конкретные ситуации в виде диалогов. Книгу очень любят практики, и для многих, в том числе для меня, это была первая книжка на тему Scrum и Agile. Также в ней описаны элементы экстремального программирования.
• «Scrum и Kanban: выжимаем максимум». Тоже на русском и бесплатная. Можно сказать, что это книга про Scrumban.
• На мой взгляд, лучшей книжкой по Scrum является «Scrum: гибкая разработка ПО» Майка Кона. В ней очень подробно расписано, как внедрить Scrum, кем должны стать менеджеры, архитекторы. Самая подробная книга на эту тему.
• И такая каноническая книга по Kanban Дэвида Андерсона - «Kanban: Successful Evolutionary Change for Your Technology Business». В следующем году выйдет обновленная версия.
• Моя книга «