Глава 3 Внедрение Скрама в организацию. - LMS
advertisement
1 2 3 4 5 6 7 8 Правительство Российской Федерации Федеральное государственное автономное образовательное учреждение высшего профессионального образования «Национальный исследовательский университет «Высшая школа экономики» 9 Факультет бизнеса и менеджмента 10 11 12 Кафедра управления проектами 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 БАКАЛАВРСКАЯ РАБОТА На тему: «Проблемы перехода к гибким методологиям управления проектами в организациях» Студент группы № 424 Курис Михаил Михайлович Руководитель ВКР Старший преподаватель Зуйков К.А. 39 40 Москва, 2015 1 2 Оглавление Введение ................................................................................................................... 4 3 Глава 1. 4 применение на предприятии .................................................................................. 7 5 1.1 Целесообразность внедрения системы управления проектами ............... 7 6 1.2 Сущность гибких методологий управления ............................................... 8 7 1.3 Целесообразность применения гибких методологий .............................. 11 8 1.5 Статистика использования гибких методологий ..................................... 13 9 1.6 Использование Scrum и Scrum-bun методологий. Основные элементы, 10 инструменты ...................................................................................................... 16 11 Выводы по главе................................................................................................ 25 12 Глава 2. Проблемы внедрения и использования Scrum методологий ............. 27 13 2.1 Факторы успеха проекта............................................................................. 27 14 2.1.1 Структура команды .............................................................................. 28 15 2.1.2 Мотивационный тип работников ....................................................... 31 16 2.2 Факторы, препятствующие внедрению методологий управления 17 проектами ........................................................................................................... 33 18 2.3 Существующие способы развертки гибких методологий ...................... 38 19 Выводы по главе................................................................................................ 41 20 Глава 3 Внедрение Скрама в организацию. ....................................................... 42 21 3.1 Основная информация о компании. .......................................................... 42 22 3.2 Базовая информация о пилотном проекте ................................................ 42 23 3.3 Методы исследования................................................................................. 43 24 3.4 Анализ спринтов ......................................................................................... 44 25 Первый спринт. ............................................................................................. 45 Гибкие методологии управления. Ключевые особенности, 2 1 Второй спринт ............................................................................................... 46 2 Третий спринт................................................................................................ 47 3 Четвертый спринт ......................................................................................... 48 4 Пятый-шестой «спринт»............................................................................... 49 5 3.5 Модель внедрения гибкой методологии в будущие проекты компании 6 ............................................................................................................................. 50 7 3.5.1 Подготовительная работа. Сбор информации о компании ............. 51 8 3.5.2 Вопрос организации команды в организации ................................... 54 9 Вывод по главе .................................................................................................. 57 10 Заключение ............................................................................................................ 58 11 Список использованной литературы................................................................... 60 12 Приложение 1 ........................................................................................................ 63 13 14 3 1 Введение 2 Выбор метода организации рабочего процесса проекта требует 3 понимания характера поставленных задач: если они отличаются высокой 4 неопределенностью состава работ и требований к ним, то одним из 5 подходящих вариантов является внедрение гибких методологий управления. 6 Переход 7 управления и составляет отдельный проект. Правильная реализация этого 8 проекта приведет к менее затратному, более эффективному способу 9 управления, а ошибки могут привести к диаметрально противоположному 10 эффекту. В этой связи организация верного перехода к гибким методологиям 11 кажется стратегически важной для деятельности всей организации. к ним сопровождается изменением существующих систем 12 Преобразование системы управления – комплексный процесс, который 13 может сопровождаться изменениями во всех сферах организации (от 14 управления командой до управления рисками), однако в современных 15 исследованиях зачастую не учитываются ключевые факторы успеха, 16 например, изначальное состояние системы мотивации и управления 17 командой. Это может привести к ошибкам в планировании перехода и, как 18 следствие, не эффективному использованию гибких методологий. 19 Соответственно, актуальной проблемой является недостаток знаний 20 касательно того, с какими трудностями сталкивается организация в ходе 21 внедрения гибких методологий и какими способами их можно преодолеть1. Предметом 22 исследования будут служить: типичные проблемы, 23 возникающие при внедрении гибких методологий в проектную организацию. 24 Объектом исследования будет служить пилотный проект по внедрению 25 гибкой методологии, осуществляемый IT компанией Целью 26 исследования является выявление типичных проблем, 27 возникающих при переходе на гибкие методологии в организации, 28 определение причин их возникновения и создание плана внедрения гибкой 1 A literature review exploring challengesand solutions when implementing agile 4 1 методологии управления, исходя из накопленного в ходе пилотного проекта 2 опыта. Для выполнения поставленной цели необходимо решить следующие 3 4 задачи: 5 Определение критериев, показывающих необходимость 1. внедрения гибких методологий. 6 7 Анализ основных гибких подходов и обоснование выбора 2. скрама и канбана для конкретной организации. 8 9 Выявление основных проблем, возникающих в ходе 3. перехода на гибкие методологии в организации. 10 11 Определение путей уклонения от возможных проблем, 4. 12 нахождение эффективных инструментов для решения возникающих 13 трудностей. 14 Нахождение решений проблем для каждой из возникших в 5. 15 ходе пилотного внедрения проблем и их обоснование. Подбор 16 инструментов для эффективного внедрения гибкой методологии в 17 организацию. 18 6. Разработка рекомендаций по корректировке плана 19 внедрения гибких методологий в организацию с учетом найденных 20 решений. 21 В данном исследовании будут использоваться такие методы 22 исследования как структурированное интервью, невключенное наблюдение, 23 анализ вторичной документации (документации пилотного проекта). 24 Данная работа состоит из трех глав. 25 В первой главе будет раскрыта целесообразность внедрения систем (в 26 том числе гибких) управления проектами. Будут описаны и 27 проанализированы текущие тренды в использовании гибких методологий и 28 проанализирована «идеальная» система гибкого управления проектом. 29 Во второй главе будет освещен вопрос ключевых факторов успеха при 30 внедрении гибких методологий управления, проблем, возникающих в ходе 5 1 их внедрения, проанализированы основные теоретические концепции, 2 позволяющие решить их. Будут разобраны основные факторы, которые 3 вызывают наибольшие трудности у менеджмента при развертывании новой 4 системы гибкого управления. 5 В третьей главе будет проведен анализ пилотного проекта по 6 внедрению гибких методологий разработки, показано, как следовало бы 7 скорректировать 8 работающей системы. структуру управления 9 6 для создания эффективно 1 Глава 1. 2 применение на предприятии 3 Гибкие методологии управления. Ключевые особенности, В этой главе будут описаны теоретические основы, на которых 4 базируются гибкие методологии 5 концептуальные 6 методологий, 7 использования. 8 1.1 Целесообразность внедрения системы управления проектами особенности приведены управления внедрения основные и проектами, раскрыты использования предпосылки для данных начала их 9 Статистика показывает, что за последние 15 лет количество 10 организаций, использующих какую-либо систему управления проектами в 11 своей работе, существенно возросло (West D. et al., 2010), однако до сих пор 12 остаются организации, которые не торопятся внедрять методологии 13 управления. В основном, данный феномен встречается в маленьких 14 организациях (до 50 человек). Тем не менее, исследования Джона Келли 15 (Kelly J., 2012) показывают, что подобным организациям лучше всего 16 подходят свободные от бюрократии методологии, фокусирующиеся на 17 команде. 18 Кроме того, результаты анализа (Pollack J., Adler D., 2015), 19 проведенного на основе 2-х независимых лонгитьюдных исследований 20 показали, что пользователей систем управления проектами, увеличивших 21 свою прибыль, на 10% больше по сравнению с теми, кто не пользовался 22 данными системами. Кроме того, эти пользователи на 5% реже испытывали 23 снижение прибыли. Более того, организации – пользователи систем 24 управления в среднем продают более чем в 3 раза больше своих 25 «бессистемных» коллег. 26 Таким образом, можно заключить, что маленькие организации должны 27 быть мотивированы внедрять системы управления, ориентированные на 28 команду. 7 1 Кроме того, вспоминая классиков менеджмента, уместным будет 2 упомянуть концепцию долгосрочной эффективности Ренсиса Лайкерта. 3 Исследователь утверждает, что для того, чтобы изменить переменные 4 факторы (производительность, текучесть кадров), нужно воздействовать на 5 причинные переменные. Следовательно, если организация хочет улучшить 6 эффективность сотрудников, ей придется начать с себя и изменить одну 7 Рисунок 1 Схема изменения результирующих переменных 8 9 (или несколько) причинных переменных(Веснин В.Р., 2011). Одной из 10 возможных альтернатив для небольших организаций являются гибкие 11 методологии, являющиеся одним из наиболее популярных сейчас способов 12 управления проектами. 13 1.2 Сущность гибких методологий управления 14 Популярные ныне гибкие методологии управления проектами 15 базируются на манифесте, принятом в феврале 2001 года. С помощью этого 16 документа авторы популяризировали 4 идеи, которые раскрывают наиболее 17 эффективный (по их мнению) подход к разработке продукта проекта: 18 Люди и взаимодействие важнее процессов и инструментов 19 Работающий 20 документации 21 22 продукт важнее исчерпывающей Сотрудничество с заказчиком важнее согласования условий контракта 8 1 2 плану.2 3 Понимание данных ценностей является ключевым компонентом для Готовность к изменениям важнее следования изначальному 4 грамотного использования 5 правильная трактовка необходима при работе с ними. Главенство 6 «людей любой и гибкой методологии, взаимодействия» над поэтому их «процессами и 7 инструментами» означает, что не слепое следование стандартам и бездумное 8 использование данных инструментов приводит проект к успеху, но люди, 9 которые вовлечены в проект. Большая вера в команду накладывает на нее 10 серьезную ответственность, что смещает фокус внимания управленца с 11 контроля над выполнением существующих регламентов процессов на 12 качество работы команды. Следовательно, для обеспечения эффективности 13 допустимо 14 управления в пользу более действенных, причем, строго говоря, этой логике 15 стоит следовать в каждом конкретном случае т.е. для каждой независимой 16 команды. отказаться от устоявшихся в организации инструментов 17 Ценность «работающего продукта», «сотрудничества с заказчиком» и 18 «готовности к изменениям» идут рука об руку друг с другом. Каждая из этих 19 идей предполагает, что наивысшая стоимость продукта может быть 20 достигнута только при постоянном и тесном взаимодействии с заказчиком. 21 Исходя из этого, способность изменять определенные элементы продукта по 22 первому требованию является базовой для любой команды.3 Для этого в 23 жертву приносится скрупулёзность ведения документации по проекту. 24 Важно осознавать, что ведение отчетности все же должно вестись со всей 25 ответственностью: авторы всего лишь подчеркивают, что этот процесс не 26 должен замедлять разработку нужного продукта. 2 http://www.agilemanifesto.org/iso/ru/ 9 Соответственно, при 1 каждом новом взаимодействии с заказчиком важно предоставлять ему 2 обновленный 3 требованиям и быть готовыми изменить продукт при первой необходимости. вариант продукта, который соответствует текущим 4 Эти 4 основные идеи позволили иначе взглянуть на неопределенность 5 и изменения происходящие по ходу проекта. Если в уже ставшем 6 классическим подходе Деминга 7 трактуются скорее как что-то негативное, что-то, что должно быть 8 минимизировано, то практики гибких методологий, использующие несколько 9 иной подход PDCA изменения (plan-do-check-ack) (Envision-Speculate-Explore-Adapt-Close) относятся к 10 изменениям как к позитивному фактору, способствующему созданию 11 продукта с более высокой ценностью для потребителя. Можно сказать, что в 12 классических методологиях (например модель «водопада») изменения несут 13 в себе отрицательную обратной связью, а в гибких методологиях – 14 положительную (Черных Е. А., 2008). 15 Таким образом, толерантность к изменениям, причем изменениям не 16 только в плане работ, но и в способах достижения цели можно считать 17 необходимым 18 методологий управления проектами. условием для эффективного использования гибких 19 Кроме того, подход предлагает взглянуть на отношения с заказчиком 20 как на взаимовыгодное сотрудничество, объединение интересов для 21 достижения общей цели – создание ценного продукта. 22 Эти 4 идеи были расширены в 12 принципах, которые еще раз 23 подчеркнули «наивысший приоритет» потребностей заказчика и объяснили, 24 как должен проходить процесс разработки продукта при гибком управлении. 25 Кроме 26 взаимодействии с заказчиком и готовности к изменениям, там появились 27 новые тезисы. В том числе о простоте как способе минимизации лишних 28 работ, 29 совершенствования процессов. Так же эти принципы подчеркивают важность 30 самоорганизующихся команд. Это значит, что работа должна производиться 10 прямого переноса ценности мысли о важности непосредственного рабочего общения, продукта, постоянного 1 в хорошо мотивированных группах, где все члены не просто являются 2 специалистами в своей области, но нацелены на достижение одних и тех же 3 результатов самым эффективным путем. Такие команды не нуждаются в 4 руководстве сверху, решения в них принимаются путем обсуждения «на 5 равных». Тем не менее, важно помнить, что какой бы самостоятельной не была 6 7 команда, она: 8 Не ставит цели сама, обычно их назначает руководство; 9 Не определяет свой состав, а формируется «сверху».4 10 1.3 Целесообразность применения гибких методологий Управление на основе гибких методологий являются одним из самых 11 12 популярных 13 применения данного подхода достаточно широка, однако нельзя говорить об 14 универсальности подхода. Существует несколько работ, посвященных 15 целесообразности использования гибких методологий для реализации 16 проекта. Так, Г. Чин утверждает [7,стр 3-10], что данный подход следует 17 использовать при определенном наборе внешне и внутриорганизационных 18 факторов. Первичным фактором, при этом, он называет проектную 19 неопределенность, 20 неопределенность внешнюю и внутреннюю. Внутренняя, при этом, включает 21 в себя технические трудности и изменение возможность изменения плана 22 проекта (как сроков и стоимости, так и содержания), а внешняя – изменение 23 требований со стороны заказчика, борьбу с конкурентами, изменения в 24 бизнес-среде или стратегии. Кроме того, необходимость в экспертной оценке 25 значительного количества принимаемых решений и высокая скорость 4 способов организации которая, в проектной свою очередь, деятельности. Сфера подразделяется на Вольфсон Б. Гибкие методологии разработки, версия 1.2 (электронная книга), 2012 11 1 принятия этих решений еще дополнительными мотиваторами, которые 2 подталкивают к использованию гибких методологий. 3 Также необходимо принимать во внимание род деятельности 4 компании, внедряющей гибкие методологии. Лучше всего они подходят для 5 тех организаций, которые разрабатывают новые технологии или платформы, 6 а хуже всего – для тех, основная деятельность которых сконцентрирована на 7 процессной деятельности. 8 Другим значимым фактором является количество стейкхолдеров: чем 9 их меньше, тем легче применять гибкие методологии, которые не 10 предназначены для 11 заинтересованных лиц. удовлетворения потребностей большого числа 12 Существуют и более быстрые способы оценки необходимости 13 применения методологий, так Мари Лотс (Lotz M., 2013) рекомендует 14 оценить проект по следующей схеме: Таблица 1 15 16 Экспресс метод для выбора подходящей проектной методологии Фактор Значение фактора Размер проекта и его Относительно сложность небольшой и Гибкие методологии Метод водопада ﻻ несложный Большой и сложный Доступ к клиенту ﻻ Легкий доступ на ﻻ протяжение всего проекта Клиент не ﻻ может быть часто вовлечен Количество связей с Мало или простые ﻻ внешними системами Много, неизвестное ﻻ количество, сложные связи 12 Терпимость клиента к Клиент лоялен к ﻻ изменениям стоимости изменениям и содержания Фиксированный ﻻ бюджет, сроки сложно изменить Скорость изменения Необходимо быстрое рынка внедрение, возможно ﻻ ограничение функциональности Время разработки и ﻻ внедрения не так критично Желание клиента Клиент обозначил свое желание касательно используемой По желанию клиента, если нет явных препятствий методологии 1 Веса у каждого параметра назначаются экспертно, в зависимости от 2 3 особенностей отрасли/проекта. 4 1.5 Статистика использования гибких методологий 5 Гибкие методологии применяются в самых различных областях от 6 разработки программного обеспечения, до оказания финансовых услуг. В 7 целом, неудивительно, что наибольшей популярностью метод пользуется у 8 разработчиков ПО, однако среди респондентов VersionOne5 так же много 9 организаций, оказывающих финансовые услуги, услуги здравоохранения, 10 занимающиеся продажами 5 http://www.versionone.com/pdf/state-of-agile-development-survey-ninth.pdf 13 1 2 3 4 Рисунок 2Сферы применения гибких методологий Пользователи этих методологий заявляют, что основными причинами для внедрения являлось желание: 5 1. Ускорить процесс поставки продукта 6 2. Усилить способность маневрировать в условиях 7 меняющихся приоритетов 8 3. Увеличить производительность 9 4. Улучшить качество производимого ПО 10 5. Улучшить бизнес/работу IT отдела. 11 87% респондентов отметили, что внедрение методик позволило 12 эффективней менять приоритеты, 84% - увеличило производительность 13 команды, 82% – увеличило «прозрачность» проекта. 14 Среди пользователей методологий абсолютное большинство 15 использует Scrum (56%), 10% - гибрид Scrum и XP, 8% - другой тип гибрида, 16 6% - скрамбан, 5% - камбан(одни из самых известных японских принципов 17 организации производства), 4% - итеративный подход, а 3% не знали, какой 18 подход 19 бережливой разработки, XP и некоторые менее известные. Показательным 20 кажется тот факт, что организации отошли от использования XP(одного из 21 наиболее популярного метода начала 2000-ых), предпочтя ему более гибкие 22 подходы. В настоящий момент эта методология в подавляющем большинстве 23 своем используется лишь в сочетании с другими, более комплексными 24 средствами управления. используют. Остальные респонденты 14 использовали методы 1 2 3 Обратная ситуация наблюдается со скрамом, который в различных модификациях используется в 72% случаев. В качестве наиболее популярных инструментов были названы 4 ежедневные встречи (планерки), короткие итерации, 5 важности элементов журнала. Так же популярностью у почти 3-х четвертей 6 респондентов 7 ретроспектив. пользуется итеративное планирование ранжирование и проведение 8 Интересным будет отметить изменение в динамике пользования 9 инструментами, так, построение карт истории стало использоваться на 13% 10 реже, меньший спад показал метод досок задач (-3%). Остальные 11 инструменты применяются примерно с той же или более высокой частотой 12 (относительно прошлого года). Так, популярность набирает канбан доска 13 (+9% к 2013 году), электронные таблицы для структурирования информации 14 (+4%). Опрос показывает, что данные инструменты кажутся организациям 15 наиболее простыми способами повысить эффективность работы команд и 16 поднять качество контроля над выполнением задач на новый уровень. 17 Также важно учесть, что в качестве основных причин провала 18 проектов, основанных на гибких методологиях, были названы: недостаток 19 опыта пользования методологий, противоречия между корп. культурой и 20 философией гибких методологий, недостаток поддержки руководства, 21 давление со стороны, принуждающее пользоваться классическими техниками 22 управления (например, методом водопада). Почти треть респондентов также 23 отметила проблемы в коммуникациях. 24 В этом контексте целесообразным будет отметить, что наименьшим 25 количеством знаний о гибких методологиях, согласно опросам, обладают 26 владельцы продукта, и высший менеджмент. С такой статистикой не 27 удивительным кажется недостаток поддержки со стороны руководства и 28 проблемы в коммуникациях – управленцы просто не говорят на языке 29 команды проекта, не умеют мыслить в тех же терминах, а значит, не 30 способны адекватно наладить работу команд. 15 1 2 3 Таким образом, можно сформулировать следующие особенности применения agile методологий: 1. Постепенный переход от отдельных инструментов и 4 методик к комплексным решениям: увеличение доли скрам и канбан 5 пользователей при уменьшении популярности XP. 6 7 8 9 10 2. Расширение сферы применения гибких методологий – от разработки ПО до проектов здравоохранения 3. Ориентация на ускорение получения рабочего продукта как основная причина внедрения гибких методологий 4. Проблемы использования в каждом третьем проекте 11 возникают 12 организационной философии и философии гибких методологий, слабой 13 поддержке руководства. 14 1.6 Использование 15 инструменты из-за проблем в коммуникациях, несовместимость Scrum и Scrum-bun методологий. Основные элементы, 16 Итак, на сегодняшний день наиболее популярными способами 17 организации управления проектом/проектами, являются Скрам, канбан и их 18 синтез. Рассмотрим данные модели и разберем, как в идеале должно 19 происходить управление. 20 Скрам является бесспорным лидером среди всех остальных гибких 21 методологий (27, 30). Он завоевал эту позицию благодаря относительной 22 простоте идей, заложенных в его основу и способности трансформироваться, 23 вбирать в себя широкий спектр инженерных практик. 24 История этой методологии управления берет свое начало в 1986 году, 25 когда Хиротака Такэути и Икудзиро Танака описали ее в «Гарвадском 26 деловом обзоре». Они указывали на ее принципиальное различие с 27 традиционными подходами, и указали на существенную эффективность 28 скрама при создании инноваций. 29 компании, инициативу подхватили Кен Швабер и Джеф Сазерлэнд. В 1995 Внедрив подобный подход в свои 16 1 году метод был представлен широкой публике на конференции в Техасе. 2 Чуть позже, в 2001 году, скрам был раскрыт Швабером К. и Бидлом М. в 3 книге «Agile Software Development with SCRUM». 4 Формальное определение скрама, которое дают его создатели это: 5 скрам - фреймворк (т.е. структура системы управления) для разработки и 6 поддержки функционально сложных продуктов. Весь фреймворк раскладывается на 3 разные группы элементов: 7 8 Роли 9 Артефакты 10 Процессы В рамках данной структуры выделяют 3 вида ролей: владелец 11 12 продукта, скрам-мастер, команда проекта. 13 Разберем чуть более подробно каждую из этих ролей. 14 Владелец продукта ответственен за достижение продуктом 15 максимальной возможной ценности. Этот человек управляет беклогом 16 продукта (журналом продукта), а значит, именно он связывает команду с 17 заказчиком и объясняет ей, какой продукт он хочет получить. Именно в 18 рамках этой роли происходит оптимизация и приоритезация требований 19 заказчика. Все решения этого сотрудника отражаются в беклоге продукта, 20 соответственно, чем качественней проработан этот артефакт, тем лучше 21 работает владелец продукта. 22 Команда проекта занимается «разработкой потенциально “Готового” к 23 выпуску Инкремента продукта каждый Спринт» [6, стр. 5]. Предполагается, 24 что 25 поставленных задач, но, помимо всего прочего, важными особенностями 26 являются: 27 28 29 она самостоятельно организует кросс-функциональность свою т.е. работу команда по выполнению обадает всеми необходимыми навыками для создания продукта; внутри команды не существует формальной иерархии. 17 1 Количество человек для каждой отдельной команды может 2 различаться, но важно помнить, что группы, в которых состоит менее 3-х 3 человек не - эффективны с точки зрения принятия решений, а те, в 4 которых более 9 – относительно тяжеловесны и сложны в управлении. 5 Обычно, размер одной команды находится в промежутке от 7 до 9 6 человек, а значит, ей характерны особенности малой социальной группы, 7 что особенно важно при создании и грамотном управлении этим 8 образованием. 9 Деятельностью по управлению, а точнее координацией деятельности 10 всех членов команды, занимается скрам-мастер. Этот сотрудник обладает 11 обширным кругом обязанностей, в который входит как помощь владельцу 12 продукта с ведением беклога продукта (журнала продукта), так и 13 обеспечение грамотного внедрения и использования мероприятий скрама [6, 14 cтр 7.]. Также он занимается устранением препятствий, мешающих команде 15 работать эффективно и помогает ей понять как правильно использовать 16 скрам техники. На его же плечи возложена необходимость планирования и 17 внедрения фреймворка в организации. Рутиной для него служит обеспечение 18 бесперебойного и правильного организованного процесса разработки 19 продукта через проведение плановых мероприятий. 20 Таким образом, если владелец продукта обеспечивает связь команды с 21 заказчиком, то скрам-мастер берет на себя обеспечение эффективных связей 22 между всеми остальными участниками процесса. 23 Работая, команда оставляет после себя как минимум 3 различных 24 материальных следа – артефакта. К ним относятся: беклог продукта (он не 25 журнал продукта), беклог спринта (он же журнал спринта), инкремент 26 продукта. 27 Журнал продукта это упорядоченный по важности список требований к 28 продукту. Очевидно, что этот документ постоянно уточняется, дополняется 29 исходя из требований заказчика, поэтому его ведение доверено владельцу 30 продукта, находящегося с ним в тесном 18 взаимодействии. Являясь 1 единственным источником требований к продукту, документ содержит всю 2 информацию о проделанных и предстоящих изменениях и текущих/будущих 3 свойствах продукта. Журнал составляется исходя из принципа «один продукт 4 – один беклог» поэтому, если над проектом работают несколько команд, то 5 они ведут его вместе. Чем выше приоритет у той или иной задачи в проекте, 6 тем детальней она расписывается в данном беклоге. 7 Достаточно очевидно, что все требования к продукту не могут быть 8 выполнены в рамках одной итерации (в данном случае спринта), поэтому для 9 удобства выполнения задач создается журнал спринта, который содержит в 10 себе все требования, которые должны быть выполнены в течение текущей 11 итерации. Этот документ может быть изменен (и изменяется) на протяжении 12 всего спринта, исходя из объема и содержания работ, которые необходимо 13 выполнить для получения подходящего инкремента, соответственно, он 14 содержит в себе условия, при достижении которых итерация будет считаться 15 завершенной. Так как данный документ содержит в себе требования, 16 относящиеся к текущей деятельности, то он обязан быть как можно более 17 детальным и понятным для команды. Важно помнить, что данный документ 18 принадлежит исключительно команде проекта и служит инструментом 19 эффективного планирования деятельности. 20 Последним обязательным артефактом, создаваемым командой, 21 является инкремент продукта, который, по сути, является версией 22 финального продукта, реализованной к текущему моменту времени. 23 Итак, вопросы «кто выполняет работы?» и «что остается после итерации?» 24 рассмотрены и остается понять, как происходит выполнение работ в течение 25 одной итерации. 26 27 Теоретики скрама причисляют к основным процессам: планирование спринта, обзор спринта, ретроспектива, скрам-митинг, спринт. 28 По используемым терминам можно понять, что ключевым термином 29 является спринт – итерация, длиной до месяца, в течение которой 30 производится инкремент продукта. Наиболее благоприятным вариантом 19 1 развития событий считается неизменность длительности каждого отдельного 2 спринта. 3 Спринт состоит из 5 элементов: его планирования, ежедневных скрам- 4 встреч, непосредственной 5 ретроспективы. разработки продукта, обзора спринта, 6 По утверждениям создателей и популяризаторов Скрама, этот элемент 7 является сердцем всей методологии. Все остальные компоненты фреймворка 8 просто организуют и поддерживают работу внутри спринта. 9 До выполнения каких-либо работ команда должна знать, какие именно 10 работы ей необходимо выполнить. Следовательно, начальным этапом любого 11 спринта является его планирование. Обычно оно происходит на встрече всей 12 скрам команды проекта и ограничено 8 часами. В течение этого времени 13 группа отвечает на 2 ключевых вопроса: 14 15 16 1. Какой инкремент необходимо создать в течение следующего спринта? 2. Как будет выполняться работа? 17 Для ответа на первый вопрос используется беклог продукта, и 18 результаты прошлых спринтов (оценочная производительность команды и 19 созданный инкремент). Процедур для выбора конкретных задач для спринта 20 существует великое множество, но все они дискуссионные. Одним из 21 вариантов является покер-планирование, которое позволяет избежать 22 конфликтов внутри команды при определении приоритета работ. 23 24 25 26 27 28 29 Данный метод предполагает разбиение истории пользователей на отдельные задачи для обеспечения простоты оценки. Сам процесс проходит в пять этапов [Вольфсон, стр 42]: 1) «Каждому участнику раздается колода карт с числовыми весами для оценки требований. 2) Начинается обсуждение и оценка очередной истории пользователя: она 20 1 2 3 4 5 6 7 зачитывается, команда задает вопросы владельцу продукта, выясняет детали, если это необходимо. 3) Каждый член команды делает свою оценку, кладя карту рубашкой вверх. 4) После того, как все члены команды сделали оценку – все карты переворачиваются и оценки сверяются. 5) Если оценки всех участников одинаковы – консенсусная 8 оценка заносится в беклог, в противном случае начинается повторное 9 обсуждение и проводится второй раунд.» 10 Одним из основных достоинств метода является то, что он позволяет 11 бороться с мнением авторитетного участника группы, в случае, если его 12 оценка существенно отличается от мнения большинства. Большинство 13 чувствует уверенность в своей правоте и не так сильно склонно менять 14 мнение в пользу позиции лидера. 15 16 Кроме того, использование таймера позволяет ограничить время обсуждения и настроить команду на более конструктивный лад. 17 Также отмечается [Вольфсон, стр 42], что после покер-планирования 18 владелец продукта/заказчик начинает лучше понимать процесс выполнения 19 поставленной задачи, что может предотвратить постановку неадекватных или 20 невыполнимых требований. 21 На вопрос о том, как будет производиться работа, команда отвечает, 22 определяя, какие части журнала продукта реализовать в рамках спринта. 23 Первые несколько дней итерации расписываются наиболее подробно – до 24 подзадач длительностью до нескольких часов. После этого оценивается 25 общий объем запланированной работы, и, в случае, если ее получается 26 слишком много или слишком мало, команда возвращается к переговорам с 27 заказчиком/владельцем продукта. 28 29 После того, как был разработан план работ итерации, команда получает возможность приступить к созданию инкремента т.е. начинается спринт. 21 1 Для того, чтобы держать руку на пульсе процесса создания 2 инкремента, каждый 3 обсуждаются оперативные задачи на день, распределяются 4 определяется объем уже выполненной работы. Каждый работник в ходе 5 встречи должен разъяснить остальным: что он сделал к этому моменту, что 6 он собирается сделать, что может ему помешать. 7 день проводятся скрам-встречи, на которых работы, Для удобства оценки объемов работ часто используют канбан доски и 8 диаграммы сгорания. Инструменты позволяют наглядно показать, 9 укладывается ли команда в назначенные сроки. В случае возникновения 10 каких-либо проблем скрам-мастер должен постараться выявить, что 11 послужило причиной сбоев и как можно скорее устранить их. 12 При этом важно помнить, что контакты на таких встречах возможны 13 исключительно между членами команды и скрам-мастером - владелец 14 продукта или заказчик могут принимать в них лишь пассивное участие. 15 (Martin R. C., 2003). 16 В конце спринта предусмотрена встреча, которая позволяет команде 17 проекта встретиться с владельцем продукта/заказчиком, чтобы обсудить 18 проделанную работу. Именно в рамках этого мероприятия производится 19 корректировка журнала продукта и определение фронта работы для 20 следующих спринтов. Данное мероприятие, обычно, длится не более 4-х 21 часов и называется обзором спринта. Схематично процесс отлично 22 представить следующим образом [Вольфсон, стр. 8] 22 1 2 Рисунок 3Обобщенная схема обзора спринта 3 После проведения обзора, команда получает достаточно информации 4 от владельца продукта для того, чтобы начать планировать следующий 5 спринт. Однако, скрам, как и любая гибкая методология, предполагает 6 постоянное улучшение процессов, поэтому, перед планированием команда 7 проводит ретроспективу спринта. Эта своеобразная работа над ошибками, 8 совершенными в течение прошедшей итерации: коллектив выявляет, что 9 мешало эффективной разработке, какие элементы системы можно улучшить 10 и как это сделать. На общем собрании обязательно присутствуют скрам- 11 мастер и команда проекта, однако, приветствуется и участие владельца 12 продукта. 13 Схематично спринт можно представить следующим образом: 23 1 2 Рисунок 4Схема проведения спринта 3 Данная структура системы управления проектом получил призвание у 4 менеджмента, однако, в нем не хватает инструментов, с помощью которых 5 можно было бы осуществлять принятие решений и разработку продукта. 6 Этот недостаток организации обычно решают, используя Скрам вместе с 7 такими методиками как канбан и XP. Обычно, из канбана, кроме 5 правил, из 8 которых подход, собственно и состоит, заимствуют канбан доски, а из XP – 9 рефакторинг (т.е. процесс улучшения кода) и непрерывную интеграцию (т.е. 10 11 процесс внедрения кода в инкремент). Необходимо понимать, что канбан-доска это вспомогательный 12 инструмент, который визуализирует работы спринта и помогает работникам 13 в режиме реального времени отслеживать, какие части инкремента 24 1 необходимо доработать 2 3 Рисунок 5 Канбан доска6 4 Выводы по главе в рамках текущей итерации. 5 Данная глава прояснила ответы на несколько вопросов. Во-первых, 6 было показано, что организации, использующие те или иные методологии в 7 управлении проектами, получают большие прибыли и меньшие убытки по 8 сравнению с теми, которые не используют никаких методологий. Во-вторых, 9 оказалось, что для маленьких организаций лучше всего подходят те 10 методологии, которые концентрируются на команде проекта и не содержат в 11 себе сложных бюрократических процедур. В-третьих, было определено, в 12 каких случаях лучше всего использовать гибкие методологии, а в каком – 13 традиционные. 14 использования гибких методологий и выявлено, что наиболее применимыми 15 являются подходы, основанные на скраме. В-пятых, был проведен обзор 16 типового процесса управления проекта с помощью скрама, показано, что 17 львиная доля структуры системы сконцентрирована на команде, инженерные 18 же практики заимствуются из более прикладных методологий. В-четвертых, были определены основные тренды 19 Можно отметить, что относительная простота скрама (которая 20 особенно заметна, если сравнивать ее с «тяжеловесным» PMBok’ом), дается 21 не 6 бесплатно: в данной структуре системы http://panda-marketing.me/kak-my-vnedryali-gibkie-metodologii/ 25 даются практические 1 рекомендации по 2 оптимизации работы 3 предположить, что авторы полагали, что профессионалы своего дела сами 4 смогут наладить управление, тем не менее, статистика показывает, что 5 каждый 6 методологии, что снижает эффективность используемых методик. третий использованию и проект подхода, исправления сталкивается но игнорируется системных с ошибок. проблемами вопрос Можно использования 7 В следующей главе будут рассмотрены проблемы внедрения и 8 использования системы управления проектами - скрам, а также разобраны 9 ключевые моменты, на которые необходимо обратить внимание организации, 10 для удачного развертывания методологии. 11 26 1 Глава 2. Проблемы внедрения и использования Scrum методологий 2 В данной главе будет проанализировано, какие шаги необходимо 3 предпринять организации, чтобы успешно внедрить и, впоследствии, 4 применять скрам. Будут разобраны основные и самые критичные проблемы 5 развертывания 6 существующие пути разрешения данных трудностей. 7 2.1 Факторы успеха проекта исследуемой структуры системы и определены 8 Внедрение методологий происходит для увеличения эффективности 9 команд в частности и бизнеса в общем. Однако, одна и та же методология 10 может приносить совершенно разные результаты для двух проектов даже 11 внутри одной организации. В этой связи, особенно 12 считать определение факторов, которые имеют реальное влияние на 13 результат проекта. Данный вопрос достаточно часто изучался различными 14 институтами, однако одно из последних широких исследований провели Т. 15 Чоу и Д. Као (Chow T., Cao D. B., 2008). На примере 109 проектов они 16 проследили за тем, почему одни проекты заканчиваются провалом, а другие – 17 лучше ожидаемого. Ученые обнаружили, что существует 3 фактора, без 18 которых проект не закончится успехом: интересным 19 1. Правильная стратегия поставки инкремента 20 2. Адекватное использование инженерных практик 21 3. Эффективная команда можно 22 Кроме того, отмечалось, что грамотно налаженный процесс гибкого 23 управления проектами, сильная вовлеченность заказчика, подходящая 24 внешняя и внутренняя среды так же оказывают существенное влияние на 25 успех проекта. 26 Если на вопрос правильной стратегии поставки инкремента и 27 правильном использовании инженерных практик, в целом, отвечают уже 28 сами гибкие методологии управления проектами, то вопрос эффективной 29 команды остается относительно нераскрытым в современных исследованиях, 27 1 посвященных гибким методологиям (Boehm B., Turner R., 2005) . Если быть 2 более точным, то в исследованиях дается информация о том, как должна 3 работать команда, но вопрос перехода к этому «идеальному» состоянию 4 остается открытым. В данном случае важно осознавать, что эффективной 5 может быть только та команда, которой адекватно управляют. Как показала 6 статистика, одним из основных факторов провала внедрения гибких 7 методологий является их несоответствие с корпоративной культурой в 8 организации, определение «базовых» (т.е. до начала процедуры внедрения) 9 характеристик команды как элемента организации, должно являться 10 первоочередной задачей ответственного управленца. Представляется, что в 11 случае перехода к новой системе, ключевыми факторами, влияющими на ход 12 трансформации, будут являться: 13 Изначальная структура команды 14 Мотивационный тип сотрудников 15 Структура будет определять, к каким практикам привыкли сотрудники, 16 а мотивационный тип – как эффективнее всего повлиять на коллектив. 17 2.1.1 Структура команды 18 19 При управлении командой проекта принято выделять следующие типы структуры команды: 20 Изоморфная (Isomorphic) 21 Экспертная (expert) 22 Коллективная (collective) 23 Структура хирургической команды (surgical) 24 При изоморфной структуре, каждый сотрудник выполняет свою часть 25 работы независимо от членов своей команды и отвечает за эту работу 26 непосредственно перед менеджером проекта. Схематично, данный тип 27 командной структуры можно представить следующим образом: 28 1 2 Рисунок 6 Изоморфная структура команды 3 При экспертной командной структуре каждый из членов команды 4 занимается только теми заданиями, которые находятся в его компетенции (а 5 точнее те, на которых он специализируется) и взаимодействует только с 6 проектный директором. Соответственно, все сотрудники должны уметь брать 7 на 8 определенным уровнем самостоятельности. Схематично, данный тип 9 командной 10 11 себя ответственность структуры за принимаемые можно представить ими решения, следующим обладать образом: Рисунок 7 Экспертная структура команды 12 Следующий тип командной структуры – командный. Как следует из 13 названия, особенностью данного вида организации командной работы 14 является совместная работа всего коллектива. Все работники одинаково 15 вовлечены в работу над проектом, а все решения принимаются коллегиально. 16 Кроме того, другой особенностью данного типа командной работы является 17 отсутствие необходимости отчитываться перед менеджером проекта за 18 каждое принятое решение. Схематично, данный тип командной структуры 29 1 можно представить следующим 2 3 Рисунок 8 «Командная» структура организации команды образом: 4 Данный тип командной организации имеет существенное ограничение 5 – он не будет адекватно работать в слишком больших (больше 9-15 человек) 6 или слишком маленьких командах(меньше 3-х человек), где негативные 7 эффекты от принятия решения в группе (конформизма, социальной 8 фасилитации, 9 влиятельней положительных. ленности и проч.)(Титова Н.Л., 2004)7 оказываются 10 Еще одним типом организации команды является так называемая 11 хирургическая структура (по аналогии с командой хирурга в операционной), 12 где проектный директор ответственен за ход реализации всего проекта. В 13 своем подчинении он имеет в подчинении ассистентов, которые помогают 14 ему выполнять работы по проекту, однако всеми критичными операциями 15 занимается он сам. Схематично, данный тип командной структуры можно 16 представить 17 18 Рисунок 9 "Хирургическая" структура организации команды 7 следующим http://ecsocman.hse.ru/text/19186924/ 30 образом: 1 Каждый из представленных типов структуры организации команды 2 определяет особый набор характеристик команды, поэтому внедрение гибких 3 методологий, в каждом случае, должно происходить в соответствии с этими 4 характеристиками. 5 2.1.2 Мотивационный тип работников 6 Кроме изначального типа структуры организации работы в команде, на 7 процесс внедрения непосредственно влияет реакция команды на 8 происходящие изменения, поэтому, необходимо понимать, чего в данном 9 случае хочет этот ключевой стейкхолдер. Для этого представляется 10 разумным определить мотивационный профиль сотрудника. Таким образом 11 можно будет понять, какие мероприятия по вовлечению работников в 12 процесс внедрения будут наиболее и наименее эффективными. 13 Одним из наиболее известных методов определения мотивационного 14 профиля является тест «Motype» (Герчиков В.И., 2005б), основанный на 15 классификации Герчикова В.И.. Ученый выделил 5 типов мотивации 16 (Герчиков 17 достижительной мотивации: 18 19 20 В.И., 2005а). Согласно данной типологии есть 4 типа Инструментальная, при которой работа рассматривается как способ получить заработок и другие блага Профессиональная, при которой ценно содержание работы, 21 возможность проявить себя, самореализоваться через выполнение 22 сложных заданий 23 Патриотическая, при которой работник «хочет участвовать 24 в реализации важного для всей организации дела» и ценит признание 25 своих заслуг 26 Хозяйская, при которой работнику необходима свобода в 27 принятии решений, хотя всю ответственность за свою деятельность он 28 берет на себя. 31 1 Так же выделяется люмпенизированный тип, которому свойственно 2 бегство от ответственности, он стремится работать как можно меньше, готов 3 выполнять почти любую работу. Он зависим от менеджера и не хочет ничего 4 менять. Ниже представлена таблица, в которой указано, какие меры 5 воздействия допустимо применять для мотивации каждого типа: Таблица 2 6 Соответствие мотивационных типов и форм стимулирования 7 Мотивационный тип Формы стимулирования Инструментал. Профессионал. Патриотическ. Хозяйский Люмпен. Негативные Денежные Натуральные Нейтральна Базовая Применима Запрещена Применима Нейтральна Применима Нейтральна Применима Запрещена Применима Нейтральна Базовая Нейтральна Базовая Моральные Патернализм Запрещена Запрещена Применима Запрещена Базовая Применима Нетральна Запрещена Нейтральна Базовая Организационные Нейтральна Базовая Нейтральна Применима Запрещена Участие в управлении Нейтральна Нейтральна Применима Базовая Запрещена 8 Названия форм стимулирования говорят сами за себя, но не лишним будет 9 кратко объяснить некоторые из них: 10 11 Натуральные формы состоят в предоставлении материальных благ в, т.ч. служебное авто, квартира и проч. 12 Патернализм как стимул характеризуется в дополнительной заботе о 13 работнике в т.ч. дополнительное страхавание, создание условий для 14 отдыха и т.д. 15 16 Организационные т.е. стимуляция за счет организации работы и ее условий. 17 Уже упомянутый тест Motype позволит определить мотивационный профиль 18 каждого из членов команды и выбрать адекватные меры стимулирования 19 интереса сотрудников. С помощью подобной категоризации интересов 20 сотрудников станет возможен конструктивный диалог, ведь обе стороны 21 будут знать, чего хочет каждая. 32 Факторы, 1 2.2 2 проектами 3 препятствующие внедрению методологий управления В первой главе данной работы было определено, что внедрение 4 методологии 5 прибыльность компании, однако исследования Д. Веста (West D. et al., 2010) 6 показывают, что почти треть организаций, которые по идее должны 7 использовать какую-то методологию, не используют никакой. У некоторых 8 исследователей (в т.ч. М. Лаанти, О. Сало, П. Абрахамссона) возник 9 закономерный вопрос: почему некоторые компании не используют никаких 10 подходов к управлению. В своей работе на эту тему они обнаружили, что в 11 качестве основных причин можно выделить 3 фактора, каждый из которых, 12 так или иначе, относится к процессу внедрения методологии: 13 14 1. 17 проектами Менеджменту может кажется, что существенно внедрение повысить методов, используемых в методологии – слишком сложный процесс 15 16 управления 2. Ведение итеративного планирования рассматривается как 3. Способы обеспечения прозрачности хода всех операций так вызов 18 же вызывают некоторые затруднения у руководства. 19 Кроме того, изменение системы коммуникаций между командами так 20 же отталкивает менеджмент от внедрения методологий. В качестве основной 21 причины, которая могла бы вызывать трудности подобного рода можно 22 назвать недостаток опыта по использованию методологий. 23 также отметить, что результаты показали, что чем дольше испытуемые 24 пользовались гибкими методологиями до исследования, т.е. чем больше 25 опыт, тем охотнее они внедряли данный подход в свои команды. Любопытно, 26 Исследования Лаанти М. и Сало. О. определили, почему руководители 27 не стремятся широко использовать гибкие методологии управления, однако, 28 помня, что некоторые проекты развертывания проваливаются, интересно 29 было бы изучить, что мешает успешно внедрить подходящую структуру 30 системы в организацию. 33 1 В данном контексте особый интерес представляет собой исследование 2 Карпова Д.В., который обобщил проблемы, возникающие в ходе внедрения 3 гибкой методологии управления. Он выделил 6 основных причин, по 4 которым развертывание систем терпит фиаско: Непонимание роли руководства 5 1. 6 методологии: 7 2. Построение слишком ригидных систем 8 3. Неадекватный порядок внедрения 9 4. Меняется форма, но не содержание 10 5. Наблюдение вместо изменений 11 6. Игнорирование системы коучинга при внедрении 12 Рассмотрим каждую из причин чуть более подробно. Роль руководства, 13 при смене методологии управления, почти всегда кардинально меняется. 14 Если 15 руководителе, он 16 властью, поэтому зачастую не обременен необходимостью структурировать и 17 объяснять свои решения. При использовании гибких методологий, власть 18 распределяется между всеми членами команды в равной мере, поэтому из 19 трех основных видов власти (экспертной, харизматической, законной) в 20 лучшем случае остаются экспертная (которая приветствуется в Скрам) и 21 харизматическая (влияние которой обычно стремятся всеми силами 22 уменьшить). Это может привести к 2 противоположным результатам: 23 руководство будет стремится вернуть себе власть (сознательно или 24 бессознательно), или руководство будет избегать участия в обсуждениях, а 25 следовательно, утратит все типы власти и будет выполнять роль безмолвного 26 наблюдателя или секретаря. в традиционных системах бремя ответственности лежит на и принимает окончательное решение. Он обладает 27 Вторая проблема – построение недостаточно гибких систем, возникает, 28 как правило, из-за того, что инициаторы и исполнители процесса 29 развёртывания не понимают философии гибкого управления. Они исполняют 30 все предписания почти что буквально, не оптимизируя систему под свои 34 1 собственные нужды, из-за чего быстро разочаровываются в подходе и 2 «кладут его на полку» возвращаясь к старым практикам. Третья проблема – неправильный порядок внедрения. Как показала 3 4 статистика использования 5 происходит по причине того, что организация пытается улучшить тот или 6 иной компонент существующей системы. Опасность кроется в том, что 7 компании забывают, что система больше суммы всех ее частей и выборочное 8 использование 9 наибольшую выгоду при игнорировании остальных компонентов. В 10 результате внедренные новшества не только не помогают, но мешают 11 управлению проектами. Образно ситуацию можно представить следующим 12 образом: пешеход увидел, что на машине комфортнее передвигаться, потому 13 как можно сидеть, но решил, что целый автомобиль ему не нужен и купил 14 подешевле, но без колес. Транспортное средство не смогло сдвинуться с 15 места, и он решил, что его обманули. Соответственно, внедренные ими 16 элементы не приносят желаемых результатов, и методология перестает 17 использоваться. компонентов, гибких методологий, которые на каждое первый взгляд внедрение принесут 18 Если предыдущие 3 проблемы относились скорее к объекту 19 управления, то четвертая проблема связана скорее с субъектом – командой 20 проекта. Суть ее – формальное внедрение новых практик при фактическом 21 использовании старых подходов. Пожалуй, это одна из самых многогранных 22 проблем, которая может быть вызвана различными причинами. В список 23 входит: отсутствие мотивации к переходу (которое, опять же, может быть 24 вызвано 25 использования новых практик, непонимание выгод от их использования и 26 т.д. целым спектром сил), недостаточное понимание способов 27 Пятая проблема так же связана с ненадлежащим использованием 28 практик гибкой методологии. По сути своей принципиальное отличие гибких 29 методологий от классических это постоянное улучшение процессов. 30 Организации, внедряющие методологию не понимают этого и периодически 35 1 оказываются в трудном положении: не готовые к изменениям в рабочем 2 процессе, команды собирают информацию о трудностях но никак не 3 пытаются ее использовать, или только создают вид, что меняют ход работы. 4 Последним выделяемым препятствием на пути внедрения эффективно 5 работающего Скрама является игнорирование роли консультантов при 6 внедрении. Организация пытается обойтись своими силами, но отсутствие 7 сотрудника с экспертной властью приводит к конфликтам, неверной 8 интерпретации методик, а значит, к ухудшению качества получаемой 9 системы управления. 10 Понятно, что не существует единого решения, которое подходило бы 11 для всех организаций, однако некоторые авторы все же предлагают 12 возможные пути решения для некоторых проблем. Так некоторые 13 исследователи (Laanti M., Salo O, 2011; Moe N. B., Dingsøyr T., 2010) 14 предлагают разделять все проблемы на: связанные с новым процессом 15 разработки продукта, конфликты старой и новой системы управления, 16 конфликты в команде. 17 Для того, чтобы не возникло проблем с новым процессом, 18 рекомендуется: собрать всеобъемлющую информацию о деятельности 19 компании и бизнес процессах, начинать построение системы снизу-вверх, а 20 не сверху вниз. Кроме того, рекомендуется создать такую систему, которая 21 позволила бы командам эффективно общаться. Достаточно подробно этот 22 вопрос рассматривает Майкл Кон (Кон М., 2011), он приходит к выводу, что 23 достаточно эффективной методом построения системы взаимодействия 24 между командами, в данном случае является использование CDE модели, 25 которая позволяет решить проблему эффективной коммуникации и снизить 26 напряженность отношений между командами. Использование модели 27 CDE(Container/Differences/Exchanges) сопряжено с управлением команд через 28 изменение либо границ групп, либо через манипуляциями различий 29 возникающими между членами группы, либо через изменение техник и 30 практик, существующих внутри группы. 36 1 К мерам воздействия на контейнеры относят: 2 1) Увеличение или уменьшение размера команды; 3 2) Изменение полномочий команды; 4 3) Создание новой команды; 5 4) Изменение принадлежности к группе (например, смена 6 партнера при парном программировании или ротация сотрудников 7 между группами). 8 Управление различиями в коллективе предполагает понимание того, 9 что разногласия не являются абсолютным злом, но могут вести к развитию. 10 Основное внимание здесь отводится стимуляции продуктивных споров, 11 которые должны снизить количество замалчиваемых противоречий и вовлечь 12 всех членов команды в решение возникшей проблемы. 13 Управление обменом предполагает изменение существующей системы 14 коммуникации. Скрам-мастер должен следить за тем, чтобы сотрудники, 15 причастные к процессу создания обсуждаемой части продукта были 16 вовлечены в дискуссию. Кроме того, необходимо стимулировать процесс 17 обучения внутри команды. 18 Напряженность во взаимодействии старой системы с новой так же 19 снижается посредством применения 20 конкурентоспособности новой системы предлагается использовать расчет 21 ценообразования на основе переменных затрат. Кроме того, конечно, 22 рекомендуется провести ряд пилотных проектов для определения наиболее 23 подходящей вариации методологии. CDE модели. Для контроля 24 Необходимо понимать, что в реальной среде команда не всегда может 25 получится идеальной даже при использовании CDE модели, поэтому в 26 зависимости от характеристик получившейся группы выделяют: 27 28 1. Команды которые одновременно использовать гибкие методологии 29 2. Которые не могут, но хотят 30 3. Команды, которые не хотят, но могут 37 не могут и не хотят 4. Команды, которые хотят и могут 1 2 Первым рекомендуется предписывающий стиль лидерства. Внедрять гибкие 3 методологии в таких командах – фактически нереально. 4 Второму типу команд рекомендуется «продавать» решения т.е. использовать 5 продающий стиль. Предполагается, что это улучшит командную работу, и 6 воспитает команду, способную к применению гибких методологий. 7 Для команд третьего типа целесообразно использовать участвующий стиль, 8 чтобы 9 стратегических задач. помогать при долгосрочном планировании и реализации 10 Четвертый тип команды уже полностью готов для использования гибких 11 методологий. Им не нужно помогать с планированием или постановкой 12 целей, 13 использовать для достижения максимального эффекта. но допустимо советовать, какие инструменты необходимо 14 Для решения конфликтов в сфере человеческих отношений авторы 15 рекомендуют обучить все заинтересованные стороны и объяснить им 16 ценность проводимых изменений. При этом важно помнить, что необходимо 17 «говорить на одном языке» со стейкхолдером т.е. работнику нужно 18 объяснить почему он должен радоваться внедрению новой методологии, а 19 заказчику – какую выгоду получит он. 20 2.3 Существующие способы развертки гибких методологий 21 Учитывая, что многочисленные компании пытаются продать ту или 22 иную систему гибкого управления проектами, закономерно, что существует 23 немало систем развертки гибких методологий. Тем не менее, доступ к ним 24 затруднен для тех компаний, которые не хотят платить за услуги внешних 25 консультантов. В научной литературе, тем не менее, содержится несколько 26 инструментов, которые рекомендуется применять при пилотном внедрении. 27 Одной из первых работ на эту тему стало исследование Пиккарэйнен М 28 и Сало О. (Pikkarainen M., Salo O., 2006) в которой анализировался метод 29 пост-итерационных мастерских (PIW). Данная методика предполагает 38 1 последовательное внедрение 2 анализировать конце 3 анализировалась и модифицировалась под нужды организации. Схематично 4 процесс внедрения можно представить следующим образом: 5 6 Рисунок 10Процесс внедрения гибкой методологии 7 Основной в проблемой практик. итераций, при где Результаты предполагается использованная использовании данного практика инструмента 8 является то, что он объясняет, какие элементы гибкой методологии должны 9 быть внедрены в первую очередь, а какие в последнюю. Также этот 10 инструмент не уделяет никакого внимания обучению сотрудников и 11 управлению командой, что не позволяет говорить о нем как о достаточном 12 методе для внедрения гибких методологий. 13 Более детальные планы обычно разрабатываются для конкретных 14 организаций индивидуально, однако, шаблонный вариант для компаний в 20- 15 50 человек предложил Борис Вольфсон [Вольфсон Б.,стр 100-112] В качестве 16 основы для своего метода он использует классическую японскую систему 17 ShuHaRi. По его плану, компания должна последовательно пройти от четкого 39 1 следования методологиям до постепенной адаптации методов под нужды 2 своей организации для того, чтобы в результате перейти к осознанному 3 применению практик и разумному выбору наиболее подходящей системы 4 управления (например: переход от скрама+XP на скрамбан). Утверждается, 5 что подобные изменения возможны в течение 14 недель. 6 Кратко описывая сам процесс можно сказать, что в течение первой 7 недели необходимо собрать информацию о бизнес процессах в организации, 8 и познакомить сотрудников с принципами гибких методологий. Это позволит 9 снизить риск возникновения проблем, связанных со столкновением старой и 10 новой системы управления, за счет учета особенностей компании при 11 построении архитектуры системы. 12 В течение второй недели команда вырабатывает понимание 13 механизмов взаимодействия команды и создания продукта. На этом этапе 14 выявляются базовые проблемные ситуации, формируются новые команды, 15 формируется начальный образ конечного продукта и методов его получения. 16 Третья неделя представляет собой так называемый калибровочный 17 спринт, в ходе которого команда учится планировать спринт, проводить 18 скрам встречи и решать конфликты в команде. 19 На четвертой неделе команда отрабатывает завершение спринта, 20 проведение ретроспективы, а уже на пятой неделе происходит освоение 21 методов анализа реализации проекта на основе количественных показателей. 22 В течение шестой недели происходит обучение проведению ретроспективы с 23 учетом количественных показателей. На 7-8 недели приходится проведение 24 предрелизного спринта, в ходе которого внедряется автоматизированное 25 тестирование, а команды учатся правильно доделывать инкремент к релизу и 26 работать с ожиданиями заказчика. 27 Во время 9-10 недели проводится 4 спринт, на котором команда 28 осваивает контроль качества и диаграммы сгорания, а на 11-12 неделе 29 команда уже должна перейти к наивысшему уровню использования 30 методологии, где ей следует подобрать комбинацию подходящих техник. 13 40 1 и 14 неделя служат для апробации новой методологии и релиза продукта. Эти 2 2 недели должны стать эталоном для последующих спринтов в новых 3 проектах. 4 Данная модель, безусловно проливает свет на практику внедрения, но 5 нужно понимать, что она достаточно условна и не учитывает выбытия членов 6 команды проекта и многие другие возможные трудности. Из-за этого, 7 поставленным срокам нельзя верить. Тем не менее, последовательность 8 проведения мероприятий соответствует главенствующим методическим 9 рекомендациям, а следовательно, сама модель может быть использована как 10 ориентир для проведения изменений. 11 Выводы по главе 12 В данной части работы был рассмотрено несколько вопросов 13 касающихся специфики применения гибких методологий. Было показано, что 14 несмотря на их эффективность, многие руководители не решаются внедрять 15 и использовать их в своих организациях, командах по ряду рассмотренных 16 причин. Так же было показано, что причиной отказа от внедрения обычно 17 является страх неудачи и неумение проводить организационные изменения. 18 Были выделены основные трудности, с которыми сталкиваются организации 19 при попытке развертывания Скрама, представлены основные пути решения 20 данных трудностей и описаны некоторые достаточно популярные способы 21 внедрения гибких структур систем управления (фрейморков). Так же 22 показано, 23 эффективность стимулов при проведении изменений, а каждого сотрудника 24 следует мотивировать исходя из его особенностей. Кроме того, показано, что 25 различные системы командной работы так же оказывают существенное 26 влияние на установившиеся корпоративные традиции и задают «типичное» 27 поведение работника, что может влиять на толерантность оного к 28 изменениям и на его способность работать в команде, как того требует скрам. что мотивационный тип 41 сотрудника будет определять 1 Глава 3 Внедрение Скрама в организацию. 2 3.1 Основная информация о компании. 3 Компания, рассматриваемая в данном исследовании начала свое 4 существование в 2001 году с продажи и обслуживания ПК оптом и в розницу. 5 В 2005 году произошло разделение организации на 2 независимые фирмы: 6 одна стала заниматься 7 ушла в IT бизнес. С тех пор она занималась разработкой, внедрением с 8 сопровождением программного обеспечения для организаций г. Кирова и 9 области. В 2009 году фирме удалось заключить контракт с одним из 10 крупных промышленных предприятий области. С тех пор фирма стабильно 11 существует, обслуживая текущих клиентов. Приток клиентов за последние 12 годы был незначительным, и прибыль почти не росла. продажей компьютерного оборудования, а другая 13 Средняя численность сотрудников 50 человек, текучесть кадров почти 14 отсутствует. До недавнего времени организация использовала в качестве 15 основного метода разработки метод водопада. Как позже оказалось, различия 16 в подходах команды к процессу выполнения работы по модели водопада и, 17 согласно скраму, оказали важнейшее влияние на ход внедрения новой 18 структуры системы. Все сотрудники находятся в одном офисном здании, в 19 котором занимают 2 этажа. 20 3.2 Базовая информация о пилотном проекте 21 В конце 2014 года компания решила попробовать внедрить гибкие 22 методологии управления в ответ на усиливающуюся конкуренцию. Основной 23 целью внедрения было уменьшение времени, затрачиваемого на разработку 24 готового продукта и увеличить производительность. Внедряя методологию, 25 организация хотела обезопасить себя от потери клиентов, которые начали 26 высказывать недовольство по поводу длительности процесса разработки. 27 Компания осуществила пилотный проект по разработке ПО для одного 28 из своих постоянных клиентов, используя скрам методологию. Проект 29 предполагал разработку и внедрение 42 системы для автоматизации 1 производства в одном из филиалов клиента. Для проекта было выделено 4600 2 часов, 7 разработчиков, 1 скрам мастер, 1 владелец продукта. Владелец 3 продукта предоставлялся компанией заказчиком и являлся одним из 4 менеджеров этой компании. 5 Руководство было крайне недовольно результатами: при плановой 6 длительности в 4 месяца проект был закончен за 5,5. Качество финальной 7 версии продукта, при этом, устроило заказчика, однако он был недоволен из- 8 за серьезных временных задержек. 9 10 Тем не менее, компания решила не отступать на пути к внедрению скрам методологии. 11 Исследование совершенных в ходе первого пилотного проекта ошибок 12 и проблем, возникших по ходу его реализации, станет базовой частью моей 13 работы, опираясь на которую я предложу подходящую схему внедрения для 14 организации, которая должна будет помочь избежать наиболее вероятных 15 проблем внедрения. 16 3.3 Методы исследования 17 Для того, чтобы проследить процесс разработки системы наиболее 18 подходящим способом было использовать невключенное наблюдение за 19 работой команды на протяжении всего хода работы, однако, географическое 20 положение объекта не позволило сделать этого. Провести наблюдение за 21 работой команды удалось только в ходе последних 1,5 месяцев проекта. Тем 22 не менее, недостающие данные были взяты из записей хода ретроспектив (с 23 первого по восьмой) так же для получения недостающей информации были 24 проведены структурированные интервью (форма в приложении) с скрам 25 мастером, владельцем продукта и членами команды проекта. Данное 26 интервью позволило выделить субъективные ощущения участников проекта 27 во время пилотного проекта, оценить их отношение к процессу по ходу его 28 реализации. Не включенное наблюдение проводилось в период с конца марта 29 по середину мая 2015го т.е в период, когда проект уже отставал по срокам. 43 1 Предполагалось, что интервью позволит выявить, какие проблемы возникли 2 в ходе реализации проекта и определить, какие ошибки допустила команда. 3 Особое внимание было уделено отношениям внутри команды проекта. Для 4 этого за основу была взят список вопросов, представленный в исследовании 5 Моэ Н.Б и др. (Moe N. B., Dingsøyr T., Dybå T. A., 2010). Данный список 6 позволил охватить все вопросы, определяющие эффективна ли команда, и 7 дал возможность проверить, правильно ли работают управленческие 8 практики скрама. 9 Невключенное наблюдение, с другой стороны, позволило относительно 10 эффективно оценить качество управленческих практик и характер отношений 11 в коллективе. Это дало возможность свежим взглядом посмотреть на 12 развитие ситуации и определить слабые точки используемого подхода. 13 Интервью проводились в ходе перерывов сотрудников в период с 5 по 10 14 апреля. Повторное интервью со всеми участниками проекта состоялось 10 15 мая. Им объяснялось, что их ответы анонимны и не могут навредить им. 16 Пояснялось, что записи бесед не публикуются, а использоваться они будут в 17 обобщенном виде. Это позволило получить откровенные мнения команды 18 проекта о ходе его реализации. Предполагается, что без подобных гарантий 19 респонденты стремились бы слукавить при ответах, чтобы избежать 20 негативной реакции со стороны руководства. 21 3.4 Анализ спринтов 22 Как уже было упомянуто, исследование первых спринтов проводилось, 23 в основном, по проектной документации и скайп-интервью с членами 24 команды и скрам-мастером. 25 проводились уже в очном формате. Так же, начиная с третьего спринта 26 проводились невключенные наблюдения. Особый интерес, в данном случае, 27 так же представляли ретроспективы проекта, во время которых указывалось, 28 какие сложности возникли (а точнее какие сложности заметили участники 29 проекта) в ходе рассматриваемого спринта и как можно улучшить процесс. Начиная с третьего спринта интервью 44 1 Исследование записей 2 испытывала трудности с: с ретроспектив 3 Работой в команде по новым правилам 4 Завершением текущих заданий в срок 5 Управлением ожиданиями заказчика показало, что команда 6 Судя по записям, так же возникли проблемы с разделением труда, 7 определением задач для текущего спринта. Можно заключить, что особые 8 трудности возникали при коммуникациях внутри коллектива, из-за чего 9 нарушалась вся система его управления. 10 Рассмотрим, что происходило в каждом из спринтов более подробно. 11 Первый спринт. 12 Можно отметить, что изначально команда с оптимизмом смотрела на 13 перспективу быть первыми пользователями скрама в организации. В ходе 14 первой ретроспективы было отмечено, что, несмотря на все трудности, 15 работа налаживается, и, в скором времени будет возможно выйти на 16 плановые показатели производительности. Ретроспектива так же показала, 17 что команда испытывала сложности при градации важности компонентов 18 журнала спринта. Имели место задержки в исполнении работ (проблема была 19 отмечена, но причина ее возникновения была списана на неопытность в 20 использовании новой методологии). Члены команды неохотно шли на 21 контакт друг с другом и, формально присутствуя на ежедневных спринт- 22 встречах, принимали в них, по большей части, пассивное участие. Так же 23 можно отметить, что в конце первого спринта, который к тому моменту 24 длился 2 недели, оказалось, что команда не успевает выполнить план, 25 поэтому они решили увеличить длину спринта до 4-х недель, при этом 26 сократив количество выпусков с 8 до 4-х таким образом планировалось 27 сэкономить время на взаимодействии с владельцем продукта и догнать план. 28 45 1 Второй спринт 2 Как уже было сказано, в течение первого спринта в команде шли на 3 компромиссы друг с другом и слушали скрам-мастера при назначении работ, 4 но уже начиная со второго, команда разобщилась настолько, что некоторые 5 спринт встречи заканчивались конфликтами. При этом, если до третей 6 недели споры как то решались, то после – члены команды перестали слушать 7 друг друга, что несколько раз приводило к тому: 8 разные работники выполняли одну и ту же работу 9 члены команды отказывались выполнять те работы, 10 которые были определены в ходе утренней спринт встречи и работали 11 по расписанию, которое не было с кем-либо согласовано. В результате 12 возникали конфликты, члены команды не шли на контакт друг с 13 другом, некоторые работы не были выполнены в ходе спринта, а 14 некоторые выполнены дважды. 15 В качестве примера, показывающего неэффективность коммуникаций, 16 можно привести следующую ситуацию: один из членов команды, 17 занимавшийся разработкой автоматического регулятора, ушел в отпуск, 18 передав свою часть работы другим работникам. При этом ретроспектива 19 показала, что никто из оставшихся сотрудников не понимал как именно он 20 проектировал регулятор. По этой причине, разработку пришлось начать 21 заново. Из-за необходимости повторять уже по сути проделанную работу, 22 команда не успела в срок закончить все элементы журнала спринта. 23 Таким образом, можно заключить, что к концу второго спринта 24 существовали проблемы одновременно и с откликом (фидбэком) от команды 25 к каждому ее члену, так и с отслеживанием выполнения задач. 26 Первая группа проблем проявилась в неспособности команды задать 27 вопросы по непонятным им элементам разрабатываемого элемента (в данном 28 случае, системы по установке автоматического регулятора расхода), а вторая 29 – в слабом интересе к деятельности других членов команды. Из-за этого 46 1 команда слабо представляла себе чем занимается каждый из ее участников, а 2 значит, не могла адекватно контролировать процесс разработки, причем 3 бесконтрольным оставался не только процесс, но и качество его исполнения. 4 Как говорилось ранее, команда не единожды заявляла, что с 5 оптимизмом смотрит на перспективу быть первыми пользователями скрама в 6 организации, при этом, даже возникшие трудности не пошатнули их желания 7 использовать методологию. Поэтому, они решили добавить канбан доску 8 текущему процессу управления, чтобы каждый участник проекта мог бы без 9 труда освежить свое представление о том, чем сейчас занимается команда и, 10 соответственно, на каком этапе находится решение той или иной задачи. Так 11 же, из-за отставания проекта и явных проблем с коммуникацией в команде, 12 было принято решение провести неофициальную мотивирующую встречу 13 для всех членов коллектива, в ходе которой руководство объяснило ценность 14 работы команды для организации. 15 Третий спринт 16 Неофициальная встреча с руководством компании подняла уровень 17 мотивации команды к работе, и, судя по интервью с сотрудниками и записям 18 с ретроспективы, существенно снизила проблему командной работы. Записи 19 показали большую сплоченность, конфликты в ходе данной фазы почти не 20 возникали. Тем не менее, из-за неспособности скрам-мастера эффективно 21 управлять командой его авторитет упал. Из-за этого сильно осложнились их 22 рабочие отношения. В ходе проведенного в тот момент интервью удалось 23 выяснить, что скрам-мастер чувствовал неуважение сотрудников, они 24 перебивали его, часто спорили. Это вылилось в отсутствие у формального 25 лидера команды (т.е. скрам-мастера) реальной власти над командой. Его 26 советы и предложения часто игнорировались, поэтому к середине 3 спринта 27 он перестал пытаться оказывать влияние на ход спринт встреч. Без 28 «модератора» команда начала испытывать трудности при определении 29 способа для реализации того или иного компонента журнала спринта. 47 1 Кроме того, дистанцирование от команды вынудило скрам-мастера 2 проводить встречи с владельцем продукта без разработчиков. Это, в свою 3 очередь, привело к своеобразному «сломанному телефону»: владелец 4 продукта передавал информацию только через скрам-мастера, а тот общался 5 с командой. Данный подход замедлил выполнение работ по спринту, а так же 6 привел к тому, что разработчики не успевали вовремя реагировать на 7 меняющиеся требования заказчика. Сотрудники стали отмечать, что скрам- 8 мастер только мешает выполнению работ. 9 При проведении ретроспективы было отмечено, что канбан-доска 10 существенно облегчила специалистам задачу по отслеживанию хода 11 выполнения работ, но владелец продукта отметил, что работы выполняются 12 слишком медленно. Команда пожаловалась на отсутствие четкого видения 13 того, чего заказчик ждет в итоге, что может говорить о неудачной системе 14 коммуникации. Разработчики отметили, что командное взаимодействие 15 существенно улучшилось по сравнению с предыдущими спринтами. Тем не 16 менее, они подчеркнули, что испытывают трудности при коллективном 17 обсуждении проблем (из-за нежелания работать с неприятными им членам 18 коллектива или из-за неуверенности, что их мнение может внести какой-то 19 полезный вклад). 20 21 Изменение системы коммуникации с владельцем продукта затронуто не было. 22 Четвертый спринт 23 Из-за того, что третья ретроспектива была недостаточно конструктивна 24 (не было выработано никаких способов улучшения процесса управления), 25 четвертый спринт прошел, в сущности так же, как и третий. Разница состояла 26 лишь в том, что скрам-мастер почти полностью исключил себя из 27 ежедневных спринт-встреч. Из-за этого команда так и не смогла 28 определиться с тем, как должен выглядеть «готовый» инкремент проекта. 29 Обсуждения действительно стали эффективней, однако не был понятен 48 1 финальный образ продукта, соответственно, в конце четвертого спринта 2 владелец продукта заявил, что необходимо добавить несколько критически 3 важных элементов, а некоторые ему уже не нужны. 4 5 Из-за этого проект пришлось продлить на дополнительный месяц, в ходе которого планировалось устранить все претензии заказчика. 6 Команда и скрам-мастер были поставлены перед фактом, что работа 7 должна быть закончена в кратчайшие сроки и что результат этого проекта 8 окажет существенное влияние на их будущее в организации. 9 Для исправления ситуации было принято решение вернуть прежний 10 формат встреч с владельцем продукта. 11 Пятый-шестой «спринт» 12 Задержка в исполнении работ и необходимость доделать все в 13 кратчайшие сроки сплотила команду, которая тем не менее, старалась 14 действовать в обход скрам-мастера. Буквально на 2 неделе пятого спринта 15 оказалось, что сделать это не так просто, потому как без формального лидера 16 принимать решение о способе разработки элемента системы крайне тяжело. 17 Каждый настаивал на том, что его способ – наиболее эффективный. Из-за 18 подобных споров скрам-встречи затягивались, а решения так и не были 19 выработаны. На 3 неделе руководство организации приняло решение 20 приостановить использование скрама и доделать оставшиеся элементы 21 традиционным для компании способом – вернуться к изоморфной команде и, 22 соответственно, жесткой структуре подчиненности. Скрам-мастер вновь стал 23 проектным менеджером и распределял обязанности внутри коллектива. Тем 24 не менее, работа над ошибками заняла почти месяц и проект был сдан 25 заказчику через 5,5 месяцев после его начала. 26 Интересно отметить так же, что по ходу процесса развертки 27 методологии происходило постепенное нарастание конфликтов в коллективе. 28 Как показали результаты интервью, удовлетворенность команды от 29 использования новых практик оставалась практически неизменной в ходе 49 1 всего проекта. Она сильно снизилась в течение 3 спринта, когда 2 напряженность между командой и скрам мастером достигла апогея, но 3 быстро вернулась к прежнему уровню. Тем не менее, после 4 спринта 4 внедрение было признанно неудавшимся и руководство решило доделать 5 проект вернувшись к старым методам. Было принято решение реализовать 6 второй пилотный проект, но для этого необходимо было проанализировать 7 возникшие проблемы и понять, как с ними можно было бороться/не 8 допустить их реализации. 9 10 Итак, если обобщить изученную ситуацию, то можно выделить следующие ошибки, совершенные при внедрении: 11 неадекватный стиль лидерства, 12 плохо организованные дискуссии, 13 отсутствие контроля за деятельностью каждого из членов 14 15 16 17 команды, плохо налаженная система обратной связи между членами команды, отсутствие правильной системы мотивации (иначе бы 18 сотрудники были бы активно вовлечены в процесс принятия 19 решений), 20 21 ошибки долгосрочного планирования (отпуск одного из сотрудников совпал с процессом внедрения). 22 В следующей части работы будет предложен ряд мер, чтобы 23 предотвратить повторное возникновение данных проблем и, соответственно, 24 скорректировать процесс внедрения гибкой методологии. 25 3.5 Модель внедрения гибкой методологии в будущие проекты компании 26 Внедрение методологии это комплексный процесс, который 27 провоцирует не реализованные ранее риски. Он вскрывает нерешенные 28 противоречия, и поэтому может быть опасен для стабильного существования 29 организации. Возврат к изначальной системе управления может стать 50 1 попыткой войти дважды в одну реку, поэтому критически важно проделать 2 подготовительную 3 безболезненное, а главное, успешное внедрение выбранной методологии. 4 Исследования дают определенную теоретическую базу, которая позволяет 5 выделить наиболее распространенные риски, однако развертке системы 6 контрмер уделяется меньше времени и сил, чем этого можно было бы 7 ожидать. Это приводит к тому, что методология развертывается в усеченном 8 виде или не развертывается вовсе, становясь просто неудачным опытом 9 организации. Для того, чтобы повысить вероятность успешного внедрения 10 скрама в компании, необходимо провести комплекс мероприятий, которые 11 будут описаны ниже. 12 3.5.1 Подготовительная работа. Сбор информации о компании работу, которая бы обеспечила относительно 13 Для грамотного внедрения любого инструмента или методологии, 14 необходимо разбираться в том, в каких условиях происходит это внедрение. 15 В данном случае, это значит, что необходимо собрать всю релевантную 16 информацию о компании, проводящей развертку, в целом, и о команде, где 17 эта развертка будет происходить, в частности. 18 Информация о компании, в данном контексте, позволит понять, нужна 19 ли процедура внедрения гибкой методологии в данном конкретном случае. 20 Для этого можно воспользоваться методом, предложенным Гэри Чином. Он 21 предлагает задуматься над внедрением тем компаниям, которые: 22 А. Проектно ориентированные 23 Б. Работают в среде с высоким уровнем внешней и 24 внутренней неопределенности 25 В. Вынуждены быстро поставлять продукцию 26 Г. Поставлены перед необходимостью часто изменять 27 содержание продукта проекта. 28 Из исследований Мари Лотс так же становится ясно, что гибкие 29 методологии подходят проектам, в которых заказчик может на постоянной 51 1 основе взаимодействовать с поставщиками продукта, а количество внешних 2 связей у проекта относительно немного. 3 Исследуемый в рамках данной работы проект подходит под 4 большинство характеристик. С одной стороны существовала внутренняя 5 неопределенность (неточные сроки разработки подходящей системы, 6 отсутствие ясного понимания о необходимых трудовых затратах), а с другой 7 – внешняя (заказчик мог поменять требования к продукту на протяжении 8 всей разработки). Кроме того, заказчик был достаточно заинтересован в 9 результатах проекта для того, мониторинга чтобы ситуации. выделить Исходя сотрудника из для 10 периодического вышесказанного, 11 становится понятно, что предприятию было бы действительно целесообразно 12 использовать гибкие методологии для реализации проекта. 13 Следующим шагом должно стать исследование/подбор команды 14 проекта. Эта процедура принципиально важна, потому что именно на базе 15 этой информации будет разрабатываться система внедрения. Так как скрам, 16 как и любая гибкая методология, основывается на команду, как на ключевой 17 фактор успеха проекта, первоочередное внимание следует уделить ей. Для 18 того, чтобы понять, что представляют из себя члены коллектива, 19 предлагается использовать тест Motype. Этот тест, состоящий из 18 вопросов, 20 определит 21 позволит понять, кто из них лучше всего подходит для апробации новых 22 практик и какие инструменты стимулирования можно и нужно применить, 23 чтобы создать атмосферу, при которой работники не будут мешать 24 изменениям. После определения мотивационного типа членов компании, 25 конструктивным кажется использование CDE модели для создания команды, 26 наиболее подходящей для внедрения стратегии. Это должны быть работники, 27 у которых преобладает патриотический тип мотивации, так же, в целом, 28 подходит профессиональный тип, следует при возможности, избегать 29 включения сотрудника с высоким уровнем избегательной мотивации. мотивационный профиль 52 сотрудников, что одновременно 1 Следует так же оценить уровень «зрелости» сформированной команды. 2 Только таким образом скрам-мастер будет понимать, какого стиля лидерства 3 ему необходимо придерживаться. 4 После того, как будут отобраны наиболее подходящие для проекта не 5 только в профессиональном, но и мотивационном плане сотрудники, можно 6 начинать планировать мероприятия, по поддержанию заинтересованности 7 сотрудников в проводимых изменениях. Зная тип организации работы в 8 команде и мотивационный тип работников, можно с определенной долей 9 уверенности прогнозировать, какие этапы внедрения должны пройти 10 безболезненно, а на каких команду нужно дополнительно контролировать и 11 побуждать к продуктивной работе. 12 В этой связи важно обратить внимание на то, как прежде была 13 устроена работа в команде, так, при изоморфном типе командной работы, 14 члены коллектива не привыкли взаимодействовать друг с другом, менеджер 15 проекта привык брать на себя ответственность и руководить с помощью 16 скорее формальной власти, нежели экспертной. То же справедливо и для 17 хирургического 18 отношениях внутри коллектива там куда менее вероятна. Для «экспертной» 19 команды, которой свойственно пренебрежение к авторитету а так же высокая 20 самостоятельность, в данном случае дополнительно стоит усилить уважение 21 к роли скрам-мастера, как эксперта в своей области. Тогда рассматриваемые 22 сотрудники смогут адекватно взглянуть на суть проводимых изменений, не 23 будут тормозить процесс. Обратная процедура должна иметь место в 24 организациях с изоморфной и хирургической структурой: в них авторитет 25 менеджера слишком высок, поэтому большинство работников не принимают 26 участия в обсуждении, для гибких методологий и скрама, в частности, такая 27 ситуация неприемлема и приведет к ухудшению качества готового 28 инкремента. типа устройства команд, 53 однако напряженность в 1 3.5.2 Вопрос организации команды в организации 2 Для рассматриваемой организации был характерен изоморфный 3 процесс организации работы, следовательно, перед началом первого спринта 4 команда должна осознать, что скрам-мастер не обладает полномочиями для 5 навязывания каких-либо решений, все они должны приниматься в 6 консенсусе. Образовавшийся вакуум власти (менеджер проекта ушел, а на 7 его место никто не пришел) будет стремиться заполнить неформальный 8 лидер команды. Еще на этапе «шторминга» он будет бороться за власть с 9 другими претендентами на лидерство. Этот процесс абсолютно нормален, 10 однако он может ухудшить качество принимаемых решений (смена шила на 11 мыло), т.е. власть просто перейдет от формального к неформальному лидеру, 12 без изменения сути процесса принятия решений. Для того, чтобы это 13 произошло, нужно искусственно ограничить власть лидера. Наиболее 14 распространенным инструментом, используемым во многих организациях 15 для этой цели, является покер-планирование. С помощью него «удельный 16 вес» решения неформального лидера будет снижен, и обсуждение будет 17 напоминать демократическое. 18 Кроме того, учитывая склонность менеджера проекта, который стал 19 скрам-мастером, навязывать свое мнение подчиненным (т.е. использовать 20 предписывающий стиль лидерства), имеет смысл использовать либо 21 менеджера более «ориентированного на человека» (по Р. Лайкерту) либо 22 использовать наемного скрам-мастера, который имел бы опыт координации 23 командой, а не управления оной. 24 В данном кейсе команда хотела, но не могла использовать гибкие 25 методологии, следовательно, в идеале, скрам мастер должен был применять 26 «продающий» стиль лидерства, а не предписывающий. 27 Так же следует заранее определить инструменты, с помощью которых 28 будет осуществляться процесс контроля за выполнением работ. Кроме 29 стандартной диаграммы сгорания имеет смысл внедрить канбан доску, 30 причем делать это желательно до возникновения проблем с отслеживанием 54 1 деятельности, а не после, как это случилось в рассматриваемом кейсе. Как 2 показало изучение кейса, данный инструмент облегчает задачу отслеживания 3 выполняемых работ. Это позволит улучшить систему коммуникации, которая 4 явно страдает от недостатка внимания и 5 сотрудниками (в первую очередь в плане работ, выполняемых их коллегами). 6 Обобщая, можно выделить следующий фронт работ, которые 7 необходимо дополнительно провести в компании для успешного внедрения 8 проекта: 9 10 11 1) Подготовительная работа. взаимопонимания Выяснить тип между командной работы. Выяснить мотивационные профили сотрудников 2) Собрать команду с помощью модели CDE. Для пилотных 12 проектов использовать сотрудников с доминирующим 13 профессиональным или патриотическим типом. Не использовать 14 работников с высокой долей избегательной мотивации. 15 3) Оценить уровень зрелости получившейся команды и 16 подобрать подходящий вид лидерства. Для команды, идентичной 17 той, которая принимала участие в пилотном проекте – продающий 18 вид лидерства. 19 4) Выяснить, как прошлая орг. культура будет мешать 20 внедрению новой системы. Для команды это – какой компонент 21 командной работы нужно изменить (в зависимости от типа 22 организации командной работы), чтобы использование гибких 23 методологий проходило адекватно. В данном случае это слабая 24 вовлеченность в коллективные обсуждения всех членов команды. 25 26 27 5) Провести тренинг с упором на тот элемент командной работы, который необходимо укрепить. 6) Определить снизить инструменты, влияние которые 28 дополнительно 29 факторов. В данном случае рекомендуется использовать покер 55 препятствующих позволят внедрению 1 планирование и канбан доску чтобы снизить напряженность при 2 принятии решений и упростить процедуру отслеживания задач. 7) Объяснить 3 команде исходя выгоды из их от внедрения мотивационного гибких 4 методологий профиля. 5 Профессионалу – большая эффективность процессов, большая 6 ценность готового продукта, патриоту – важность внедрения для 7 организации. 8 8) Оценить возможность привлечения сотрудников с опытом 9 работы со скрамом (наемный скрам-мастер или работник с первого 10 пилотного проекта). 11 9) Начать процесс развертки. 12 10) Ограничивать количество компонентов журнала 13 спринта на основании экспертной оценки и анализа предыдущего 14 опыта. 15 11) Вовлечение каждого сотрудника в скрам-встречи. 16 Поощрять участие в обсуждении. В данном случае может быть 17 достаточно публичной устной похвалы, если речь пойдет о 18 сотрудниках – патриотах. 19 20 21 22 23 12) Ограничить время спринта и не пытаться увеличить 13) После каждого спринта оценивать использованные его. инструменты с помощью пост-итерационных мастерских. 14) Не допускать возникновения концентрации власти в 24 руках у какого-либо участника проекта. Использовать для этого 25 покер планирование или модель CDE. 26 15) Обеспечить владельцу продукта доступ к команде. 27 Встречи с ним принципиально не должны проводиться без 28 разработчиков. 56 1 Вывод по главе 2 В этой части работы было проведено исследование пилотного проекта 3 по внедрению гибких методологий управления. Было показано, что 4 возникающие проблемы, по большей части, связаны с управлением командой 5 проекта. Выявлено, что при развертывании методологии значительно 6 влияние существовавшей до этого корпоративной культуры (в частности, 7 типа организации командной работы) и мотивационного типа работников. 8 Показано, что исследуемая организация столкнулась с проблемами, которые 9 можно было бы избежать, если бы была проведена подготовка к процессу 10 внедрения, а процесс развертывания был бы последовательным. Вместо 11 этого, компания сразу же решила реализовывать проект, за что и поплатилась 12 отставанием от графика и неудовлетворенным заказчиком. 13 В этой главе так же предложен ряд мер, проведение которых должно 14 скорректировать процесс внедрения в будущих проектах организации и 15 сделать его более эффективным. 16 17 57 1 2 Заключение 3 В ходе данного исследования были выделены и проанализированы основные 4 критерии определяющие целесообразность внедрения гибкой методологии 5 управления 6 инструменты и практики, используемые в рамках гибких методологий, 7 особое внимание, при этом было уделено скарму как наиболее популярной 8 структуре системы управления проектами. Были исследованы основные 9 проблемы, мешающие успеху внедрения, акцент, при этом был сделан на 10 создании эффективной команды. Особое внимание, при этом, было уделено 11 мотивационным типам сотрудников и начальной структуре командной 12 работы как факторам, значительно влияющим на процедуру развертки 13 гибких методологий. После этого был проведен разбор методов, некоторых 14 методов, позволяющих разрешить возникающие трудности. Далее был 15 проведен анализ пилотного проекта по внедрению скрама. С помощью 16 нескольких структурированных интервью с командой проекта, скрам- 17 мастером, 18 серьезные проблемы при внедрении рассматриваемой структуры системы 19 управления (т.е. скрама). После выявления основных проблем, был 20 предложен план по корректировке процедуры развертки методологии с 21 учетом предшествующего опыта. 22 Исследование, проведенное в данной работе, показало, что, успех внедрения 23 скрама, как командно-ориентированной структуры системы управления 24 (фреймворка) во многом зависит от качества управления командой. Было 25 определено, что значительными факторами определяющими особенности 26 внедрения скрама в организацию являются изначальный тип командной 27 работы и мотивационный тип сотрудников. Для каждого типа характерны 28 свои собственные особенности внедрения, связанные с устоявшимися 29 корпоративными нормами. Так было показано, что изоморфная командная 58 проектами. Также были проанализированы и основные анализа документации проекта были обнаружены наиболее 1 структура характеризуется слабым вовлечением сотрудников в групповое 2 обсуждение и принятие решений, а менеджер проекта или, в данном случае, 3 скрам мастер, пытается не координировать деятельность команды, а 4 управлять ей. 5 В качестве возможного продолжения исследования хотелось бы предложить 6 исследование влияния хирургического, командного, экспертного типа 7 организации работы в команде на внедрение гибких методологий. Так же 8 перспективным 9 осуществления внедрения гибкой методологии исходя из мотивационных 10 кажется создание модели типов. 11 59 идеальной команды для 1 2 3 4 5 6 7 8 9 10 11 12 13 14 Список использованной литературы 1. Арчибальд Р. Д. Управление высокотехнологичными программами и проектами. – М. : Компания АйТи, 2010. 2. Вольфсон Б. Гибкие методологии разработки. Электронная версия 1.2, 2012. 3. Веснин В.Р. Теория организации в схемах: учебное пособие. – М.: Проспект, 2011. – 128 с. 4. Кон М. Scrum: гибкая разработка ПО //М.:«Вильямс. – 2011. – С. 576. 5. Ядов В.А. Стратегия социологического исследования В. А. Ядов. — 3-е изд., испр. — Москва: Омега-Л, 2007. — 567 с. 6. Fowler M., Highsmith J. The agile manifesto //Software Development. – 2001. – Т. 9. – №. 8. – С. 28-35. 7. Chin G. Agile project management: how to succeed in the face of 15 changing project requirements. – AMACOM Div American Mgmt Assn, 16 2004. -229 c. 17 18 19 8. Martin R. C. Agile software development: principles, patterns, and practices. – Prentice Hall PTR, 2003. 9. Герчиков В. И. Типологическая концепция трудовой мотивации 20 (часть 1) //Мотивация и оплата труда. – 2005. – Т. 2. Режим доступа: 21 [http://grebennikon.ru/article-wvgs.html] 22 10.Герчиков В. И. Типологическая концепция трудовой мотивации 23 (часть 2) //Мотивация и оплата труда. – 2005. – Т. 3. – С. 2-6. 24 11.Гульбина Н. И. Теория институциональных изменений Д. Норта 25 //Вестник Томского государственного университета. – 2004. – №. 26 283. 27 12.Карпов Д. В. Гибкая методология разработки программного 28 обеспечения //Вестник Нижегородского университета им. Н.И. 29 Лобачевского. – 2011. – №. 3-2. 60 1 13.Черных Е. А. Agile Project Management—новый подход к 2 управлению инновационными проектами //Менеджмент качества. – 3 2008. – Т. 2. – С. 84-94. 4 14.Boehm B., Turner R. Management challenges to implementing agile 5 processes in traditional development organizations //Software, ieee. – 6 2005. – Т. 22. – №. 5. – С. 30-39. 7 15.Chow T., Cao D. B. A survey study of critical success factors in agile 8 software projects //Journal of Systems and Software. – 2008. – Т. 81. – 9 №. 6. – С. 961-971. 10 16.Laanti M., Salo O., Abrahamsson P. Agile methods rapidly replacing 11 traditional methods at Nokia: A survey of opinions on agile 12 transformation //Information and Software Technology. – 2011. – Т. 53. 13 – №. 3. – С. 276-290. 14 17.Koch, A.S., 2005. Agile Software Development: Evaluating the Methods 15 for Your Organizations. Artech House, Northwood, Massachusetts, 2005, 16 PP. 9-13, 89-97. 17 18.Leau Y. B. et al. Software development life cycle AGILE vs traditional 18 approaches //International Conference on Information and Network 19 Technology. – 2012. – Т. 37. – №. 1. – С. 162-167. 20 19.Moe N. B., Dingsøyr T., Dybå T. A teamwork model for understanding 21 an agile team: A case study of a Scrum project //Information and 22 Software Technology. – 2010. – Т. 52. – №. 5. – С. 480-491. 23 20.Musztyfaga M., Skołud B. Human resources management in a project 24 type tasks //Journal of Achievements in Materials and Manufacturing 25 Engineering. – 2007. – Т. 25. – №. 2. – С. 95-98. 26 21.Pikkarainen M., Salo O., Still J. Deploying agile practices in 27 organizations: a case study //Software Process Improvement. – Springer 28 Berlin Heidelberg, 2005. – С. 16-27. 29 22.Pikkarainen M., Salo O., A Practical Approach for Deploying Agile 30 Methods Extreme Programming and Agile Processes in Software 61 1 Engineering Lecture Notes in Computer Science Volume 4044, 2006, pp 2 213-214 3 23.Pollack J., Adler D. The relationship between project management and 4 small to medium enterprise profitability //Global Conference on Business 5 & Finance Proceedings. – Institute for Business & Finance Research, 6 2015. – Т. 10. – №. 1. – С. 344. 7 24.Turner R., Ledwith A., Kelly J. Project management in small to medium- 8 sized enterprises: Tailoring the practices to the size of company 9 //Management Decision. – 2012. – Т. 50. – №. 5. – С. 942-957 10 11 12 25.Arell R. et al. Characteristics of agile organizations //Agile Alliance. – 2012. 26.Lotz M., Waterfall vs. Agile: Which is the Right Development 13 Methodology for Your Project? Режим доступа: 14 [http://www.seguetech.com/blog/2013/07/05/waterfall-vs-agile-right- 15 development-methodology] 16 17 27.West D. et al. Agile development: Mainstream adoption has changed agility //Forrester Research. – 2010. – Т. 2. – С. 41. 18 28.9TH ANNUAL State of Agile™ Survey 19 29. http://agilemanifesto.org 20 30. www.versionone.com 21 31. http://www.delfy.biz/methods/tmg 22 32. http://ecsocman.hse.ru/text/19186924/ 23 33.https://gupea.ub.gu.se/bitstream/2077/30050/1/gupea_2077_30050_1.pdf 62 1 Приложение 1 2 Уважаемые сотрудники! 3 В нашей организации проходит исследование, посвященное проблемам, 4 возникающим в ходе внедрения гибкой методологии управления проектами. 5 Целью исследования будет служить создание такой системы, которая была 6 бы комфортна для вас и эффективна для вашего работодателя. Ваши 7 ответы будут учтены при принятии решения о развертывании системы на 8 другие проекты организации. 9 Данное интервью является анонимным. Никто не получит доступа к 10 исходной информации. 11 1. Как организована работа в ходе данного проекта? 12 2. Как она была организована ранее? 13 3. Как решаются возникающие проблемы? 14 4. Как они решались ранее? 15 5. Вы имеете общее представление о том, чем занимаются другие 16 сотрудники? 17 6. Как ранее вы узнавали о деятельности других членов команды? 18 7. Насколько просто для вас заниматься задачей, которую начал кто-то 19 другой? 20 8. Как эта проблема решалась в прошлых проектах? 21 9. Как вы узнаете о изменениях в проекте? 22 10.Как вы узнавали в изменениях в предыдущих проектах? 23 11.Как вы внедряете изменения в проекте? 24 12.Как эта проблема решалась ранее? 25 13.У команды, в которой вы работаете, есть общая цель? 26 14.Была ли общая цель у команды в других проектах? 27 15.Все ли понимают, каково ожидаемое окончание проекта? 28 16.Все ли понимали, каково ожидаемое окончание проекта в предыдущих 29 30 проектах? 17.Делятся ли члены команды своими мнениями о проекте? 63 1 18.А в предыдущих проектах? 2 19.Делятся ли члены команды важной информацией о ходе проекта друг 3 с другом? 4 20.А в предыдущих проектах? 5 21.Как бы вы оценили коммуникации в команде? 6 22.А в предыдущих проектах? 7 23.Эффективна ли команда? 8 24.А в предыдущих проектах? 9 25.Вам кажется, что скрам хорошо подходит для данного проекта? 10 26.Какие элементы работают? 11 27.Какие элементы не работают? 12 28.Есть ли что-то, что вы бы хотели добавить в рамках данной беседы? 13 64
