Почему у одних получается, а у других — нет. эксперт про опыт внедрения agile

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

Методология Аджайл (Agile methodology) — один из самых популярных способов достижения этой цели. Согласно исследованию State of Agile (2020), 95% респондентов заявили, что их компании частично либо полностью используют Agile методологии ведения проектов. 

Также участники опроса рассказали, в каких департаментах их организаций используют Agile методологии. Среди них:

  • Разработка программного обеспечения (37%).
  • IT (26%).
  • Управление операциями(12%).
  • Маркетинг (7%).
  • Отдел кадров или HR (6%).
  • Отдел продаж (5%).

Почему у одних получается, а у других — нет. Эксперт про опыт внедрения agile

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

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

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

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

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

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

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

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

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

Преимущества Agile:

  • Быстрое обнаружение и исправление ошибок.
  • Прозрачность рабочего процесса.
  • Частые и ожидаемые релизы.
  • Предсказуемая стоимость проекта.
  • Оперативное принятие решений.
  • Нацеленность на пользователей.
  • Конечный продукт является лучшей своей версией.
  • Высокий уровень удовлетворенности заказчиков.

Почему у одних получается, а у других — нет. Эксперт про опыт внедрения agile

Agile манифест

Публикация Agile манифеста в 2001 году знаменовала рождение Agile как методологии.

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

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

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

За последние 20 лет с момента создания манифест приняли многие команды и организации из разных профессиональных сфер. Сегодня документ доступен более чем на 50 языках, включает в себя 4 ценности и 12 принципов.

4 ценности Agile манифеста:

  1. Взаимодействие с людьми важнее рабочих процессов и инструментов.
  2. Качество продукта важнее подробной документации.
  3. Сотрудничество с клиентами важнее, чем обсуждение условий контракта.
  4. Реагирование на изменения важнее следования первоначальному плану.

Почему у одних получается, а у других — нет. Эксперт про опыт внедрения agile

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

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

  1. Главный приоритет — удовлетворение потребностей клиента. Достигается это за счет постоянной и систематической поставки ценного ПО.  
  2. Изменения требований одобряются, независимо от того, на какой стадии разработки находится продукт. 
  3. Частые релизы усовершенствованного продукта приветствуются.

  4. Разработчики и представители бизнеса должны работать сообща ежедневно на протяжении всего проекта.
  5. Личное общение с командами и внутри них является наилучшим способом передачи информации.
  6. Мотивация сотрудников должна быть в приоритете.

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

  7. Работающее ПО — главный показатель прогресса.
  8. Важно, чтобы инвесторы, команда разработчиков и пользователи поддерживали постоянный рабочий ритм.

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

  9. Непрерывное внимание к совершенству проектирования и качеству разработки повышает гибкость проекта.
  10. Простота — необходимая часть эффективной работы с Agile.

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

Популярные Agile методологии 

Существует множество различных методологий (или фреймворков) гибкой разработки, которые держат за основу ценности и принципы Agile манифеста. Канбан (Kanban), Скрам (Scrum), Бережное производство (Lean) и Экстремальное программирование (XP) — часто используемые из них.

Почему у одних получается, а у других — нет. Эксперт про опыт внедрения agile

Kanban

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

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

Scrum

Скрам — это методология управления проектами, в которой командой руководит Скрам-мастер. Его главная задача состоит в устранении преград на пути к завершению проекта. 

Работа в команде делится на короткие повторяющиеся циклы, которые называются спринтами и обычно длятся 1-4 недели. При этом команда собирается на ежедневные митинги (стендапы), чтобы обсудить текущие задачи и препятствия, которые предстоит преодолеть.

Экстремальное программирование (XP)

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

Доступно проиллюстрирует идею XP способ «парного программирования». В этом случае один разработчик занимается написанием кода, а его коллега непрерывно просматривает и проверяет написанное, не дожидаясь окончания работы первого программиста.

Бережливое производство (Lean)

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

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

Другие гибкие методологии разработки ПО

В управлении проектами существует ряд других методологий управления проектами кроме тех, что мы перечислили выше:

  • Разработка, управляемая функциональностью (FDD).
  • Crystal Clear. 
  • Метод разработки динамических систем (DSDM).
  • Разработка через тестирование (TDD).
  • Адаптивные рамки проекта (APF),
  • и другие.

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

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

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

Например, разработчики программного обеспечения чаще предпочитают Scrum и XP, в то время как Канбан — любимец команд, ориентированных на сервис (IT, маркетинг или отдел кадров).

Кому подойдет методология Agile?

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

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

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

  • Если грядущий проект технологически сложный и комплексный.

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

  • Если проект продолжительный по времени.

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

  • Если в реализации проекта много неопределенных моментов.

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

  • Если количество идей по проекту превышает возможности команды.

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

  • Если клиент хочет участвовать в каждом этапе реализации проекта.

Идеальное условие для внедрения Agile методологий — это заинтересованность заказчика в плотном сотрудничестве с командой.

Инструменты для работы с Agile-проектами

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

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

Онлайн-диаграмма Ганта с легкостью выполнит все эти задачи и упростит работу с проектом всем его участникам. 

Почему у одних получается, а у других — нет. Эксперт про опыт внедрения agile

GanttPRO — инструмент для управления проектами на основе диаграммы Ганта. С ним вы можете вести несколько проектов одновременно, управлять ресурсами и финансами, а также делиться планами при помощи ссылки даже с незарегистрированными пользователями.

Попробуйте GanttPRO бесплатно!

Какую гибкую методологию управления проектами предпочитаете вы?

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

А какие Agile методологии управления проектами предпочитает ваша команда? Делитесь в х ниже.

4 шага к Agile-маркетингу, или Как компании реагируют на перемены

Постигая Agile

4 шага к Agile-маркетингу, или Как компании реагируют на перемены

15 июня 2019 2 300 просмотров

Лиана Хазиахметова

В первой части интервью с Юлией Тегель мы говорили о преимуществах Agile-маркетинга, а также о том, где гибкость не работает. Юлия — Agile коуч, Agile-маркетолог и научный редактор книги «Agile-маркетинг». Во второй части интервью мы сосредоточились на практике — как внедрить гибкие методологии, с чего начать и как бороться со сложностями.

— Agile-маркетинг в России только начинает развиваться. Как маркетологи реагируют на внедрение гибких методологий?

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

Задавая вопрос на конференции «Кто уже знаком с agile-маркетингом?», я видела 3-5 поднятых рук, сейчас, как правило, уже большая часть зала слышала/читала, а кто-то уже имеет практический опыт agile в своих организациях.

Почему у одних получается, а у других — нет. Эксперт про опыт внедрения agile
Agile-маркетинг

Почему у одних получается, а у других — нет. Эксперт про опыт внедрения agile
Юлия Тегель

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

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

— Есть ли примеры компаний, которые уже перешли на рельсы agile в маркетинге или близки к этому? Что изменилось в их работе? К каким результатам это привело?

— Да, конечно, есть. Более того, некоторые компании (чаще это стартапы) интуитивно Agile. Иногда я слышу фразу «А мы так и живем, только не знали, что мы Agile!» И это здорово.

Таким командам, как правило, нужно выбрать подходящий фреймворк или методологию (Scrum/Kanban/Scrumban), определенные практики, чтобы в интуитивное развитие добавить системность.

Ведь, когда встанет вопрос роста и масштабирования, интуиции станет мало.

Бизнесы очень разных категорий начинают переводить свои не IT-департаменты, в том числе маркетинг, на Agile.

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

Мы выстраивали маркетинг по ценностям и принципам agile и в медицине — в стоматологической клинике, и в компании, занимающейся B2B продажами оборудования…

  • Если говорить о результатах из моей практики, то это значительное уменьшение времени на вывод новых продуктов/коммуникационных кампаний на рынок (до 2-х недель — от идеи до готового продукта), увеличение количества новых, креативных идей, более эффективное взаимодействие между департаментами/командами, повышение мотивации и вовлеченности сотрудников, увеличение оборота компании.
  • А еще более счастливые сотрудники ????
  • Почему у одних получается, а у других — нет. Эксперт про опыт внедрения agile
    Agile делает команду сплоченнее. Источник

Могу ли я сказать, что такие результаты достигаются только за счет перехода на Agile? Скорее, нет.

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

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

Хорошо, если в этот момент с вами будет специально обученный человек — agile-коуч, который поможет команде не утонуть в долине слез. И примерно через полгода вы увидите первые положительные результаты, а через год они уже будут устойчивыми.

— Что, на ваш взгляд, самое сложное во внедрении agile-маркетинга?

— Меняться руководителю. Ведь, если Agile приходит в компанию, то изменения затрагивают не только сотрудников, но и руководство. Подход «вы там их измените, и все у нас будет ОК» не работает.

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

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

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

— С чего начать компаниям, которые хотят стать agile, но боятся?

— Ответить на вопрос «Зачем нам Agile». Причем не только в разрезе бизнеса или руководителя, но и понять, зачем Agile каждому сотруднику. Ведь, если человек не будет понимать «зачем» ему лично изменения, то он будет их саботировать.

— Внедрять нужно комплексно? Или можно начать с чего-то простого?

— Начните с пилотной команды.

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

2. Сформируйте команду — идеально до 9 человек.

3. Пройдите обучение, чтобы у всех было единое информационное пространство, понимание терминологии, инструментов и дальнейших шагов.

4. Действуйте! Причем по технике СЮ-ХА-РИ. Не пытайтесь сразу что-то изменить и адаптировать под себя. Начните с четкого соблюдения положений выбранного фреймворка/методологии (Scrum/Kanban/Scrumban). Помните, чтобы изменения были приняты, нужно время.

Почему Agile не «внедряют», или как «вырастить» Agile?

Это третья статья из серии «Введение в Agile». В предыдущих статьях мы рассказали, чем отличается Agile от классического проектного управления, и в каких проектах стоит применять Agile.

Почему у одних получается, а у других — нет. Эксперт про опыт внедрения agile

Напомним, сфера применения Agile по модели Киневин – запутанные системы и задачи, в которых непонятен финальный продукт или неизвестна технология его создания.

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

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

Для того, чтобы работать в среде запутанных задач, с высокой неопределенностью, значительными изменениями и новой информацией, необходим особый, «гибкий» склад ума (Agile mindset). Такой тип мышления называется «ориентированным на рост». Его характеризует:

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

-избегание неопределенности.

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

Таким образом, Agile — это не только практики, но и гибкий образ мышления. Следование практикам без понимания общих ценностей и принципов гибких подходов превращают Agile в карго-культ. О понятии и примерах карго-культа в Agile мы писали этим летом.

Вот основные признаки Agile-команды:

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

Вместе с тем, ответственность за создание продукта делится равномерно между всеми участниками и лежит на команде в целом.

В Agile не выделяют одного ответственного за результат; -чтобы в команде не возникало внутренней структуры, она должна быть малочисленной: для ориентира популярны «закон Миллера» (магическое число семь плюс-минус два) и «2-pizza team» (команда должна быть такого размера, чтобы всех участников можно было накормить двумя пиццами); -эта команда автономна, ее работа не зависит от каких-либо внешних воздействий и не может быть нарушена внешним вмешательством; -эта команда кросс-функциональна, то есть любой участник может выполнять любую из задач, которые команда берет в работу. Конечно, для сложных продуктов редкой будет ситуация, когда все участники команды в совершенстве владеют всеми функциями. В этом случае говорят о развитии «Т-компетенций»: каждый участник глубоко разбирается в своей профильной деятельности (вертикальная черта в «Т») и средне – в смежных областях (горизонтальная черта в «Т»), может при необходимости помочь или заменить другого участника; -эта команда мотивирована на создание результата: поскольку команда сама определяет, как выстроить работу над продуктом, все участники должны понимать цели, для которых создается продукт, каково его назначение, какие проблемы заказчика он должен решать; -эта команда обладает достаточной смелостью, чтобы блокировать попытки вмешаться в ее работу и навязать срочные, но не приоритетные требования; -рекомендуется физически размещать Agile-команду в одном помещении. Это помогает быстро общаться, быть в курсе общего состояния работы без формальных совещаний по статусу. При этом помещение для команды лучше выбирать изолированное от шума и присутствия других сотрудников: это поможет избавиться от информационного загрязнения и сфокусироваться на задаче.

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

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

-Формирование (Forming, решение первой задачи вместе); -Шторм (Storming, социальное взаимодействие, распределение ролей);

-Нормализация (Norming, переключение внимания с разрешения конфликтов на выполнение задач);

-Работа (Performing, слаженная работа и качественные результаты). Почему у одних получается, а у других — нет. Эксперт про опыт внедрения agile

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

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

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

Резюме

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

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

Поэтому Agile «выращивают», а не внедряют.

Источник: pmservices

Почему Agile не работает и что с этим делать

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

Почему у одних получается, а у других — нет. Эксперт про опыт внедрения agile

/ Flickr / Hamza Butt / CC

Гибкие методологии не новы, не оригинальны и испробованы многими компаниями.

И некоторые из них (как, например, американская компания-поставщих BI-решений для железных дорог Railinc) признают, что agile — лучшее, что могло с ними произойти. Правда, их энтузиазм разделяют не все.

Крис Йорк (Chris York), тестировщик и разработчик с пятнадцатилетним опытом, утверждает, что ни разу в своей жизни не видел, чтобы гибкие методологии работали так, как надо.

По данным исследования VersionOne, 98% компаний считают свои agile-проекты успешными. Однако всего 7% респондентов сказали, что внедрение agile помогло компании лучше адаптироваться на рынке, и только 11% опрошенных заявили, что достигли высокого уровня компетентности внутри организации благодаря agile. Остальные 82% говорят, что всё ещё не достигли желаемого уровня «гибкости». Возможно, эти компании что-то делают не так, попробуем разобраться, что именно. В agile-проектах общение — важная составляющая процесса, так же как и ежедневные встречи. Вся команда должна понимать, что произошло вчера, и что запланировано на завтра. Если люди общаются лично, они работают лучше: об этом говорит шестой принцип agile.

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

Кроме IBM удалённых сотрудников «превращают в офисных» компании Reddit, Aetna, Bank of America и Best Buy.

Диана Герсон (Diane Gherson) старший вице-президент по кадровой политике IBM говорит, что причина изменений состоит в том, что при этом подходе можно развивать «непрерывный процесс генерации инноваций».

Хуан Эмилио Инзауррага (Juan Emilio Inzaurraga), менеджер проектов компании Hexacta, также подчеркивает важность общения в agile-командах.

Компания практикует ежедневные встречи/звонки с участием заказчика, и, по словам Хуана, это помогает ему определять прогресс команды, возможные узкие места и недостатки продукта.

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

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

Разумеется, если ситуация преподносится руководством именно так, энтузиазма у сотрудников новые подходы не вызовут.

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

Стив Берчук (Steve Berczuk), ведущий инженер и скрам-мастер в Fitbit, подчеркивает — в некоторых компаниях внедрение agile конфликтует с ранее принятыми политиками по найму удаленных работников.

Увлечение личными встречами тоже имеет свои негативные последствия. Например, опытный разработчик и резидент Quora Оливер Долан (Oliver Dolan) подсчитал, что на ежедневные встречи уходит 2640 минут или 44 часа за 1 спринт. Это не так уж и мало.

Пользователи Hacker News также приводят множество аргументов против этих встреч: встречи убивают мотивацию, отвлекают, раздражают разработчиков, о чём также упоминает Джон Парселл (John Purcell), создатель образовательного проекта CaveOfProgramming.

Все эти опасения — не повод «отменять agile». Вопрос в том, насколько удачно компания сможет адаптировать гибкую методологию под себя.

Например, другой резидент Quora, Патриция Оковицка (Patrycja Okowicka), разработчик с двенадцатилетним стажем, говорит, что в ее scrum-команде встречи занимают только 15% времени, остальные 85% — чистая работа.

При таком подходе волноваться о том, что вся работа превращается в совещания, не приходится.

И несмотря на уверенность одного из создателей Agile Manifesto Роберта Мартина (Robert Martin) в том, что для достижения результата разработчикам нужно находиться буквально «в одной комнате», примеры того, как распределенные команды успешно внедрили agile, тоже существуют.

Например, Джейми Болстер (Jamie Bolster), генеральный директор MentorMate, успешно управлял командой разработчиков, которые работали удалённо, с помощью agile.

А Сандип Джоши (Sandeep Joshi), разработчик Microsoft, предлагает конкретные действия для грамотного управления удалённой командой.

Энтони Мерсино (Anthony Mersino), основатель тренинговой компании Vitality Chicago и автор книги «Agile Project Management: A Nuts and Bolts Guide to Sucess», утверждает, что менеджеров в agile вообще не должно быть. А Стив Деннинг (Steve Denning), автор шести книг о бизнесе и блога в Forbes, говорит, что «менеджмент» и agile — два разных мира. Предполагается, что члены команды могут сами организовать рабочий процесс и мотивировать себя.

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

Патрик Харрингтон (Patrick Harrington), один из основателей и главный аналитик данных компании Paysa, подчёркивает, что опытные разработчики не нуждаются в постоянном надзоре, они уже достаточно взрослые и мотивируются KPI.

Проблема в том, что менеджера обычно привыкли видеть «надсмотрщиком над разработчиками», в то время как в действительности (в особенности в agile-командах) его роль должна быть совершенно иной.

В сообществах вроде Hacker News [1, 2] разработчики отмечают, что «идеальный PM» должен быть на стороне команды, помогать каждому ее участнику разобраться в целях и задачах проекта, по возможности устранять мешающие факторы вроде нехватки ресурсов и (самое главное) защищать интересы и время разработчиков, а также ограждать команду от слишком частых совещаний и прочей энтропии. Такой подход позволит программистам работать слаженно и быстро реагировать на требования клиента — а это именно то, к чему стремятся agile-команды.

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

Один из участников этого треда на Hacker News проводит аналогию с футболом. В футбольной команде все игроки четко понимают цель, обладают навыками, чтобы её достичь.

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

Никто не дышит футболистам в спину со словами: «Нужно забить гол через 15 минут и 48 секунд после начала матча и не минутой позже, даже если это невозможно». Такая команда работает слаженно и обычно достигает цели, и это именно то, что пытаются донести agile-методологии.

Следование принципам agile положительно влияет на эффективность работы, но (само по себе) не является показателем эффективности: выполнение формальных «ритуалов agile» не приблизит команду к достижению KPI.

Более того, и показатели, по которым измеряется качество работы, с введением agile имеет смысл пересмотреть: если ваша команда должна незамедлительно реагировать на новые вводные, быстро адаптироваться к меняющейся ситуации, могут ли при этом оставаться неизменными KPI и подходы к их оценке? Этот вопрос, в частности, поднимает Джим Хайсмит (Jim Highsmith) в книге Agile Project Management.

Иногда такой «гибкий» пересмотр KPI «на ходу» требует немало смелости. Кстати, именно смелость сказать, что что-то в проекте идет не по заранее спланированному сценарию, как одну из важнейших качеств agile-лидера, выделяет Гари Поллис (Gary Pollice), практикующий профессор информатики и один из авторов книги «Разработка программных проектов. На основе Rational Unified Process (RUP)».

Когда термин «agile» стал популярным, многие компании решили внедрить методологию, только чтобы быть «в теме». Один из резидентов Hacker News делится своим опытом на этот счёт. Когда он работал коуч-руководителем по agile-методологии, каждый раз он наблюдал, как компании внедряют внешние вещи: встречи, итерации и др., но рабочий процесс остается таким же, как до внедрения agile. Получается, что компания следует принципам agile внешне, а внутри всё равно использует условный waterfall. К сожалению, если принципы нового подхода непонятны участникам, «откат назад» будет неизбежен — люди, которые попадают в agile-среду без четкого понимания ее задач и преимуществ, будут тяжело к ней адаптироваться и постоянно возвращаться к вертикальному менеджменту.

С другой стороны, нет необходимости и в «дословном копировании» всех нюансов того или иного подхода — особенно если вы не понимаете, что именно они дают вашему проекту.

В конце концов, у всех методологий есть свои плюсы и минусы.

Поэтому вместо междоусобных войн вроде: Lean vs Agile или Kanban vs Scrum, полезнее будет посмотреть на общие черты различных методологий, объединить самые выгодные для конкретной команды и проекта и внедрить их.

Один из успешных примеров — команда разработчиков RentaTeam. Они изменили принципы общения в команде и подстроили agile-методологии под свою команду и проект. Так agile обрёл смысл для сотрудников, а продуктивность разработчиков возросла на 30%.

По мнению Грега Йоргенсена (Greg Jorgensen), «типичного программиста» с сорокалетним опытом работы, увлечённая команда профессионалов, которая не зависит от решений сверху, понимает цели и требования и знает, как их достичь — вот, что сделает проект успешным. Методологии и инструменты — это прекрасно, но главное — это люди.

P.S. Наши материалы о методологиях разработки программного обеспечения: P.P.S. Материалы по теме из блога «ИТ Гильдии»:

Просто космос. Практикум по Agile-жизни, наполненной смыслом и энергией. Катерина Ленгольд — отзыв

Всем привет!

Я давно увлекаюсь планированием, перечитала кучу книжек и попробовала многое из того, что там написано, но моя жизнь не стала от этого лучше и организованнее. Пока в прошлом году я не натолкнулась на книгу Катерины Ленгольд «Просто космос». Благодаря ей я начала практиковать спринты и в этом отзыве хочу изложить свою историю знакомства с этой книгой.

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

Но потом, прочитав отзыв на неё в блоге Марьяны Терехиной (@planme.blog), я решила эту книгу всё-таки прочитать.

После прочтения эта книга «взорвала» мне мозг! Я вдруг поняла, что нашла, наверное, идеальную для себя систему планирования. Честно, это была первая книга, после чтения которой я вдруг подняла попу с дивана и начала планировать свой первый спринт. В ходе своих первых спринтов я даже перечитывала эту книгу каждую неделю.

Для написания этого отзыва я решила ещё раз перечитать книгу и заодно — отделить удачное от неудачного и в рассказать о своем опыте чтения и проработки книги.

Почему у одних получается, а у других — нет. Эксперт про опыт внедрения agile

Вот так выглядит мой экземпляр книги. Несмотря на то, что я поначалу перечитывала её довольно часто (как уже писала выше), книга за полтора года практически никак не изменилась.

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

Ещё в книге есть удобная закладка, которая поможет не потеряться в процессе чтения.

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

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

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

Выводы я для себя сделала такие:

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

  • Во-вторых, со временем я поняла, что отрезки планирования в 9 и в 3 недели плохо сопоставимы с ориентацией на месяц/неделю/год.
  • В-третьих, я поняла, что некоторые практики вроде «утренних страниц» мне порой не заходят, а некоторые методы я даже не пыталась практиковать (например, список антипрокрастинации).
  • Тем не менее, несмотря на свой негативный опыт (которые заключался в том, что не всех своих целей я достигаю быстро и результативно, как хотела), я все же рекомендую эту книгу.
  • Ну, а мне ещё предстоит дальше изучать планирование, чтобы найти свои лайфхаки по достижению целей.

Достоинства

  • Без воды
  • Бери и делай
  • Много практики

Недостатки

  • Не все можно (и нужно!) внедрить сразу

Читать все отзывы 3

  1. Другие отзывы
  2. Смотрите также
  • Практикум по высшей математике том 2 Иа Каплан Супер!стоит только захотеть понять интегрирование и открыть этот учебник и … … и вам удастся это сделать! Конечно автор не вставит всю теорию и умение решать интегралы вам в мозг,как ,кстати, и препод,но в этой книге всё разжёвывается досконально!Отличный практикум!Несмотря на то,что там подробно объяснено только интегральное исчисление,ну еще немного…
  • ЕГЭ по математике 2015 (базовый уровень) И В Ященко Кто же придумывает этот бред? Примеры некоторых задач, которые решали разные люди и у всех разные ответы… Хочу поделиться своим впечатлением от сборника типовых тестовых заданий подготовки к ЕГЭ (базовый уровень) под редакцией И.В. Ященко, 2015 год. Сборник, в принципе, нормальный, сын по нему готовился к сдаче ЕГЭ в 11 классе.
  • «Вы еще не говорите по немецки?» Самоучитель для начинающих. И. Г. Клочко Отличная книга. Подойдет и начинающим и тем, у кого уже есть базовые знания. Здравствуйте! Хочу рассказать сегодня о замечательной и очень полезной книге(т.е. самоучитель для начинающих) для тех, кто хочет выучить немецкий язык. Не так давно задалась целью выучить немецкий язык. Лазила по книжным магазинам и сайтам в поиске хорошего самоучителя.
  • Жизнь Бунина. В. И. Муромцева-Бунина Биография нобелевского лауреата Ивана Алексеевича Бунина устами его жены….интересно ли? Привет, привет! Давненько я ничего не писала, а так хочется! Бросив себе книговызов , я все еще хочу успеть его выполнить! Одной из книг, которую я недавно прочла ,стала биография знаменитого и всеми любимого нобелевского лауреата Ивана Алексеевича Бунина, которую написала его жена Вера Ивановна…
  • Agile life. Катерина Ленгольд Новинка 20-го года. Лучшая книга по планированию ♥ как достигать своих целей, сохраняя баланс между работой, саморазвитием и семьей Я редко пишу отзывы на книги, но сейчас потянуло поделиться последними прочитанными. Ну как последними, в рамках полугода. Самым соком. Книгами, которые реально оказали на меня воздействие, несколько изменили стиль жизни и ее восприятие. Первая на очереди « Agile life» Катерины Ленгольд. Свежая.
  • Популярные отзывы
  • Важные годы. Почему не стоит откладывать жизнь на потом. Мэг Джей Это лучшие годы твоей жизни! Давай быстрее, а то опоздаешь! Почему все так топят за брак? Разберем эффект сожительства, силу случайных связей и что точно нельзя упускать пока тебе 20+ лет — много фото Всем Привет! Вот сидишь ты и смотришь в окно, а в это время проходят те самые ЛУЧШИЕ ГОДЫ ТВОЕЙ ЖИЗНИ! Все чаще думаешь о том, что все упускаешь, жизнь проходит мимо, а вот у других она гороздо лучше, чем у меня… Сегодня порассуждаем именно об этом.
  • 6 минут. Ежедневник, который изменит вашу жизнь. Спенст Доминик Можно ли изменить жизнь, уделяя ежедневнику 6 минут каждый день? Привет! Я люблю всякого рода ежедневники и блокноты, поэтому, когда на день рождения я получила ежедневник «6 минут» , то очень обрадовалась! Качественный, аккуратный и очень красивый блокнот с обложкой оттенка «Мята» (мне он кажется нежно-голубым).
  • 30 шикарных дней. Твой план по созданию жизни твоей мечты. Феррис Фиона Одним словом, шикарная шикарность изысканной изысканостью погоняет. Попалась книга случайно на глаза. Мне просто понравилось название. Оптимистично. А этого сейчас в моей жизни не хватает. Очень. Прочла аннотацию. Нет, чуда я не ждала. Просто вот конкретные способы поднять себе настроение, стать спокойнее. Отвлечься. Что-то позитивное. В общем, рассказываю.
  • Исцели свою жизнь. Луиза Хей ⭐️Одна из моих самых любимых авторов! Прекрасные книги Луизы Хей, которые я рекомендую к прочтению и немного информации о ней!⭐️ Всем доброго времени суток!   Сегодня хочу поделиться своим впечатлением от прочтения книги Луизы Хей «Исцели свою жизнь» .   Начну с того, кто такая Луиза Хей?
  • Теперь «Я обычная» звучит как комплимент самой себе! Актуальная книга XXI века о том, что нужно наслаждаться ПРОСТОЙ жизнью, пока другие фотошопят свою! Привет всем!   Я не часто читаю книги по психологии, мотивации и т.п., потому что большинство из них написаны скучным, а порой и сложным языком. Но иногда мне попадаются действительно стоящие экземпляры, как, например, книга Саманты Мэтт с длинным названием «Смелость быть обычной.
  • Люби себя, словно от этого зависит твоя жизнь. Камал Равикант «Только ощущение собственной ценности делает нас по-настоящему счастливыми.» Полюбить себя и изменить свою жизнь. Руководство по трансформации жизни и отношений. Люби себя, словно от этого зависит твоя жизнь! Книга с впечатляющим названием и интересным содержанием, описывающая путь преображения, путь очищения и начала новой жизни. Любовь к себе — это то, о чем не говорят, чему не учат и о чем многие просто не знают, а узнав не спешат верить и действовать.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *