Автор:
Алия Мустафина
Управление проектами в IT: 5 кейсов, которые вас вдохновят
С развитием технологий и формированием новых отраслей привычные подходы классического проектного управления теряют свою актуальность. Все более востребованы гибкие методики Agile, позволяющие в режиме реального времени оперативно формировать требования, внедрять новшества и изменять собственные бизнес-процессы. Это возможно благодаря эффективному взаимодействию самоорганизующихся команд, в состав которых входят специалисты разного профиля. Эксперты GPI group безоговорочно поддерживают гибкие подходы управления проектами Agile с поэтапным запуском стратегических инициатив и использованием приоритизации задач. В нашем обзоре мы представили 5 знаменитых историй успеха, которые наглядно демонстрируют силу «гибкой разработки» сегодня.
Управление проектами в IT: три жизненных цикла
Непросто управлять людьми. Втройне сложнее управлять большой группой людей, да еще и эффективно. Пожалуй, это и толкает управленцев на новые поиски идей в достижении поставленных задач. Пробуя и ошибаясь, бизнес ищет свои методики, формулы, практики – смешивая их и оптимизируя, учитывая провалы и возможные риски, теряя время, а порой и деньги.
Любая компания, отдавая предпочтение планированию, а не привычной работе по накатанной, подбирает свою методологию, которая будет полезна именно ей. Конечно, гораздо легче делать, как привыкли – по инструкции, в порядке очереди, как написано в книжке. Куда сложнее искать и нарабатывать собственные инструменты для реализации выбранных приоритетов.
Проектный менеджмент (РМ) в данном случае становится популярным и все более востребованным в самых разных отраслях. Ведь он и есть методология управления компанией, подразумевающая разделение имеющегося объема работы на части (проекты).
Многие компании только сейчас начинают понимать, что классическая, зачастую бюрократическая схема менеджмента по принципу «надо вот так и никак иначе», где есть строгий начальник и подчиненный, изживает себя. Данный шаблон бесполезен в условиях мирового рынка. Наступило время проектного управления с отдельными задачами и делегированием полномочий.
Во многом его развитию способствовал информационный бум интернета 2010-х годов. Тогда на нашу голову в свободном доступе «свалились» тонны ранее не доступной информации от зарубежного бизнеса из разряда «что такое менеджмент», «как разделять полномочия, уменьшать риски» и т.д.
Сегодня мы можем видеть в последних обновлениях, как корпорации с мировым именем и многомиллионной прибылью непрерывно сливаются или делятся на подразделения. Это – яркий пример РМ, когда в зависимости от критериев поставленных задач происходят «сдвиги», однако внутри компании продолжается прежняя работа по достижению стратегических задач.
IT project management (управление проектами IT) в данном случае собирает в одно целое выявленные методы, принципы и политику ведения бизнеса. Благодаря ему сопровождение проектов становится более прозрачным, начиная от создания концепции и до полного завершения.
Если говорить коротко о том, как управлять проектами в IT, то, в первую очередь, необходимо определить функции, нарисовать схемы, таблицы всей компании и отдельно взятого проекта. Исходя из полученных приоритетов, выбираете максимально подходящую методологию. Далее дело остается за специальным сервисом по управлению проектами, где вся представленная информация будет компоноваться, контролироваться и улучшаться.
В целом, управлению проектами в IT свойственно 3 цикла:
- Прогнозируемый – самый традиционный из всех имеющихся, предполагает поэтапное линейное движение.
- Итерационный – самый инновационный, подразумевающий увеличение функционала ПО при необходимости с каждым новым шагом – неизменно в рамках одного и того же проекта.
- Адаптивный – самый гибкий, при котором в любой момент может поменяться цель компании, или вовсе стратегия. И неважно, что задумывалось первоначально. Здесь наше все – Agile, Scrum и другие гибкие методы.
Agile – безусловно, ключевая методика IT project management, которую, если и ругают, то хвалят точно чаще. Сложности с внедрением Agile, как правило, возникают в крупных компаниях с десятками команд, работающими над достижением общей цели.
Ниже мы представим наиболее популярные кейсы с известными заголовками, демонстрирующие то, что масштабирование Agile не только допустимо, но и может приносить большие выгоды. Будем рады, если из данных примеров вы возьмете что-то полезное для собственного опыта.
LEGO
Используемый фреймворк Agile: Scaled Agile Framework (SAFe)
Старт реализации: 2015 год
Свой путь к гибкости LEGO начала с внесения изменений на командном уровне. В то время в организации было задействовано 20 продуктовых команд. Изначально лишь 5 команд были преобразованы в Scrum-команды. Постепенно по их стопам пошли оставшиеся 15 команд.
Несмотря на предпринятые изменения, команды по-прежнему не могли эффективно сотрудничать друг с другом. Тогда компания последовала шаблону структуры SAFe и добавила еще один уровень – так называемый программный уровень с созданием команды команд (также известная как Agile Release Train (ART).
Команда команд каждые 8 недель собиралась на большую сессию планирования, длившуюся полтора дня. Во время этой встречи команды демонстрировали свою работу, оценивали риски, планировали следующий период выпуска.
Не забыла LEGO и про разделение на организационные уровни, характерные для структуры SAFe. Это – уровень портфеля, самый верхний уровень системы с долгосрочными бизнес-планами, заинтересованными сторонами и высшим руководством.
Для справки: SAFe — фреймворк, своего рода надстройка над SCRUM, оптимизирующая управление командами из 100 и более человек. Востребована при необходимости координации работы над отдельным проектом или взаимосвязанными проектами для 5 или более Scrum-команд.
Результаты:
- После того, как разработчикам была предоставлена возможность управлять работой специалистов, утратила силу необходимость в армии «менеджеров с ненужными таблицами». Ушла необходимость вести лишнюю документацию и осуществлять тем самым непродуктивную работу.
- Разработчики стали давать более точные оценки, а результаты оказались более предсказуемыми. Если раньше быстрее всех мог закончить свои задачи работник, умеющий кричать громче всех, то теперь, когда видимость стала предельной, решения принимались, исходя из реальной необходимости.
- Ничто не может сравниться с личным общением и тем положительным влиянием, которое оно оказывает на моральный дух команды. Особенно общение во время масштабных встреч команд.
- Визуальное, неформальное (в игровой форме) планирование помогает сосредоточиться, делает многие вопросы очевидными и упрощает их решение. Предоставление сотрудникам независимости придало им мотивации, напрямую улучшив показатели в работе.
Cisco
Используемый фреймворк Agile: Scaled Agile Framework (SAFe)
Старт реализации: 2015 год
Исследование сотрудника компании А. Панди касается отдельного продукта Cisco – Платформы выставления счетов за подписку.
Ранее проект придерживался методологии Waterfall. Это значит, что у Cisco были отдельные группы работников, ответственные за проектирование, сборку, тестирование и внедрение. Погрешностей было много, а сроки часто срывались. Люди работали сверхурочно.
В 2015 году компания перешла на SAFe.
Cisco создала три объединенные команды Agile разработчиков (Agile Release Trains), работающих совместно на протяжении длительного времени по следующим направлениям:
- Возможности;
- Дефекты;
- Проекты.
Каждый день команды собиралась на 15-минутное совещание для обсуждения рабочих моментов. Таким образом, с переходом на SAFe в работе была достигнута максимальная прозрачность: каждая команда знала, что делают другие. Кроме того, через подобную подотчетность и регулярное обновление статусов командам было легче понимать, какие действия предпринимать непосредственно внутри.
Проект также был объединен со структурой Scrum, которая использовалась в другом продукте – приложении WebEx для Samsung. Кроме того, были задействованы некоторые методы XP – такие, как разработка через тестирование и непрерывная интеграция (CI). Таким образом, в рамках одной компании был использован один фреймворк Agile для одного продукта, и другой – для иного. Такое тоже допустимо и, как видим, неплохо работает.
Результаты:
После того, как Cisco начала следовать методологии SAFe, чаще выпускать релизы и внедрять непрерывную интеграцию (CI), она получила:
- Снижение критических и серьезных дефектов на 40%.
- Снижение DRR (процент отклоненных дефектов) на 16%.
- Повышение на 14% DRE (Defect Removal Efficiency) – благодаря CI и большему взаимодействию с международными командами.
- Исчезла необходимость в сверхурочных работах, соблюдались запланированные дедлайны.
British Telecom
Используемый фреймворк Agile: Scrum + XP
Старт реализации: 2004 год
Задача – переход на 90-дневный цикл доставки. Исследование было проведено Я. Эвансом из British Telecom, где он рассказал о переходе компании на Agile. В 2004 году в British Telecom был принят новый ИТ-директор, который решил в корне изменить процесс Waterfall.
Старая модель вызывала ряд проблем:
- Слишком много людей создавали требования и почти все они имели высокий приоритет;
- Были предприняты попытки объединить максимальное количество рабочих задач в один проект;
- На этапе проектирования было слишком много посредников – как результат, процесс согласования выдавался мучительно сложным;
- Сроки разработки выполнялись с трудом – на разработчиков оказывалось сильное давление, при этом времени на контроль качества оставалось мало;
- Внедрение ожидаемо превращалось в кошмар – отдельные проекты или даже целые программы были упразднены за неактуальностью на текущий момент.
Чтобы решить все эти проблемы, British Telecom решила применить гибкий подход к разработке программного обеспечения и перейти на более короткие циклы выпуска:
- Вместо того, чтобы заранее утверждать документально все требования, было принято решение идти от обратного и действовать по ходу развития событий.
- Клиенты были вовлечены в процесс согласования.
- Стали проводиться меньшие, но более частые итерации – в целях улучшения качества.
Результаты:
По прошествии двух лет с момента преобразований никто в British Telecom не пожелал вернуться к старой модели Waterfall.
Вот некоторые достижения, к которым пришли:
- Срок поставки сократился с 12 месяцев до 90 дней.
- Все участники сошлись во мнении установить строгие приоритеты и сосредоточиться только на тех проектах, которые увеличивают ценность бизнеса.
- По итогам каждого цикла программа оценивалась на предмет количества так называемых успешных маркеров. Исходя из результатов, команда могла рассчитывать на бонус.
- Использование гибких методов повысило моральный дух и мотивацию разработчиков.
Национальный банк Канады
Используемый фреймворк Agile: Scrum of Scrums
Старт реализации: 2012 год
Национальный банк Канады принял решение о переходе на Agile с целью поиска баланса между жесткими требованиями соответствия и практиками Agile – для достижения максимальной гибкости. Зачастую приходилось идти на компромисс – было много вещей, которые банк просто не мог оставить на волю случая.
Результаты:
- Требования к бэклогу должны быть подписаны, прежде чем их можно будет выбрать для спринта.
- Введен порядок согласования спринтов.
- Решено создать долгосрочную дорожную карту Sprint, отражающую стратегические планы компании.
- Архитектура стала конечным продуктом, и ее нужно было решать на ранней стадии проекта (в то время как Agile обычно советует брать на себя серьезные обязательства как можно позже).
- Был разработан инновационный метод утверждения, так называемый «План «Минус тридцать». Согласно этому плану, команда начинает сбор данных для будущих проектов и их согласование в середине текущего спринта (за 30 дней до начала).
PTC
Используемая среда Agile: дисциплинированная гибкая разработка DAD
Старт реализации: 2014 год
В этом тематическом исследовании рассказывается о том, как Д. Дэйм помог PTC достичь гибкости, следуя подходу DAD.
Метод предназначен для компаний, где имеются:
- Большие команды;
- Устаревший код (по статистике около 90% Agile-команд имеют дело с унаследованным кодом);
- Организационные и иные сложности;
- Четкое следование нормативным требованиям.
Прежде чем приступить к сотрудничеству с командой PTC, Д. Дэйм убедил их признать, что Agile – не панацея, и нельзя полагаться только на нее в решении всех имеющихся проблем.
Во многом PTC столкнулся с теми же трудностями, что и Национальный банк Канады из выше представленного исследования:
- Это было строго регулируемое пространство, требующее соблюдения множества нормативных требований.
- Изначально всегда возникали паузы между спринтами, поскольку на согласование рабочих моментов уходило много времени.
- Также на начальных этапах почти всегда присутствовал «побочный эффект» – незавершенные текущие задачи из предыдущего спринта.
- Разработчикам и менеджерам было трудно прийти к единому результату.
Что было сделано в итоге для решения данных четырех проблем:
- Чтобы избежать утверждения любой крошечной функции, Дэйв решил разграничить задачи с высоким и низким уровнем риска. В последнем случае команды могли принимать самостоятельно решение, не прибегая к утверждению вышестоящих лиц.
- Если раньше команда заканчивала спринт и ждала, когда сможет приступить к следующему, теперь для устранения пауз между ними была создана команда разработчиков. Цель команды – непрерывно работать над получением обратной связи от клиентов / акционеров.
- Для предотвращения перезагруженности были пересмотрены условия планирования и подготовки. Принято решение иметь 2 уровня DoD, где помимо своего у каждой команды, также будет DoD всей компании – в целях поддержания общего качества.
Итак, попробуем выделить, что объединило представленные исследования. Все компании, внедрившие фреймворки Agile, отметили:
- Более высокую производительность;
- Меньше дефектов продукта;
- Больше четкости при оценке рисков;
- Больше счастья в глазах сотрудников;
- Экономию времени при выходе на рынок.
Практически каждая из данных компаний адаптировала готовую структуру Agile к своим конкретным потребностям.
Безусловно, Agile невозможно реализовать с наскока, неопытной командой, за короткий отрезок времени, но внедрение гарантированно улучшит взаимодействие между IT и бизнесом, ускорит выход продукта на рынок, повысит ценность продукта для конечного клиента.
При этом ваша концепция управления проектами может отличаться от общепринятых в отрасли и от популярных за рубежом. Только практика покажет, насколько удачной была ваша стратегия.
Оставайтесь гибкими, создавайте лучшие продукты, и да пребудет с вами сила Agile!
С развитием технологий и формированием новых отраслей привычные подходы классического проектного управления теряют свою актуальность. Все более востребованы гибкие методики Agile, позволяющие в режиме реального времени оперативно формировать требования, внедрять новшества и изменять собственные бизнес-процессы. Это возможно благодаря эффективному взаимодействию самоорганизующихся команд, в состав которых входят специалисты разного профиля. Эксперты GPI group безоговорочно поддерживают гибкие подходы управления проектами Agile с поэтапным запуском стратегических инициатив и использованием приоритизации задач. В нашем обзоре мы представили 5 знаменитых историй успеха, которые наглядно демонстрируют силу «гибкой разработки» сегодня.
Управление проектами в IT: три жизненных цикла
Непросто управлять людьми. Втройне сложнее управлять большой группой людей, да еще и эффективно. Пожалуй, это и толкает управленцев на новые поиски идей в достижении поставленных задач. Пробуя и ошибаясь, бизнес ищет свои методики, формулы, практики – смешивая их и оптимизируя, учитывая провалы и возможные риски, теряя время, а порой и деньги.
Любая компания, отдавая предпочтение планированию, а не привычной работе по накатанной, подбирает свою методологию, которая будет полезна именно ей. Конечно, гораздо легче делать, как привыкли – по инструкции, в порядке очереди, как написано в книжке. Куда сложнее искать и нарабатывать собственные инструменты для реализации выбранных приоритетов.
Проектный менеджмент (РМ) в данном случае становится популярным и все более востребованным в самых разных отраслях. Ведь он и есть методология управления компанией, подразумевающая разделение имеющегося объема работы на части (проекты).
Многие компании только сейчас начинают понимать, что классическая, зачастую бюрократическая схема менеджмента по принципу «надо вот так и никак иначе», где есть строгий начальник и подчиненный, изживает себя. Данный шаблон бесполезен в условиях мирового рынка. Наступило время проектного управления с отдельными задачами и делегированием полномочий.
Во многом его развитию способствовал информационный бум интернета 2010-х годов. Тогда на нашу голову в свободном доступе «свалились» тонны ранее не доступной информации от зарубежного бизнеса из разряда «что такое менеджмент», «как разделять полномочия, уменьшать риски» и т.д.
Сегодня мы можем видеть в последних обновлениях, как корпорации с мировым именем и многомиллионной прибылью непрерывно сливаются или делятся на подразделения. Это – яркий пример РМ, когда в зависимости от критериев поставленных задач происходят «сдвиги», однако внутри компании продолжается прежняя работа по достижению стратегических задач.
IT project management (управление проектами IT) в данном случае собирает в одно целое выявленные методы, принципы и политику ведения бизнеса. Благодаря ему сопровождение проектов становится более прозрачным, начиная от создания концепции и до полного завершения.
Если говорить коротко о том, как управлять проектами в IT, то, в первую очередь, необходимо определить функции, нарисовать схемы, таблицы всей компании и отдельно взятого проекта. Исходя из полученных приоритетов, выбираете максимально подходящую методологию. Далее дело остается за специальным сервисом по управлению проектами, где вся представленная информация будет компоноваться, контролироваться и улучшаться.
В целом, управлению проектами в IT свойственно 3 цикла:
- Прогнозируемый – самый традиционный из всех имеющихся, предполагает поэтапное линейное движение.
- Итерационный – самый инновационный, подразумевающий увеличение функционала ПО при необходимости с каждым новым шагом – неизменно в рамках одного и того же проекта.
- Адаптивный – самый гибкий, при котором в любой момент может поменяться цель компании, или вовсе стратегия. И неважно, что задумывалось первоначально. Здесь наше все – Agile, Scrum и другие гибкие методы.
Agile – безусловно, ключевая методика IT project management, которую, если и ругают, то хвалят точно чаще. Сложности с внедрением Agile, как правило, возникают в крупных компаниях с десятками команд, работающими над достижением общей цели.
Ниже мы представим наиболее популярные кейсы с известными заголовками, демонстрирующие то, что масштабирование Agile не только допустимо, но и может приносить большие выгоды. Будем рады, если из данных примеров вы возьмете что-то полезное для собственного опыта.
LEGO
Используемый фреймворк Agile: Scaled Agile Framework (SAFe)
Старт реализации: 2015 год
Свой путь к гибкости LEGO начала с внесения изменений на командном уровне. В то время в организации было задействовано 20 продуктовых команд. Изначально лишь 5 команд были преобразованы в Scrum-команды. Постепенно по их стопам пошли оставшиеся 15 команд.
Несмотря на предпринятые изменения, команды по-прежнему не могли эффективно сотрудничать друг с другом. Тогда компания последовала шаблону структуры SAFe и добавила еще один уровень – так называемый программный уровень с созданием команды команд (также известная как Agile Release Train (ART).
Команда команд каждые 8 недель собиралась на большую сессию планирования, длившуюся полтора дня. Во время этой встречи команды демонстрировали свою работу, оценивали риски, планировали следующий период выпуска.
Не забыла LEGO и про разделение на организационные уровни, характерные для структуры SAFe. Это – уровень портфеля, самый верхний уровень системы с долгосрочными бизнес-планами, заинтересованными сторонами и высшим руководством.
Для справки: SAFe — фреймворк, своего рода надстройка над SCRUM, оптимизирующая управление командами из 100 и более человек. Востребована при необходимости координации работы над отдельным проектом или взаимосвязанными проектами для 5 или более Scrum-команд.
Результаты:
- После того, как разработчикам была предоставлена возможность управлять работой специалистов, утратила силу необходимость в армии «менеджеров с ненужными таблицами». Ушла необходимость вести лишнюю документацию и осуществлять тем самым непродуктивную работу.
- Разработчики стали давать более точные оценки, а результаты оказались более предсказуемыми. Если раньше быстрее всех мог закончить свои задачи работник, умеющий кричать громче всех, то теперь, когда видимость стала предельной, решения принимались, исходя из реальной необходимости.
- Ничто не может сравниться с личным общением и тем положительным влиянием, которое оно оказывает на моральный дух команды. Особенно общение во время масштабных встреч команд.
- Визуальное, неформальное (в игровой форме) планирование помогает сосредоточиться, делает многие вопросы очевидными и упрощает их решение. Предоставление сотрудникам независимости придало им мотивации, напрямую улучшив показатели в работе.
Cisco
Используемый фреймворк Agile: Scaled Agile Framework (SAFe)
Старт реализации: 2015 год
Исследование сотрудника компании А. Панди касается отдельного продукта Cisco – Платформы выставления счетов за подписку.
Ранее проект придерживался методологии Waterfall. Это значит, что у Cisco были отдельные группы работников, ответственные за проектирование, сборку, тестирование и внедрение. Погрешностей было много, а сроки часто срывались. Люди работали сверхурочно.
В 2015 году компания перешла на SAFe.
Cisco создала три объединенные команды Agile разработчиков (Agile Release Trains), работающих совместно на протяжении длительного времени по следующим направлениям:
- Возможности;
- Дефекты;
- Проекты.
Каждый день команды собиралась на 15-минутное совещание для обсуждения рабочих моментов. Таким образом, с переходом на SAFe в работе была достигнута максимальная прозрачность: каждая команда знала, что делают другие. Кроме того, через подобную подотчетность и регулярное обновление статусов командам было легче понимать, какие действия предпринимать непосредственно внутри.
Проект также был объединен со структурой Scrum, которая использовалась в другом продукте – приложении WebEx для Samsung. Кроме того, были задействованы некоторые методы XP – такие, как разработка через тестирование и непрерывная интеграция (CI). Таким образом, в рамках одной компании был использован один фреймворк Agile для одного продукта, и другой – для иного. Такое тоже допустимо и, как видим, неплохо работает.
Результаты:
После того, как Cisco начала следовать методологии SAFe, чаще выпускать релизы и внедрять непрерывную интеграцию (CI), она получила:
- Снижение критических и серьезных дефектов на 40%.
- Снижение DRR (процент отклоненных дефектов) на 16%.
- Повышение на 14% DRE (Defect Removal Efficiency) – благодаря CI и большему взаимодействию с международными командами.
- Исчезла необходимость в сверхурочных работах, соблюдались запланированные дедлайны.
British Telecom
Используемый фреймворк Agile: Scrum + XP
Старт реализации: 2004 год
Задача – переход на 90-дневный цикл доставки. Исследование было проведено Я. Эвансом из British Telecom, где он рассказал о переходе компании на Agile. В 2004 году в British Telecom был принят новый ИТ-директор, который решил в корне изменить процесс Waterfall.
Старая модель вызывала ряд проблем:
- Слишком много людей создавали требования и почти все они имели высокий приоритет;
- Были предприняты попытки объединить максимальное количество рабочих задач в один проект;
- На этапе проектирования было слишком много посредников – как результат, процесс согласования выдавался мучительно сложным;
- Сроки разработки выполнялись с трудом – на разработчиков оказывалось сильное давление, при этом времени на контроль качества оставалось мало;
- Внедрение ожидаемо превращалось в кошмар – отдельные проекты или даже целые программы были упразднены за неактуальностью на текущий момент.
Чтобы решить все эти проблемы, British Telecom решила применить гибкий подход к разработке программного обеспечения и перейти на более короткие циклы выпуска:
- Вместо того, чтобы заранее утверждать документально все требования, было принято решение идти от обратного и действовать по ходу развития событий.
- Клиенты были вовлечены в процесс согласования.
- Стали проводиться меньшие, но более частые итерации – в целях улучшения качества.
Результаты:
По прошествии двух лет с момента преобразований никто в British Telecom не пожелал вернуться к старой модели Waterfall.
Вот некоторые достижения, к которым пришли:
- Срок поставки сократился с 12 месяцев до 90 дней.
- Все участники сошлись во мнении установить строгие приоритеты и сосредоточиться только на тех проектах, которые увеличивают ценность бизнеса.
- По итогам каждого цикла программа оценивалась на предмет количества так называемых успешных маркеров. Исходя из результатов, команда могла рассчитывать на бонус.
- Использование гибких методов повысило моральный дух и мотивацию разработчиков.
Национальный банк Канады
Используемый фреймворк Agile: Scrum of Scrums
Старт реализации: 2012 год
Национальный банк Канады принял решение о переходе на Agile с целью поиска баланса между жесткими требованиями соответствия и практиками Agile – для достижения максимальной гибкости. Зачастую приходилось идти на компромисс – было много вещей, которые банк просто не мог оставить на волю случая.
Результаты:
- Требования к бэклогу должны быть подписаны, прежде чем их можно будет выбрать для спринта.
- Введен порядок согласования спринтов.
- Решено создать долгосрочную дорожную карту Sprint, отражающую стратегические планы компании.
- Архитектура стала конечным продуктом, и ее нужно было решать на ранней стадии проекта (в то время как Agile обычно советует брать на себя серьезные обязательства как можно позже).
- Был разработан инновационный метод утверждения, так называемый «План «Минус тридцать». Согласно этому плану, команда начинает сбор данных для будущих проектов и их согласование в середине текущего спринта (за 30 дней до начала).
PTC
Используемая среда Agile: дисциплинированная гибкая разработка DAD
Старт реализации: 2014 год
В этом тематическом исследовании рассказывается о том, как Д. Дэйм помог PTC достичь гибкости, следуя подходу DAD.
Метод предназначен для компаний, где имеются:
- Большие команды;
- Устаревший код (по статистике около 90% Agile-команд имеют дело с унаследованным кодом);
- Организационные и иные сложности;
- Четкое следование нормативным требованиям.
Прежде чем приступить к сотрудничеству с командой PTC, Д. Дэйм убедил их признать, что Agile – не панацея, и нельзя полагаться только на нее в решении всех имеющихся проблем.
Во многом PTC столкнулся с теми же трудностями, что и Национальный банк Канады из выше представленного исследования:
- Это было строго регулируемое пространство, требующее соблюдения множества нормативных требований.
- Изначально всегда возникали паузы между спринтами, поскольку на согласование рабочих моментов уходило много времени.
- Также на начальных этапах почти всегда присутствовал «побочный эффект» – незавершенные текущие задачи из предыдущего спринта.
- Разработчикам и менеджерам было трудно прийти к единому результату.
Что было сделано в итоге для решения данных четырех проблем:
- Чтобы избежать утверждения любой крошечной функции, Дэйв решил разграничить задачи с высоким и низким уровнем риска. В последнем случае команды могли принимать самостоятельно решение, не прибегая к утверждению вышестоящих лиц.
- Если раньше команда заканчивала спринт и ждала, когда сможет приступить к следующему, теперь для устранения пауз между ними была создана команда разработчиков. Цель команды – непрерывно работать над получением обратной связи от клиентов / акционеров.
- Для предотвращения перезагруженности были пересмотрены условия планирования и подготовки. Принято решение иметь 2 уровня DoD, где помимо своего у каждой команды, также будет DoD всей компании – в целях поддержания общего качества.
Итак, попробуем выделить, что объединило представленные исследования. Все компании, внедрившие фреймворки Agile, отметили:
- Более высокую производительность;
- Меньше дефектов продукта;
- Больше четкости при оценке рисков;
- Больше счастья в глазах сотрудников;
- Экономию времени при выходе на рынок.
Практически каждая из данных компаний адаптировала готовую структуру Agile к своим конкретным потребностям.
Безусловно, Agile невозможно реализовать с наскока, неопытной командой, за короткий отрезок времени, но внедрение гарантированно улучшит взаимодействие между IT и бизнесом, ускорит выход продукта на рынок, повысит ценность продукта для конечного клиента.
При этом ваша концепция управления проектами может отличаться от общепринятых в отрасли и от популярных за рубежом. Только практика покажет, насколько удачной была ваша стратегия.
Оставайтесь гибкими, создавайте лучшие продукты, и да пребудет с вами сила Agile!
Комментариев ещё нет.